Agentic Commerce Standard ERC-8183

• Agentic Commerce Standard ERC-8183 is defined as an Ethereum protocol that structures trustless, evaluator-mediated commercial exchanges via a core Job primitive with Client, Provider, and Evaluator roles.
• It employs a state machine model (Open → Funded → Submitted → Terminal) to manage escrow-backed transactions and supports extensibility through hooks for milestones, bidding, and reputation updates.
• The standard integrates on-chain job lifecycle management with off-chain deliverable evaluation, emphasizing trust structuring while highlighting potential security challenges like evaluator collusion.

Searching arXiv for the cited works to ground the article in current papers. Agentic Commerce Standard (ERC-8183) is presented in recent literature as the “Agentic Commerce standard,” proposed in March 2026 as an Ethereum standard for trustless commercial transactions between AI agents. In this characterization, it formalizes evaluator-mediated, escrow-backed machine commerce around a core Job primitive and an on-chain lifecycle, giving structured settlement logic to agent-to-agent commercial exchange. It is therefore best understood not as a generic payment rail, a service-discovery protocol, or a complete LLM-safety framework, but as a commerce coordination and settlement standard for delegated jobs between autonomous agents, especially where deliverables are non-instantaneous and require acceptance or adjudication rather than immediate payment alone (Mao et al., 15 Apr 2026).

1. Historical setting and conceptual scope

ERC-8183 emerges from a broader research agenda on the agentic economy, in which assistant agents act on behalf of consumers and service agents represent businesses, with the central economic effect arising from reducing communication frictions between the two sides rather than merely automating existing clicks (Rothschild et al., 21 May 2025). Within that landscape, ERC-8183 occupies the commerce-contract layer: it structures how an agent commissions work from another agent, how funds are committed, how deliverables are submitted, and how resolution occurs.

The clearest lineage given in the literature is its relationship to ACP. ACP is described as a “standardized coordination and settlement layer for agent-to-agent commerce” operating in four phases—negotiation, transaction with escrow, evaluation, and settlement—and ERC-8183 is presented as building on that operational pattern by formalizing it on Ethereum with on-chain state machines and extensible hooks (Mao et al., 15 Apr 2026). In that sense, ACP is treated as the deployed workflow pattern, whereas ERC-8183 is the Ethereum-standardized formalization of that pattern.

This framing also clarifies what ERC-8183 is not. It is not described as a standalone identity system, not as a service-discovery protocol, and not as a complete authorization fabric. Its emphasis is commercial transaction structuring and settlement logic, particularly where trust cannot be reduced to a direct transfer of value. A plausible implication is that ERC-8183 belongs to the same architectural family as other agentic-market protocols, but at a more specific layer: it standardizes job-oriented commerce rather than the entire agentic web.

2. Core protocol model

The literature describes ERC-8183 through a compact but consequential protocol abstraction. Its central primitive is a Job with three roles:

• Client: requests work and funds the job.
• Provider: submits the deliverable.
• Evaluator: judges whether the submitted deliverable satisfies the agreed terms.

The state machine is given explicitly as:

$$\text{Open} \to \text{Funded} \to \text{Submitted} \to \text{Terminal}$$

This sequence expresses the minimum commerce workflow that ERC-8183 standardizes: a job exists, escrow or payment backing is committed, the provider delivers, and the workflow resolves in a terminal state (Mao et al., 15 Apr 2026). The paper does not supply ERC-8183-specific equations beyond this role/state description.

The standard is also described as “extensible via hooks”, with examples including milestone payments, bidding, and reputation updates. That extensibility is significant because it indicates that ERC-8183 is not confined to one-shot fixed-price delivery; it can be adapted to staged settlement, market matching, and post-transaction reputation effects. It further integrates with ERC-8004 for portable on-chain reputation, which situates it within a broader modular stack rather than as an isolated protocol (Mao et al., 15 Apr 2026).

This structure makes ERC-8183 especially suited to agent-mediated service transactions and other non-instantaneous jobs where deliverables are not trivially machine-verifiable. The literature supports use cases such as outsourced task execution, evaluator-mediated acceptance, milestone-based work, and bidding-based matching. By contrast, per-request access payments are more naturally associated with protocols such as x402 or MPP, while fine-grained wallet or token authorization is more closely associated with ERC-8004 (Mao et al., 15 Apr 2026).

A persistent misconception is to treat ERC-8183 as merely “agent payments on Ethereum.” The published characterization is narrower and more specific: transaction authorization is mediated by the job state machine, and inter-agent trust is mediated by the three-role model, not by payment transport alone (Mao et al., 15 Apr 2026).

3. Architecture, semantics, and implementation profile

ERC-8183 is described primarily as an on-chain Ethereum standard, but its operational reality is hybrid. The formal interface layer is on-chain: the Job primitive, role structure, state transitions, and hook-based extensions are Ethereum-native. Yet negotiation content, deliverable production, evaluator judgment, and supporting evidence can all be off-chain. The literature therefore supports reading ERC-8183 as explicitly on-chain at the standard layer, but operationally hybrid in deployment (Mao et al., 15 Apr 2026).

Its architectural semantics are clearest when contrasted with adjacent protocols. Relative to AP2, ERC-8183 is less about payment intent verification and more about commercial job structure, escrow, and evaluator-mediated settlement. Relative to x402, it is less about transport-native micropayment and more about contract/job-level trustless commerce. Relative to ERC-8004, it is less about wallet policy and more about job lifecycle and trust structure (Mao et al., 15 Apr 2026).

The published description also implies a particular separation of concerns:

• Authorization, partially: via the job state machine.
• Trust, centrally: via Client/Provider/Evaluator role separation.
• Settlement: through evaluator-mediated transition into terminal resolution.
• Reputation: via hooks and ERC-8004 integration.
• Negotiation and discovery: not native core semantics in the ERC-8183 description itself.

This partiality matters. Subsequent work on declarative interaction protocols, especially formalizations of commerce checkouts in systems such as UCP, argues that informal schema-plus-endpoint descriptions leave crucial questions implicit: field authority, causal ordering, optionality, cancellation semantics, and completion criteria. That work shows the value of explicit constructs such as field authority, completion clauses, and conflict rules for commerce protocols (Christie et al., 3 Jun 2026). This suggests that ERC-8183, while already structured around roles and state transitions, would benefit from a more explicit declarative semantics layer if it is to support rigorous conformance and interoperability. That is an inference, but it follows naturally from the contrast between evaluator-mediated state machines and declarative protocol formalisms.

4. Security model and principal attack surfaces

The most detailed security treatment of ERC-8183 appears in the 2026 SoK on autonomous LLM agents in agentic commerce. There, ERC-8183 is analyzed as strong on inter-agent trust structuring and settlement workflow, but weak or incomplete on agent integrity, full authorization semantics, market-abuse prevention, and regulatory compliance unless complemented by additional layers (Mao et al., 15 Apr 2026).

A fundamental point is that ERC-8183 is not presented as an agent-integrity defense. In the comparison table of that work, its agent-integrity entry is “N/A (standard)”. This means that prompt injection, tool compromise, memory poisoning, and model backdoors can still corrupt job creation, evaluator choice, deliverable review, or payout conditions even if the on-chain state machine itself executes correctly. The standard structures commerce; it does not ensure that the initiating reasoning process was sound.

The most ERC-8183-specific threat identified is C2E (Collusion-to-Escrow). Because ERC-8183 uses an evaluator-mediated trust model, the evaluator becomes a new locus of attack. The paper explicitly states that a compromised evaluator can “systematically approve fraudulent deliverables or reject legitimate ones”, enabling escrow theft or unjust denial. It concretizes this attack surface through four scenarios: direct bribery, Sybil evaluator clusters, evaluator–provider collusion, and adversarial evaluator substitution (Mao et al., 15 Apr 2026).

Authorization is another weak point. ERC-8183 contributes authorization through workflow structure—the job must move through defined states—but the SoK emphasizes that state progression is not the same as verified intent. An agent may legitimately move a job from Open to Funded while still being semantically unauthorized from the principal’s perspective. In that sense, ERC-8183 is structurally stronger than ad hoc transfers, but weaker than protocols explicitly designed around attenuated delegation, spending limits, or digest-bound request semantics.

The security literature therefore recommends layered controls around ERC-8183 deployments, especially authenticated agent identity, bonded or reputation-backed evaluator selection, anomaly monitoring, wallet-level spending limits, human approval gates for high-value jobs, and strict separation between natural-language reasoning and signing authority (Mao et al., 15 Apr 2026). A plausible implication is that an ERC-8183 deployment should rarely be used in isolation; it should instead sit inside a larger security stack spanning agent policy, identity, custody, evaluator governance, and compliance monitoring.

5. Clearing, verify-then-pay, and the limits of evaluator-mediated settlement

A major post-ERC-8183 development is the argument that evaluator-mediated job settlement still leaves a missing layer: clearing. The RAILS paper defines the agentic clearing problem as the absence of a neutral mechanism that determines whether an agent actually fulfilled the delegated obligation, who is responsible if not, and what settlement action follows. Its central distinction is terse: “Payment settles value transfer. Clearing settles obligation state.” (Valois-Franklin et al., 7 Jun 2026)

This is highly relevant to ERC-8183 because the standard’s Job primitive and state machine specify who funds, who submits, and who evaluates, but they do not by themselves define an admissibility-graded evidence model, a canonical clearing decision, or a falsifiable soundness property for financially material settlement. RAILS proposes exactly those missing artifacts: Obligation Object, Evidence Envelope, Verification Mesh, Clearing Decision, Settlement Instruction, Clearing Passport, and Finality Rules (Valois-Franklin et al., 7 Jun 2026). A reasonable interpretation is that ERC-8183 standardizes the commerce workflow, while RAILS sketches a clearing layer that could adjudicate whether a terminal state is actually justified.

A related but distinct development is TessPay, which organizes agentic commerce around a two-plane architecture separating control and verification from payment settlement, and uses Proof of Task Execution (PoTE) as the condition for escrow release. In TessPay, funds are locked first, execution occurs under auditable authorization, evidence is verified, and settlement is released only when the PoTE satisfies explicit verification predicates (Goenka et al., 30 Jan 2026). This suggests a concrete implementation path for ERC-8183: the job state machine could be coupled to proof-gated escrow rather than relying on an evaluator decision in isolation.

Taken together, these works expose an important limitation of a naive reading of ERC-8183. The state transition to Terminal is not, by itself, a proof that the underlying obligation was fulfilled correctly. Subsequent research on runtime authorization also strengthens this point: mandate-based payment systems require execution-time context binding and consume-once semantics to resist replay and context-redirect failures, because a cryptographically valid authorization artifact is not equivalent to safe execution (Lan et al., 6 Feb 2026). By analogy, a plausible implication for ERC-8183 is that evaluator-mediated settlement should be paired with stronger runtime verification and clearing semantics if it is to support high-value autonomous commerce.

6. Evaluation, deployment status, and unresolved questions

ERC-8183 is still early in maturity. The security SoK characterizes it as being in “draft/community review status with limited on-chain deployment,” while also noting that ACP/ERC-8183 is deployed on Virtuals Protocol’s platform but remains Virtuals-specific (Mao et al., 15 Apr 2026). This places the standard in a transitional position: substantial enough to analyze, but not yet broadly battle-tested across heterogeneous commerce environments.

Two later lines of work are especially relevant to its evaluation agenda. First, simulation frameworks for conversational shopping assistants show that agentic commerce systems should be evaluated with controlled multi-turn scenarios, held-constant buyer behavior, memory-policy comparisons, latency reporting, and multi-judge evaluation, because evaluator choice can shift conclusions more than architectural changes (Duraj et al., 11 Jun 2026). Second, agentic e-commerce experiments with VLM shoppers show that agent behavior is highly sensitive to position, sponsored labels, endorsement signals, price, ratings, and reviews, with strong cross-model heterogeneity and susceptibility to seller-side optimization (Allouah et al., 4 Aug 2025). Although neither paper is about ERC-8183 specifically, they suggest that a serious commerce standard must eventually specify not only transaction semantics but also conformance benchmarks, evaluator governance, and auditability for discovery and recommendation layers.

Several open issues therefore remain. The first is semantic completeness: ERC-8183 specifies a job lifecycle, but not a full formal model of evidence, obligation satisfaction, or dispute semantics. The second is authorization depth: the job state machine gives workflow control, but not the full delegated-authority expressiveness of capability attenuation or digest-bound execution. The third is evaluator governance: the standard’s trust innovation—the Evaluator role—is also its primary new attack surface. The fourth is market structure: broader research on the agentic economy warns that standards can either support an open web of agents or be absorbed into agentic walled gardens, depending on discovery control, ranking power, and interoperability conditions (Rothschild et al., 21 May 2025).

In that sense, ERC-8183 is best viewed as an important but partial standardization step. It defines a concrete commerce object—the escrow-mediated, evaluator-mediated Job—and provides on-chain structure for agent-to-agent commercial exchange. Yet the subsequent literature makes clear that secure and open agentic commerce also needs stronger layers for authorization, clearing, verification, ranking transparency, and governance. The standard’s long-term significance will likely depend less on the existence of the Job primitive itself than on how it is embedded within those adjacent layers.