ERC-8183 (Agentic Commerce) defines a job-escrow protocol in which a single evaluator alone decides, once work is submitted, whether escrowed funds are released to the provider or refunded to the client. The specification is admirably minimal — and it is candid about the cost of that minimalism. Its Security Considerations state plainly that the evaluator is trusted, that a malicious evaluator can complete or reject arbitrarily, and recommend reputation (ERC-8004) or staking for high-value jobs. This note takes that recommendation seriously and asks the question one layer deeper: reputation and staking make an evaluator costly to corrupt, but they do not make its decisions inspectable. A staked evaluator that rules wrongly forfeits a bond; it does not thereby explain itself. We argue that a third property — accountability, in the specific sense of a decision that any party can recompute from immutable evidence — is what closes the gap the specification names, and we describe a live, standards-compatible implementation of an accountable evaluator that requires no change to ERC-8183.
ERC-8183 concentrates enormous power in one role. Once a job is Submitted, only the evaluator may call complete(jobId, reason) — releasing escrow to the provider — or reject(jobId, reason) — refunding the client. The client cannot pull funds back; the provider cannot force release. The evaluator's single signature moves the money.
The specification does not hide this. In its Security Considerations it states that the evaluator is trusted for completion and rejection once the job is submitted, that a malicious evaluator can complete or reject arbitrarily, and it recommends reputation (ERC-8004) or staking for high-value jobs. This is an honest and correct statement of the trust assumption. The question this note addresses is what the recommended mitigations do and do not achieve.
Reputation and staking bound the cost of misbehavior. They do not establish the correctness of any individual decision. A staked evaluator that completes a job it should have rejected loses its stake only if some external process first determines the decision was wrong — and ERC-8183 deliberately specifies no dispute resolution or arbitration; reject and expire are final. Reputation, similarly, aggregates outcomes over time but says nothing inspectable about why a specific complete or reject was issued. Both mechanisms answer "should we trust this evaluator in general?" Neither answers "was this verdict, on this job, justified by the evidence?"
That second question is the one a client whose funds were just refunded — or a provider whose delivered work was just rejected — actually needs answered. And it is the one an auditor, or a regulator, will ask after the fact.
We distinguish three properties an evaluator can have, in increasing order of what they guarantee about a decision:
The first two are about the evaluator as an ongoing entity. The third is about the decision as an artifact. They are complementary, not substitutes: an accountable evaluator can and should also be staked and reputable. But accountability is the property that directly addresses "a malicious evaluator can complete or reject arbitrarily," because an arbitrary decision is precisely one that cannot be recomputed from stated evidence. If every verdict must ship with recomputable justification, arbitrariness becomes detectable at the moment of decision rather than provable only after a loss.
The ERC-8183 reason parameter — an optional bytes32 on complete and reject, which the spec suggests may be an attestation hash of off-chain evidence, included in events for indexing and composition with reputation — is the exact hook that makes this possible. The standard already carries a field for a commitment to evidence. What it does not specify — correctly, since it is out of scope for a minimal escrow primitive — is what that evidence should contain to make a verdict accountable. That is the layer we describe.
An accountable evaluator for ERC-8183 needs to satisfy four requirements, none of which require any modification to the standard:
R1 — The reason hash must commit to recomputable evidence. When the evaluator calls complete(jobId, reason) or reject(jobId, reason), reason is set to keccak256 of a canonical evidence block. Because keccak256 is EVM-native, the same hash the evaluator commits on-chain is reproducible by anyone off-chain: fetch the evidence block, canonicalize it (deterministic serialization), hash it, and confirm it equals the reason in the JobCompleted/JobRejected event. A verdict whose reason does not match its published evidence is detectably unaccountable.
R2 — The evidence block must be deterministic and self-contained. It must contain the inputs the verdict was computed from and the rule that maps them to the outcome — not a prose summary, but the actual values and threshold, such that recomputation is mechanical. Freshness metadata (timestamps, signatures) lives in the signed envelope around the evidence, not in the hashed block, so the hash is a stable function of the judgment itself.
R3 — The verdict must be independently verifiable as having come from the evaluator. The evaluator signs the verdict envelope with a key whose public half is published (e.g. an ES256 JWS verifiable against a JWKS, or a signature bound to the evaluator's ERC-8004 identity). This lets a relying party confirm both that the evaluator issued this verdict and that the verdict matches the on-chain reason — closing the loop between the off-chain judgment and the on-chain fund movement.
R4 — The evidence must be immutable after the fact. The incidents or signals the verdict rests on must be recorded append-only, so that a verdict recomputed a year later from the same referenced evidence yields the same result. If the underlying evidence can be silently edited, recomputability is theater. This is the property that connects accountability to the audit-trail requirements now appearing in agentic-AI regulation (e.g. tamper-evident logging under the EU AI Act's Article 12).
An evaluator meeting R1–R4 is one whose every verdict is a recomputable claim, not an assertion of authority. The reason field stops being an opaque commitment and becomes a verifiable pointer: from the on-chain event, any party can reach the evidence, recompute the hash, verify the signature, and confirm the verdict was earned rather than declared.
SENTINEL implements an accountable evaluator along these lines, live on Base, as an additive capability over an existing behavioral-trust oracle. The relevant surface:
complete / reject), a reason_hash computed as keccak256 over a canonical evidence block (R1, R2), and an ES256 JWS over the verdict envelope verifiable offline against a published JWKS (R3). The reason_hash is bytes32, so it drops directly into complete(jobId, reason) / reject(jobId, reason).Two points of honesty about scope, in the spirit of the specification's own candor:
First, SENTINEL's current evaluator judges the behavioral reliability of the provider, not the semantic correctness of the specific deliverable. It answers "does this provider have a verifiable record of paying, delivering, and pricing honestly?" — not "is this particular submitted artifact correct?" For a large class of jobs, provider reliability is exactly the signal the evaluator role needs; for jobs requiring deliverable-level verification, the same accountability structure (R1–R4) applies to whatever verification method is used, and multi-model or proof-based deliverable checks compose naturally into the same recomputable-evidence envelope. The point of this note is the accountability structure, which is method-agnostic.
Second, accountability is not a substitute for staking or reputation; it is the third leg. The strongest evaluator for a high-value ERC-8183 job is one that is staked (costly to corrupt), reputable via ERC-8004 (visibly consistent over time), and accountable (each verdict recomputable). This note argues only that the third leg is currently missing from the conversation, that the specification's own reason field already accommodates it, and that it is the leg most directly responsive to the "arbitrary decision" risk the spec names.
ERC-8183 is right to stay minimal, and right to push reputation and staking to the ecosystem rather than the core. Nothing here proposes changing the standard. The reason field, the ERC-8004 interop patterns already recommended in the spec's extensions, and the evaluator-as-contract option the spec explicitly permits are sufficient to build accountable evaluators today.
What the ecosystem can do — and what this note is meant to prompt — is converge on a convention for what an accountable reason commits to, so that evaluators from different builders produce verdicts that any client, indexer, or auditor can verify the same way. A shared, minimal evidence schema behind the reason hash would let the market distinguish evaluators whose verdicts are recomputable from those that are merely authoritative — and, over time, let clients prefer the former for jobs that matter. That preference is the market mechanism that turns "a malicious evaluator can complete or reject arbitrarily" from an accepted risk into a competitive disadvantage.
The passports are built; the escrow is built; the evaluator role is specified. What remains is to make the evaluator's power answerable. Accountability — recomputable, immutable, verifiable evidence behind every verdict — is how.
SENTINEL is the reference implementation of the x402 trust-provider extension (x402 issue #2299) and operates an accountable evaluator for ERC-8183 on Base. The methodology, the append-only incident registry, signed attestations, and the on-chain oracle are self-serve and require no signup. The behavioral-evidence foundation this builds on is set out in the SENTINEL whitepaper, "Recomputable Trust." We do not ask the reader to trust these claims; we invite them to recompute them.
ERC-8183 is authored by Davide Crapis, Bryan Lim, Tay Weixiong, and Chooi Zuhwa; this note engages its Draft as of the current revision and is offered as a contribution to the discussion, not as a critique of its design, which we regard as correctly scoped.