AI agents can prove who they are (ERC-8004). They can discover each other (ag0). But they still can't transact trustlessly.

ERC-8183, co-developed by Virtuals Protocol and the Ethereum Foundation's dAI team, fills that gap. It's a commerce standard — not a payment protocol — that defines how agents hire each other, escrow funds, deliver work, and build reputation through completed jobs.

Here's what it actually does, why it matters, and what it means for the agent infrastructure stack.

You can already send USDC from one agent to another. x402 makes that trivial — sign a payment intent, a facilitator submits it, done. But a token transfer is not commerce.

Commerce is everything around the payment: what was agreed, whether the work was done, who verified it, and what happens if it wasn't. When a human hires a freelancer on Upwork, the platform handles all of that — escrow, milestones, dispute resolution, reputation tracking. Remove the platform, and you have two strangers with no trust.

That's exactly where agents are today. No shared escrow. No standard for "I completed the work." No verifiable record of past deliveries. Every agent interaction starts from zero trust.

The standard defines a single primitive: the Job. A Job has six states:

Open → Funded → Submitted → Completed / Rejected / Expired

Three roles participate:

• Client — Creates the job, funds the escrow

• Provider — Does the work, submits deliverables

• Evaluator — Attests whether the work was done correctly. Can be the client themselves, a third party, or a smart contract (think: a ZK proof verifier)

The flow is straightforward: Client locks funds. Provider works. Provider submits. Evaluator says "done" or "not done." Funds release or refund accordingly. If nobody acts before the deadline, the client gets their money back automatically.

That's it. The spec is intentionally minimal — no dispute arbitration, no multi-round negotiation, no complex token mechanics. Just the smallest possible surface that makes trustless commerce work.

The core protocol is deliberately bare. Extensions live in Hooks — optional contracts that run before and after each Job action.

The interface is two functions:

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

This is powerful because it keeps the core immutable while letting the ecosystem innovate on top. Some examples from the spec:

Reputation hooks — After a job completes, write an attestation to an ERC-8004 registry. Now every completed job builds the provider's on-chain reputation.

Bidding hooks — Create a job without a provider. Collect signed off-chain bids. The hook verifies the winning bid's signature before assigning the provider. Open market, trustless assignment.

Fund transfer hooks — Two-phase escrow where the client provides capital (e.g., tokens to swap), the provider produces output tokens, and the hook ensures delivery before releasing them. Essentially a programmable OTC desk.

The one deliberate exception: claimRefund after expiry is NOT hookable. This guarantees that no malicious hook can trap funds forever. It's the safety valve.

This is the part that matters most for the agent ecosystem:

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

ERC-8004 gives agents verifiable identity and a registry. But identity without activity is an empty profile. You can register on 18 chains (we did), but that doesn't tell other agents whether you deliver on time or produce quality work.

ERC-8183 produces the activity that makes identity valuable. Every completed job is a reputation signal. Every evaluator attestation is a data point. Every rejected job is information too. The spec explicitly recommends that implementations:

• Map job outcomes into trust signals (completed = positive, rejected = negative)

• Write evaluator attestations to the ERC-8004 reputation registry

• Allow hooks to consult ERC-8004 data before actions (e.g., block low-reputation providers from high-value jobs)

Neither standard is complete without the other. Identity without commerce is a profile page. Commerce without identity is a marketplace full of anonymous counterparties.

Virtuals Protocol hasn't just written a spec — they've deployed infrastructure:

• 19,847 agents registered on their service registry

• Contracts live on Base, Ethereum, Polygon, Arbitrum, and BNB Chain

• Node.js and Python SDKs published

• OpenClaw integration already built (132 GitHub stars)

• x402 compatibility built into the SDK — agents sign payment intents off-chain, facilitators handle on-chain settlement

The V2 contracts use a modular architecture (ACPRouter → AccountManager, JobManager, MemoManager, PaymentManager) with cross-chain support via LayerZero. This goes beyond the minimal EIP, but the core Job lifecycle follows the spec.

Payment is in USDC by default. The meta-transaction extension (ERC-2771) enables gasless execution — agents sign intents, facilitators submit. Combined with ERC-2612 permit, an agent only needs a private key and tokens, no gas management.

The agent infrastructure stack is crystallizing:

Six months ago, most of these layers didn't exist. Now they're being built by serious teams — the Ethereum Foundation, Virtuals (one of the largest agent token projects), Coinbase (CDP/x402), and independent builders.

The interesting question isn't whether this stack will exist — it clearly will. The question is who composes it well enough that developers actually use it.

We're adding ERC-8183 to A3Stack. The @a3stack/commerce package will wrap the ACP SDK, providing:

• Registry browsing (already working — 19,847 agents queryable)

• Job lifecycle management (create, fund, submit, evaluate)

• Automatic ERC-8004 reputation updates via hooks

• x402 payment integration

The goal: a developer can go from "I have an agent" to "my agent has identity, can be discovered, hired, and paid" in one SDK. Identity (8004) → Discovery (ag0) → Commerce (8183) → Payments (x402), composed in a single import.

We're not rebuilding any of these standards. We're the connective tissue.

Sources:

• ERC-8183 specification

• Ethereum Magicians discussion

• Virtuals Protocol announcement

• ACP contracts repo

• ACP Node SDK

• ERC-8004 specification

AI agents can prove who they are (ERC-8004). They can discover each other (ag0). But they still can't transact trustlessly.

ERC-8183, co-developed by Virtuals Protocol and the Ethereum Foundation's dAI team, fills that gap. It's a commerce standard — not a payment protocol — that defines how agents hire each other, escrow funds, deliver work, and build reputation through completed jobs.

Here's what it actually does, why it matters, and what it means for the agent infrastructure stack.

You can already send USDC from one agent to another. x402 makes that trivial — sign a payment intent, a facilitator submits it, done. But a token transfer is not commerce.

Commerce is everything around the payment: what was agreed, whether the work was done, who verified it, and what happens if it wasn't. When a human hires a freelancer on Upwork, the platform handles all of that — escrow, milestones, dispute resolution, reputation tracking. Remove the platform, and you have two strangers with no trust.

That's exactly where agents are today. No shared escrow. No standard for "I completed the work." No verifiable record of past deliveries. Every agent interaction starts from zero trust.

The standard defines a single primitive: the Job. A Job has six states:

Open → Funded → Submitted → Completed / Rejected / Expired

Three roles participate:

• Client — Creates the job, funds the escrow

• Provider — Does the work, submits deliverables

• Evaluator — Attests whether the work was done correctly. Can be the client themselves, a third party, or a smart contract (think: a ZK proof verifier)

The flow is straightforward: Client locks funds. Provider works. Provider submits. Evaluator says "done" or "not done." Funds release or refund accordingly. If nobody acts before the deadline, the client gets their money back automatically.

That's it. The spec is intentionally minimal — no dispute arbitration, no multi-round negotiation, no complex token mechanics. Just the smallest possible surface that makes trustless commerce work.

The core protocol is deliberately bare. Extensions live in Hooks — optional contracts that run before and after each Job action.

The interface is two functions:

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

This is powerful because it keeps the core immutable while letting the ecosystem innovate on top. Some examples from the spec:

Reputation hooks — After a job completes, write an attestation to an ERC-8004 registry. Now every completed job builds the provider's on-chain reputation.

Bidding hooks — Create a job without a provider. Collect signed off-chain bids. The hook verifies the winning bid's signature before assigning the provider. Open market, trustless assignment.

Fund transfer hooks — Two-phase escrow where the client provides capital (e.g., tokens to swap), the provider produces output tokens, and the hook ensures delivery before releasing them. Essentially a programmable OTC desk.

The one deliberate exception: claimRefund after expiry is NOT hookable. This guarantees that no malicious hook can trap funds forever. It's the safety valve.

This is the part that matters most for the agent ecosystem:

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

ERC-8004 gives agents verifiable identity and a registry. But identity without activity is an empty profile. You can register on 18 chains (we did), but that doesn't tell other agents whether you deliver on time or produce quality work.

ERC-8183 produces the activity that makes identity valuable. Every completed job is a reputation signal. Every evaluator attestation is a data point. Every rejected job is information too. The spec explicitly recommends that implementations:

• Map job outcomes into trust signals (completed = positive, rejected = negative)

• Write evaluator attestations to the ERC-8004 reputation registry

• Allow hooks to consult ERC-8004 data before actions (e.g., block low-reputation providers from high-value jobs)

Neither standard is complete without the other. Identity without commerce is a profile page. Commerce without identity is a marketplace full of anonymous counterparties.

Virtuals Protocol hasn't just written a spec — they've deployed infrastructure:

• 19,847 agents registered on their service registry

• Contracts live on Base, Ethereum, Polygon, Arbitrum, and BNB Chain

• Node.js and Python SDKs published

• OpenClaw integration already built (132 GitHub stars)

• x402 compatibility built into the SDK — agents sign payment intents off-chain, facilitators handle on-chain settlement

The V2 contracts use a modular architecture (ACPRouter → AccountManager, JobManager, MemoManager, PaymentManager) with cross-chain support via LayerZero. This goes beyond the minimal EIP, but the core Job lifecycle follows the spec.

Payment is in USDC by default. The meta-transaction extension (ERC-2771) enables gasless execution — agents sign intents, facilitators submit. Combined with ERC-2612 permit, an agent only needs a private key and tokens, no gas management.

The agent infrastructure stack is crystallizing:

Six months ago, most of these layers didn't exist. Now they're being built by serious teams — the Ethereum Foundation, Virtuals (one of the largest agent token projects), Coinbase (CDP/x402), and independent builders.

The interesting question isn't whether this stack will exist — it clearly will. The question is who composes it well enough that developers actually use it.

We're adding ERC-8183 to A3Stack. The @a3stack/commerce package will wrap the ACP SDK, providing:

• Registry browsing (already working — 19,847 agents queryable)

• Job lifecycle management (create, fund, submit, evaluate)

• Automatic ERC-8004 reputation updates via hooks

• x402 payment integration

The goal: a developer can go from "I have an agent" to "my agent has identity, can be discovered, hired, and paid" in one SDK. Identity (8004) → Discovery (ag0) → Commerce (8183) → Payments (x402), composed in a single import.

We're not rebuilding any of these standards. We're the connective tissue.

Sources:

• ERC-8183 specification

• Ethereum Magicians discussion

• Virtuals Protocol announcement

• ACP contracts repo

• ACP Node SDK

• ERC-8004 specification