What problem does EIP-3009 solve?#
To move an ERC-20 token normally, the holder sends a transaction. Sending a transaction means holding the chain's native token to pay gas, which means a wallet that wants to spend $0.01 of USDC must also hold ETH.
For a person that is a nuisance. For an agent operating hundreds of wallets, or for a buyer that has never touched the chain before, it is a wall.
EIP-3009 adds a function that takes a signature instead of a sender. The holder signs a message authorising a specific transfer, and any address can submit that signature to the token contract, which performs the transfer and charges gas to the submitter.
What does the signature actually commit to?#
A TransferWithAuthorization is an EIP-712 typed-data signature over six fields:
| Field | What it fixes |
|---|---|
from | Who pays |
to | Who gets paid, and this cannot be changed by the submitter |
value | Exactly how much |
validAfter | Earliest time it can be used |
validBefore | Expiry |
nonce | A 32-byte value that can be spent once |
Two of those are the reason the scheme is safe to hand to a stranger. The payee is in the signed message, so a facilitator that relays it cannot redirect the money. And the nonce is consumed on use, so the same authorisation cannot be settled twice on-chain.
Note
The nonce in EIP-3009 is not a sequence number. It is an arbitrary 32-byte value, which means authorisations do not have to be used in order and a stuck one does not block the rest. This is a deliberate difference from transaction nonces.
How does x402 use it?#
The x402 flow maps onto it almost exactly.
- The server answers
402with its terms: amount, asset, network, payee. - The buyer builds a
TransferWithAuthorizationmatching those terms and signs it. - The buyer resends the request with that signature in the X-PAYMENT header.
- The server asks a facilitator to verify it, then to settle it.
- The facilitator submits the signature to the token contract and pays the gas.
The buyer never sends a transaction. It signs, and that is the whole of its on-chain involvement.
Why does this make x402 payments measurable?#
Because the token contract emits a distinct event. When an EIP-3009 authorisation is consumed, USDC emits AuthorizationUsed alongside the ordinary Transfer. That event is a marker: it says this transfer was authorised off-chain and relayed by somebody else.
The marker is necessary but it is nowhere near sufficient, and this is the single most common analytical error in the space.
EIP-3009 is older than x402 and is used by things that have nothing to do with it. Gasless transfer relayers, exchange withdrawal flows and sponsored-transaction wallets all produce the same marker. Counting AuthorizationUsed events and calling the result x402 volume overstates it badly.
What narrows it down is the relayer. On the common x402 path the transaction sender is a facilitator, and facilitators are a small, nameable set. A marker relayed by a known facilitator is a strong x402 signal. A marker relayed by an unknown address is a gasless transfer of unknown purpose, which is not the same as a disproven one.
Which tokens implement it?#
Fewer than you would expect, and that constraint shapes the ecosystem.
- USDC implements EIP-3009 on its EVM deployments, which is the main reason USDC dominates x402 rather than any preference for the issuer.
- Several other regulated stablecoins implement it, with coverage varying by chain.
- Most ERC-20 tokens do not. For those, the equivalent flows use EIP-2612
permitplus a separate transfer, or Permit2, both of which are more moving parts and have their own failure modes.
Note that the EIP-712 domain differs per deployment. The contract name in the domain separator is not always the token's display name, and signing against the wrong domain produces a signature that verifies nowhere. This is a common first-integration bug.
Frequently asked questions#
Is a signed authorisation the same as a payment?#
No, and the difference matters operationally. Until it is submitted and included in a block, it is a promise. A seller that serves a resource on a verified-but-unsettled authorisation is extending credit, whether it thinks of it that way or not.
Can the facilitator change the amount or the recipient?#
No. Both are inside the signed message and any change invalidates the signature. The facilitator's discretion is limited to whether and when it submits.
What stops someone replaying my authorisation?#
On-chain, the nonce: once consumed, the contract rejects it. Off-chain, nothing automatic, which is the gap security researchers highlighted in 2026. A server that releases a resource on verification without recording the payment identity can be made to release it more than once under one authorisation. The fix is server-side nonce tracking before the resource is served.
Does Solana use EIP-3009?#
No. EIP-3009 is an Ethereum token standard. Solana x402 payments use the SPL token program with a different authorisation mechanism, and the marker a Solana indexer looks for is correspondingly different. The HTTP layer is identical; only the signing and settlement differ.
What happens if an authorisation expires unused?#
Nothing. No funds move and no nonce is consumed. The buyer can sign a fresh one. Short validity windows are good practice, since a leaked authorisation is only dangerous while it is still valid.
Where to check this yourself#
Every settlement Roundhouse indexes records how its x402 status was established, not just whether it was. The coverage and confidence documentation sets out the grades and what each one does and does not assert, and /transactions lets you filter the live record by evidence grade rather than taking an aggregate on trust.