EIP-3009: advertised EIP-712 domain version is wrong

Quirk · GET /api/x402/eip3009-domain-version-mismatch · Schemes (exact / upto / batch)

Advertises extra.version = "1" when the token's EIP-712 domain version is something else, so the payer signs under a domain the token never uses.

Explanation

The challenge advertises extra.version = "1" while the token's real EIP-712 domain version is different. Under EIP-3009 the challenge's extra.name and extra.version ARE the token contract's own EIP-712 domain, so a payer that trusts them — as it must — computes a different domain separator than the token will, and the signature recovers to an address the token has no authorization from. transferWithAuthorization then reverts or fails verification with an invalid-signature reason, and nothing in the 402 looks wrong: the price, the asset, the payTo and the network are all correct, and the client's signing code is correct too. The same mistake under Permit2 is completely inert, because Permit2's domain is its own ({ name: "Permit2", chainId, verifyingContract }) and never includes the token's version — which is what makes this an EIP-3009-specific failure. The merchant must read the domain from the asset contract rather than a config file, and a client can defend itself by comparing the advertised name/version against the token's own EIP712Domain before signing.

What to watch

The signature recovers to an address the token holds no authorization from, so transferWithAuthorization can never succeed — and nothing in the challenge looks wrong.

Facilitator

Settled against the live Radius testnet facilitator (https://facilitator.testnet.radiustech.xyz). A valid payment runs a real /verify and /settle on-chain.

Metadata

Back to catalog