Gasless USDC Transfers: How Paymasters Work and Who Pays

Every EVM chain charges for computation in its native coin: ETH on Ethereum, POL on Polygon, AVAX on Avalanche. USDC lives inside a contract on those chains, so moving it is a contract call, and a contract call needs gas. A wallet with USDC and nothing else is stuck, even though the USDC is worth far more than the gas.

For years the only answer was: keep a little native coin on every chain you use. That is a poor answer for a multichain user, and the top-up itself needs gas you do not have. It is also the moment where people pick up a scam token that looks like the coin they need; see how to spot a fake token.

The cleaner answer is a gasless USDC transfer: let someone else pay the gas and settle in USDC. That someone else is a paymaster, and the standard that makes it safe is ERC-4337 ^[1].

ERC-4337 is the account abstraction standard, now Final on Ethereum ^[1]. It does not change the chain's rules; it adds a second lane. You sign a user operation instead of a transaction: sender, nonce, call data, gas limits and a signature ^[1].

Signed user operations go to a bundler, a node that collects many of them and wraps them into one ordinary transaction to a single contract called the EntryPoint ^[1]. The bundler pays the chain's gas for that wrapper; the EntryPoint unpacks each operation, asks the sending account to validate it, and runs it ^[1].

The part that matters here is a fourth role. The standard defines a paymaster as a helper contract that agrees to pay for the transaction, instead of the sender itself ^[1]. The EntryPoint validates the account first, then the paymaster, and only then executes the call ^[1].

A paymaster holds a deposit of native coin at the EntryPoint, which draws gas from that deposit rather than from your wallet ^[1]. So the bundler is repaid by the EntryPoint, the EntryPoint by the paymaster, and the paymaster needs to be repaid by you. In a gasless USDC transfer, that last step happens in USDC.

Circle Paymaster is the one we use. It is an onchain contract that lets users pay network gas in USDC instead of the chain's native token, with no Circle account or API key ^[4]. Circle's docs list it on seven mainnets: Arbitrum, Avalanche, Base, Ethereum, Optimism, Polygon and Unichain ^[4].

How does the paymaster take USDC from you without a gas-paying approval? Through EIP-2612, the permit extension to the token standard ^[5]. A permit is a signed message that changes your allowance, so the owner never sends an approve transaction, and it carries a deadline and a nonce so it cannot be replayed ^[5]. You sign a permit that lets the paymaster spend up to a ceiling of your USDC; it pulls what the gas cost and leaves the rest.

The price is not free. Circle's docs say an addition of 10 percent on gas applies on Arbitrum and Base and their testnets ^[4]. That is Circle's line item, not ours; the docs list none on the other chains ^[4].

There was a catch. The EntryPoint only talks to smart accounts, and most people hold USDC at an ordinary address, an EOA controlled by a private key. EIP-7702 solved it, and it went live on Ethereum mainnet with the Pectra upgrade on 7 May 2025 ^[3].

EIP-7702 lets an EOA set code on its own account ^[2]. You sign an authorization naming a delegate contract and the chain it applies to; the chain writes a small delegation indicator into your account that points at that contract ^[2]. Your address stays the same and your key stays in charge; the account simply gains the ability to validate user operations. The EIP was written with sponsorship in mind ^[2].

A first gasless USDC transfer from a fresh wallet includes that authorization, so it needs one extra signature; every later send skips it. We measured this on Amoy: three signatures for the first send, two for the repeat. We also checked that the delegate's bytecode is identical on every chain we enable.

Nothing in the flow moves signing off the phone. When a send on Pay fails for lack of gas, the app offers to pay the network fee in USDC instead. Accept, and our backend prepares the unsigned user operation: nonce, gas fields, the paymaster address and the USDC transfer call. It cannot sign any of it; see how to send crypto for the normal flow it mirrors.

The device then signs up to three things with the key in its secure keychain: the one-time EIP-7702 authorization, the EIP-2612 permit that lets the paymaster pull USDC up to a ceiling, and the user operation itself, hashed the way the v0.8 EntryPoint hashes it ^[6]. The review screen shows the fee, the ceiling and, on a first send, a note that the address is being upgraded.

Before relaying, our backend checks the signed operation against what it prepared. The sender must be the wallet that asked. The recipient must be the screened recipient. The permit must name the paymaster we quoted, at or under the quoted ceiling. And the call data digest must match byte for byte, so nothing can be swapped in after the review screen. Only then does it go to a bundler: prepare, sign on device, relay, as on our security page.

In our first Amoy proof the recipient received the USDC, the sender's balance fell by the amount sent plus a small USDC gas cost, and the sender's POL balance stayed at zero. We later ran the mainnet path end to end and left it enabled; see everyday multichain.

If you build a gasless USDC transfer, the EntryPoint will reject you with short codes before it lets you succeed. The standard groups them: AA1 codes are sender creation errors, AA2 sender validation errors and AA3 paymaster validation errors ^[1].

The first is AA24 signature error, which the EntryPoint raises when the account's validation says the signature does not match ^[6]. It names neither hashing nor delegation, which makes it painful. In our case the device hashed an empty init code, while the v0.8 EntryPoint puts the delegate's address in that slot for an EIP-7702 account, so we signed a different digest from the one the contract recovered. Read the contract's hashing code and pin a fixture from it.

The second is AA33 reverted, which means the paymaster's own validation call failed ^[6]. It arrives with the paymaster's reason appended, and that reason is what you must read. Ours once said the transfer amount exceeded the allowance: our permit ceiling was too small because the paymaster priced gas through its own oracle, which on the testnet quoted the native coin far above market. We fixed it by reading the oracle and extra gas figure from the contract and sizing the permit from those.

The third is the pre-permit allowance revert. Ask a bundler to estimate gas before the user has signed the permit and the paymaster has no allowance to pull, so in our runs simulation reverted with the AA33 code and an allowance message. That is expected, not a bug; our backend treats that pairing as the normal pre-permit case and still reports any other paymaster revert. Estimation accepts things that submission rejects, so the only proof is a landed transaction.

For the user the cost is the network's gas, priced in USDC by the paymaster, plus Circle's addition on the two chains where it applies ^[4]. SpendTheBits adds a small service fee, under 1 percent, on the flows listed on our pricing page; the in-app Fees screen is the source of truth.

Two limits matter. First, the permit leaves whatever the paymaster did not spend as a standing allowance, so we size the ceiling from the contract's own numbers, not a flat figure, and we show it. Second, this is an EVM story; USDC on Solana or the XRP Ledger has its own fee model, and the wallet shows the native balance you need there.

Use a gasless USDC transfer when you hold USDC on a chain and no native coin. If you build agents that pay for things, a signed authorization of the same kind is what makes our x402 payments gasless for the payer.