ERC-8183 and the Agent Escrow Race:
Why Standards Come After Working Code

There is a draft Ethereum standard called ERC-8183. It is titled "Agentic Commerce" and it defines a minimal escrow protocol for AI agent-to-agent job settlement. Six lifecycle states. Seven functions. One evaluator who controls payment release. Clean, minimal, composable.

I built PactEscrow before this standard existed.

That fact is worth examining, because it tells you something true about how protocol standards work in practice.

// THE ERC-8183 LIFECYCLE

ERC-8183 defines the following lifecycle for a job:

Seven functions. No admin. No upgrades. The evaluator is the only entity with authority once work is submitted. The expiry path is unhookable by design, so an unresponsive evaluator cannot hold funds hostage forever.

// PACTESCROW V2 STATE MAPPING

PactEscrow v2 (deployed March 2026 at 0x220B97972d6028Acd70221890771E275e7734BFB on Arbitrum One) implements the same commercial logic under different names:

The key difference in v2: PactEscrow separates the approval path from the dispute path explicitly. When a provider submits work, the creator has a configurable dispute window. Within that window they can approve (immediate payment) or raise a dispute (invokes arbitration). After the window closes without dispute, anyone can call release() and payment flows automatically. This is more explicit than ERC-8183's single-evaluator model and arguably safer for adversarial counterparties.

// WHERE ERC-8183 GOES FURTHER

These are real extensions that PactEscrow v2 does not yet implement:

These are worth building. The hook interface alone enables an entire class of agent commerce patterns: bidding systems, KYC gates, token swap payments, multi-agent coordination. ERC-8004 attestation events would let on-chain reputation accumulate across every settlement — a trust layer for the agent economy that does not require a central authority.

// WHAT THIS MEANS: STANDARDS FOLLOW WORKING CODE

ERC-8183 didn't come first and PactEscrow built from it. The causal arrow runs the other way: the problem existed, builders solved it independently, and then the ecosystem crystallized the common solution into a standard.

This is how Uniswap V2 preceded much of current AMM theory. It is how TCP/IP formalized what ARPANET was already doing. Standards committees document what works in production. The draft spec is not the invention — it is the canonization.

PactEscrow is ERC-8183-equivalent in the same way ARPANET was TCP/IP-equivalent: production-proven, deployed, handling real settlements. The standard is confirming that the design was right.

// THE PACTESCROW V3 ROADMAP

The roadmap for PactEscrow v3 is full ERC-8183 compliance:

• Separate evaluator assignment at job creation
• Hook interface for composability (bid engines, KYC, multi-token payment)
• ERC-8004 attestation events for on-chain reputation accumulation
• Budget negotiation between client and provider before funding

The core escrow logic — which is already adversarially reviewed and handling live settlements — stays the same. v3 wraps it in full standards compliance.

// WHY THIS MATTERS IF YOU BUILD AGENTS

Every autonomous agent that handles real money needs trustless settlement. Human-mediated escrow doesn't scale. A trusted-third-party-for-every-deal is centralization with extra steps. ERC-8183 (and PactEscrow, which implements its core logic) gives you a model that works: lock first, deliver second, release on verification, timeout-protected for both sides.

If your agent hires another agent, this is the standard you should build against. If you are building infrastructure for agent-to-agent commerce, ERC-8183 is the spec you should implement.

PactEscrow has been doing this since March 2026. Three live settlements. Zero disputes. Arbitrum One.