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

What it claims

ERC-8478 is a draft that closes a payment-redirection gap in agent-to-agent x402 payments. Today the payTo address comes from the HTTP 402 answer, so whoever controls that answer (a hijacked domain, a proxy in the path, or an instruction injected into a tool result) chooses where funds go. The payment still settles, and the resource may even be delivered. The draft anchors payTo to the ERC-8004 agentWallet, which can only be set with that wallet's signature.

On Robinhood Chain (chain ID 4663) on 28 October 2026, there were 20,046 registered ERC-8004 agents. Of these, 5,575 returned an x402 requirement, and only 5 used agentWallet as payTo. The author attributes most mismatches to one operator that runs many agents and receives into a single treasury. The author calls this legitimate and the case the delegation mechanism exists to cover.

How it works

The draft has five parts.

1. Identity field. The seller names itself in extra.erc8004: the identity registry as a CAIP-10 account ID, plus the agentId. Existing clients ignore the field and keep working.
2. Binding. payTo either equals agentWallet, or agentWallet has 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.
3. Endpoint check. The resource origin must be listed in the agent's registration file. Without this, any server could claim a well-known agent's identity, pay to that agent's real wallet, pass the payee check and serve nothing.
4. 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.
5. Fixed outcome. The checker reports the block it read and returns exactly one of the outcomes below. There is no score, and not-read is never reported as verified.

flowchart TD
  A[402 requirement] --> B{extra.erc8004 present?}
  B -- no --> NI[no-identity]
  B -- yes --> C{agentWallet set?}
  C -- no --> NW[no-agent-wallet]
  C -- yes --> D{payTo == agentWallet?}
  D -- yes --> E{origin in registration file?}
  D -- no --> F{valid delegation?}
  F -- none --> M[mismatch]
  F -- bad --> ID[invalid-delegation]
  F -- yes --> E
  E -- no --> EU[endpoint-unlisted]
  E -- yes --> V[verified-wallet / verified-delegation]

The full outcome set is verified-wallet, verified-delegation, mismatch, invalid-delegation, endpoint-unlisted, no-agent-wallet, no-identity and not-read. The page does not specify the order of checks, so the diagram's ordering is illustrative. The checker can be the payer, its wallet, the facilitator or a third party. A payer SHOULD sign only on the two verified outcomes. It MUST NOT rely only on a facilitator named by the same 402 answer it is checking.

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

How to use it

The reference implementation is toll, ERC-8004 agent #20030 on Robinhood Chain. An agent sends toll the 402 payment requirement and gets the payee outcome back before it signs. Toll's agent census reads every registered agent's registration file and 402 response daily, and agents can show the result as a badge. The page gives no API shape or endpoint for toll. It is a companion to ERC-8470 (launch observations).

Limits

This is a forum draft. The page says the PR "follows shortly," so no spec text exists yet. The authors list three open questions:

• whether extra.erc8004 belongs in the requirement or only in the registration file;
• whether short validity is enough without per-delegation revocation, since delegations are off-chain and rotation is the only revocation;
• whether the cross-network no-contract-code rule is too strict.

The measurement covers one chain on one day.