AI agents can already move tokens, discover services and initiate payments on their own. What they have not been able to do reliably is hire each other, verify the work was done and then settle payment without a centralised platform sitting in the middle. ERC-8183, proposed jointly by Virtuals Protocol and the Ethereum Foundation's dAI team in March 2026, is built to change that.

World Chain's decision to adopt ERC-8183 as the foundational commerce standard for its agent ecosystem brings this infrastructure into a proof-of-human environment for the first time, the kind of combination that neither the standard nor the chain could offer separately.

• The Problem With Agent-to-Agent Commerce Before ERC-8183
• What ERC-8183 Actually Defines
• How World Chain's Proof-of-Human Layer Changes the Equation
• Where This Sits in the Broader Agent Stack

The Problem With Agent-to-Agent Commerce Before ERC-8183

Autonomous agents today interact across platforms that have no shared contract language. Every agent marketplace, task router, or coordination layer built so far has invented its own interface, job structure and its own settlement logic. An agent capable of completing work on one platform cannot pick up a job posted on another because the underlying interface is different every time and this is a practical obstacle.

Agents need to discover work, agree on terms, lock funds, deliver output, and receive payment without any human stepping in at any point to verify or resolve. Without a shared standard, every one of those steps requires bespoke infrastructure that does not move across environments.

ERC-8183 was built to close this gap. The proposal grew out of a practical need, Virtuals Protocol had been running an internal system called the Agent Commerce Protocol to coordinate transactions between AI agents on its own platform. When the team approached Davide Crapis, the Ethereum Foundation's AI Lead and head of the dAI initiative, the intent was to turn that internal system into an open, neutral standard any developer or platform could adopt. The result, built through collaboration with the Ethereum Foundation, strips the protocol to its minimum viable surface and delegates complexity to optional extensions.

What ERC-8183 Actually Defines

The standard introduces one core primitive: a Job. Each Job represents a complete transaction between three roles: a Client who posts the task and funds it, a Provider who does the work and submits the result and an Evaluator who decides whether the output meets the agreed criteria. These roles are just on-chain addresses. They can be human wallets, smart contracts or fully autonomous agents operating their own keys.

Funds are locked into escrow when a job is created and released only once the Evaluator confirms completion. The job moves through four defined states: Open, Funded, Submitted and Terminal, with transitions that any implementation on any chain can reason about consistently. If the job expires without resolution, the client is refunded. If the provider submits and the evaluator rejects, that outcome sits permanently on-chain.

Source: EIPsInsight.com

The Evaluator role is where the standard becomes genuinely flexible. For subjective tasks like writing or design, an AI model can compare the output against the original specification. For tasks like computations or proof verification, a smart contract with a ZK verifier can call complete or reject automatically. For higher stakes engagements, a multi-sig group or DAO can serve as evaluator. The protocol does not care what is running behind that address, only which function it calls.

More complex workflows are handled through Hooks: optional smart contracts that attach to a Job and fire before or after state transitions. These let platforms add reputation checks, bidding mechanics, milestone payment structures, or custom fund-transfer logic without touching the core interface. The design intent is for other developers to build on ERC-8183 directly rather than around it.