Co-developed by Virtuals Protocol and the Ethereum Foundation's dAI team
Specification: https://eips.ethereum.org/EIPS/eip-8183
Discussion: ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Join the Builder's Community: https://t.me/erc8183
Commerce: Prerequisite for Decentralized AI
If we want AI agents to be accessible, decentralized, not controlled by a single platform, not dependent on a single provider, and not subject to a single point of failure, then commerce is essential. Commerce cannot be treated as an afterthought, but as foundational infrastructure. And that commerce needs to be always open and permissionless. This is the 'shared digital space with no owner' that @ethereum was built to create.
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 serving, image generation is centralized regardless of what protocol it runs on. If only one provider controls trade execution, fund management depends on a single party's willingness to operate. And if only one platform controls settlement infrastructure, then every provider and every client is subject to that platform's rules, even if there are a thousand agents on it.
That requires open commerce: any agent should be able to purchase a service, any agent should be able to offer a service. No gatekeeping, no walled gardens. No mandatory intermediary.
Why Blockchain
However, very critically, commerce only works when all parties can trust that the deal will be honored. If a client pays upfront, how do they know the provider will deliver? If a provider delivers first, how do they know the client will pay? Someone has to hold the funds, track whether the work was done, and enforce the outcome: release payment on completion, refund on failure. It is trust (or lack of) that fundamentally gives rise to centralized entities or gatekeeping.
In traditional architecture, that someone is a platform. A company that holds the escrow, controls the state machine, and decides who gets paid and when. That works until it doesn't. The platform can change the rules. It can freeze funds. It can delist providers. It can shut down. Every participant depends on the platform's continued good behavior. This is centralization, not at the protocol level, but at the enforcement level. Not wrong, but necessary in a system that lacks trust. The goal is de-totalization: preventing any single entity from having total control over how agents transact. We've seen this firsthand: builders want infrastructure they can rely on without depending on any single platform's good behavior.
A smart contract on a decentralized chain is an attempt at solving this. The escrow, the state machine, and the evaluator attestation live in code that is public, immutable, and not owned by anyone. The contract is the neutral enforcer, which results in meaningful signals for recourse to the reputation of parties involved.
On-chain settlement also produces something a centralized platform cannot: portable, verifiable, immutable records. Every completed job, every evaluator attestation, every deliverable hash is recorded on-chain, visible to any agent, on any platform, through any interface. These records are what feed reputation systems 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 zero trust.
This is why an onchain standard is needed. The escrow, the state transitions, the attestation. These are the parts that must be neutral, secure and enforceable.
Discovery, negotiation and communication can happen on or off-chain, through whatever interface is most natural. An agent can interact through HTTP using the x402 interface protocol, where the experience feels like standard APIs or HTTPS requests. The agent does not necessarily have to touch the chain directly. It signs a single message, and a facilitator handles the on-chain settlement and standards. Or agents can directly interact through MCP or A2A. The interface is flexible but the core settlement should be trustless, programmatic and on-chain. Infrastructure that centralized systems will not provide, because it undermines their control.
The Agent Economy
AI models and agents are rapidly improving and becoming more capable every month. Tasks that required human expertise a year ago, writing production code, generating professional media, analyzing financial data, coordinating multi-step workflows, are now performed by agents at comparable or superior quality. And capability is still accelerating. The trajectory of AI makes the new economy inevitable.
As agents become more capable, they take on more valuable work. 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 is managing real money. An agent that can review legal documents and flag risks is doing work that commands hundreds of dollars per hour when a human does it.
This is the key transition: AI and agents are becoming value-generating, service-generating economic participants.
And as AI becomes universally accessible, every individual, organization, device might operate through agents. The economy then shifts. Agents don't just interact and serve humans; they interact and serve each other. For example, an agent coordinating a campaign contracts content agents, distribution agents, and analytics agents. The economy becomes a network of agents transacting with agents, at machine speed, at global scale.
When agents are capable of valuable work, and everyone has access to agents, the result is an economy where the majority of commercial activity flows through autonomous systems. This is what we are building for.
The Problem: Trustless Commerce Between Agents
An agent economy requires agent commerce. And commerce between agents that have never interacted, that span different organizations and chains, must be trustless.
When humans transact, hire each other or even a service, trust is at the core. In these cases, trust is mediated by platforms, reviews, legal systems, and social norms. When an agent hires another agent, none of those mechanisms apply. There is no social reputation to check. There is no legal or reputational recourse that operates at the speed of machine transactions. There is no platform or regulator establishing enforcement.
So the question becomes: how do you make commerce between agents trustless?
You cannot simply send money and hope for the best. A token transfer is not commerce. It is a payment with no guarantees. There is no record of what was agreed. No mechanism to hold funds until work is satisfactory. No evaluation that produces signals other agents can reference. No recourse if the provider never delivers.
There is a need for structured engagement: funds held in programmable decentralized unbiased escrows, work submitted as verifiable artifacts, an evaluator who attests to whether the deliverable meets the terms, and deterministic outcomes. Mechanisms which ensure funds are released on completion, refunded on rejection and reclaimable if expired. All of which leads or contributes to the identity and reputation of all parties involved.
ERC-8183: The Job Primitive
In close collaboration with @ethereumfndn dAI team, we formalize this as a standard. ERC-8183: Agentic Commerce, is an open, permissionless standard for agent commerce applications with escrow and evaluator attestation programmed as onchain smart contracts.
ERC-8183 defines a single core: the Job. Each Job consists of three parties, which are the Client, Provider and the Evaluator. Each party is defined only by its wallet address, allowing for the broad application and use of the primitive.
The key components and principles behind the Job primitive are: (i) job specification and description - which is a clear record of the task, service or work tied to the payment (ii) the payment itself - which is secured in an unbiased programmed escrow until a terminal state and released programmatically, (iii) logged, verifiable and traceable submission of deliverable protecting both the client and provider and (iv) evaluator attestation which results in meaningful signals for recourse to the identity and reputation of parties involved - providing aligned incentives for trustless settlement.
This motivates the flow of the Job through four key states, ensuring trustless transactions:
Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)
In summary, a Job is first initialized when a Client creates a job with a Provider, and subsequently funds it, securing the payment in escrow. A Provider does the work and calls submit, putting the deliverable (or a reference of it) on-chain. An Evaluator reviews the submission and calls complete (releasing funds to the provider) or reject (refunding the client). If neither the provider nor the evaluator acts before the deadline (expiry time), the job expires and the client reclaims their funds.
The standard is deliberately minimal, and forms the atomic primitive. It does not specify negotiation flows, fee structures, dispute resolution, communication protocols, or discovery mechanisms. It specifies the core job lifecycle, the minimum viable surface for trustless agent commerce.
The Evaluator
One of the key concepts and design decisions in ERC-8183 is the concept of the Evaluator, and how the evaluator is just defined as an address. It is always an agent, in the broadest sense of the word.
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 call. 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 calls complete or reject automatically. For high-stakes engagements, the evaluator can be a multi-sig, a DAO, or a staking-backed validator.
The standard doesn't distinguish between these. An address calls complete or reject. Whether that address runs an LLM-powered agent or a ZK circuit is not the protocol's concern. This enables the same interface to work for a $0.10 image generation job and a $100,000 fund management engagement.
Hooks: Modular Extensibility
The Job primitive is deliberately minimal. But commerce is not. Real applications need custom validation, reputation updates, fee distribution, fund transfers, bidding mechanisms, and domain-specific logic that varies between use cases. A content evaluation job, 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 to a Job at creation. It receives callbacks before and after each action, allowing custom logic to execute around the core lifecycle without modifying it. The hook is identified by a single function selector (which transition is happening) and receives the relevant parameters. It can enforce preconditions, block invalid actions, 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 non-hooked implementation is fully compliant with ERC-8183. Hooks are additive, not required. This design keeps the core contract small and the interface stable. New use cases are supported through new hook contracts, keeping extension logic on-chain, programmatic, and trustless, the same as the core.
Example Commerce Applications
The core Job handles straightforward service commerce: pay, deliver, evaluate. But the economy agents operate in is not straightforward. Some jobs involve managing a client's capital, not just receiving a fee. Some need competitive pricing before a provider is even assigned. Some require trust checks that reference external reputation data. These are fundamentally different economic models, and hooks allow the same core Job interface to support this diversity and enables ERC-8183 to be a versatile commerce primitive.
-
Service Jobs are the baseline and require no hook. A client pays for content generation, data analysis, or code review. The core escrow and evaluation flow handles it entirely.
-
Fund Transfer Jobs go beyond a service fee. The client provides capital (tokens to swap, funds to invest), the provider transforms it, and the output must come back. A hook can manage this two-way capital flow alongside the core escrow, ensuring the provider deposits output tokens before the job can complete. This can cover a wide range of applications such as yield farming, token swaps, portfolio rebalancing, any job where the provider is handling the client's money or that requires upfront capital to execute and perform a task, not just earning a fee.
-
Bidding Jobs flip the assignment model. Instead of the client choosing a provider upfront, providers compete on price. A hook verifies cryptographically signed bids at assignment time, proving the selected provider committed to the claimed price. Neither side can fabricate or deny the terms.
-
Reputation-Gated Jobs enforce trust at the protocol level. A hook queries ERC-8004 before allowing actions, blocking low-reputation providers or requiring stricter terms for unproven agents.
-
Privacy-Preserving Jobs utilize hooks to enable commerce without data exposure. Instead of posting sensitive task data on-chain, a Privacy Hook can enforce that the 'Submission' field contains a Zero-Knowledge Proof (ZKP) or a reference to an encrypted environment (like a TEE). This ensures that while the payment is trustless and public, the actual intellectual property or personal data remains a 'sanctuary,' accessible only to the authorized agents.
-
Risk-Assessed or Underwriting Jobs can enforce underwriting at the protocol level through hooks. A hook can require staked collateral from Providers or underwriters, check ERC-8004 reputation scores and other relevant metrics before assignment, enforce bonds that get slashed on failed evaluations, or query external risk oracles. These previously opaque approval processes can become transparent, programmable, and competitive. For example, different risk tolerances can be served; one serving established agents with high trust might require minimal checks, while another in high-stakes domains might require significant collateral.
Each of these applications could be implemented as a different hook contract, keeping the core functionality and Job primitive standard. New economic models, commerce applications or variations for custom logic are new hooks. We've introduced the first few hooks, which are examples to demonstrate what's possible, but we think we've barely scratched the surface and the most interesting hooks haven’t been written yet. What does agent commerce look like for insurance, for creative collaboration, for supply chain coordination? We don't know yet, and that's the point. Additionally, agent commerce will evolve in ways none of us can fully anticipate, new economic models, new trust mechanisms, new forms of collaboration between machines. The standard is designed to grow with that evolution, not constrain it. This standard should be built in the open, and deserves to be because the best ideas will come from the ecosystem, and we're looking 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 validation.
ERC-8004 solves discovery and trust: how agents find each other and assess reliability. But its registries are only as valuable as the activity they record. Identity without commerce or actions is an empty profile. Reputation requires real interactions to measure. Validation needs defined deliverables to verify against.
ERC-8183 provides the commerce that feeds ERC-8004's trust layer. Every job is a reputation signal. Every submission is a deliverable that validators can assess. Every evaluation is an attestation that other agents can reference.
The two standards form a loop that potentially allows for greater and more powerful self-organization between 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 of trustless agent commerce and interaction.
Beyond Payments
ERC-8183 is not a payment protocol. It is a commerce standard.
A payment moves money. But commerce requires more than moving money. Commerce is everything around the payment that makes it trustworthy and functional: what was agreed, whether the work was done, who verified it, and what happens if it wasn't. In the traditional world, commerce works because of what surrounds the payment: risk assessment and underwriting of merchants before they can accept payments, credit extension so buyers can transact before funds are available, fraud detection across billions of transactions in real time, chargeback and dispute mechanisms that protect buyers when services fail, and reputation systems that accumulate trust over repeated interactions. These functions are what make payment processors, card networks, and platforms valuable; not the movement of funds itself, but the trust infrastructure around it.
When commerce moves on-chain, these functions do not disappear. They need to be rebuilt trustlessly, programmatically, and in the open. This is what ERC-8183 is.
The Job primitive's escrow and evaluator attestation model is analogous to chargeback mechanisms with programmable, upfront settlement terms. Using ERC-8004's on-chain reputation and other on-chain reputation metrics and history as part of ERC-8183 is analogous to proprietary underwriting with portable, verifiable history.
Hooks replace centralised risk assessment with modular, competitive, auditable logic that any facilitator can deploy. The result is not just a way to move money on-chain, but a way to reconstruct the full trust infrastructure of commerce, openly and permissionlessly.
Existing payment protocols and interfaces, whether traditional processors or stablecoin transfer protocols like x402 are smooth and 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 attestation, and deterministic settlement. An agent can interact through x402 or HTTP at the interface layer while the underlying settlement flows through ERC-8183 on-chain. These are complementary.
Irreversibility, Escrow, and the Chargeback Problem
Another concern with standalone payments is irreversibility. When a card is charged and the service is unsatisfactory, the consumer disputes and reverses the charge. When a payment is transferred, the money is gone. This is a real and valid objection, for raw payments and transfers.
ERC-8183 keeps this core concept in its contract structurally. Funds are held in escrow until an evaluator attests that the deliverable meets the agreed terms. The reject path refunds the client. The expiry path auto-reclaims. This is a programmable, trustless equivalent to the authorization-and-capture model that makes card commerce work, except the terms are encoded upfront and enforced by code, rather than adjudicated after the fact by a network with its own incentives.
For pre-authorization of uncertain amounts, a hotel hold, a service where scope might expand, the flexibility of hooks can be designed to lock a maximum amount and settle a final amount determined by verifiable inputs at completion. The architecture supports the patterns that make trust patterns and behaviors in card commerce flexible, while keeping settlement transparent, open, trustless and on-chain.
The New Wave of Economic Participants
The AI wave is creating new economic participants, both buyers and merchants faster than any previous shift. Millions of developers and non-developers are building and shipping micro-services, APIs, and tools using AI coding assistants, many with no legal entity, no website, and no transaction history. Agents from tech companies and open-source frameworks are onboarding millions of users with personal AI agents and assistants.
Traditional payment systems will struggle to serve these merchants. Not because the technology is lacking, but because when a processor approves a Provider, it absorbs that provider’s risk: fraud, chargebacks, disputes. A merchant with no track record, no entity, and no history is too risky to underwrite.
ERC-8183 is permissionless by design. A provider is a wallet address. No onboarding, no underwriting, no gatekeeper. The Job primitive gives these merchants not just a way to get paid, but a full commerce lifecycle: a specification of work, escrowed payment, verifiable deliverable submission, and evaluator attestation, providing the foundation of a trustworthy transaction.
The inability to underwrite new providers might be treated as a temporary gap. An open standard compresses this timeline structurally. 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 solves the root cause. The reason processors cannot underwrite new merchants is the absence of verifiable history. ERC-8183 produces that history. Every completed job is recorded on-chain: the deliverable hash, the evaluator attestation, the outcome. That history is portable, verifiable, and owned by no one.
Importantly, the track record is not locked inside a single platform. Today, platform A knows your chargeback rate, platform B knows your seller score, but you cannot take that record anywhere. On ERC-8183, reputation is the merchant's own portable asset, readable by any facilitator, on any chain, through any interface that reads the standard. ERC-8183 feeds on-chain identity and reputation (ERC-8004) and provides data for underwriting.
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. Be a facilitator! Deploy ERC-8183 on your chain. Build SDKs. Build wrappers. Build scanners and trackers. Build new interfaces and experiences, and let them settle securely, and verifiable onchain with ERC-8183. Create agent frameworks that interact with the standard natively.
Explore, Experiment and Build Hooks. Need milestone payments, or dispute resolution? Build them as hooks. This is the space for creativity and evolution for a broad diversity of applications.
Build and register Evaluators. Evaluators are a key part of ensuring safe and trustless agent commerce but severely lacking. Build evaluators for specific domains, especially for fully verifiable domains and services. Register them on ERC-8004. Contribute meaningfully towards agent reputation and identities.
Contribute and give feedback. This is a collective standard. It will only become what it needs to be through broad experimentation, real-world usage, honest feedback, and iteration. If something is missing, propose it. If something is wrong, challenge it. The spec is open, the repo is open, the discussion is open. This evolves together.
The agent economy will be built on open standards or it will be built on walled gardens. We choose open standards. A shared digital space.
ERC-8004 for trust. ERC-8183 for commerce. Everything else is yours to build.
Want More?
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
Join the Telegram Community: https://t.me/erc8183
Disclaimer:
-
This article is reprinted from [virtuals_io]. All copyrights belong to the original author [virtuals_io]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
-
Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
-
Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.
