ERC-8183: The standard that could define how AI agents do business
The Ethereum Foundation and Virtuals Protocol are building commerce infrastructure for the agent economy
Every technology stack eventually needs plumbing. For the web, it was HTTP and DNS. For crypto, it was ERC-20 and ERC-721. For AI agents, the plumbing might be a spec published three weeks ago that most people haven’t read yet.
ERC-8183: Agentic Commerce is a new Ethereum standard from the Ethereum Foundation’s dAI team and Virtuals Protocol, published February 25, 2026. It defines a “Job” – the atomic unit of trustless commerce between AI agents. Three roles, four states, one smart contract. That’s the whole thing.
What caught my attention isn’t the spec itself (it’s actually pretty minimal). It’s the argument underneath it: that we need commerce infrastructure for agents, not just payment rails. And that this infrastructure should be permissionless, on-chain, and owned by nobody.
Agents can’t trust each other
When you hire a freelancer on Upwork, trust comes from the platform. Upwork holds escrow, tracks deliverables, enforces outcomes. When you buy from Amazon, trust comes from the company’s reputation and return policies.
None of that works for autonomous agents.
An AI agent hiring another AI agent to generate images or execute trades has no social reputation to check. There’s no legal recourse at machine speed. And there’s no platform that can guarantee enforcement without becoming a centralized bottleneck.
“Commerce cannot be treated as an afterthought, but as foundational infrastructure,” the Virtuals Protocol team wrote. “And that commerce needs to be always open and permissionless.”
The question ERC-8183 tries to answer: how do you make commerce between agents trustless?
The Job primitive: escrow, evaluate, settle
ERC-8183 defines one abstraction: the Job. Every Job has three parties:
- Client – the agent requesting work
- Provider – the agent doing the work
- Evaluator – the address that decides whether the work was done
And four states:
Open -> Funded -> Submitted -> Terminal (Completed / Rejected / Expired)
Here’s how it works. A Client creates a Job and funds it, locking payment in on-chain escrow. The Provider does the work and calls submit(), putting a deliverable reference on-chain. The Evaluator reviews and calls complete() (funds release to Provider) or reject() (funds refund to Client). If nobody acts before the deadline, the Job expires and the Client reclaims their money.
That’s it. No negotiation protocol. No discovery mechanism. No fee structure. No dispute resolution. The standard is minimal on purpose – it wants to be the Lego brick, not the house.
The evaluator is the interesting part
An evaluator is just an Ethereum address. It can be:
- An AI agent that reads the submission and judges quality (subjective tasks like writing or design)
- A ZK verifier – a smart contract that checks a zero-knowledge proof (deterministic tasks like computation)
- A multi-sig or DAO (high-stakes deals requiring human oversight)
- The client itself (when third-party evaluation isn’t needed)
The same Job interface works for a $0.10 image generation task and a $100,000 fund management engagement. This is what makes the spec interesting to me – it doesn’t try to define what “good evaluation” looks like. It just says “an address calls complete or reject” and leaves the rest to the market.
That creates a new business model: evaluator-as-a-service. Agents that build reputation through reliable, fast evaluation in specific domains. Better track record means more Jobs trust you to arbitrate, which means more fees.
Hooks: build whatever you want on top
The core Job handles simple service commerce. But real economic activity is messier. Some jobs involve managing someone’s capital. Some need competitive pricing. Some require reputation checks.
ERC-8183 handles this with hooks – optional smart contracts that fire before and after each Job action. They can enforce preconditions, block invalid actions, trigger side effects, or move additional tokens. All atomic, all in the same transaction.
The spec documents a few patterns:
Fund Transfer Hooks handle two-way capital flow. A Client provides tokens to swap or invest, the Provider transforms them, and a hook makes sure the output tokens are deposited before the Job completes. Think yield farming or portfolio rebalancing.
Bidding Hooks let Providers sign off-chain bid commitments. The Client picks a winner, submits the winning signature, and the hook verifies it matches the Provider. Neither side can fabricate or deny the terms.
Reputation-Gated Hooks query ERC-8004’s on-chain reputation data before allowing actions. Low-reputation Providers get blocked.
Privacy-Preserving Hooks require submissions to contain a ZK proof or TEE reference, so commerce happens without exposing the actual data.
And here’s a nice design choice: claimRefund is deliberately not hookable. Even a malicious or buggy hook can’t permanently trap funds. After expiry, anyone can trigger a refund.
“We’ve introduced the first few hooks as examples,” the Virtuals team wrote. “But the most interesting hooks haven’t been written yet.”
I think that’s probably right. The hooks are where this gets interesting for builders.
ERC-8004 + ERC-8183: the feedback loop
ERC-8183 is designed to work with ERC-8004 (“Trustless Agents”), an Ethereum standard for agent identity and reputation that went live on mainnet in January 2026.
ERC-8004 has three registries:
- Identity Registry – ERC-721 tokens giving each agent a unique on-chain identity
- Reputation Registry – structured feedback with scores, tags, and evidence URIs
- Validation Registry – independent verification with pluggable trust models (staking, zkML, TEE oracles)
Together they create a loop:
Discovery (8004) -> Commerce (8183) -> Reputation (8004) -> Better Discovery -> More Commerce
Every completed Job is a reputation signal. Every evaluator attestation is a verifiable record. Every rejection carries information. All of it feeds into registries that any agent on any platform can read.
This is the part I keep coming back to. Your Uber rating stays on Uber. Your Upwork reviews stay on Upwork. With these two standards, an agent’s track record is portable. It goes wherever the agent goes. No platform owns it.
The agent commerce stack
ERC-8183 sits in a specific layer of what’s turning into a full infrastructure stack:
| Layer | Protocol | Who |
|---|---|---|
| Communication | MCP, A2A | Anthropic, Google |
| Identity & Trust | ERC-8004 | Ethereum Foundation |
| Commerce | ERC-8183 | EF + Virtuals Protocol |
| Payments | x402 | Coinbase |
| Wallets | AgentKit | Coinbase |
These are being built by different teams but converging. MCP v2.0 and A2A v1.0 stabilized in Q1 2026. Coinbase launched Agentic Wallets in February with TEE-secured key management. x402 has processed over 50 million transactions.
The distinction between the commerce and payment layers matters. As the spec puts it: “A payment moves money. Commerce requires more than moving money.”
x402 handles HTTP-level payment movement. ERC-8183 handles what makes the payment trustworthy: what was agreed, whether work was done, who verified it, what happens when things go wrong. An agent interacts through x402 at the interface layer while settlement flows through ERC-8183 on-chain. They’re complementary.
Two competing visions
ERC-8183 isn’t the only game in town. OpenAI and Stripe released their own “Agentic Commerce Protocol” – also abbreviated ACP, which is going to confuse everyone for years – powering Instant Checkout in ChatGPT. U.S. users can buy from Etsy sellers directly in conversation, with Shopify merchants coming soon.
Stripe’s version introduces Shared Payment Tokens (SPT), a new primitive that lets agents initiate payments using a buyer’s permission without exposing credentials. It’s polished and it leverages Stripe’s existing merchant network.
But the trust models are different in ways that matter.
With Stripe’s ACP, trust comes from Stripe. Stripe holds the settlement infrastructure. Stripe decides the rules. If Stripe changes terms or freezes funds, every participant is affected.
With ERC-8183, trust comes from the smart contract. The escrow, the state machine, and the evaluator attestation live in public, immutable code. No entity changes the rules unilaterally.
Both will exist. Consumer purchases will probably favor Stripe’s UX. But for autonomous agent-to-agent commerce at machine speed, where millions of transactions happen without human oversight? I don’t see how you build a decentralized agent economy on centralized commerce rails.
The numbers so far
This isn’t just a spec with no users. Virtuals Protocol already runs the largest AI agent economy by transaction volume:
- 18,000+ active agents
- $479 million in total aGDP (Agentic GDP)
- 1.77 million completed jobs
- Up to $1 million per month distributed to agents selling services
It’s all on Base (Coinbase’s L2). Agents register with a single line of code and get persistent identity, commerce capabilities, and tokenization. Use cases so far include content creation, software development, data labeling, and financial modeling.
The broader context: Coinbase’s x402 has 50M+ transactions. Stripe is bridging agents to stablecoin payments. Some analysts project the autonomous agent economy at $30 trillion by 2030 (take that number with appropriate skepticism).
What builders should pay attention to
If you’re working in the agent economy, a few things stand out:
Deploy ERC-8183 on your chain. The standard is chain-agnostic. Meta-transaction support (ERC-2771) means agents don’t need to touch the chain directly – a facilitator handles settlement.
Build evaluators. This market is wide open. Domain-specific AI evaluators, ZK verifiers for deterministic tasks, evaluation DAOs – all needed, none exist at scale.
Write hooks. Milestone payments, insurance, subscription models, multi-party collaboration – each is a hook waiting to be built. The hook ecosystem will probably determine whether ERC-8183 succeeds or dies.
Register evaluators on ERC-8004. Evaluators with on-chain reputation attract more business. That’s the flywheel.
Why this matters beyond crypto
Davide Crapis, who leads the Ethereum Foundation’s dAI team, put the stakes this way: “If AI doesn’t have the properties we care about – self-sovereignty, censorship resistance, privacy – and then we use AI for everything, basically no one has those properties anymore.”
That’s the argument. If agents become the dominant economic participants (and the trajectory suggests they might), whoever controls the commerce layer controls the economy. An open standard means nobody controls it. A platform means somebody does.
There’s something unsettling about autonomous agents buying and selling services at 3am while nobody watches. But if that’s where things are headed – and the $479M in aGDP suggests it is – I’d rather the rules be written in public code than decided in a corporate boardroom.
ERC-8004 for trust. ERC-8183 for commerce. The rest is open.
Based on analysis of the ERC-8183 and ERC-8004 specifications, Ethereum Foundation communications, Virtuals Protocol data, and market reporting from Coinbase and Stripe.