Virtuals and the Ethereum Foundation release ERC-8183: Trustless On-Chain Business Protocol

Author: Virtuals Protocol

Translation: Deep潮 TechFlow

Deep潮 Guide: Virtuals Protocol, in collaboration with the Ethereum Foundation dAI team, has released the ERC-8183 standard proposal. Its core idea is to establish a trustless on-chain business protocol for economic interactions between AI Agents. This is not just another payment protocol but a comprehensive business infrastructure covering task specifications, escrow, delivery verification, and evaluation certification. Paired with the earlier ERC-8004 (Agent Identity and Reputation), these two standards form a closed loop: discovery, transactions, reputation building, improved discovery, and more trustless transactions. If you’re interested in how AI Agent economics can be implemented on-chain, this is a must-read.

Full text below:

Developed jointly by Virtuals Protocol and the Ethereum Foundation dAI team

Standards and Specifications:

Discussion: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

Join the Builder Community:

Business: The Preconditions 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 free from single points of failure, then business infrastructure is essential. Business cannot be an afterthought; it must be foundational. And this infrastructure must always be open and permissionless. This is precisely why @ethereum was created—to build a “shared digital space without owners.”

Why? Because decentralization at the AI and Agent layer requires many independent Agents and services. For example, if only one Agent can generate images and it stops service, then regardless of the protocol it runs on, image generation becomes centralized. If only one provider controls transaction execution, then fund management depends on that provider’s operational willingness. If only one platform controls settlement infrastructure, then every provider and customer is subject to that platform’s rules—even if there are thousands of Agents on it.

This necessitates open business: any Agent should be able to purchase services, any Agent should be able to offer services. No gatekeepers, no walled gardens, no mandatory intermediaries.

Why Blockchain?

The key is that business only functions when all parties trust that transactions will be fulfilled. If a customer pays upfront, how do they know the provider will deliver? If the provider delivers first, how do they know the customer will pay? There must be someone holding funds, tracking task completion, and executing results: releasing payment upon completion, refunding upon failure. It’s trust (or lack thereof) that fundamentally leads to centralized entities or gatekeepers.

In traditional architectures, this “someone” is the platform. A company holds escrow funds, controls state machines, and decides who gets paid when. This approach works—until it doesn’t. Platforms can change rules, freeze funds, delist providers, shut down. Every participant relies on the platform’s ongoing good faith. This is centralization—not at the protocol level, but in execution. It’s not wrong, but in trustless systems, it’s necessary. Our goal is “de-totalization”: to prevent any single entity from having full control over Agent transaction methods. We’ve seen developers want infrastructure they can rely on, but without depending on any single platform’s goodwill.

Decentralized smart contracts on-chain are an attempt to solve this. Escrows, state machines, and evaluator certifications exist in open, immutable, code that belongs to no one. Contracts are neutral executors, providing meaningful signals about reputation and trustworthiness.

On-chain settlement also produces things that centralized platforms cannot: portable, verifiable, tamper-proof records. Every completed task, each evaluator certification, each delivery hash is recorded on-chain, visible to any Agent, platform, or interface. These records feed reputation systems and Agent identities. Without on-chain settlement, there’s no verifiable history. Without verifiable history, there’s no portable reputation. Without portable reputation, every Agent interaction starts from zero trust.

This is why on-chain standards are necessary. Escrows, state transitions, certifications—these must be neutral, secure, and executable.

Discovery, negotiation, and communication can happen on-chain or off-chain, via any natural interface. Agents can interact through HTTP using the x402 protocol, experiencing it as a standard API or HTTPS request. Agents don’t necessarily need direct on-chain contact. They can sign a message, with a facilitator handling on-chain settlement and standards. Or they can interact directly via MCP or A2A. Interfaces are flexible, but core settlement should be trustless, programmable, and on-chain. This is infrastructure that centralized systems cannot provide, as it would weaken their control.

Agent Economy

AI models and Agents are advancing rapidly each month. Tasks that once required human expertise—writing production code, generating professional media, analyzing financial data, coordinating multi-step workflows—are now performed by Agents at comparable or higher quality. Capabilities are accelerating. The trajectory of AI development makes a new economy inevitable.

As Agents become more powerful, their work becomes more valuable. An Agent that can generate images indistinguishable from professional photography is a paid service. An Agent that analyzes portfolios and executes optimized trades manages real money. An Agent that reviews legal documents and flags risks performs work that costs hundreds of dollars per hour for humans.

This is the key shift: AI and Agents are becoming economic participants who create value and provide services.

When AI becomes accessible to everyone—individuals, organizations, devices—the economy will transform. Agents won’t just interact with humans; they will interact and trade with each other. For example, an Agent coordinating marketing campaigns might sign contracts with content Agents, distribution Agents, and analysis Agents. The economy becomes a network of Agent-to-Agent transactions, operating at machine speed and scaling globally.

With Agents capable of performing valuable work and everyone having an Agent, most commercial activity will flow through autonomous systems. This is the future we are building.

The Problem: Trustless Business Between Agents

Agent economy requires Agent-to-Agent commerce. When Agents from different organizations and chains interact for the first time, that commerce must be trustless.

Humans rely on trust when transacting, hiring, or using services. Platforms, reviews, legal systems, and social norms mediate trust. But when one Agent hires another, these mechanisms don’t apply. No social reputation is available, no legal or reputation recourse operates at machine speed, and there’s no platform or regulator to enforce.

So the question is: how to enable trustless Agent-to-Agent commerce?

You can’t just send tokens and hope for the best. A token transfer isn’t commerce; it’s just an unguaranteed payment. There are no records of what was agreed, no mechanism to hold funds before work is satisfactory, no signals for other Agents to reference, and no recourse if the provider doesn’t deliver.

What’s needed is a structured collaboration mechanism: funds held in programmable, decentralized escrow; work submitted as verifiable artifacts; evaluators certifying whether deliverables meet terms; and deterministic outcomes. Funds are released upon completion, refunded upon rejection, and recoverable after expiry. All these contribute to or depend on the identity and reputation of each party.

ERC-8183: Job Primitive

In collaboration with @ethereumfndn dAI team, we formalized this into a standard. ERC-8183: Agentic Commerce is an open, permissionless standard for Agent business applications, with escrow and evaluator certification implemented as on-chain smart contracts.

ERC-8183 defines a core unit: Job. Each Job involves three parties—Client, Provider, and Evaluator. Each is identified solely by their wallet address, making this primitive broadly applicable.

Key components and principles behind the Job primitive include: (i) task specification and description—a clear record of the task, service, or work tied to payment; (ii) payment itself—held in escrow until final state, then programmatically released; (iii) recorded, verifiable, traceable delivery artifacts—protecting both client and provider; (iv) evaluator certification—producing signals about identities and reputations that enable trustless settlement.

This drives the Job through four key states, ensuring trustless transactions:

Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)

In summary: the client creates a Job with a provider, deposits funds into escrow. The provider completes work and calls submit, uploading deliverables (or references). The evaluator reviews and calls complete (releasing funds to provider) or reject (refunding client). If neither acts before deadline, the Job expires, and funds are reclaimed.

This standard intentionally remains minimal, forming an atomic primitive. It does not specify negotiation processes, fee structures, dispute resolution, communication protocols, or discovery mechanisms. It only defines the core Job lifecycle—the minimal surface for trustless Agent commerce.

Evaluators

A key concept and design decision in ERC-8183 is the evaluator (Evaluator), defined simply as an address. It is always an Agent, in the broadest sense.

For subjective tasks like writing, design, or analysis, the evaluator can be an AI Agent that reads submissions, compares with requests, and makes judgments. For deterministic tasks like computation, proof generation, or data transformation, the evaluator can be a smart contract wrapping a ZK verifier. The provider submits proof, the evaluator verifies on-chain and automatically calls complete or reject. For high-risk scenarios, the evaluator can be multisig, DAO, or collateral-backed validators.

The standard makes no distinction. 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 $0.10 image generation tasks and $100,000 fund management.

Hooks: Modular Extensibility

The Job primitive is deliberately minimal. But business isn’t. Real applications require custom verification, reputation updates, fee distribution, fund transfers, bidding mechanisms, and domain-specific logic.

ERC-8183 addresses this with Hooks. A Hook is an optional smart contract attached at Job creation. It receives callbacks before and after each operation, enabling custom logic around the core lifecycle without modifying it. A Hook is identified by a single function selector, receives relevant parameters, and can enforce preconditions, block invalid actions, 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. No Hook implementation fully complies with ERC-8183. Hooks are supplementary, not mandatory. This design keeps the core contract lean and interface stable. New use cases can be supported via new Hook contracts, with logic kept on-chain, programmable, and trustless—just like the core.

Example Business Applications

The core Job handles direct service commerce: payment, delivery, evaluation. But the Agent economy is more complex. Some Jobs involve managing client capital, not just fees. Some require bidding before assigning a provider. Some need external reputation data for trust checks. These are fundamentally different economic models. Hooks enable the same core Job interface to support this diversity, making ERC-8183 a universal primitive.

Service-based Jobs are the baseline, requiring no Hooks. Clients pay for content generation, data analysis, or code review. The core escrow and evaluation process handle everything.

Fund transfer Jobs go beyond fees. Clients provide capital (tokens to swap, funds to invest), providers convert it, and output must be returned. Hooks can manage this bidirectional capital flow outside core escrow, ensuring providers deposit output tokens before Job completion. This covers scenarios like yield farming, token swaps, portfolio rebalancing—any Job where providers handle client funds or need upfront capital.

Bidding Jobs flip the allocation model. Instead of clients pre-select providers, providers compete on price. Hooks verify encrypted bids via signatures, proving the chosen provider committed to the claimed price. No one can forge or deny terms.

Reputation-gated Jobs enforce trust at the protocol level. Hooks query ERC-8004 before operations, blocking low-reputation providers or requiring stricter terms for unverified Agents.

Privacy-preserving Jobs use Hooks for confidential commerce. Privacy Hooks can require the “submit” field to contain a zero-knowledge proof (ZKP) or an encrypted reference (e.g., TEE), instead of revealing sensitive task data on-chain. This ensures payments are trustless and public, while IP or personal data remains private, accessible only to authorized Agents.

Risk assessment/underwriting Jobs can execute underwriting at the protocol level via Hooks. Hooks can require providers or underwriters to stake collateral, check ERC-8004 reputation scores, execute slashes on failed assessments, or query external risk oracles. Previously opaque approval processes become transparent, programmable, and competitive.

Each of these applications can be implemented as different Hook contracts, keeping the core functionality and Job primitive standard unchanged. New economic models, business applications, or custom logic variants are just new Hooks. We’ve introduced initial Hooks as examples of what’s possible, but we believe we’ve only scratched the surface. What will Agent business look like in insurance, creative collaboration, supply chain coordination? We don’t know yet—that’s the point. Agent business will evolve in ways we can’t fully predict—new economic models, trust mechanisms, machine-to-machine collaboration forms. The standard is designed to grow with this evolution, not constrain it. It should be built openly, because the best ideas will come from the ecosystem, and we look forward to discovering them together.

Synergy with ERC-8004

ERC-8183 is not standalone. It is synergistic with ERC-8004 (“Trustless Agents”), Ethereum’s standard for Agent identity, reputation, and verification.

ERC-8004 addresses discovery and trust: how Agents find each other and assess reliability. But its registry’s value depends on the activity recorded. An identity without real interactions is an empty profile. Reputation needs genuine exchanges to measure. Verification requires defined deliverables to confirm.

ERC-8183 provides the business activity feed that fuels ERC-8004’s trust layer. Each Job is a reputation signal. Each submission is a deliverable that evaluators can assess. Each evaluation is a certification that other Agents can reference.

Together, these standards form a cycle that could enable Agents to self-organize through trustless interactions:

Discovery (8004) → Business (8183) → Reputation (8004) → Better discovery → More trustless business

Both are indispensable. Combined, they form the foundation for trustless Agent commerce and interaction.

Beyond Payments

ERC-8183 is not a payment protocol but a business standard.

Payments move money. But business involves much more: agreements, work completion, verification, dispute resolution. In the traditional world, business works because of the supporting infrastructure around payments: risk assessment and underwriting before accepting a merchant, credit extension for pre-funding transactions, real-time fraud detection, buyer protections, reputation systems built through repeated interactions. These are the core value of payment processors, card networks, and platforms—not just moving funds but enabling trust.

When business moves on-chain, these functions don’t disappear. They must be rebuilt trustlessly, programmatically, openly. That’s what ERC-8183 does.

The escrow and evaluator certification model in Job primitives resembles a programmable, pre-settlement “chargeback” mechanism. Using ERC-8004’s on-chain reputation and other reputation metrics as part of ERC-8183 is akin to portable, verifiable underwriting history. Hooks replace centralized risk assessment with modular, competitive, auditable logic. Any facilitator can deploy them. The result is not just a way to transfer funds on-chain but a way to rebuild the entire trust infrastructure of business—open and permissionless.

Existing payment protocols and interfaces—whether traditional payment processors or stablecoin transfer protocols like x402—offer smooth, internet-native experiences for moving funds. ERC-8183 manages the full lifecycle of trustless transactions: specification, escrow, deliverable submission, evaluator certification, and deterministic settlement. Agents can interact via x402 or HTTP at the interface layer, while settlement flows on-chain via ERC-8183. They complement each other.

Irreversibility, Escrow, and Chargebacks

Another concern with independent payments is irreversibility. When a credit card is charged and the service is unsatisfactory, consumers can dispute and reverse the charge. Once funds are transferred out, they’re gone. This is a real and valid objection for traditional payments.

ERC-8183 preserves this core concept in its contract structure. Funds are held in escrow until the evaluator certifies that deliverables meet the terms. Rejection refunds the customer. Expiry automatically reclaims funds. This is the programmable, trustless equivalent of the authorization-capture model—what makes card-based commerce work—except the terms are pre-coded and executed by smart contracts, not a network’s adjudication.

For pre-authorizations of uncertain amounts—hotel deposits, scope-expanding services—Hooks can be designed to lock a maximum amount, then settle the final amount based on verifiable inputs at completion. This supports flexible trust models and behaviors for card-based commerce while maintaining transparent, open, and trustless on-chain settlement.

New Wave of Economic Participants

The AI surge is creating new economic participants at an unprecedented pace—buyers and merchants alike. Millions of developers and non-developers are building and deploying microservices, APIs, and tools with AI programming assistants, many without legal entities, websites, or transaction histories. 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 technical limitations, but because onboarding a provider involves risk: fraud, chargebacks, disputes. A merchant without records, entity, or history is too risky to underwrite.

ERC-8183 is permissionless by design. A provider is just a wallet address. No onboarding, no underwriting, no gatekeepers. The Job primitive offers these merchants not just a payment method but a full business lifecycle: task specification, escrowed payment, verifiable deliverables, evaluator certification—laying the foundation for trusted transactions.

The inability to underwrite new providers may 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 centralized consensus. But more fundamentally, ERC-8183 combined with ERC-8004 not only bridges underwriting gaps but addresses the root cause: lack of verifiable history. Each completed Job is recorded on-chain: deliverable hashes, evaluator certifications, results. This history is portable, verifiable, and belongs to no one.

Crucially, these records are not locked within a single platform. Today, Platform A knows your chargeback rate; Platform B knows your seller ratings. But you can’t take these records with you. On ERC-8183, reputation becomes a portable asset owned by the merchant. Any facilitator, chain, or interface reading the standard can access it. ERC-8183 feeds on-chain identity and reputation (ERC-8004) and provides underwriting data.

Building the Future of Agent Business and Decentralized AI

ERC-8183 is an open trustless Agent business standard. Ways to participate:

Build with ERC-8183. Become a facilitator! Deploy ERC-8183 on your chain. Develop SDKs, wrappers, scanners, and trackers. Create new interfaces and experiences that settle securely and verifiably on-chain via ERC-8183. Build native Agent frameworks that interact with this standard.

Explore, experiment, and develop Hooks. Need milestone payments or dispute resolution? Build them as Hooks. This is the space for creativity and diverse applications to evolve.

Develop and register evaluators. Evaluators are critical for ensuring secure, trustless Agent commerce, but currently scarce. Build evaluators for specific domains, especially fully verifiable ones. Register them on ERC-8004. Contribute meaningful signals to Agent reputation and identity.

Contribute and provide feedback. This is a collective standard. Only through broad experimentation, real-world use, honest feedback, and iteration can it become what it needs to be. If something’s missing, suggest it. If there are errors, challenge them. The standard is open, the codebase is open, discussions are open. It’s a collective evolution.

Agent economy will be built on open standards or walled gardens. We choose open standards—a shared digital space.

ERC-8004 for trust. ERC-8183 for commerce. And the rest is up to you.

Related Links:

ERC-8183 Specification:

ERC-8004 Specification: eips.ethereum.org/EIPS/eip-8004

ERC-8183 Discussion: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

Telegram Community: