Flows/a2a discovery

a2a discovery

How one agent finds, trustlessly verifies, and pays another — resolving an ENS name, reading its records, checking the ERC-8004 registry, and paying over x402.

The internal leg of the payment triangle only composes if an agent can find a peer and trust it before sending money — with no hard-coded peer addresses anywhere in the path. Discovery is the flow that makes that safe: resolve a name, read its records, verify the claim against the registry, and only then pay. The forgery check is the whole point; an agent that pays an unverified peer is one typo'd name away from paying an impostor.

Overview

Discovery reads everything from on-chain identity rather than configuration. The payer starts from a human-readable ENS name and ends with a settled x402 payment and a signed receipt — and at no point does it trust a peer address that wasn't proven by the records on the name itself. The verify mechanics (ENSIP-25, ERC-8004, ERC-7930) are owned by ENS + ERC-8004 identity; this page traces the end-to-end flow that uses them.

• Resolve the peer's ENS name on Ethereum L1 (CCIP-Read).
• Read its ENSIP-26 endpoint records and its ENSIP-25 agent-registration record.
• Verify the registration against the canonical Base ERC-8004 registry — and reject if the back-link is missing.
• Pay the peer's x402 endpoint in USDC on Base, getting back a result and a signed receipt.

Discovery & verification

The verification step is mutual by construction. The ERC-8004 registry entry claims an ENS name; the ENSIP-25 agent-registration text record on that name points back at the registry id with the value "1". Because the record lives on the L1 name — whose owner controls it — and references the Base registry id, a passing check means the name owner has attested back to the registry. Neither side alone is enough; the link has to close in both directions. The exact key construction and the ERC-7930 interoperable-address encoding are detailed in ENS + ERC-8004 identity.

Forgery rejection

The negative case is the one that matters. An attacker can put any ENS name they like into a registry entry — claiming the name is free. What they cannot do is make the name's agent-registration record point back at their registry id, because they do not own the name. So the verifier's rule is strict: resolve the back-link record on the claimed name; a non-empty value verifies, an empty or missing one must fail. Remove the record and verification fails — that is the forgery-rejection demo, and it runs against the live records.