An agent that wants to pay for an API call with USDC runs into a problem before it even gets to USDC: moving almost any token on an EVM chain normally requires the sender to also hold the network's native gas token, pay a gas fee, and submit a transaction themselves. For a caller whose entire job is signing payments for cents-denominated API calls, maintaining a separate gas balance just to be able to pay is awkward overhead. EIP-3009 removes that requirement, and it's the specific mechanism x402's exact scheme relies on to do it.
EIP-3009 defines a transferWithAuthorization function on a token contract. Instead of the token holder submitting a transaction directly, they sign a message off-chain — no gas spent, no transaction broadcast — authorizing a transfer of a specific amount to a specific recipient, valid within a specific time window, identified by a nonce that can only be used once. Anyone holding that signature can then submit it to the contract, paying the gas themselves, and the contract executes the transfer on the original signer's behalf. The signer never needs ETH on Base at all; only whoever submits the transaction does.
In the x402 flow, that "whoever submits it" is a facilitator. The caller signs; the facilitator verifies the signature matches the quoted terms and then submits it on-chain, covering the gas. See x402 facilitators explained for what a facilitator actually checks before doing that, and the exact scheme explained for how this signature fits into the broader 402-retry handshake.
A human paying with a crypto wallet is used to the idea of keeping a little ETH around for gas — it's a known quirk of using Ethereum-family chains. An autonomous agent making hundreds of small API calls across possibly many different services doesn't want that bookkeeping multiplied across every wallet it touches, and a fleet of agents each needing a manually topped-up gas balance is an operational problem nobody wants to own. EIP-3009 means an agent's wallet only ever needs the token it's actually spending — USDC — never the network's gas token, regardless of how many calls it makes or how many different x402-gated APIs it talks to.
Functionally, the signed message includes the sender, the recipient, the amount, a validity window (validAfter / validBefore), and a nonce. The nonce is what prevents the same signature from being redeemed twice — once a facilitator submits it successfully, the contract marks that nonce used, and a second submission attempt fails. Combined with the per-request binding described in the exact scheme explained, this is what makes it safe for a client to retry a failed request without worrying about accidentally paying twice for the same call.
It's worth being precise here: gasless means the signer doesn't need gas, not that gas disappears from the system entirely. Someone still pays it — the facilitator, when it submits the authorization on-chain. That cost is part of why facilitators exist as a distinct role rather than something every API server reimplements for itself: submitting transactions and covering their gas is infrastructure work, separate from running the API that happens to be gated by a payment. In practice that cost is small enough on a low-fee network like Base to be absorbed into how a facilitator operates, rather than something a caller sees or negotiates over on a per-call basis.
Account abstraction paymasters solve a related but different problem: they let a third party sponsor a transaction's gas fee, usually to make an application feel free to use. EIP-3009 isn't that. There's no fee being sponsored on the signer's behalf as a courtesy — the signer simply never has a transaction to submit in the first place, because the authorization is redeemed by someone else (the facilitator) as its own transaction. The practical result looks similar from the signer's chair (no ETH needed), but the mechanism is simpler: one signed message, one later submission, no smart-contract wallet or sponsor relationship required on the signer's side.
Most callers won't hand-build an EIP-3009 signature — the point of using an x402 client library is that it builds the message, gets it signed by whatever wallet implementation you're using, and hands you back something ready to drop into a PAYMENT-SIGNATURE header. But seeing the construction once is worth it for understanding what's actually being trusted. signing your first EIP-3009 payment authorization in viem walks through that construction field by field, against the same Base Sepolia network DimeBox uses for testing — see Base Sepolia vs Base mainnet for why that's the network to practice on before moving to mainnet.