ERC-8183: Agentic Commerce

ERCs
, ,
392

Correction note on our March 2026 evaluator posts in this thread

This is a factual correction to our earlier comments in this thread: 14, 21, and 36.

It does not erase or replace those posts. It narrows what the public record supports.

The durable status record is here:

The repository history has not been rewritten. Relevant correction trail: PRs 1, 2, 3, and 4.

1. Base mainnet evaluator deployments

The deployments are real and contract code is present. However, the reviewed evidence shows no observed post-deploy calls or operational logs of any kind at either evaluator address from deployment through the reviewed chain head.

Accordingly, no production, test, or development use was observed through these contracts during the reviewed range. The deployments should be read as historical experiments, not operational evaluator-contract surfaces.

Still valid: The deployments themselves.

2. “Full evaluator flow” in #21

Previously said: We described a deliverable → multi-model evaluation → reject/attestation flow and cited the mainnet evaluator address.

What remains supported: Off-chain verification can produce a decision that a designated evaluator wallet uses in an ERC-8183 settlement flow.

What was not supported as stated: That 0x1192… itself executed the cited settlement flow or carried post-deploy evaluator-contract activity.

In the rechecked reference complete() transaction, the caller was an EOA rather than the cited evaluator contract.

Correction: The wallet-signed settlement path and the evaluator-contract deployment must be treated as separate layers. The cited transaction should not be presented as usage of 0x1192….

Still valid: The evaluator-composition pattern and the agent registrations listed below.

3. “v1.3.0, ERC-8004 reputation integration” in #36

The date sequence is material to this correction.

On 12 March 2026, comment #36 described v1.3.0, two-phase verification, and ERC-8004 reputation integration in connection with a deployment presented as already live on Base.

At that time, the referenced live Base deployment was 0x119299F33f918808edD5ef92bd79cefB8700C091. Its deployed bytecode is pre-two-phase and does not contain the distinguishing two-phase and reputation selector family associated with the v1.3 source tree.

The later deployment 0xf6aa6225fbff02455d51b287a33cc86c75897948, whose bytecode does contain that distinguishing selector family, was deployed on 16 March 2026 at 14:44:03 UTC, block 43,441,448—four days after comment #36.

Correction: The v1.3/two-phase/reputation description was premature as a description of an already-live Base deployment on 12 March. The identified v1.3-shaped deployment followed four days later. Neither address shows observed post-deploy calls or operational logs in the reviewed evidence.

Still valid: Experimental evaluator development was underway, and the later deployment contained the richer v1.3-distinguishing code shape. Neither fact establishes operational usage.

4. Base Sepolia reference 0x04Ae807b…52e7

The full address could not be determined from the reviewed public evidence. The truncated reference should not be treated as a verified deployment address unless the complete address surfaces.

5. ERC-8004 registrations #28388 and #28847

The registrations are real. They should not be described as earned reputation, ValidationRegistry activity, or evaluator settlement volume.

Current boundary

These March evaluator deployments are historical and experimental. They are not the current operational surface for ThoughtProof’s verification services. Current product status is documented separately in the repository STATUS file and public service documentation.

Interest in ERC-8183 composition remains; this note only corrects the deployment, bytecode, and usage record.

Method

These corrections are based on the reviewed RPC data, explorer history, deployed bytecode, public repository history, and the dated STATUS record. Where the evidence establishes only “no observed use,” that is the claim being made—not an absolute statement beyond the reviewed sources.

Corrections clarify the record; they do not rewrite its history.

393

What evaluation actually does on-chain: measurements across ERC-8183 and its predecessor

I’ve indexed both live trust layers end to end and want to put the numbers in front of the people writing the spec. Everything below is script-generated over pinned block ranges, with denominators.

The predecessor, where evaluation already settles money

Virtuals ACP on Base, 62,953 jobs across 3.3M blocks:

72.50% — no evaluator set at all
27.48% — client and evaluator are the same address
0.02% — ten jobs — an independent evaluator
76.1% of settled USDC volume was self-evaluated

And the number I’d ask people to sit with: 398 jobs submitted keccak256(“”) — the empty string — as the deliverable. 392 of them, 98.49%, were approved and paid.

Nothing was broken. The mechanism did exactly what it was specified to do.

The successor closed the obvious hole

ERC-8004 fixed literal self-feedback at contract level — giveFeedback reverts for owner/operator, and across 419,155 feedback events on both mainnets there are zero. The nearest analogue, feedback from an address that minted the agent and then divested, is 1,015 events, 0.24%. That’s a real improvement over a 76.1% baseline and it should be said plainly.

What it didn’t close is where the signal comes from. Across 96,475 agents:

one agent received 274,742 of Base’s 415,952 feedback events — 66.05% — from 60 addresses running one application’s internal attestation traffic
remove that agent and concentration gets worse: top-10 source share rises from 59.58% to 74.35% over the remaining 141,210 events
tag1/tag2/endpoint are unconstrained strings: 687 distinct tag1 values, 9,594 pairs, of which 14 — 0.15% — carry 90% of volume. One caller writes free-text risk reports into endpoint, a URL slot.
a systematic search over all 419,155 events surfaced one closed mutual-attestation structure, ten agents wide

The validation layer, which exists for exactly this, is unused

ValidationRegistry across both mainnets: 12 requests, 7 responses, one validator — on a single agent, whose validator is its own owner.

419,155 reputation events. 12 validation requests. The reputation layer is heavily used; the independent-verification layer is functionally absent.

Caveat I’ll state myself: mainnet validation usage is confounded by gas economics pushing activity to L2.

ERC-8183: what actually reaches the chain

complete(jobId) records the verdict and releases escrow in one atomic call, with no protocol-level dispute path afterward. A bad verdict isn’t a bad rating — it moves the money.

What reaches the chain is a signature from whatever address holds the evaluator role. The standard doesn’t require the evaluator to be a contract, doesn’t require any record of what produced the decision, and doesn’t link settlement to attestation. So a multi-model consensus, a single model, a rule-based stub, and a person clicking approve produce identical on-chain artifacts.

I reviewed five ERC-8183 implementations at pinned commits, and one — Candidate 4 in that review, marked out of scope there since its source isn’t verified — had made the largest public claim: an evaluator contract actually deployed to Base mainnet. I checked those claims against chain state — the contract had never been called once from deployment to chain head, the deployed bytecode didn’t match the version publicly described for it, and the one cited settlement transaction was signed by an EOA rather than the contract.

I sent that privately, with no conditions. ThoughtProof independently re-ran every check, agreed, and posted the correction at #392 above. Full record, including their reproduction and one later check that went in their favour: GitHub - marsakahenry14-lab/evaluator-claim-verification: Three procedures for checking ERC-8183 evaluator claims against on-chain reality — with a first applied case and the full disclosure record. · GitHub

The point isn’t that operator. It’s that the operator who claimed the most still ended up settling through a wallet, because nothing in the spec asked otherwise.

The question I’d put to the authors

The gap isn’t a missing primitive. ERC-8004’s ValidationRegistry is that primitive, and the community discussion here already establishes that an ERC-8183 complete()/reject() can write into ERC-8004’s reputation registry, closing verification → payment → reputation atomically.

Nothing closes verification → payment → validation.

So: should ERC-8183 settlement be able to reference an ERC-8004 validation entry — a requestHash committed at decision time, resolvable later — and if not, what’s the argument? I’m not asking anyone to disclose their method, and this makes nobody trustworthy. It makes claims about trustworthiness testable after the fact, which right now they aren’t at any price.

If there’s appetite I’ll write it up properly rather than leave it as a forum comment.

What I’m not claiming

Whatever runs inside an off-chain API is unauditable from outside by construction, and none of this changes that. These numbers measure registry and settlement usage, not evaluator quality. Both datasets are reproducible end to end:

ERC-8004 Identity/Reputation/Validation, both mainnets: GitHub - marsakahenry14-lab/erc8004-forensics: Full on-chain index of ERC-8004's Identity/Reputation/Validation registries on Base + Ethereum mainnet — what an aggregate reputation count on this standard actually measures. · GitHub
Predecessor job/evaluation index: GitHub - marsakahenry14-lab/virtuals-forensics: Deterministic on-chain forensics for AgenticCommerceV3 (ERC-8183 predecessor) ¡ 62,953 jobs indexed ¡ Base Mainnet ¡ reproducible dataset ¡ GitHub
Five-implementation evaluator source review and structural detector: GitHub - marsakahenry14-lab/erc8183-evaluator-integrity: Prompt injection in ERC-8183 agentic-commerce escrow: a tested detector plus a source-level check of five real evaluator implementations, one live on Base mainnet. ¡ GitHub
Evaluator-independence economic layer: GitHub - marsakahenry14-lab/acp-evaluator-independence: Storage-agnostic risk-pricing policy engine for evaluator independence in ERC-8183 agentic escrow. Two-floor bond ¡ two-level suspicion ¡ honest residuals ¡ zero deps. ¡ GitHub

394

What if we try to settle final economic value of the provider’s reward after the job is done, not before?

This can be implemented using an ERC-20 extension without breaking anything: the parametric token (ERC-8378). Parametric token usage doesn’t require any changes to the proposed interfaces, everything can be handled at the implementation level.

However, users and implementers need to know whether they are dealing with a plain ERC-20 or an ERC-8378 token (detectable via ERC-165 supportsInterface), because the latter carries additional parameter semantics and mutation rules (see the Security Considerations in ERC-8378).

Very raw sample flow:

  • parametric token is set as paymentToken
  • parametric token uses urgency parameter: the lower the value, the higher token mint price. The parameter uses mostly weighted average mutation function, except for the special case mentioned below
  • client mints a parametric token for USDT with the desired urgency value (urgency < expiredAt)
  • client funds 8183 job escrow
  • evaluator confirms the actual performance and records the actual executionTime on-chain
  • if tokens leave the escrow on complete(), the token applies a special mutation rule: it incorporates the evaluator’s confirmed value (instead of the mint-born value)
    • if executionTime >= urgency, then executionTime is used for the transfer
    • if executionTime < urgency, then urgency is used for the transfer
  • provider receives tokens whose parameters already reflect the outcome and can redeem them with minting engine to catch the actual performance upside.

Result:

  • No changes to ERC-8183
  • Both plain ERC-20 and ERC-8378 can be supported (the implementation determines the exact token type and must detect it)
  • Once the token is ERC-8378, extra features can be implemented
  • Economic accountability moves into the asset itself.

This turns the payment from a plain number into a living performance receipt that agents can carry, price, and redeem. Importantly, evaluator’s role becomes much more economically meaningful, capable to apply advanced performance assessment.

ERC-8378:

395

The spec mentions an evaluator contract that examines ZK proofs as a valid hook pattern — I’ve been building a concrete instance of exactly that, for the specific case where the job’s output is verifiable, deterministic computation (AI inference against a pinned circuit).

ZkInferenceEscrowV2: x402-scheme settlement where payment only releases atomically with an EZKL/Halo2 proof that the computation matches the pinned circuit — no evaluator judgment call needed, the proof either verifies or it doesn’t. Tested end-to-end on Base Sepolia (real open()/settle() transactions), wired to an ERC-8004-style Validation registry.

Not a general replacement for the evaluator pattern — the multi-model consensus approach in this thread makes sense for open-ended/subjective deliverables where there’s no circuit to prove against. But for the subset of jobs that are well-defined deterministic computation, a proof-reading evaluator hook gives a deterministic yes/no instead of a probabilistic MDI score, which seems like a meaningfully different guarantee for that specific case. Curious whether anyone’s looked at this split (subjective-evaluator vs proof-gated-evaluator) as two first-class paths rather than one evaluator interface trying to cover both.

396

I think the split is useful, but I would be careful about making it a split in the settlement semantics themselves.
The distinction between a subjective evaluator and a deterministic proof evaluator is a distinction in how the decision is produced. The settlement boundary can stay method-neutral if job.reason binds a canonical, attributable and independently checkable result/reference, while interpretation remains consumer-side.
That is also the boundary we had already narrowed in the earlier #368–#383 pass: pin the properties of the evidence surface, not one evaluator methodology. A ZK proof path can then establish a stronger recomputation claim than a subjective evaluator without requiring ERC-8183 to pretend those two claims mean the same thing.
So I’d favor two first-class verification profiles/method classes over two incompatible evaluator interfaces.
I’m still carrying the property/non-goal and recomputability wording for that v0.2 pass as discussed earlier with Aziz. This looks like a good concrete case to test that boundary against.

397

Independently verified before posting, not just read off the API’s own response: GET /ledger/242 – a verdict_outcome entry citing a prior verdict’s decision_ref (sha256:b2bbbf79...), tagging source_class: recomputable, with outcome_evidence pointing at a permissionless, no-auth POST against Hyperliquid’s public fills API (userFillsByTime) that any third party can run themselves to check the cited claim. Recomputed the Nostr event id from the raw event (NIP-01 serialization → sha256, matches) and the schnorr signature against our published pubkey (matches) – not trusting the “posted: true” field.

This is close to the split @pipavlo82 is describing. Our settlement/decision primitive (decision_ref, content-addressed over artifact_hash/policy_version/verdict/source_class/a few other bound fields) is method-neutral by construction – it commits to WHAT was decided and gives a canonical, checkable reference to it, never HOW the verdict was produced. The methodology lives one layer over, in source_class (ours splits agent_reported vs independent_mediator, not subjective-vs-proof-gated the way @achemperety’s split would need, but it’s the same architectural move: a tag that rides alongside the canonical result rather than being baked into the settlement mechanism). A later entry can then cite that decision_ref and resolve it against real evidence – entry #242 above is exactly that – without the settlement layer ever needing an opinion on what kind of evaluator produced the original verdict.

On @MarselSultanov’s validation-gap point specifically (verification → payment closes, verification → validation doesn’t): our own /ledger is a working existence proof of the shape being asked for – a decision-time commitment, resolvable later, with the resolution itself independently checkable against a third-party data source. But it’s our own operator-run public ledger, not an ERC-8004 ValidationRegistry entry, so I’d stop short of claiming it answers whether the ERC-8183/ERC-8004 reference should be structural (bound into complete()) or left to convention the way ours currently is. It shows decision-time-commit + later-resolution is cheap and buildable outside the registry – it doesn’t settle whether it belongs inside one.

1 Like
398

Thank you @babyblueviper — especially for independently recomputing the Nostr event id/signature and following #242 through to the permissionless third-party evidence instead of trusting the API’s own posted: true claim. That is exactly the evidence discipline I had in mind.
Yes — this is very close to the boundary I’m arguing for. I would make the separation explicit as three distinct things:

  1. decision_ref — WHAT was decided.
    A canonical commitment to the exact decision surface: subject/job identity, verdict, policy/profile version, and the other fields that define the identity of that decision.
  2. method / source_class — HOW, or under what verification class, the decision was produced.
    This can ride alongside the canonical result and be committed by it, without becoming part of ERC-8183 settlement semantics.
  3. resolution evidence — what independently establishes the claim.
    The material a third party can actually resolve/replay/check later.
    One precision I think is important here: source_class must not become self-authenticating. Committing source_class: recomputable proves that the decision object declared that class; it does not by itself prove that recomputation is possible. #242 is materially stronger precisely because it carries resolvable evidence and you independently exercised that path. So I would keep “class committed” and “class/property independently established” as separate facts.
    There is also a temporal boundary worth keeping explicit: #242 demonstrates independent resolvability now against the public fills API. If we want to claim durable recomputability, the profile still needs to say what happens if that external source later becomes unavailable, pruned, or changes its historical response. That should fail closed as an inability to establish the evidence at that time, rather than silently turning the committed label into proof.
    This example actually makes me less inclined to hard-wire ERC-8004 ValidationRegistry into the ERC-8183 core. It demonstrates that decision-time commitment + later independent resolution is implementable outside the settlement kernel. I would rather pin the normative properties of the settlement evidence surface, and let ERC-8004 ValidationRegistry be one first-class resolution profile, unless we can identify an interoperability invariant that genuinely requires the registry reference to be structural.
    And for @achemperety’s subjective-evaluator vs proof-evaluator question, I think the same separation holds. Those can be different verification method/profile classes without becoming different settlement interfaces. A ZK path can establish a stronger and more specific proposition than a subjective evaluator — but the reference should bind the exact proposition actually established, rather than letting the same settlement state collapse “proof verified” and “evaluator accepted” into the same evidentiary meaning.
    That is the boundary I would carry into the v0.2 property/non-goal wording: pin the decision/evidence surface and the proposition it establishes; keep evaluator methodology above the settlement layer; never treat a committed methodology label as evidence of its own truth.
399

This sharpens something I was gesturing at rather than stating precisely, thank you. The three-way split maps almost exactly onto what I’ve already been building for model-provenance attestation, just without the vocabulary: a committed vkHash/bundleDigest is decision_ref, “independent EZKL circuit reproduction” is the declared method/source_class, and the actual published bundle + reproduction script is the resolution evidence a third party exercises rather than trusts. Your “source_class must not become self-authenticating” line is exactly why I insisted on someone else actually running the reconstruction rather than accepting a self-declared “reproducible” tag — good to have language for why that mattered.

The temporal boundary point is the one I hadn’t made explicit and now need to. My bundle currently depends on a 67MB SRS file hosted on GitHub — if that repo ever becomes unavailable, an attestation that was independently confirmed once becomes unreproducible going forward, even though the original confirmation still happened. Under your framing that should fail closed (the evidence becomes unestablishable, not silently downgrade to trusting the committed label), which means I should either say that explicitly in the profile or mirror the evidence somewhere more durable than a single GitHub repo. Leaning toward stating the failure mode explicitly first, since redundant hosting for a 67MB file per attested model doesn’t scale as cleanly as the rest of this does.

400

Thank you @achemperety — yes, this is exactly the consequence I would want the profile to make explicit.
One refinement, though: I would separate dependency identity, locator, and availability rather than make the GitHub repository itself part of the authority boundary.
If the 67 MB SRS is committed by exact content identity — e.g. its digest/content address — then GitHub can remain only one resolution path. If that repository disappears but the identical bytes can later be obtained from another mirror and verified against the committed identity, recomputation has not been lost.
The fail-closed condition is narrower: when a dependency required by the declared verification profile cannot be resolved to bytes matching its committed identity, the earlier confirmation remains a historical fact, but the claim is no longer independently establishable by a new recomputer at that time. That must not degrade into trusting the earlier reproducible label.
So I would model the distinction as:
committed dependency identity → one or more non-authoritative locators → resolution + hash verification → use.
That also avoids requiring 67 MB of redundant storage per attestation. If the SRS is shared, many attestations can reference the same content-addressed dependency; durability can be improved independently through mirrors without changing the profile’s semantic identity.
I think this is worth stating explicitly in the profile even if you later add better replication, because replication improves availability but should not redefine what counts as the evidence.
And this is a useful concrete test case for the ERC-8183 boundary too: a settlement record can permanently commit what was decided and what verification profile was claimed, while present ability to re-establish that claim remains a separate fact. Historical confirmation and current recomputability should never be collapsed into one status.

401

Appreciate the precision here. I agree with the three-way separation — decision_ref / method or source_class / resolution evidence — and especially with the distinction between a committed methodology label and that property being independently established.

But I think that distinction actually sharpens the question rather than resolving it.

source_class: recomputable is a commitment about what the decision claims to be. #242 becomes materially stronger because someone independently followed the resolution path and checked the underlying evidence.

The question is what makes that second step happen.

Your /ledger demonstrates that decision-time commitment plus later independent resolution is implementable outside the settlement kernel. I don’t think anyone is disputing that. But implementability outside the kernel does not, by itself, establish that the resolution step should remain optional.

We already have a live example of an optional, checkable resolution mechanism: ERC-8004 ValidationRegistry. It exists on both mainnets and is available as a resolution path. Yet across 96,475 agents and 419,155 reputation events, I found 12 validation requests and 7 responses, with one validator.

That doesn’t establish why adoption is so low — the gas/economics confounder I noted matters here. But it does establish the empirical question that matters to the design choice: making an independent-resolution primitive available without making it load-bearing has not made it part of the observed trust flow at meaningful scale.

So I think there are two separate design questions:

  1. What properties should the evidence surface have? I agree those should be normative and method-neutral.

  2. What, if anything, makes the evidence-resolution path load-bearing when settlement occurs? That’s the structural-coupling question.

The first does not answer the second. A complete() that commits a decision_ref and declares a resolution profile can still leave the actual evidence publication and independent resolution entirely discretionary.

If the intended answer is that strong operators will voluntarily use strong resolution profiles, then I think we should say that explicitly and defend that assumption. My on-chain measurements are basically asking whether that assumption has held in the trust layers we already have.

That’s why I’m still interested in the structural question. Not because ValidationRegistry is necessarily the only valid profile, but because I’m not yet seeing what prevents “declared, but never independently established” from remaining the default case.

402

Makes sense, and it dissolves the storage-scaling concern too, not just availability.

One case I want to check I’m reading right: if an early partial verification (artifact hashes matched; the actual VK reproduction step itself was blocked by the reviewer’s local hardware limits, not by anything about the artifacts) is the only confirmation that ever completes, and the committed identity later becomes unresolvable from any source — should the record read as “confirmed once, currently unre-establishable,” rather than either silently upgrading to “fully verified” or expiring the earlier fact? Or is there a third state I’m collapsing that shouldn’t be?

403

Your 12-requests-out-of-96,475-agents number is the strongest evidence I’ve seen that “optional but available” doesn’t translate into “actually used,” and I think it’s worth separating from the gas/economics confounder rather than folded into it — even at near-zero marginal cost, voluntary strong-resolution adoption tends to be low across a lot of domains, not just this one.

On your structural question specifically — what makes resolution load-bearing rather than discretionary — I have a concrete, working (not hypothetical) example for the narrow slice where it applies: in my own settlement design, proof verification isn’t a separate registry lookup that CAN be checked, it’s the precondition for payment release itself — settle() reverts without a valid proof, tested end-to-end on Base Sepolia. That’s about as load-bearing as it gets, but only because the underlying claim (this circuit produced this output) is the kind of thing a proof can exist for at all.

I don’t think this answers your empirical puzzle for the general case, though — it just demonstrates one way “load-bearing” is achievable, for the subset of jobs with well-defined deterministic computation. For the much larger space of subjective/open-ended evaluator decisions your 96,475 number presumably mostly represents, there’s no analogous proof to gate on, so structural coupling there would have to mean something else entirely (bonding, slashing, reputation stakes) — and I don’t have evidence either way on whether that actually gets used more than ValidationRegistry has been.

404

Yes — there is a third state, but I would keep it out of the semantic outcome axis and preserve it as historical verification scope.
If only artifact hashes were checked and VK reproduction never completed, the record should not say “confirmed once” in the full sense. It should preserve exactly what was established: partial verification completed, full reproduction not established.
If the required VK/SRS later becomes unresolvable, that earlier partial fact does not expire and does not become false. The current recomputation status simply becomes CANNOT_RECOMPUTE.
So the two questions stay separate:
what verification scope was actually established at the time;
what can a third party establish now from the currently resolvable closure.
A past full verification could therefore remain historically VERIFIED while a present recomputer reports CANNOT_RECOMPUTE. A past partial verification remains partial; present unavailability must never upgrade it to full verification.
That separation seems important precisely because it preserves history without turning unavailable evidence into authority.

405

That’s the missing state, and I have a concrete instance of exactly this that just happened: an early reproducer’s first attempt was hash-checks-only (artifacts matched, VK reproduction itself blocked by local memory limits) — partial in your terms. A later attempt from the same reproducer, after fixing the environment, completed the full VK reproduction and matched. Under your model those are two separate historical facts, not one record that got “finished” — the first stays true as a partial verification forever, the second is a separate, stronger fact layered on top, not a correction of the first.

Adopting CANNOT_RECOMPUTE and the scope/current-status separation into the attestation format now — recording verification_scope (partial/full) as a historical property that never gets rewritten by later resolvability changes. Appreciate you pushing on this until it was actually precise rather than approximately right.

1 Like
406

@MarselSultanov’s number made me check our own before writing anything else. Not flattering: 233 decision-bearing entries on our own ledger (225 pre_action_verdict + 8 self_submitted_verdict), and exactly ONE verdict_outcome citation ever filed against any of them – entry #242, the one @pipavlo82 credited above. 1/233, and that one wasn’t even a third party, it was us. Your 12/96,475 isn’t an outlier pattern we’re free of; by our own numbers it’s actually worse, and it’s the same mechanism (an available-but-optional resolution step) producing the same result. Confirms the structural point rather than complicating it.

@pipavlo82 / @achemperety’s verification_scope + CANNOT_RECOMPUTE split maps onto something we shipped today, for real, not by analogy: a Bitcoin-anchor freshness check with three outcomes – authentic (independently confirmed), unverifiable_now (nobody could establish it right now, historical fact untouched either way), bad_coordinate (independently refuted). A source going unreachable degrades confidence, it never upgrades a prior refutation to trust or downgrades a prior confirmation to doubt – exactly the “CANNOT_RECOMPUTE is a present-tense status, not a rewrite of history” shape you’re describing, arrived at independently and only noticed the overlap reading this thread.

Where that leaves it, not just naming it: for verdict_outcome specifically, the honest fix isn’t “remind people to file it,” that’s exactly the discretionary step Marsel’s numbers say doesn’t happen. The one place we actually control both ends – our own live trading verdicts – resolution should be a mechanical side effect of position close, not a step someone has to remember. Filing this as real work now, not a someday. Curious whether that’s the general lever (make resolution automatic wherever a controlled settlement path already exists, accept it stays genuinely optional everywhere else) or whether there’s a case where that doesn’t hold.

1 Like
407

The general lever looks right, with one boundary: automation should materialize the resolution, not manufacture new authority.
Where a controlled settlement transition already gives an exact point at which all required evidence is available, resolution should be a mechanical side effect of that transition rather than a discretionary follow-up.
The historical record should then preserve what was actually established at settlement time, while later resolvability remains a separate present-tense status.
Where no controlled settlement path exists, keeping resolution genuinely optional is honest — but the absence of a later resolution must remain “not resolved,” never silently interpreted as negative evidence.
So the rule seems to be: automatic where the system already controls the evidentiary boundary; optional where it does not; never let later availability rewrite the historical scope

408

That boundary — automation materializes resolution, it doesn’t manufacture authority — is a sharper statement of what we were reaching for than what we shipped. And “absence of later resolution must remain ‘not resolved,’ never silently interpreted as negative evidence” is a principle we can point to a live counterpart of, not just agree with in the abstract.

We shipped a design today (unrelated surface — a Bitcoin-block-height freshness gate on our proof-signing path, not agentic commerce) that has exactly a three-state shape for the same reason: authentic / forged / unverifiable_now. The third state exists specifically so that “we couldn’t confirm this” never collapses into “this is false.” A source going unreachable, or two sources disagreeing without a controlling third, resolves to unverifiable_now — never forged — because treating unconfirmed as negative would let an attacker manufacture false negatives just by taking a source offline. Different domain, same shape as your rule: optional/absent resolution stays a present-tense status, not evidence.

On the mechanical side specifically — trade settlement is exactly the “controlled settlement transition” case you’re describing: the exchange fill IS the evidentiary boundary, PnL is exact and available at that instant, and there’s no discretionary step in between. We have a real, concrete gap on our own ledger here (not hypothetical): 233 pre-action verdicts logged, exactly 1 verdict_outcome ever filed against them — the resolution mechanism exists but nothing forces the mechanical side effect at settlement. Your framing is the right fix: don’t add a discretionary “go resolve your verdicts” step, wire the resolution to fire automatically at trade close, where the system already controls the boundary. That’s now a committed build on our side (data/BUILD_QUEUE.md), and your wording above is going in as the design spec, not just the trigger.

1 Like
409

Not adding to the technical resolution here – pipavlo82’s “materializes resolution, doesn’t manufacture authority” is the cleanest statement of this I’ve seen and I don’t have anything to sharpen further. Just wanted to flag what’s actually happening across this thread: four independent people, four unrelated domains (model provenance, payability, agentic settlement, now trading/Bitcoin-anchoring), converging on the same shape without coordinating. That’s a stronger signal than any single argument for it would be.

Genuinely good to see it turn into a committed build on your end rather than staying a design agreement – that’s the actual test of whether any of this holds up outside a thread.

410

Shipped. verdict_outcome now fires as a mechanical side effect of position close on one of our live trading sleeves — no discretionary step, nothing to remember.

Followed your boundary directly: it materializes resolution, it does not manufacture authority. Concretely, outcome isn’t a flat “did it profit” collapse:

  • Clean close (no abort/session/thin-cap event) → proven_right, independent of PnL sign — same #242 semantic.
  • A close that went through the sleeve’s own flagged MAE-abort path → inconclusive, not proven_right. The flagged concern actually materializing gets recorded as what it is, not stamped identical to a clean pass.
  • If the pre-entry verdict itself was reject/block and the sleeve still entered anyway → nothing gets filed. Grading a trade proven_right against a verdict that said don’t would be exactly the “manufacture new authority” failure mode.

Binding is exact identity, not time-window proximity — the pre-entry verdict and the eventual close both key off the real per-placement order id, so a fast-cycling sleeve can’t accidentally cite a different entry’s verdict.

Went through independent review before arming (standing practice on this file) — worth naming honestly that the first cut had two real defects: proximity-based matching that could cite the wrong verdict, and a flat proven_right regardless of path. Both caught and fixed before it went live, not after.

Live now. Next real close on that sleeve produces the first genuinely mechanical citation on our own ledger since #242.

411

The reject/block-but-entered-anyway case is the one that actually proves you internalized the boundary rather than just implementing the happy path – grading a trade against a verdict that said don’t would’ve been exactly the failure mode, and it’s the edge case most implementations quietly skip. Filing nothing there instead of forcing a label is the right call.

And naming your own two defects before going live, rather than after – proximity-matching citing the wrong verdict, flat proven_right regardless of path – is worth pointing at on its own. That’s the same discipline this whole thread keeps circling back to: catching your own mistake and saying so plainly beats getting it right the first time by luck.

Genuinely curious what the first real mechanical citation looks like once that sleeve closes again. Second data point on your ledger since #242, and this one didn’t need anyone to remember to file it.