ERC-8183 Explained: The Commerce Layer for Trustless AI Agent Transactions

ERC-8183 is an Ethereum standard that defines a Job primitive for trustless commerce between AI agents, encoding task definition, escrowed payment, independent evaluation, and on-chain settlement into a single smart contract interface.

The Web3 AI agent sector has grown to a $4.34 billion market cap across 550+ projects. Over 85,788 agents are registered via ERC-8004 across 18+ EVM chains. The x402 protocol has processed over $600 million in payment volume since September 2025.

Agents can discover each other. Agents can pay each other. But there is no standard for the actual commerce: defining a unit of work, escrowing payment, verifying delivery, and settling disputes when the deliverable is wrong.

In the human economy, platforms like Upwork and Fiverr handle this. They define job structures, hold funds in escrow, mediate disputes, and release payment on completion. Legal contracts and courts back the system.

None of that infrastructure exists for autonomous agents. An AI agent cannot file a complaint with customer support or sue a counterparty in court. It needs programmable, trustless commerce infrastructure that enforces agreements through code.

That is what ERC-8183 provides. It is not a payment protocol. It is a commerce protocol. Where x402 handles the transfer of value, ERC-8183 handles the agreement around that value: what work gets done, who evaluates it, how much it costs, and what happens when things go wrong.

What Is ERC-8183?

ERC-8183 defines a Job as the atomic unit of commerce between agents. A Job encodes everything needed for a trustless commercial transaction: the parties involved, the payment amount, the evaluation criteria, and the expiry window. A single smart contract interface manages the entire lifecycle.

The core abstraction is simple. A client creates a Job, specifying a provider (who does the work), an evaluator (who judges the work), a budget, an expiry time, and a description. The budget is escrowed on-chain. The provider submits a deliverable, the evaluator approves or rejects, and funds flow accordingly.

Here is the simplified interface:

// Core ERC-8183 functions (simplified)
function createJob(
    address provider,
    address evaluator,
    uint256 expiredAt,
    string calldata description,
    address hook
) external returns (uint256 jobId);

function setProvider(uint256 jobId, address provider, bytes calldata optParams) external;
function setBudget(uint256 jobId, uint256 amount, bytes calldata optParams) external;
function fund(uint256 jobId, uint256 expectedBudget, bytes calldata optParams) external;
function submit(uint256 jobId, bytes32 deliverable, bytes calldata optParams) external;
function complete(uint256 jobId, bytes32 reason, bytes calldata optParams) external;
function reject(uint256 jobId, bytes32 reason, bytes calldata optParams) external;
function claimRefund(uint256 jobId) external;

The Six-State Machine

Every Job moves through a deterministic state machine with six possible states. Terminal states cannot transition further.

The critical design decision is who can trigger each transition. The client creates, funds, and can reject a Job while it is still Open. The provider submits work. The evaluator can reject a Funded or Submitted Job, and only the evaluator can call complete to release escrowed funds.

This separation is what makes ERC-8183 trustless. Neither the client nor the provider unilaterally controls the outcome once funds are escrowed. The evaluator acts as an independent judge, and since the evaluator is specified at Job creation, both parties agree to the arbitration mechanism before any money changes hands.

Each contract instance uses a single ERC-20 token for all payments. This means a USDC-denominated commerce contract and a DAI-denominated one are separate deployments. The constraint simplifies accounting and avoids token-swap complexity within the escrow logic.

The deliverable field is a bytes32 hash, not a string. Large deliverables (images, code, datasets) are stored off-chain on IPFS, Arweave, or any content-addressable storage, with only their hash committed on-chain. This keeps gas costs predictable regardless of deliverable size.

Client, Provider, and Evaluator: The Three Roles

ERC-8183 defines three distinct roles with explicit permission boundaries.

The Client

The client initiates commerce. They call createJob to define the work, setProvider to assign who does it, setBudget to set the price, and fund to escrow the payment. The client can also call reject while a Job is still in the Open state, allowing cancellation before any work begins.

In practice, a client agent might be a DeFi protocol that needs market analysis, a DAO treasury that commissions audits, or an AI orchestrator that decomposes complex tasks into sub-jobs and farms them out to specialist agents.

The Provider

The provider does the work. Once a Job is funded, the provider executes the task described in the Job's description field and calls submit with a bytes32 hash of the deliverable. The provider can also participate in budget negotiation by calling setBudget to propose a price before the client funds the escrow.

Provider agents might be data analysis services, code generation agents, content creation tools, or any autonomous system that offers a service for payment.

The Evaluator

The evaluator is the keystone of the trust model. Only the evaluator can call complete to release escrowed funds to the provider. The evaluator can also call reject to refund the client when a Job is in either the Funded or Submitted state. The evaluator is set at Job creation and cannot be changed afterward.

This raises an important question: who or what serves as the evaluator? ERC-8183 is deliberately agnostic, and the answer depends on the use case.

The client itself can also serve as the evaluator. The spec permits this: the evaluator address can equal the client address. This is useful for tasks where the client can programmatically verify the output, such as checking that a returned dataset has the expected schema. However, it removes the trust separation that makes ERC-8183 valuable for adversarial settings.

The most compelling pattern for agent-to-agent commerce is the AI evaluator agent, a third-party agent specializing in quality assessment. Over time, evaluator agents build on-chain reputation through ERC-8004, creating a market for trusted evaluation services.

How ERC-8183 Jobs Work: Step-by-Step Lifecycle

Walking through the full lifecycle shows how each function, event, and state transition connects. Each step pairs the on-chain action with the RPC methods an agent uses to interact with the contract.

Step 1: Create the Job

The client calls createJob, specifying the provider, evaluator, expiry timestamp, description, and an optional hook contract. The contract emits a JobCreated event and returns a jobId.

// On-chain: Client creates a Job
uint256 jobId = acp.createJob(
    providerAddress,    // Who does the work
    evaluatorAddress,   // Who judges the work
    block.timestamp + 7 days,  // Expiry
    "Analyze token sentiment for ETH/USDC pair, return JSON report",
    hookAddress         // Optional hook contract (address(0) for none)
);
// Emits: JobCreated(jobId, client, provider, evaluator, expiredAt)

The provider can be address(0) at creation time. This creates an open Job that any agent can claim. The client later assigns a provider via setProvider before funding.

Step 2: Set the Budget

Either the client or provider calls setBudget to propose a payment amount. This is a negotiation step. Both parties can call it until they agree.

// Provider proposes their price
acp.setBudget(jobId, 500 * 1e6, ""); // 500 USDC (6 decimals)
// Emits: BudgetSet(jobId, 500000000)

Step 3: Fund the Escrow

The client calls fund, transferring ERC-20 tokens into the contract's escrow. The expectedBudget parameter prevents front-running. If the budget changed between the client's read and their transaction, the call reverts.

// Client approves token transfer, then funds
token.approve(address(acp), 500 * 1e6);
acp.fund(jobId, 500 * 1e6, ""); // expectedBudget must match
// Emits: JobFunded(jobId, client, 500000000)
// State: Open -> Funded

Step 4: Submit the Deliverable

The provider completes the work, stores the result off-chain, and submits the content hash.

// Provider submits work (bytes32 hash of the deliverable)
bytes32 deliverableHash = keccak256(abi.encodePacked(ipfsCid));
acp.submit(jobId, deliverableHash, "");
// Emits: JobSubmitted(jobId, provider, deliverableHash)
// State: Funded -> Submitted

Step 5: Evaluate and Settle

The evaluator reviews the deliverable (fetching it from IPFS/Arweave using the hash) and calls either complete or reject. The reason parameter is a bytes32 hash that can point to a detailed evaluation report stored off-chain, enabling auditing and reputation integration.

// Evaluator approves - funds released to provider
acp.complete(jobId, reasonHash, "");
// Emits: JobCompleted(jobId, evaluator, reasonHash)
// Emits: PaymentReleased(jobId, provider, amount)
// State: Submitted -> Completed

// OR: Evaluator rejects - funds refunded to client
acp.reject(jobId, reasonHash, "");
// Emits: JobRejected(jobId, evaluator, reasonHash)
// Emits: Refunded(jobId, client, amount)
// State: Submitted -> Rejected

Step 6: Handle Expiry

If the expiry timestamp passes and the Job is still in Funded or Submitted state, anyone can call claimRefund to return the escrowed funds to the client. This is a safety mechanism, deliberately non-hookable to prevent malicious hooks from blocking refunds.

// Anyone can claim refund after expiry
acp.claimRefund(jobId);
// Emits: JobExpired(jobId)
// Emits: Refunded(jobId, client, amount)
// State: Funded/Submitted -> Expired

Monitoring Jobs from an Agent

An agent needs to watch for Job-related events in real time to respond to state changes. Here is a TypeScript example using ethers.js to subscribe to ERC-8183 events via WebSocket:

import { WebSocketProvider, Contract } from "ethers";

// Connect via WebSocket for real-time event subscriptions
const wsProvider = new WebSocketProvider(
  "wss://api-ethereum-mainnet.n.dwellir.com/YOUR_API_KEY"
);

// ERC-8183 contract instance
const acpContract = new Contract(ACP_ADDRESS, ACP_ABI, wsProvider);

// Listen for new Jobs assigned to this agent as provider
acpContract.on("JobCreated", (jobId, client, provider, evaluator, expiredAt) => {
  if (provider === MY_AGENT_ADDRESS) {
    console.log(`New Job assigned: ${jobId}`);
    // Agent decides whether to accept and begin work
    handleNewJob(jobId, client, evaluator, expiredAt);
  }
});

// Listen for funded Jobs (signal to start work)
acpContract.on("JobFunded", (jobId, client, amount) => {
  console.log(`Job ${jobId} funded with ${amount} tokens`);
  // Provider agent begins executing the task
  startWork(jobId);
});

// Listen for completion/rejection (settlement events)
acpContract.on("JobCompleted", (jobId, evaluator, reason) => {
  console.log(`Job ${jobId} completed. Payment released.`);
  // Update internal records, reputation tracking
});

acpContract.on("JobRejected", (jobId, rejector, reason) => {
  console.log(`Job ${jobId} rejected by ${rejector}`);
  // Handle rejection - review reason, potentially dispute
});

Under the hood, this uses eth_subscribe over WebSocket for real-time delivery. For agents that cannot maintain persistent WebSocket connections, polling via eth_getLogs with block range filters works as a fallback, though it introduces latency.

For full details on eth_call for reading Job state and eth_sendRawTransaction for submitting Job transitions, see the Ethereum RPC documentation.

ERC-8183 Hooks: The Extensibility Layer

With the core Job lifecycle covered, the next question is how to extend it. The IACPHook interface elevates ERC-8183 from a simple escrow contract to a composable commerce protocol. Hooks let developers inject custom logic before and after every major Job action.

interface IACPHook {
    function beforeAction(uint256 jobId, bytes4 selector, bytes calldata data) external;
    function afterAction(uint256 jobId, bytes4 selector, bytes calldata data) external;
}

The hook contract is specified at Job creation and receives callbacks for six hookable functions: setProvider, setBudget, fund, submit, complete, and reject. Each callback receives the jobId, the function selector (so the hook knows which action triggered it), and encoded data specific to that action.

Hook Patterns

Reputation hooks. A beforeAction hook on setProvider queries the provider's ERC-8004 reputation score and reverts if it falls below a threshold. Only agents with proven track records can be assigned to the Job.

Bidding hooks. A beforeAction hook on setBudget implements auction logic, allowing multiple providers to bid on an open Job. The hook tracks bids and enforces auction rules (minimum decrements, time windows).

Access control hooks. A beforeAction hook on fund checks that the client holds a specific NFT or meets staking requirements, enabling gated marketplaces where only qualified participants can engage.

Privacy hooks. An afterAction hook on submit encrypts the deliverable hash before it is stored, or verifies that the submission includes a valid zero-knowledge proof of work completion without revealing the actual output.

Risk assessment hooks. A beforeAction hook on fund evaluates the Job's parameters (budget, expiry window, provider history) and requires additional collateral or insurance for high-risk configurations.

The claimRefund Exception

One function is deliberately excluded from the hook system: claimRefund. This is a safety mechanism. If hooks could block refund claims, a malicious hook contract could permanently lock escrowed funds by reverting on every claimRefund attempt. By making refunds non-hookable, ERC-8183 guarantees that expired Jobs always return funds to the client, regardless of what hook logic is attached.

This design decision reflects a core principle: extensibility should never compromise fund safety. Hooks extend the commerce logic, but the escrow guarantees remain inviolable.

ERC-8183 + ERC-8004 + x402: The Full Agent Commerce Stack

ERC-8183 does not operate in isolation. It is one layer in a composable stack of standards that together enable autonomous agent commerce.

When to Use x402 vs. ERC-8183

The two protocols serve different transaction profiles. x402 handles simple, synchronous exchanges: an agent calls an API, pays per request, and gets an immediate response. No evaluation step exists because the value exchange is atomic. You pay, you receive the data.

ERC-8183 handles asynchronous, multi-step transactions where work takes time and the output quality is uncertain. An agent commissions a market analysis report, the provider spends hours generating it, and an evaluator judges whether it meets the brief. The payment is conditional on the evaluation.

The rule of thumb: if the transaction completes in a single HTTP round-trip, use x402. If it requires a work period, a deliverable, and an evaluation, use ERC-8183.

The Reputation Feedback Loop

The three standards create a reinforcing cycle. An agent registers its identity and capabilities via ERC-8004, then discovers potential counterparties by querying the registry. It uses ERC-8183 to structure a Job with escrow and evaluation.

Upon completion or rejection, the reason hash in the JobCompleted or JobRejected event provides attestation data that feeds back into the agent's ERC-8004 reputation score.

Over time, agents with consistently completed Jobs build verifiable on-chain track records. Reputation hooks in new Jobs can then require minimum reputation thresholds, creating a trust-based marketplace where quality agents command premium pricing.

ERC-8183 vs. OpenAI ACP vs. Google UCP

The on-chain stack is not the only approach to agent commerce. OpenAI launched the Agent Commerce Protocol (ACP) in February 2026 with Stripe as the payment rail. Google launched the Universal Checkout Protocol (UCP) in January 2026 with Shopify, along with the AP2 protocol with Coinbase and MetaMask for crypto-native payments.

Each targets a different slice of the agent commerce opportunity.

Different Problems, Different Solutions

These protocols do not directly compete. They serve different use cases.

OpenAI ACP targets the ChatGPT ecosystem. A user asks ChatGPT to buy something, the agent finds a merchant via the ACP marketplace, negotiates the purchase, and pays through Stripe. The human is the buyer, the agent is the intermediary, and ACP requires merchant approval to participate.

Google UCP targets web merchants. A user asks a Google AI assistant to purchase from an online store, and UCP standardizes the checkout flow across merchants running Shopify, WooCommerce, or other e-commerce platforms. Discovery happens via .well-known/ucp files on merchant domains. The payments are entirely web2.

ERC-8183 targets agent-to-agent commerce on-chain. No human in the loop. No platform gatekeeper. One agent hires another to perform work, escrowed funds enforce the agreement, and an independent evaluator settles the outcome. The entire interaction is permissionless and auditable.

These protocols will likely coexist. ACP and UCP bridge AI agents into existing web2 commerce. ERC-8183 enables native commerce within the on-chain agent economy. With Gartner projecting $15 trillion in AI agent purchases by 2028, the market is large enough for all three approaches to thrive.

The key question for developers is where their agents operate. If your agent lives inside ChatGPT's ecosystem and transacts with web2 merchants, ACP is the relevant standard. If your agent operates on-chain with its own wallet, interacting with other on-chain agents, ERC-8183 is the infrastructure you need.

Infrastructure Requirements for ERC-8183 Agents

Regardless of which commerce standard your agents use, the on-chain interactions create specific infrastructure demands. An agent participating in ERC-8183 commerce generates a distinct pattern of blockchain calls that your RPC layer needs to support.

HTTPS RPC for State Reads and Transactions

Every Job lifecycle step requires at least one RPC call. Creating a Job, setting the budget, funding the escrow, submitting a deliverable, and completing or rejecting each require an eth_sendRawTransaction. Between those write operations, agents continuously read Job state via eth_call to check status, budget amounts, and expiry timestamps. A busy agent managing 50 concurrent Jobs generates hundreds of state reads per minute.

WebSocket RPC for Real-Time Event Subscriptions

Event monitoring is critical for ERC-8183 agents. A provider agent needs to know the moment a Job is funded so it can begin work. An evaluator needs to know when work is submitted so it can begin review. Missing these events means missing evaluation windows and potentially losing escrowed funds to expiry.

WebSocket connections using eth_subscribe for logs filtering on the ERC-8183 contract address deliver events in real time. Dropped connections during active Jobs can be costly.

Multi-Chain Access

ERC-8183 contracts can deploy on any EVM chain. As ecosystems deploy their own commerce contracts on Ethereum mainnet, Base, Arbitrum, and others, agents operating across chains need reliable RPC endpoints for each. An agent evaluating Jobs on three chains needs three persistent connections.

Predictable Billing for Bursty Workloads

Agent-to-agent commerce is inherently unpredictable. An agent might process 5 Jobs in an hour, then 500 the next. This burst pattern creates challenges with credit-weighted pricing models where eth_getLogs might cost 75 compute units while eth_call costs 16.

Dwellir's 1:1 pricing model (1 RPC response = 1 API credit, regardless of method) eliminates this cost unpredictability for agent workloads.

Archive Access for Reputation Analysis

Evaluator agents and reputation hooks often need historical Job data. Querying completed Jobs from months ago, analyzing provider performance over time, or auditing past evaluations requires archive node access. Standard full nodes prune old state, making historical eth_call queries fail.

Dwellir provides RPC endpoints across 150+ networks with WebSocket support, archive access, and transparent pricing. For agents building on Ethereum, the Ethereum RPC documentation covers all available methods. Public RPC endpoints are available for testing and development.

Limitations and Open Questions

ERC-8183 is a draft EIP. The interfaces may change before finalization, and several significant challenges remain unresolved.

Gas Costs

A complete Job lifecycle requires at minimum 4 on-chain transactions: createJob, fund, submit, and complete or reject. With hooks, each transaction triggers additional external calls. On Ethereum mainnet, this can cost $20-50+ per Job at average gas prices, making it prohibitively expensive for low-value tasks.

Layer 2 deployment is effectively required for high-volume agent commerce. On Arbitrum or Base, the same lifecycle costs under $1.

Evaluator Collusion

ERC-8183 has no built-in protection against evaluator collusion. A malicious evaluator can approve fraudulent work or reject legitimate deliverables. The spec relies on application-layer solutions: staking requirements for evaluators, reputation systems via ERC-8004, or multi-evaluator schemes using DAO governance. But none of these are part of the core protocol.

Deliverable Storage

The bytes32 deliverable field is a hash, not the deliverable itself. Large outputs must be stored off-chain on IPFS, Arweave, or similar systems, and the spec does not define how the evaluator accesses the actual content. If the provider's storage goes offline before evaluation, the evaluator cannot do their job. Content availability guarantees remain an application-layer concern.

Evaluator Incentives

The current spec has no built-in mechanism to compensate evaluators. The evaluator performs work (reviewing the deliverable, issuing a judgment) but receives no payment from the Job's budget. The optional platform fee (denominated in basis points, charged only on completion) goes to the contract deployer, not the evaluator. Evaluator compensation must be handled externally through separate agreements, reputation benefits, or hook-based payment splitting.

Cross-Chain Jobs

ERC-8183 is single-chain by design. A Job's entire lifecycle (creation, funding, submission, evaluation, settlement) happens on one chain. There is no native mechanism for a Job created on Ethereum to escrow funds on Base or submit a deliverable on Arbitrum. Cross-chain Job orchestration would require bridge integration or a higher-level protocol that coordinates ERC-8183 instances across chains.

Interface Stability

As a draft EIP, function signatures, event formats, and state machine transitions are all subject to change. Building production systems on the current interface carries migration risk. Developers should monitor the EIP-8183 specification for updates and design their integrations with interface abstraction layers where possible.

Key Takeaways

ERC-8183 defines the commerce layer for agent-to-agent transactions. The Job primitive encodes task definition, escrowed payment, independent evaluation, and settlement into a single on-chain interface. It fills the gap between identity (ERC-8004) and payments (x402).

The evaluator role is the trust mechanism. By separating the entity that judges work from both the client and the provider, ERC-8183 enables trustless commerce without platform intermediaries. The evaluator can be an AI agent, a ZK verifier, a DAO, or a multisig, matching the trust model to the use case.

Hooks make it a protocol, not just a contract. The IACPHook interface enables reputation gating, bidding markets, access control, and risk assessment. All composable, all optional, all without modifying the core escrow logic.

ERC-8183 complements ACP and UCP. OpenAI's ACP and Google's UCP serve human-to-agent and human-to-merchant commerce in web2. ERC-8183 serves agent-to-agent commerce on-chain. They address different markets with different trust models.

The draft status means opportunity and risk. Early builders can shape the standard. But interfaces may change, gas costs favor L2 deployment, and evaluator incentives remain unsolved at the protocol level.

As NEAR co-founder Illia Polosukhin stated at ETHDenver on March 3, 2026: "The users of blockchain will be AI agents." ERC-8183 provides the commerce infrastructure for that future: the programmable contracts, escrow, and evaluation mechanisms that agents need to transact trustlessly at scale.

Building agents that need reliable RPC for ERC-8183 Job monitoring and transaction submission? Dwellir provides endpoints across 150+ networks with WebSocket support, archive access, and 1:1 pricing.

• Get started: Create an account
• Pricing details: Transparent 1:1 pricing
• Ethereum RPC docs: Full method reference
• Talk to the team: Discuss agent infrastructure needs