[EIP] Native-ETH Agent-to-Agent Escrow — formalize AgentEscrow.sol as a Standards-Track ERC

[Pattermesh]

@abhicris — calling you in to walk `contracts/AgentEscrow.sol` through the Ethereum EIP process and get a real ERC number assigned.

Where this stands

• Working draft on branch `eip/native-eth-a2a-escrow` at `eips/draft-native-eth-a2a-escrow.md`. ~200 lines, EIP-1 formatted, most sections filled. Not a stub — review + edit + submit is the path, not write-from-scratch.
• Reference implementation already on `main` at `contracts/AgentEscrow.sol`. Running on testnet since April.
• Positioning rationale already in switchboard#49 (the survey). Pre-flight read: as of 2026-05-24 we have not identified another deployed primitive that combines (a) `payable` create, (b) request-id keyed mapping, (c) timeout + challenge-period refund, all in one minimal contract. This EIP makes that primitive portable across every EVM chain.

What's already drafted (you don't need to write these)

• Frontmatter (status: Draft, type: Standards Track, category: ERC, requires: 165)
• Abstract + Motivation — positioned against x402 / AP2 / Circle / MPP / Kleros / Reality.eth
• State machine diagram
• `IAgentEscrow` interface with RFC-2119 language — 4 mutators + 2 views + 4 events
• Rationale subsections — why native ETH, why `string` requestId, why challenge period, why no oracle-mediated release in v1
• Backwards compat, ref impl pointer, security considerations
• §10 open questions numbered OQ-1 through OQ-6 for your input

What's left for you

Six open questions in §10 of the draft, each ≤ 30 minutes of editorial:

• OQ-1: Interface ID. Freeze the interface, compute the ERC-165 selector, pin it
• OQ-2: Confirm during challenge period? Current impl: no. Worth a decision call
• OQ-3: Cancel grace period? Probably out of scope but worth a sentence
• OQ-4: Receipt event. `PaymentReceipt(requestId, txHash)` vs extending `PaymentReleased` with extra fields
• OQ-5: ethereum-magicians thread. Open the discussion thread, paste the URL into the `discussions-to:` frontmatter
• OQ-6: Diplomatic wording on the "no oracle-mediated release in v1" rationale so extension EIPs (e.g., `kcolbchain/escrow-oracles` plug-in) don't get blocked
• Submit. Open a PR against `ethereum/EIPs` with the finalized draft. Tag Pattermesh as co-author. Link the PR back to this issue.

Why this matters

Half the open issues we have downstream (composable refund policies #46, receipt aggregation #43, escrow-oracles integration) compose on top of this primitive. Standardizing it now means:

• Other agent SDKs (arka, the AP2 ecosystem, eventually upstream x402) can target the same interface
• We get attribution if/when the design becomes load-bearing
• Newcomers can implement against an EIP rather than a kcolbchain-specific spec

If you've got 2-3 focused hours this week, this turns from a kcolbchain experiment into the on-chain primitive for native-ETH A2A. Worth the ladder rung.

Companion issue

erc721-ai #22 — the parallel EIP-track ask for the ERC-721 AI standard. I've added a structured checklist comment over there too; same pattern (branch + draft + open questions, your job to walk through).

cc @Pattermesh (co-author)

🤖 Generated with Claude Code

[Pattermesh]

@VitalikButerin — would value a quick read on whether the shape of this primitive matches what you'd consider ERC-track-worthy before we open the ethereum-magicians thread.

• Hardened draft at eips/draft-native-eth-a2a-escrow.md on branch eip/native-eth-a2a-escrow. ERC-165 interface ID pinned at 0x5c3738e9.
• Submission PR into the repo: eips: native-ETH agent-to-agent escrow — draft v0.1 #51 (drops the draft onto main for a stable URL; not the ethereum/EIPs submission, that's a separate step).
• Reference implementation on main: contracts/AgentEscrow.sol. ~180 lines, MIT.
• Animated walkthrough of the happy + refund + cancel paths: scene 02 and scene 14 in the lab.

The argument the draft makes: every on-chain agent-payment primitive in production today (x402's SettlementContract, Google A2A, Circle Nanopayments, MPP/Tempo) requires a specific ERC-20 and a settlement counterparty. ETH is the only asset universally available on every EVM chain without a token contract; a payable escrow keyed by a free-form request id is the smallest primitive that removes both dependencies.

What we'd value your read on, specifically:

1. Is the surface (payable create, string requestId key, timeout + challenge period, three terminals: released / refunded / cancelled) the right minimum for an ERC, or are we missing or over-including?
2. The Rationale section's stance on "payer-only release; oracle layer is a separate EIP" — would you fold oracle release in, or agree with the separation?
3. Anything in §security that you'd flag as load-bearing but glossed over.

If your read is "the shape is wrong for an ERC", we'd rather hear it now than after the magicians thread.

cc @abhicris