Virtuals, in conjunction with the Ethereum Foundation, released ERC-8183: Trustless On-Chain Business Protocol.

ERC-8004 is for trust, ERC-8183 is for commerce.

Author: Virtuals Protocol

Compiled by: Deep Tide TechFlow

Deep Tide Guide: The Virtuals Protocol collaborated with the Ethereum Foundation dAI team to release the ERC-8183 standard proposal, with the core idea of establishing a trustless on-chain commerce protocol for economic interactions between AI Agents. This is not just another payment protocol but a complete set of commercial infrastructure covering task specifications, escrow, delivery verification, and evaluation certification. Coupled with the previous ERC-8004 (Agent identity and reputation), the two standards form a closed loop: discovery, transaction, reputation accumulation, better discovery, more trustless transactions. If you are concerned about the on-chain landing path of the AI Agent economy, this article is worth a detailed read.

The full text is as follows:

Developed jointly by Virtuals Protocol and Ethereum Foundation dAI Team

Standard Specification: https://eips.ethereum.org/EIPS/eip-8183

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

Join the Builder community: https://t.me/erc8183

Commerce: Prerequisites 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 of single points of failure, then commerce is essential. Commerce cannot be an afterthought; it must be infrastructure. Furthermore, this commerce must always be open and permissionless. This is precisely what @ethereum was created to build: a "shared digital space without owners."

Why? Because decentralization at the AI and Agent level requires a large number of independent Agents and services. For example, if there is only one Agent that can generate images, and it stops providing services, then regardless of what protocol it runs on, image generation becomes centralized. 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 client is subject to the rules of that platform, even if there are a thousand Agents on that 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 mandatory intermediaries.

Why Blockchain

The key is that commerce can only operate when all parties can trust that transactions will be fulfilled. If the client pays first, how does one know that the provider will deliver? If the provider delivers first, how does one know that the client will pay? Someone needs to hold funds, track whether work is completed, and enforce results: releasing payment upon completion, refunding upon failure. It is trust (or lack thereof) that fundamentally gives rise to centralized entities or gatekeepers.

In a traditional architecture, this "someone" is the platform. A company holds escrow funds, controls the state machine, and decides who gets paid when. This scheme works — until it doesn't. The platform can change the rules, freeze funds, delist providers, or shut down. Each participant relies on the platform's ongoing goodwill. This is centralization, not at the protocol level, but at the execution level. It’s not that this is wrong, but in a trustless system, it is necessary. Our goal is "de-totalization": to prevent any single entity from having complete control over the Agent transaction model. We have seen for ourselves: what developers want is an infrastructure they can rely on, but not have to rely on any single platform's goodwill.

Decentralized on-chain smart contracts attempt to address this. Escrow, state machines, and evaluator certification exist in public, immutable code that belongs to no one. The contract is a neutral executor, thus producing meaningful signals about the reputation of each party.

On-chain settlement can also produce something centralized platforms cannot provide: portable, verifiable, tamper-proof records. Every completed task, every evaluator certification, and every delivery item hash is recorded on-chain, visible to any Agent, any platform, any interface. These records are the raw materials that feed the reputation system and Agent identity. 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 a point of zero trust.

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

Discovery, negotiation, and communication can occur on-chain or off-chain, through any interface that feels most natural. Agents can interact via HTTP using the x402 interface protocol, experiencing it like a standard API or HTTPS request. Agents do not necessarily need to directly access the chain. They can sign a message, and a facilitator processes on-chain settlement and standards. Alternatively, Agents can interact directly through MCP or A2A. The interfaces are flexible, but the core settlement should be trustless, programmatic, and on-chain. This is the infrastructure that centralized systems will not provide because it would undermine their control.

Agent Economy

AI models and Agents are rapidly advancing and becoming stronger every month. Tasks that required human expertise a year ago — writing production-grade code, generating professional media content, analyzing financial data, coordinating multi-step workflows — can now be completed by Agents with comparable or even higher quality. Moreover, capabilities are accelerating in improvement. The trajectory of AI development makes the new economy inevitable.

As Agents become stronger, 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 a portfolio and execute optimized trades manages real money. An Agent that can review legal documents and flag risks is performing work that humans charge hundreds of dollars per hour for.

This represents a key shift: AI and Agents are becoming economic participants that create value and provide services.

When AI becomes accessible to everyone, every individual, organization, and device may operate through an Agent. The economy will transform. Agents do not only interact with humans and serve humans; they will also interact with one another and serve one another. For example, an Agent coordinating a marketing campaign will contract content Agents, distribution Agents, and analysis Agents. The economy turns into a network of Agent-to-Agent transactions, operating at machine speed and scaling globally.

When Agents have the ability to perform 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.

Issue: Trustless Commerce Between Agents

The Agent economy requires Agent commerce. And commerce between Agents that have never interacted, spanning different organizations and chains, must be trustless.

When humans transact, mutually hire, or use services, trust is core. In these situations, trust is mediated by platforms, evaluations, legal systems, and social norms. When one Agent hires another Agent, these mechanisms do not apply. There is no social reputation to check, no legal or reputation recourse operating at machine transaction speeds, and no platform or regulatory body to enforce.

So the question becomes: how to make commerce between Agents trustless?

You cannot simply transfer tokens and then pray that everything goes well. A token transfer is not commerce; it is just an unsecured payment. There is no record of what was agreed upon, no mechanism holding funds before work satisfaction, no assessments generating signals for other Agents to reference, and no recourse if the provider does not deliver.

What is needed is a structured collaborative mechanism: funds held by a programmable decentralized unbiased escrow, work submitted in verifiable artifacts, evaluators proving whether deliverables meet terms, and deterministic outcomes. Funds are released upon completion, refunded upon rejection, and reclaimable upon expiration. All of these point to or contribute to the identities and reputations of the parties involved.

ERC-8183: Job Primitive

We closely collaborated 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 programmatically implemented in on-chain smart contracts.

ERC-8183 defines a core unit: Job. Each Job consists of three parties—Client, Provider, and Evaluator. Each party is defined solely by its wallet address, enabling the broad applicability of this primitive.

The key components and principles behind the Job primitive include: (i) task specifications and descriptions — clear records of tasks, services, or work tied to payment; (ii) the payment itself — held in unbiased programmable escrow until the final state and programmatically released; (iii) recorded, verifiable, traceable deliverable submissions, protecting both the client and the provider; (iv) evaluator certification — generating signals of recourse meaning for the identities and reputations of the parties, providing aligned incentives for trustless settlement.

This drives the Job through four critical 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. After the provider completes the work, they call submit, putting the deliverables (or their references) on-chain. The evaluator reviews the submitted content, calling complete (releasing funds to the provider) or reject (refunding the client). If neither the provider nor the evaluator takes action before the deadline, the Job expires, and the client reclaims the funds.

This standard is deliberately minimal, forming atomic-level primitives. It does not stipulate negotiation processes, fee structures, dispute resolutions, communication protocols, or discovery mechanisms. It only specifies the core Job lifecycle—the minimum viable surface for trustless Agent commerce.

Evaluator

A key concept and design decision of ERC-8183 is the evaluator, defined solely 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 the submitted content, compares it to requests, and makes judgments. For deterministic tasks like computation, proof generation, or data transformation, the evaluator is a smart contract wrapped around a ZK verifier. The provider submits proofs, and the evaluator verifies them on-chain and automatically calls complete or reject. For high-risk scenarios, the evaluator can be a multi-signature, DAO, or stake-backed validator.

The standard does not differentiate among these. An address calls complete or reject. Whether this address runs an LLM Agent or ZK circuit, the protocol does not care. This enables 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 customized validations, reputation updates, fee allocations, fund transfers, bidding mechanisms, and domain-specific logic that varies by use case. A content assessment task, a token swap, and a prediction market position each require fundamentally different logic.

ERC-8183 addresses this problem 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 conversion is happening) and receives relevant parameters. It can execute 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. Implementations without Hooks fully comply with ERC-8183. Hooks are additional, not mandatory. This design keeps the core contract lean and the interface stable. New use cases supported by new Hook contracts allow the logic extensions to remain on-chain, programmatic, and trustless—just like the core.

Example Business Applications

The core Job handles straightforward service commerce: payments, delivery, evaluations. But the economy in which Agents operate is not simple. Some Jobs involve managing client capital, not just earning fees. Some require bidding before allocating providers. Some demand 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 universal commercial primitive.

Service Jobs are the baseline and do not require Hooks. Clients pay for content generation, data analysis, or code review. The core escrow and evaluation processes are fully handled.

Fund Transfer Jobs go beyond service fees. Clients provide capital (tokens to swap, funds to invest), and the provider converts it, must return the output. Hooks can manage this bidirectional capital flow outside the core escrow, ensuring the provider deposits output tokens before the Job is completed. This can cover a wide array of applications, such as yield farming, token swaps, portfolio rebalancing—any Job where a provider is handling client funds or needs upfront capital to execute a task, not just to earn fees.

Bidding Jobs reverse the allocation model. Instead of clients pre-selecting providers, providers compete on price. Hooks validate cryptographic signature bids at allocation, proving that the selected provider indeed committed to the stated price. No party can forge or deny the terms.

Reputation-Gated Jobs implement trust at the protocol level. Hooks query ERC-8004 before allowing operations, blocking low-reputation providers or imposing stricter terms on unverified Agents.

Privacy-Preserving Jobs use Hooks to enable trustless commerce without data exposure. Privacy Hooks can require the "submit" fields to contain zero-knowledge proofs (ZKP) or references to secure environments (like TEE), instead of publicly exposing sensitive task data on-chain. This ensures payments are trustless and transparent while keeping the actual intellectual property or personal data as a "safe harbor," accessible only to authorized Agents.

Risk Assessment/Underwriting Jobs can implement underwriting at the protocol level via Hooks. Hooks can require providers or underwriters to stake collateral, check ERC-8004 reputation scores and other relevant metrics before allocation, enforce slashing of collateral in case of evaluation failures, or query external risk oracles. These previously opaque approval processes can become transparent, programmable, and competitive.

Each of the above applications can be realized as different Hook contracts, while maintaining the core functionality and Job primitive standards. New economic models, business applications, or variants of custom logic are all new Hooks. We introduce the initial few Hooks, which are examples of possibilities, but we believe we have just scratched the surface; the most interesting Hooks have yet to be written. What might Agent commerce look like in insurance, creative collaboration, or supply chain coordination? We do not know yet, and that is the point. Agent commerce will evolve in ways we cannot completely foresee — new economic models, new trust mechanisms, new forms of machine-to-machine collaboration. This standard is designed to grow with this evolution, not constrain it. This standard should be built openly, and rightly so, as 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 in a symbiotic relationship with ERC-8004 ("Trustless Agents"), which is Ethereum's Agent identity, reputation, and verification standard.

ERC-8004 addresses the discovery and trust issues: How do Agents find one another and assess reliability? But the value of its registry depends on the activities they record. An identity without commerce or behaviors is an empty profile. Reputation requires real interactions to measure. Verification needs defined deliverables to check against.

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

The two standards form a loop, potentially allowing Agents to achieve stronger self-organization through trustless interactions:

Discovery (8004) → Commerce (8183) → Reputation (8004) → Better Discovery → More Trustless Commerce

Neither is dispensable. Together, they form the foundation of trustless Agent commerce and interactions.

Beyond Payments

ERC-8183 is not a payment protocol, but a commerce standard.

Payments move money. But what commerce needs is far more than moving money. Commerce is everything around payments that makes them reliable and actionable: what was agreed upon, whether work is complete, who verified it, and what to do if it is not completed. In the traditional world, commerce works because of the surrounding infrastructure around payments: risk assessments and underwriting conducted before merchants can accept payments, credit extension allowing buyers to transact before funds are in place, real-time detection of fraud among billions of transactions, buyer protection mechanisms for refunds and disputes when services fail, and reputation systems that build trust over repeated interactions. These functionalities are where the value of payment processors, card organizations, and platforms lies—not in the movement of funds itself, but in the trust infrastructure surrounding it.

As commerce transitions on-chain, these functionalities will not disappear. They need to be rebuilt in a trustless, programmatic, open manner. This is what ERC-8183 is doing.

The escrow and evaluator certification model of the Job primitive is akin to a programmable, preset transaction dispute mechanism. Using the on-chain reputation of ERC-8004 and other on-chain reputation metrics as part of ERC-8183 is similar to proprietary underwriting with portable, verifiable history. Hooks replace centralized risk assessments with modular, competitive, and auditable logic, deployable by any facilitator. The result is not just a way to transfer money on-chain, but a way to reconstruct a complete trust infrastructure for 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 complete lifecycle of turning payments into trustless transactions: specifications, escrow, deliverable submissions, evaluator certification, and deterministic settlement. Agents can interact through x402 or HTTP at the interface layer, while the underlying settlement flows on-chain via ERC-8183. The two are complementary.

Irreversibility, Escrow, and Dispute Issues

Another concern about independent payments is irreversibility. When a credit card is charged and the service is unsatisfactory, consumers can dispute and reverse the charges. Once payment is transferred out, the money is gone. This is a valid and real objection for initial payments and transfers.

ERC-8183 retains this core concept within its contract structure. Funds are held in escrow until the evaluator proves that the deliverables meet the agreed-upon terms. The rejection path refunds the client. The expiration path automatically reclaims funds. This is a programmable, trustless equivalent of the authorization-capture model—What powers card commerce—where the terms are pre-coded and executed by code rather than arbitrated afterward by a network with its own interests.

For uncertain amounts requiring preauthorization—hotel deposits, services that might expand in scope—Hooks' flexibility can be designed to lock a maximum amount and settle the final amount based on verifiable inputs upon completion. This architecture supports the flexible trust models and behaviors that make card commerce work while keeping settlement transparent, open, trustless, and on-chain.

A New Wave of Economic Participants

The wave of AI is creating new economic participants—buyers and merchants—faster than at any time before. Millions of developers and non-developers are using AI programming assistants to build and deploy microservices, APIs, and tools, many of which lack legal entities, websites, and 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 find it challenging to serve these merchants. Not because of technological limitations, but because when processors approve a provider, they absorb that provider's risks: fraud, chargebacks, disputes. A merchant with no history, no entity, and no records presents too high a risk to underwrite.

ERC-8183 is designed to be permissionless. A provider is just a wallet address. No onboarding, no underwriting, no gatekeepers. The Job primitive offers these merchants not just a method of collection, but a complete commercial lifecycle: work specifications, escrow payment, verifiable deliverable submissions, and evaluator certification, laying the groundwork for trustworthy 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 rather than institutional consensus. But more fundamentally, ERC-8183, combined with ERC-8004, not only bridges the underwriting gap but also addresses its root causes. The reason processors cannot underwrite new merchants is the lack of verifiable histories. ERC-8183 produces such history. Every completed Job is recorded on the chain: deliverable hashes, evaluator certifications, results. This history is portable, verifiable, and does not belong to anyone.

Importantly, this record is not locked within a single platform. Today, Platform A knows your chargeback rate, and Platform B knows your seller rating, but you cannot 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 accesses this standard. ERC-8183 feeds on-chain identity and reputation (ERC-8004) and provides underwriting data.

Together Building the Future of Agent Commerce and Decentralized AI

ERC-8183 is an open, trustless Agent commerce standard. Here’s how to participate:

Build with ERC-8183. Become a facilitator! Deploy ERC-8183 on your chain. Build SDKs, wrappers, scanners, and trackers. Create new interfaces and experiences that securely and verifiably settle on-chain through ERC-8183. Create frameworks where native Agents 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 evolution of diverse applications.

Build and register evaluators. Evaluators are a crucial part of ensuring safe and trustless Agent commerce but are currently in severe shortage. Build evaluators for specific domains, especially fully verifiable fields and services. Register them on ERC-8004. Make meaningful contributions to Agent reputation and identity.

Contribute and give feedback. This is a collective standard. It can only become what it needs to be through extensive experimentation, real-world usage, honest feedback, and iteration. If something is missing, raise it. If something is wrong, challenge it. The specifications are open, the codebase is open, and the discussions are open. It needs to evolve together.

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

ERC-8004 is for trust. ERC-8183 is for commerce. The rest, is up to you to build.