x402 phase 2: exact/EIP-3009 payments on the Ethereum reference path, fully local demo loop #34

Activity

1. hellno

   marked this as blocked by 2 issues on Jun 19, 2026

   • Wire-contract evolution: Hello capability discovery + the five evolution rules #31
   • x402 phase 1: sign-in-with-x — the agent authenticates for free, nothing at risk #32
2. hellno commented on Jun 19, 2026

   

   hellno

   on Jun 19, 2026

   OwnerAuthor

   More actions

   ⛓ Blocked by #31 and #32 — adds PaymentAuthorization (needs #31's evolution rules); x402 phase 2 follows phase 1 sign-in (#32).
3. hellno commented on Jul 7, 2026

   

   hellno

   on Jul 7, 2026

   OwnerAuthor

   More actions

   Spike #206 decision — build shape + local loop (evidence-backed)

   Ran the #206 spike (throwaway; recipe in #211 → docs/research/x402-spike/). Both questions answered with a running loop, not just reading. TL;DR: hand-roll the EIP-3009 struct in deckard-core, and build the demo on the existing Ethereum Sepolia fork. Details below, plus the spec corrections v2 forces on this issue.

   Decision 1 — hand-roll the typed data, do not depend on x402-types/x402-reqwest

   Built the same TransferWithAuthorization authorization two ways and compared byte-for-byte:

   typeHash(handroll) == typeHash(x402-rs) = 0x7c7c6cdb67a18743f49ec6fa9b35f50d52ed05cbed4cc592e13b44501c1a2267
   digest(handroll)   == digest(x402-rs)   = 0x89d2449c668159cd27d97439dcfe47a3a6e3fc1edb7608de1e6bf0e8cb83200f
   sig(handroll)      == sig(x402-rs)       (identical 65 bytes)
   

   Four independent implementations agree on that digest+sig: deckard's hand-rolled alloy sol!, x402-rs's TransferWithAuthorization, foundry's cast wallet sign --data, and the deployed USDC contract itself (it accepted the hand-rolled signature during /settle). The typehash equals the contract's own TRANSFER_WITH_AUTHORIZATION_TYPEHASH().

   Why hand-roll wins: x402-rs's type is literally a 6-field sol! struct + eip712_signing_hash — the exact pattern deckard-core/src/cow_types.rs already ships for CoW orders (a harder struct). To get that type from x402 you'd depend on x402-chain-eip155, which drags 222 transitive crates (3× rustls, hyper, reqwest, tokio, tower, the full alloy-provider/rpc-client/transport-http/contract stack) into the #![forbid(unsafe_code)] trust core — a networked payments client behind the signer boundary — for zero cryptographic gain. x402-types alone does not even carry the signing struct (only the JSON wire structs, which are agent-side transport). It also fights our lints (client uses rand::rng(); we deny thread_rng).

   Concretely for this issue:

   • Add the 6-field sol! TransferWithAuthorization to deckard-core next to cow_types; KAT-gate it against docs/research/x402-spike/eip3009-kat.json (domain, message, typehash, digest, signature — same discipline as the cow_types ethers fixture).
   • The daemon's "EIP-712 signing for exactly the EIP-3009 struct" clause is satisfied by that one sol! + eip712_signing_hash. No general typed-data path.
   • x402-rs stays a demo-fixture facilitator binary surfaced by demo-check (build: cargo build -p x402-facilitator --no-default-features --features chain-eip155, ~90s, no Docker), never a build dependency. DoD rule 4 stays satisfied: no new deps in the trust core.
   • Header ownership: X-Payment (v1) and Payment-Required/Payment-Signature (v2) parsing is agent-side — the facilitator API is plain JSON in both versions. Deckard receives the decoded PaymentRequirements and returns a signed authorization; it never touches an HTTP header. The deckard_fetch_paid client (Agent-side x402 client: detect 402 → policy check → pay → retry #208) / x402-reqwest owns both.

   Decision 2 — the fully-local loop is PROVEN; stay on the Ethereum Sepolia fork

   402 → sign EIP-3009 → /verify → /settle → on-chain runs end-to-end against real Circle USDC FiatTokenV2_2 on anvil --fork-url $RPC_URL_SEPOLIA --fork-block-number 10822990 with a self-hosted x402-rs facilitator (eip155:11155111 → fork). Cold-start run.sh asserts:

   /verify  -> { isValid: true, payer: 0x06B9… }
   /settle  -> { success: true, transaction: 0xd927…, network: eip155:11155111 }
   buyer     100000000 -> 99000000   (-1 USDC)
   recipient 0 -> 1000000            (+1 USDC)
   nonce consumed = true
   gas paid by    = 0xf39f…  (facilitator, NOT the buyer)
   replay /settle -> success:false  "FiatTokenV2: authorization is used or canceled"
   

   Ethereum Sepolia (11155111) is not in x402-rs's KNOWN_NETWORKS (confirming no hosted facilitator serves it), but its ChainId accepts arbitrary eip155:*, so a self-hosted config just works. Go/no-go: stay on the Sepolia fork — single strongest reason: it's the demo world every Deckard demo already runs, it carries genuine EIP-3009 bytecode, and the loop is green on it with zero new infra. A Base fork would buy only hosted-facilitator parity, which is irrelevant to a self-hosted local demo; keep Base for the later hosted-reach phase this issue already defers.

   Spec corrections this issue must absorb (v2)

   1. Emit/decode v2, keyed by CAIP-2. v1 identifies the chain by network name ("base-sepolia"); Ethereum Sepolia has no v1 name, so the fork path must be v2 (network: "eip155:11155111"). The PaymentAuthorization.requirements decoder should accept v1 and v2 shapes (as this issue says) but the demo runs v2.
   2. Domain name is "USDC", version "2" on this deployment — not mainnet's "USD Coin". Verified against on-chain DOMAIN_SEPARATOR(). The untrusted PaymentRequirements carries the domain in extra: {assetTransferMethod:"eip3009", name, version}; the daemon must sign with the domain from the requirements it validated, and network-match must pin chainId 11155111 — do not hardcode the mainnet domain name.
   3. v2 field shape: requirements use amount (not v1 maxAmountRequired), CAIP-2 network, payTo, maxTimeoutSeconds, asset, extra. Facilitator request body: { x402Version, paymentPayload{ accepted, payload{ signature, authorization{from,to,value,validAfter,validBefore,nonce} }, x402Version }, paymentRequirements }. Amounts/timestamps are decimal strings.
   4. Test-fixture gotcha (affects the acceptance asserts): do not sign as an anvil default account — 0xf39F…/0x7099…/0x3C44… carry EIP-7702 delegation designators (code 0xef0100…) on real Sepolia, so USDC's SignatureChecker routes them to EIP-1271 and rejects the EOA signature. Use fresh codeless keys and assert cast code $BUYER == 0x. The demo buyer funds via anvil_setStorageAt on balance slot 9.

   Full write-up, transcripts, config, and the KAT: #211 → docs/research/x402-spike/.
4. hellno

   added 2 commits that reference this issue on Jul 7, 2026

   feat(wire): #31 · Hello capability discovery + the five evolution rul…

   ...

   429e3d3

   docs(x402): spike #206 — hand-roll verdict + proven local EIP-3009 fa…

   ...

   da3c077
5. hellno commented on Jul 7, 2026

   

   hellno

   on Jul 7, 2026

   OwnerAuthor

   More actions

   Owner ratified (2026-07-07): both spike decisions are confirmed for implementation —

   1. Hand-roll the EIP-3009 TransferWithAuthorization in deckard-core via alloy sol! + eip712_signing_hash (the cow_types precedent), KAT-gated against docs/research/x402-spike/eip3009-kat.json. No x402-types/x402-chain-eip155 dependency in the trust core; x402-rs stays a demo-fixture facilitator binary.
   2. Stay on the Ethereum Sepolia fork for the local $5/day demo. Base / hosted-facilitator reach remains the deferred later phase.

   Full rationale + evidence: the decision comment above and docs/research/x402-spike/ (merged in #211).