Pre-ERC: x402 Payee Verification for ERC-8004 Agents

What it is

A Pre-ERC draft on Ethereum Magicians (page text dated around 28 October 2026) that adds a payee check to x402 payments between ERC-8004 agents. Today the payTo address comes from the seller's 402 response and nothing ties it to the seller's ERC-8004 identity. Whoever controls that HTTP answer can choose where the money goes: a hijacked domain, a proxy in the path, or an instruction injected into a tool result. The payment still settles and the resource may still be delivered. The PR for the draft had not yet been posted.

How it works

• The payment requirement names the seller in extra.erc8004: the identity registry as a CAIP-10 account id, plus the agentId. Existing clients ignore the field and keep working.
• payTo is bound to the identity if it equals the agentWallet. It is also bound if the agentWallet signed an EIP-712 payee delegation for that exact payTo, network, asset and origin.
• Delegations are time-limited. Rotating the agentWallet revokes every delegation it signed, and there is no revocation list. Contract wallets sign through ERC-1271.
• The resource origin must be listed in the agent's registration file. Without this, any server could name a well-known agent, set payTo to that agent's wallet, pass the check and serve nothing.
• If the payment is already signed, the checker also compares the signed recipient and amount with the requirement. This catches a payment built from a different requirement.
• A checker may be the payer, its wallet, the facilitator or a third party. It returns one outcome and states the block it read. not-read is never reported as verified.

What to do

The draft says a payer SHOULD sign only on verified-wallet or verified-delegation. It also says a payer MUST NOT rely only on a facilitator named by the same 402 answer it is checking.

For a payee on a different network than the registry, the draft accepts the agentWallet only when it has no contract code on the registry's chain. Otherwise it requires a delegation.

The reference implementation is toll (ERC-8004 agent #20030 on Robinhood Chain). An agent sends it the 402 payment requirement and gets the payee outcome before signing. Its daily census reads every registered agent's registration file and 402 response.

Caveats

• The measurement is one chain on one day (Robinhood Chain, 4663, 28 October 2026). Most mismatches come from a single operator that runs many agents into one treasury. The authors call that setup legitimate, which is why delegations exist.
• The authors leave three questions open: whether extra.erc8004 or the registration file alone should carry the identity, whether short validity is enough without per-delegation revocation, and whether the contract-code rule for cross-network payees is too strict.
• The draft is a companion to ERC-8470 (launch observations). The page gives no spec text, schema or delegation typed-data fields, so integrators cannot implement it yet.