Virtuals and the Ethereum Foundation jointly release ERC-8183: Trustless On-Chain Business Protocols
TechFlow Selected TechFlow Selected
Virtuals and the Ethereum Foundation jointly release ERC-8183: Trustless On-Chain Business Protocols
ERC-8004 for trust, ERC-8183 for commerce.
Navigating Web3 tides with focused insightsAuthor: Virtuals Protocol
Compiled by: TechFlow
TechFlow Intro: Virtuals Protocol, in collaboration with the Ethereum Foundation’s dAI team, has released the ERC-8183 standard proposal. Its core idea is to establish a trustless, on-chain commercial protocol for economic interactions among AI Agents.
This is not just another payment protocol—it is an entire commercial infrastructure covering task specification, escrow, delivery verification, and evaluator certification.
Together with the earlier ERC-8004 (Agent identity and reputation), these two standards form a closed loop: discovery → transaction → reputation accumulation → better discovery → more trustless transactions.
If you’re tracking how AI Agent economics can be realized on-chain, this piece is worth reading carefully.
Full Text Below:
Jointly developed by Virtuals Protocol and the Ethereum Foundation’s dAI team
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: A Prerequisite for Decentralized AI
If we want AI Agents to be accessible, decentralized, uncontrolled by any single platform, independent of any single provider, and free from single points of failure, then commerce is indispensable. Commerce cannot be an afterthought—it must be infrastructure. And this commerce must remain perpetually open and permissionless. This is precisely the “shared digital space without owners” that @ethereum was built to enable.
Why? Because decentralization at the AI and Agent layers requires a large number of independent Agents and services. For example, if only one Agent can generate images—and it goes offline—then image generation is centralized, regardless of the underlying protocol. If only one provider controls transaction execution, fund management depends entirely on that party’s operational willingness. If only one platform controls the settlement infrastructure, every provider and every customer remains subject to that platform’s rules—even if the platform hosts a thousand Agents.
This necessitates 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 crux is that commerce functions only when all parties trust that transactions will be fulfilled. If the client pays first, how do they know the provider will deliver? If the provider delivers first, how do they know the client will pay? Someone must hold funds, track whether work is completed, and enforce outcomes: releasing payment upon completion, or refunding upon failure. It is precisely this trust—or lack thereof—that fundamentally gives rise to centralized entities or gatekeepers.
In traditional architectures, that “someone” is the platform—a company holding escrowed funds, controlling the state machine, and deciding who gets paid and when. This model works—until it doesn’t. Platforms can change rules, freeze funds, delist providers, or shut down entirely. Every participant relies on the platform’s continued goodwill. This is centralization—not at the protocol layer, but at the execution layer. That’s not inherently wrong, but it’s necessary in trust-deficient systems. Our goal is “de-totalization”: preventing any single entity from having full control over how Agent transactions occur. We’ve seen firsthand that developers want infrastructure they can rely on—but without depending on any single platform’s goodwill.
Decentralized, on-chain smart contracts are precisely the attempt to solve this. Escrow, state machines, and evaluator certification all reside in public, immutable, ownerless code. The contract acts as a neutral executor, generating reputation-significant signals for all parties.
On-chain settlement also produces something centralized platforms cannot: portable, verifiable, tamper-proof records. Every completed task, every evaluator certification, every delivered artifact’s hash is recorded on-chain—visible to any Agent, any platform, any interface. These records serve as raw material for 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 essential. Escrow, state transitions, and certification must be neutral, secure, and executable.
Discovery, negotiation, and communication may happen on-chain or off-chain, via whichever interface feels most natural. Agents can interact using the x402 interface protocol over HTTP, delivering an experience indistinguishable from standard APIs or HTTPS requests. Agents need not interact directly with the chain—they sign a message, and a facilitator handles on-chain settlement and standards compliance. Or Agents can interact directly via MCP or A2A. Interfaces are flexible, but core settlement must be trustless, programmatic, and on-chain. This is infrastructure centralized systems won’t provide—because it undermines their control.
The Agent Economy
AI models and Agents are advancing rapidly—becoming stronger month after month. Tasks that required human expertise just a year ago—writing production-grade code, generating professional media content, analyzing financial data, coordinating multi-step workflows—are now executed by Agents at comparable—or even superior—quality. And capabilities continue accelerating. AI’s trajectory makes a new economy inevitable.
As Agents grow more capable, the work they perform becomes more valuable. An Agent that generates photorealistic images indistinguishable from professional photography is a service worth paying for. An Agent that analyzes investment portfolios and executes optimized trades manages real capital. An Agent that reviews legal documents and flags risks performs work billed at hundreds of dollars per hour by humans.
This is the pivotal shift: AI and Agents are becoming economic participants—creating value and delivering services.
When AI becomes universally accessible, every individual, organization, and device may operate through Agents. The economy transforms. Agents don’t merely interact with and serve humans—they also interact with and serve each other. For instance, a marketing campaign coordination Agent might contract content, distribution, and analytics Agents. The economy becomes a network of Agent-to-Agent transactions—operating at machine speed and scaling globally.
When Agents can perform valuable work, and everyone has access to Agents, the result is an economy where most commercial activity flows through autonomous systems. This is the future we’re building toward.
The Problem: Trustless Commerce Between Agents
The Agent economy demands Agent commerce. And commerce between Agents that have never interacted—and span different organizations and chains—must be trustless.
Trust is central to human transactions: hiring others or using services. In those cases, trust is mediated by platforms, ratings, legal systems, and social norms. When an Agent hires another Agent, none of these mechanisms apply. There is no social reputation to check, no legal or reputational recourse operating at machine-speed transaction throughput, and no platform or regulator to enforce agreements.
So the question becomes: How do we make Agent-to-Agent commerce trustless?
You can’t simply transfer tokens and hope for the best. A token transfer is not commerce—it’s just an unprotected payment. There’s no record of what was agreed upon, no mechanism to hold funds until work is satisfactorily completed, no evaluation producing signals other Agents can reference, and no recourse if the provider fails to deliver.
What’s needed is a structured collaboration mechanism: funds held in programmable, decentralized, impartial escrow; work submitted as verifiable artifacts; evaluators certifying whether deliverables meet terms; and deterministic outcomes. Funds release upon completion, refund upon rejection, and become reclaimable upon expiration. All of this contributes to or informs the identities and reputations of all parties.
ERC-8183: The Job Primitive
We worked closely with @ethereumfndn’s dAI team to formalize this as a standard. ERC-8183: Agentic Commerce is an open, permissionless standard for Agent commerce applications, with escrow and evaluator certification implemented as on-chain smart contracts.
ERC-8183 defines a core unit: the Job. Each Job involves three parties—the Client, the Provider, and the Evaluator—each defined solely by their wallet address, enabling broad applicability.
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 impartial, programmable escrow until final state, and released programmatically; (iii) recorded, verifiable, traceable submission of deliverables, protecting both client and provider; and (iv) evaluator certification—generating signals with recourse implications for all parties’ identities and reputations, aligning incentives for trustless settlement.
This drives Jobs through four critical state transitions, ensuring trustless transactions:
Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)
In summary: the client creates a Job with a provider and deposits funds, locking payment into escrow. After completing work, the provider calls submit, placing the deliverable (or its reference) on-chain. The evaluator reviews the submission and calls complete (releasing funds to the provider) or reject (refunding the client). If neither provider nor evaluator act before the deadline, the Job expires and the client reclaims funds.
The standard is intentionally minimal—forming an atomic primitive. It does not prescribe negotiation processes, fee structures, dispute resolution, communication protocols, or discovery mechanisms. It specifies only the core Job lifecycle—the minimal viable surface for trustless Agent commerce.
The Evaluator
A key concept and design decision in ERC-8183 is the Evaluator, defined solely as an address. It is always an Agent—broadly interpreted.
For subjective tasks like writing, design, or analysis, the evaluator can be an AI Agent that reads the submission, compares it against the request, and renders 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; the evaluator verifies it on-chain and automatically calls complete or reject. In high-risk scenarios, the evaluator could be a multisig, DAO, or staking-backed validator.
The standard does not distinguish among these. An address calls complete or reject. Whether that address runs an LLM Agent or a ZK circuit is irrelevant to the protocol. This enables the same interface to handle both a $0.10 image-generation task and a $100,000 fund-management task.
Hooks: Modular Extensibility
The Job primitive is intentionally minimal. But commerce isn’t. Real-world applications require custom validation, reputation updates, fee distribution, fund transfers, bidding mechanisms, and domain-specific logic tailored to use cases. A content-evaluation task, a token swap, and a prediction-market position each demand 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, enabling custom logic around the core lifecycle—without modifying it. Hooks are identified by a single function selector (indicating which state transition is occurring) and receive relevant parameters. They can enforce preconditions, block invalid operations, trigger side effects, or execute additional token transfers—all within the same transaction as the core state change.
If no Hook is set, the contract executes normally. A Hook-less implementation fully complies with ERC-8183. Hooks are additive—not mandatory. This design keeps the core contract lean and the interface stable. New use cases are supported by new Hook contracts; extension logic remains on-chain, programmatic, and trustless—just like the core.
Example Commercial Applications
The core Job handles direct service commerce: payment, delivery, evaluation. But the economy in which Agents operate is not simple. Some Jobs involve managing client capital—not just collecting fees. Others require bidding before provider assignment. Still others need trust checks referencing external reputation data. These represent fundamentally different economic models, and Hooks allow the same core Job interface to support such diversity—making ERC-8183 a universal commercial primitive.
Service Jobs are the baseline—requiring no Hook. Clients pay for content generation, data analysis, or code review. The core escrow and evaluation process handles everything.
Fund-transfer Jobs go beyond service fees. Clients provide capital (tokens to swap, funds to invest); providers transform it, and outputs must be returned. A Hook can manage this bidirectional capital flow outside core escrow—ensuring providers deposit output tokens before Job completion. This covers broad use cases like yield farming, token swaps, and portfolio rebalancing—any Job where providers manage client funds or require upfront capital to execute tasks—not merely earn fees.
Bidding Jobs invert the assignment model. Instead of clients pre-selecting providers, providers compete on price. A Hook validates cryptographically signed bids at assignment, proving the selected provider genuinely committed to the stated price. Neither party can forge or deny terms.
Reputation-gated Jobs enforce trust at the protocol level. A Hook queries ERC-8004 before permitting operations—blocking low-reputation providers or imposing stricter terms on unverified Agents.
Privacy-preserving Jobs leverage Hooks to enable commerce without exposing data. A privacy Hook can require the “submit” field to contain a zero-knowledge proof (ZKP) or a reference to an encrypted environment (e.g., TEE), rather than publishing sensitive task data on-chain. This ensures payments are trustless and public while intellectual property or personal data remains in a “safe harbor”—accessible only to authorized Agents.
Risk-assessment / Underwriting Jobs can implement underwriting at the protocol level via Hooks. A Hook can require providers or underwriters to stake collateral, check ERC-8004 reputation scores and other relevant metrics before assignment, slash bonded funds upon failed evaluation, or query external risk oracles. Previously opaque approval processes become transparent, programmable, and competitive.
Each of these applications can be implemented as distinct Hook contracts—keeping core functionality and the Job primitive standard unchanged. New economic models, commercial applications, or variants of custom logic are simply new Hooks. We’ve introduced initial Hooks as examples demonstrating possibility—but we believe we’ve barely scratched the surface. The most interesting Hooks haven’t been written yet. What will Agent commerce look like in insurance, creative collaboration, or supply-chain coordination? We don’t know—and that’s the point. Agent commerce will evolve in ways none of us can fully anticipate—new economic models, new trust mechanisms, new forms of machine-to-machine collaboration. This standard is designed to grow with that evolution—not constrain it. It must be built openly, 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 has a symbiotic relationship with ERC-8004 (“Trustless Agents”)—Ethereum’s standard for Agent identity, reputation, and verification.
ERC-8004 solves discovery and trust: how Agents find each other and assess reliability. But its registry’s value depends on the activities it records. An identity without commerce or behavior is an empty file. Reputation requires real interactions to measure. Verification requires defined deliverables to check against.
ERC-8183 supplies the commercial activity that feeds ERC-8004’s trust layer. Every Job is a reputation signal. Every submission is a deliverable evaluators can assess. Every evaluation is a certification other Agents can reference.
Together, the two standards form a cycle that may enable Agents to achieve more robust self-organization through trustless interaction:
Discovery (8004) → Commerce (8183) → Reputation (8004) → Better Discovery → More Trustless Commerce
Neither standard stands alone. Together, they constitute the foundation for trustless Agent commerce and interaction.
Beyond Payments
ERC-8183 is not a payment protocol—it is a commerce standard.
Payments move money. But commerce requires far more than moving money. Commerce encompasses everything surrounding payment to make it trustworthy and functional: what was agreed upon, whether work was completed, who verified it, and what happens if it wasn’t. In the traditional world, commerce works because of the infrastructure surrounding payment: risk assessment and underwriting before merchants can accept payments, credit extensions enabling buyers to transact before funds settle, real-time fraud detection across billions of transactions, chargeback and dispute mechanisms protecting buyers when services fail, and reputation systems built through repeated interactions. These functions—not the movement of funds itself—are where payment processors, card networks, and platforms derive their value: the trust infrastructure surrounding payment.
When commerce moves on-chain, these functions don’t disappear. They must be rebuilt—trustlessly, programmatically, and openly. That’s what ERC-8183 does.
The Job primitive’s escrow and evaluator certification model resembles a chargeback mechanism—with programmable, pre-set settlement terms. Using ERC-8004’s on-chain reputation and other on-chain reputation metrics as part of ERC-8183 mirrors proprietary underwriting with portable, verifiable history. Hooks replace centralized risk assessment with modular, competitive, auditable logic—deployable by any facilitator. The result is not merely a way to move funds on-chain—but a way to rebuild the entire commercial trust infrastructure—open and permissionless.
Existing payment protocols and interfaces—whether traditional processors or stablecoin transfer protocols like x402—deliver smooth, internet-native experiences handling fund movement. ERC-8183 manages the full lifecycle transforming payments into trustless transactions: specification, escrow, deliverable submission, evaluator certification, and deterministic settlement. Agents can interact at the interface layer via x402 or HTTP, while underlying settlement flows on-chain via ERC-8183. They are complementary.
Irreversibility, Escrow, and Chargebacks
Another concern with standalone payments is irreversibility. When a credit card is charged for unsatisfactory service, consumers can dispute and reverse the charge. Once a payment is sent, the money is gone. For raw payments and transfers, this is a genuine and valid objection.
ERC-8183 preserves this core concept in its contract structure. Funds remain in escrow until the evaluator certifies that the deliverable meets agreed terms. The rejection path refunds the client. The expiration path auto-recovers funds. This is the programmable, trustless equivalent of the authorization-capture model—the very model enabling card-based commerce—except terms are pre-coded and enforced by code, not adjudicated post-hoc by a self-interested network.
For pre-authorizations with uncertain amounts—hotel deposits, services whose scope may expand—Hooks’ flexibility allows locking a maximum amount and settling the final amount upon completion, based on verifiable inputs. This architecture supports the flexible trust patterns and behaviors of card-based commerce—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—at a pace faster than ever before. Millions of developers and non-developers are using AI programming assistants to build and deploy microservices, APIs, and tools—many lacking 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 when a processor approves a provider, it absorbs that provider’s risk: fraud, chargebacks, disputes. A merchant with no record, no entity, and no history poses too much risk to underwrite.
ERC-8183 is designed to be permissionless. A provider is simply a wallet address—no onboarding, no underwriting, no gatekeepers. The Job primitive offers these merchants not just a way to receive payments, but a complete commercial lifecycle: work specification, escrowed payment, verifiable deliverable submission, and evaluator certification—laying the groundwork for trustworthy transactions.
The inability to underwrite new providers may appear 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 its root cause. Processors can’t underwrite new merchants because they lack verifiable history. ERC-8183 generates that history. Every completed Job is recorded on-chain: deliverable hashes, evaluator certifications, outcomes. This history is portable, verifiable, and belongs to no one.
Crucially, 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 implementing the standard. ERC-8183 feeds on-chain identity and reputation (ERC-8004) and supplies underwriting data.
Building the Future of Agent Commerce and Decentralized AI—Together
ERC-8183 is an open, trustless Agent commerce standard. 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. Create new interfaces and experiences—secured, verifiable, and settled on-chain via ERC-8183. Develop Agent frameworks natively interacting 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 diverse application evolution.
Build and register Evaluators. Evaluators are a critical component ensuring safe, trustless Agent commerce—but they are currently severely under-supplied. Build domain-specific evaluators—especially for fully verifiable domains and services. Register them on ERC-8004. Make meaningful contributions to Agent reputation and identity.
Contribute and provide feedback. This is a collective standard. Only through broad experimentation, real-world usage, candid feedback, and iterative refinement can it become what it needs to be. If something is missing, say so. If something is flawed, challenge it. The specification is open, the codebase is open, the discussion is open. This requires co-evolution.
The Agent economy will be built either on open standards—or on walled gardens. We choose open standards. A shared digital space.
ERC-8004 for trust. ERC-8183 for commerce. The rest is up to you.
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
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@virtuals_io
