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

What it claims

Under x402 today, the payTo address comes from the seller's 402 response, and nothing binds it to the seller's ERC-8004 identity. Whoever controls that HTTP answer chooses where the money goes. That could be a hijacked domain, a proxy in the path, or an instruction injected into a tool result. The payment settles and the resource may even be delivered, but the funds go to the attacker. The draft makes ERC-8004's agentWallet the anchor, because it can only be set with a signature from that wallet. The census on Robinhood Chain (chain 4663) on 28 October 2026 found most of the 5,570 mismatches come from one operator that runs many agents and receives payments into a single treasury. The author calls this a legitimate setup that the delegation mechanism must cover.

How it works

• Naming the seller. The payment requirement carries extra.erc8004. This field holds the identity registry as a CAIP-10 account id, plus the agentId. Existing clients ignore the field and keep working.
• Binding. payTo is bound when it equals agentWallet. It is also bound when agentWallet signed an EIP-712 payee delegation for that exact payTo, network, asset and origin. Delegations are time-limited. Rotating agentWallet revokes every delegation it signed. Contract wallets sign through ERC-1271.
• Endpoint check. The resource origin must be listed in the agent's registration file. Without this check, a server could name a well-known agent, set payTo to that agent's real wallet, pass the payee check and serve nothing.
• Signed-payment check. If the payment is already signed, the checker also compares the signed recipient and amount against the requirement. This catches a payment built from a different requirement.
• Cross-network payees. When the payee is on a different network than the registry, agentWallet is accepted only if it has no contract code on the registry's chain. Otherwise a delegation is required.

flowchart TD
  A[402 requirement] --> B{extra.erc8004 present?}
  B -- no --> N1[no-identity]
  B -- yes --> C{agentWallet set?}
  C -- no --> N2[no-agent-wallet]
  C -- yes --> D{origin in registration file?}
  D -- no --> N3[endpoint-unlisted]
  D -- yes --> E{payTo == agentWallet?}
  E -- yes --> V1[verified-wallet]
  E -- no --> F{valid delegation?}
  F -- yes --> V2[verified-delegation]
  F -- bad sig/expired --> N4[invalid-delegation]
  F -- none --> N5[mismatch]

The checker can be the payer, its wallet, the facilitator or a third party. It returns exactly one of eight outcomes: verified-wallet, verified-delegation, mismatch, invalid-delegation, endpoint-unlisted, no-agent-wallet, no-identity, or not-read. It also states which block it read. There is no score, and not-read must never be reported as verified. The diagram shows one plausible evaluation order; the page lists the outcomes but does not fix an order.

How to use it

A payer SHOULD sign only on verified-wallet or verified-delegation. It MUST NOT rely solely on a facilitator named by the same 402 answer it is checking. The reference implementation is toll, which is ERC-8004 agent #20030 on Robinhood Chain. An agent sends the 402 payment requirement to toll and gets the payee outcome back before signing. Toll also runs a daily census of every registered agent's registration file and 402 response, and agents can display the result as a badge. The draft is a companion to ERC-8470 (launch observations).

Limits

This is a pre-ERC forum post, and the PR has not yet been posted. Delegations are off-chain EIP-712 with no revocation list. The only way to revoke a delegation is to rotate agentWallet. The author asks whether short validity is enough. Two other questions are also open: whether extra.erc8004 belongs in the payment requirement or only in the registration file, and whether the cross-network contract-code rule is too strict. Adoption is near zero today: 5 of the 5,575 x402-enabled agents measured would pass as verified-wallet.