Author: Virtuals Protocol
Compiled by: Deep Tide TechFlow
Deep Tide Guide: Virtuals Protocol, in collaboration with the Ethereum Foundation's dAI team, has released the ERC-8183 standard proposal. The core idea is to establish a set of trustless on-chain commerce protocols for economic interactions between AI Agents. This is not just another payment protocol, but a comprehensive commercial infrastructure covering task specification, escrow, delivery verification, and evaluation certification. Combined with the previous ERC-8004 (Agent Identity and Reputation), the two standards form a closed loop: discovery, transaction, reputation accumulation, better discovery, and more trustless transactions. If you are interested in the on-chain implementation path of the AI Agent economy, this article is worth a detailed read.
Full Text Below:
Jointly developed by Virtuals Protocol and the Ethereum Foundation dAI team
Standard Specification: https://eips.ethereum.org/EIPS/eip-8183
Discussion Area: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Join the Builder Community: https://t.me/erc8183
Commerce: A Prerequisite for Decentralized AI
If we want AI Agents to be accessible, decentralized, not controlled by a single platform, not reliant on a single provider, and without single points of failure, then commerce is essential. Commerce cannot be an afterthought; it must be infrastructure. And this commerce must always be open and permissionless. This is exactly what @ethereum was created to build: a "shared digital space without an owner."
Why? Because decentralization at the AI and Agent level requires a large number of independent Agents and services. For example, if only one Agent can generate images and it stops working, then image generation is centralized, regardless of the protocol it runs on. If only one provider controls transaction execution, then fund management depends on the operational willingness of a single party. If only one platform controls the settlement infrastructure, then every provider and every customer is subject to that platform's rules, even if there are a thousand Agents on the platform.
This requires open commerce: any Agent should be able to purchase services, and any Agent should be able to provide services. No gatekeepers, no walled gardens, no forced intermediaries.
Why Blockchain
The key is that commerce only works when all parties can trust that transactions will be fulfilled. If the customer pays first, how do they know the provider will deliver? If the provider delivers first, how do they know the customer will pay? Someone needs to hold the funds, track whether the work is completed, and execute the outcome: release payment upon completion, refund upon failure. It is trust (or the lack thereof) that fundamentally gives rise to centralized entities or gatekeepers.
In traditional architectures, this "someone" is the platform. A company holds the escrowed funds, controls the state machine, and decides who gets paid when. This system works—until it doesn't. The platform can change the rules, freeze funds, delist providers, and shut down. Every participant relies on the platform's continued goodwill. This is centralization, not at the protocol level, but at the execution level. This isn't to say it's wrong, but it's necessary in systems lacking trust. Our goal is "de-totalization": preventing any single entity from having complete control over how Agent transactions occur. We've seen it firsthand: what developers want is infrastructure they can rely on but don't have to rely on the goodwill of any single platform.
Decentralized on-chain smart contracts are the attempted solution to this. Escrow, the state machine, and evaluator certification all exist in public, immutable code that belongs to no one. The contract is the neutral executor, generating signals meaningful to the reputation of all parties.
On-chain settlement also produces something centralized platforms cannot provide: portable, verifiable, tamper-proof records. Every completed task, every evaluator certification, every delivery hash is recorded on-chain, visible to any Agent, any platform, any interface. These records are the raw material for feeding reputation systems and Agent identities. Without on-chain settlement, there is no verifiable history. Without verifiable history, there is no portable reputation. Without portable reputation, every Agent interaction starts from zero trust.
This is why on-chain standards are needed. Escrow, state transitions, certification—these parts must be neutral, secure, and executable.
Discovery, negotiation, and communication can happen on-chain or off-chain, through any interface that is most natural. Agents can interact via HTTP using the x402 interface protocol, and the experience will feel like a standard API or HTTPS request. The Agent doesn't necessarily need to touch the chain directly. It signs a message, and a facilitator handles the on-chain settlement and standards. Or the Agent can interact directly via MCP or A2A. The interface is flexible, but the core settlement should be trustless, programmatic, and on-chain. This is infrastructure that centralized systems will not provide because it undermines their control.
Agent Economy
AI models and Agents are rapidly improving and becoming more powerful every month. Tasks that required human expertise a year ago—writing production-level code, generating professional media content, analyzing financial data, coordinating multi-step workflows—can now be done by Agents with comparable or even higher quality. And capabilities are accelerating. The trajectory of AI makes a new economy inevitable.
As Agents become more powerful, the work they undertake becomes more valuable. An Agent that can generate images indistinguishable from professional photography is a service worth paying for. An Agent that can analyze an investment portfolio and execute optimized trades manages real money. An Agent that can review legal documents and flag risks does work that humans charge hundreds of dollars per hour for.
This is the key shift: AI and Agents are becoming economic participants that create value and provide services.
As AI becomes accessible to everyone, every individual, organization, and device may operate through Agents. The economy will shift. Agents won't just interact with and serve humans; they will also interact with and serve each other. For example, an Agent coordinating a marketing campaign will contract content Agents, distribution Agents, and analysis Agents. The economy becomes a network of Agents transacting with Agents, running at machine speed, scaling to a global size.
When Agents are capable of doing valuable work, and everyone has an Agent, the result is an economy where most commercial activity flows through autonomous systems. This is the future we are building for.
The Problem: Trustless Commerce Between Agents
The Agent economy requires Agent commerce. And commerce between Agents that have never interacted, across different organizations and chains, must be trustless.
When humans transact, hire each other, or use services, trust is central. In these cases, trust is mediated by platforms, reviews, legal systems, and social norms. When one Agent hires another, none of these mechanisms apply. There is no social reputation to check, no legal or reputational recourse operating at machine transaction speeds, no platform or regulator to enforce.
So the problem becomes: How do you make commerce between Agents trustless?
You can't simply transfer tokens and hope for the best. A token transfer is not commerce; it's just a payment without guarantees. There is no record of what was agreed upon, no mechanism to hold funds until work is satisfactory, no evaluation that produces signals for other Agents to reference, no recourse if the provider doesn't deliver.
What's needed is a structured coordination mechanism: funds held in programmable, decentralized, unbiased escrow, work submitted as verifiable artifacts, evaluators certifying whether the delivery meets the terms, outcomes being deterministic. Funds are released upon completion, refunded upon rejection, and recoverable upon expiration. All of this points to or contributes to the identity and reputation of the parties involved.
ERC-8183: The Job Primitive
We have worked closely with the @ethereumfndn dAI team to formalize this into a standard. ERC-8183: Agentic Commerce is an open, permissionless standard for Agent commerce applications, with escrow and evaluator certification programmed as on-chain smart contracts.
ERC-8183 defines a core unit: the Job. Each Job consists of three parties—the Client, the Provider, and the Evaluator. Each party is defined solely by their wallet address, making the primitive broadly applicable.
The key components and principles behind the Job primitive include: (i) Task specification and description—a clear record of the task, service, or work bound to payment; (ii) The payment itself—held in unbiased, programmed escrow until a terminal state, and released programmatically; (iii) Recorded, verifiable, traceable delivery submissions, protecting both client and provider; (iv) Evaluator certification—producing signals meaningful for recourse in the identities and reputations of the parties, providing aligned incentives for trustless settlement.
This drives the Job through four key states, ensuring trustless transactions:
Open → Funded → Submitted → Terminal( Completed / Rejected / Expired)
In summary: A client creates a Job with a provider, then injects funds, locking the payment in escrow. The provider, upon completing the work, calls submit, placing the delivery (or a reference to it) on-chain. The evaluator reviews the submission, calling complete (releasing funds to the provider) or reject (refunding the client). If neither the provider nor the evaluator acts by the deadline, the Job expires, and the client recovers the funds.
The standard is deliberately minimal, forming an atomic primitive. It does not prescribe negotiation processes, fee structures, dispute resolution, communication protocols, or discovery mechanisms. It only specifies the core Job lifecycle—the minimum viable surface for trustless Agent commerce.
Evaluators
A key concept and design decision in ERC-8183 is the Evaluator, defined solely as an address. It is always an Agent, in the broadest definition.
For subjective tasks like writing, design, or analysis, the evaluator can be an AI Agent that reads the submission, compares it to the request, and makes a judgment. For deterministic tasks like computation, proof generation, or data transformation, the evaluator is a smart contract wrapping a ZK verifier. The provider submits a proof, and the evaluator verifies it on-chain and automatically calls complete or reject. For high-stakes scenarios, the evaluator can be a multi-sig, a DAO, or a staking-backed validator.
The standard does not distinguish between these. An address calls complete or reject. Whether that address runs an LLM Agent or a ZK circuit, the protocol doesn't care. This allows the same interface to handle both a $0.1 image generation task and a $100,000 fund management task.
Hooks: Modular Extensibility
The Job primitive is deliberately minimal. But commerce is not. Real applications require custom validation, reputation updates, fee distribution, fund transfers, bidding mechanisms, and domain-specific logic that varies by use case. A content evaluation task, a token swap, and a prediction market position each require fundamentally different logic.
ERC-8183 solves this with Hooks. A Hook is an optional smart contract attached at Job creation. It receives callbacks before and after each operation, allowing custom logic to execute around the core lifecycle without modifying it. A Hook is identified by a single function selector (which transition is happening) and receives relevant parameters. It can perform preconditions, block invalid operations, trigger side effects, or perform additional token transfers, all within the same transaction as the core state change.
If no Hook is set, the contract executes normally. An implementation without Hooks is fully ERC-8183 compliant. Hooks are additive, not required. This design keeps the core contract lean and the interface stable. New use cases are supported via new Hook contracts, with the extension logic kept on-chain, programmatic, and trustless—just like the core.
Example Commerce Applications
The core Job handles direct service commerce: payment, delivery, evaluation. But the economy Agents operate in is not simple. Some Jobs involve managing client capital, not just collecting fees. Some require bidding before assigning a provider. Some require trust checks referencing external reputation data. These are fundamentally different economic models, and Hooks allow the same core Job interface to support this diversity, making ERC-8183 a general commerce primitive.
Service Jobs are the baseline and require no Hook. The client pays for content generation, data analysis, or code review. The core escrow and evaluation process handles it completely.
Funds-in-Motion Jobs go beyond service fees. The client provides capital (tokens to swap, funds to invest), the provider transforms it, and the output must be returned. Hooks can manage this two-way capital flow outside the core escrow, ensuring the provider deposits the output tokens before Job completion. This can cover a wide range of applications, like yield farming, token swaps, portfolio rebalancing—any Job where the provider handles client funds or needs upfront capital to execute the task, not just earn a fee.
Bid-based Jobs flip the allocation model. Instead of the client pre-selecting a provider, providers compete on price. The Hook validates cryptographically signed bids at allocation time, proving the selected provider did commit to the claimed price. Neither party can forge or deny the terms.
Reputation-Gated Jobs enforce trust at the protocol level. The Hook queries ERC-8004 before allowing operations, blocking low-reputation providers or requiring stricter terms for unverified Agents.
Privacy-Preserving Jobs leverage Hooks for commerce with no data exposure. A privacy Hook can require the "submit" field to contain a reference to a zero-knowledge proof (ZKP) or an encrypted enclave (like a TEE), rather than exposing sensitive task details on-chain. This ensures payment is trustless and public while actual intellectual property or personal data remains in a "safe haven," accessible only to authorized Agents.
Risk Assessment/Underwriting Jobs can execute underwriting at the protocol level via Hooks. A Hook can require the provider or an underwriter to stake collateral, check ERC-8004 reputation scores and other relevant metrics before allocation, enforce slashing bonds upon evaluation failure, or query external risk oracles. These previously opaque approval processes can become transparent, programmable, and competitive.
Each of the above applications can be implemented as different Hook contracts, keeping the core functionality and Job primitive standard unchanged. New economic models, commerce applications, or variants of custom logic are new Hooks. We introduced the first few Hooks as examples to show what's possible, but we believe we've only scratched the surface, and the most interesting Hooks haven't been written yet. What will Agent commerce look like in insurance, creative collaboration, supply chain coordination? We don't know yet, and that's the point. Agent commerce will evolve in ways we can't fully foresee—new economic models, new trust mechanisms, new forms of machine-to-machine coordination. The standard is designed to grow with that evolution, not constrain it. This standard should be built in the open, as it should be, because the best ideas will come from the ecosystem, and we look forward to discovering them together.
Symbiosis with ERC-8004
ERC-8183 does not exist in isolation. It is symbiotic with ERC-8004 ("Trustless Agents"), the Ethereum standard for Agent identity, reputation, and verification.
ERC-8004 solves the discovery and trust problem: how Agents find each other and assess reliability. But the value of its registries depends on the activity they record. Identity without commerce or behavior is an empty profile. Reputation requires real interactions to measure. Verification requires defined deliverables to check against.
ERC-8183 provides the commercial activity that feeds the ERC-8004 trust layer. Every Job is a reputation signal. Every submission is a deliverable that verifiers can assess. Every evaluation is a certification that other Agents can reference.
The two standards form a cycle that could enable more powerful self-organization of Agents through trustless interactions:
Discovery (8004) → Commerce (8183) → Reputation (8004) → Better Discovery → More Trustless Commerce
Neither is complete without the other. Together, they form the foundation for trustless Agent commerce and interaction.
Beyond Payment
ERC-8183 is not a payment protocol; it is a commerce standard.
Payments move money. But commerce requires much more than moving money. Commerce is everything around the payment that makes it trustworthy and operational: what was agreed upon, whether the work was done, who verified it, what happens if it wasn't done. In the traditional world, commerce works because of the配套设施 around the payment: risk assessment and underwriting of merchants before they can accept payments, credit extension enabling buyers to transact before funds are settled, real-time fraud detection across billions of transactions, chargeback and dispute mechanisms protecting buyers when services fail, and reputation systems building trust through repeated interactions. These functions are the value of payment processors, card networks, and platforms—not the movement of funds itself, but the trust infrastructure around it.
When commerce moves on-chain, these functions don't disappear. They need to be rebuilt in a trustless, programmatic, open way. This is what ERC-8183 is doing.
The Job primitive's escrow and evaluator certification model is analogous to a chargeback mechanism with programmable, preset settlement terms. Using ERC-8004's on-chain reputation and other on-chain reputation indicators as part of ERC-8183 is analogous to proprietary underwriting with portable, verifiable history. Hooks replace centralized risk assessment with modular, competitive, auditable logic that any facilitator can deploy. The result is not just a way to move funds on-chain, but a way to rebuild the complete trust infrastructure of commerce—open and permissionless.
Existing payment protocols and interfaces, whether traditional processors or stablecoin transfer protocols like x402, are smooth, internet-native experiences that handle the movement of funds. ERC-8183 manages the full lifecycle that turns a payment into a trustless transaction: specification, escrow, deliverable submission, evaluator certification, and deterministic settlement. Agents can interact at the interface layer via x402 or HTTP, while the underlying settlement flows through ERC-8183 on-chain. The two are complementary.
Irreversibility, Escrow, and the Chargeback Problem
Another concern with raw payments is irreversibility. When a credit card is charged and the service is unsatisfactory, the consumer can dispute and reverse the charge. Once a payment is transferred out, the money is gone. This is a real and valid objection for raw payments and transfers.
ERC-8183 preserves this core concept in the contract structure. Funds are held in escrow until an evaluator certifies that the delivery meets the agreed terms. The rejection path refunds the client. The expiration path auto-reclaims. This is the programmable, trustless equivalent of the authorize-capture model—the model that makes card commerce work—except the terms are pre-coded and enforced by code, not adjudicated after the fact by a network with its own interests.
For pre-authorizations of uncertain amounts—hotel deposits, services that might expand in scope—the flexibility of Hooks can be designed to lock a maximum amount, settling the final amount upon completion based on verifiable inputs. This architecture supports the trust models and behaviors that make card commerce flexible, while keeping settlement transparent, open, trustless, and on-chain.
A New Wave of Economic Participants
The AI wave is creating new economic participants—both buyers and merchants—faster than ever before. Millions of developers and non-developers are building and publishing microservices, APIs, and tools using AI programming assistants, many without legal entities, websites, or transaction history. Agents from tech companies and open-source frameworks are attracting millions of users through personal AI agents and assistants.
Traditional payment systems will struggle to serve these merchants. Not because of technology, but because when a processor approves a provider, it absorbs that provider's risk: fraud, chargebacks, disputes. A merchant with no record, no entity, no history is too risky to underwrite.
ERC-8183 is permissionless by design. A provider is a wallet address. No onboarding, no underwriting, no gatekeepers. The Job primitive gives these merchants not just a way to get paid, but a full commerce lifecycle: work specification, escrowed payment, verifiable delivery submission, and evaluator certification, laying the foundation for trustworthy transactions.
The inability to underwrite new providers might be seen as a temporary gap. An open standard structurally compresses this timeline. Any facilitator can deploy ERC-8183 today. The ecosystem evolves through experimentation, not institutional consensus. But more fundamentally, ERC-8183 combined with ERC-8004 doesn't just bridge the underwriting gap; it addresses the root cause. The reason a processor can't underwrite a new merchant is the lack of verifiable history. ERC-8183 produces that history. Every completed Job is recorded on-chain: delivery hash, evaluator certification, outcome. This history is portable, verifiable, and belongs to no one.
Critically, this record isn't locked inside a single platform. Today, Platform A knows your chargeback rate, Platform B knows your seller rating, but you can't take those records with you. On ERC-8183, reputation is the merchant's own portable asset, readable by any facilitator, any chain, any interface that reads the standard. ERC-8183 feeds on-chain identity and reputation (ERC-8004) and provides underwriting data.
Building the Future of Agent Commerce and Decentralized AI Together
ERC-8183 is an open standard for trustless Agent commerce. Here's how to get involved:
Build with ERC-8183. Become a facilitator! Deploy ERC-8183 on your chain. Build SDKs, wrappers, scanners, and trackers. Build new interfaces and experiences that settle securely and verifiably on-chain via ERC-8183. Create Agent frameworks that natively interact with this standard.
Explore, experiment, and build Hooks. Need milestone payments or dispute resolution? Build them as Hooks. This is the space for creativity and the evolution of diverse applications.
Build and register Evaluators. Evaluators are a critical part of ensuring secure, trustless Agent commerce but are severely lacking today. Build evaluators for specific domains, especially fully verifiable ones and services. Register them on ERC-8004. Contribute meaningfully to Agent reputation and identity.
Contribute and provide feedback. This is a collective standard. Only through broad experimentation, real-world use, candid feedback, and iteration can it become what it needs to be. If something is missing, propose it. If something is wrong, challenge it. The specification is open, the codebase is open, the discussion is open. This needs to evolve together.
The Agent economy will be built on open standards, or it will be built in walled gardens. We choose open standards. A shared digital space.
ERC-8004 for trust. ERC-8183 for commerce. The rest, you build.
Related Links:
- ERC-8183 Specification: https://eips.ethereum.org/EIPS/eip-8183
- ERC-8004 Specification: eips.ethereum.org/EIPS/eip-8004
- ERC-8183 Discussion: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
- Telegram Community: https://t.me/erc8183
