​EIP-3009 defines transferWithAuthorization and receiveWithAuthorization — two functions that let a token holder authorize a one-time, recipient-specific transfer through an EIP-712 signed message. Authored by Petri Wessman and Yusaku Senga and submitted as EIP-3009, the standard targets stablecoin payment use cases that don't fit cleanly into the allowance-and-spend model of ERC-2612 permit.
​

This article explains the EIP-3009 interface, the authorization message structure, the difference between EIP-3009 and ERC-2612 permit, and the production stablecoins that ship EIP-3009 — including USDC, PYUSD, USDP, and FDUSD. It covers the use cases EIP-3009 was designed for and the gasless payment flows it enables.
​

EIP-3009 adds two functions to an ERC-20 contract:

The signed message follows EIP-712 typed data with a domain separator pinned to the token contract. The nonce is a 32-byte random value (not a sequential nonce like ERC-2612), so the holder can have many authorizations outstanding in parallel.
​

By April 2026, EIP-3009 is implemented by USDC across all Circle-issued chains, by PYUSD on Ethereum and Solana (with the EVM contract using the spec), by USDP, FDUSD, and a handful of other regulated stablecoins.
​

Both standards let a user authorize token movement via signature, but the semantics differ in three load-bearing ways.
​

ERC-2612 sets an allowance. The signature says "spender X may transferFrom up to N tokens at any time." Once the allowance is set, the spender can pull funds whenever they want, up to the cap.
​

EIP-3009 authorizes a specific transfer. The signature says "transfer N tokens from A to B between time T1 and T2." Once the transfer happens, the nonce is consumed; the authorization can't be reused. There is no lingering allowance.
​

ERC-2612 doesn't bind to a recipient. The spender (an approved contract) can use the allowance to send tokens anywhere, including to itself. EIP-3009 binds the destination directly into the signature: a phished EIP-3009 signature for "send 100 USDC to address X" can only send to X. The attacker has to be X to benefit.
​

ERC-2612 has a single deadline. EIP-3009 has both validAfter and validBefore, allowing scheduled payments — sign now, payable in two weeks, expires in three weeks. This fits subscription, escrow, and milestone-based use cases.
​

The standard targets payment flows that don't fit the DeFi allowance model.
​

A merchant runs a payment service that accepts USDC. The customer signs a transferWithAuthorization message; the merchant's relayer submits it on-chain, paying gas. The customer never holds ETH and never pays gas; the merchant nets gas cost out of the payment amount. Common pattern in payroll, vendor payments, and POS systems for stablecoin acceptance.
​

An employer pre-signs transferWithAuthorization messages for upcoming payroll dates. Employees collect their authorizations and submit receiveWithAuthorization when convenient. The employer commits in advance; the employee chooses execution timing. The validAfter field guarantees no early collection.
​

A buyer signs a transferWithAuthorization to a milestone contract, with validAfter = delivery date. The contract claims the funds when conditions are met. No allowance sits exposed; the authorization is single-use and time-bounded.
​

Generic meta-transaction frameworks (Biconomy, OpenZeppelin Defender) accept EIP-3009 signatures alongside ERC-2612 permits. The user signs once; the relayer submits and pays gas, deducting cost from the transferred amount or charging through a separate fee mechanism.
​

The signed message has the following structure:
​

The nonce is a 32-byte value the signer chooses. The token contract maintains a per-account nonce-used bitmap; once a nonce has been spent, future submissions with the same nonce revert.
​

The 32-byte nonce space (versus ERC-2612's sequential uint256) lets a signer issue many parallel authorizations. A payroll system can pre-sign 100 paychecks with random nonces; employees can submit them in any order. ERC-2612's sequential nonces would force serialization.
​

Replay protection works by the bitmap. cancelAuthorization(nonce) is also part of the spec — a signer who wants to revoke an outstanding authorization can call it themselves (paying gas) or sign a cancel message that a relayer submits.
​

EIP-3009 is implemented by stablecoins focused on payment use cases.
​

Circle's USDC supports EIP-3009 across Ethereum, Arbitrum, Optimism, Base, Polygon, Avalanche, and other chains. Circle's stablecoin-evm contracts implement both EIP-3009 and ERC-2612 simultaneously. Most USDC payment integrations route through EIP-3009; DeFi integrations use ERC-2612.
​

PayPal's PYUSD on Ethereum implements EIP-3009 alongside ERC-2612. The dual support reflects PYUSD's positioning across both consumer payments (EIP-3009) and DeFi integrations (ERC-2612).
​

Paxos's USDP and First Digital's FDUSD ship EIP-3009 as standard. Both are issuer-regulated stablecoins emphasizing payment use cases.
​

Tether's USDT does not implement EIP-3009 on Ethereum. USDT integrations relying on signed authorizations typically route through Permit2 or direct approve/transferFrom.
​

The four signed-authorization mechanisms on ERC-20 in 2026:

Use the right tool: EIP-3009 for payments and recipient-bound transfers; ERC-2612 for DeFi allowances; Permit2 when the spender needs to handle arbitrary tokens.
​

Stablecoin orchestration platforms accept multiple authorization formats as inputs. Eco's stablecoin orchestration network treats EIP-3009 as a primary intake format for payment-style flows: a customer signs transferWithAuthorization on the source chain, Eco's solver layer fronts liquidity on the destination chain, and the source-chain authorization is submitted to release the customer's funds. The recipient-bound nature of EIP-3009 (only the named recipient can claim) maps cleanly to onchain merchant payments and B2B settlement. Read the Permit1 deep dive for the ERC-2612 comparison and the essential ERC standards reference for the broader catalog.
​

Both functions execute the same transfer but differ in who can submit. transferWithAuthorization can be submitted by anyone, including a third-party relayer. receiveWithAuthorization requires msg.sender equals the recipient, preventing front-running by other relayers who might intercept the signed message.
​

USDC implements both. Payment integrations typically use EIP-3009 (recipient-bound, one-shot). DeFi integrations typically use ERC-2612 (allowance-based). Circle's contracts expose both interfaces simultaneously.
​

Yes. The spec includes cancelAuthorization(nonce) — the signer can submit a cancellation transaction (paying gas) to invalidate an outstanding nonce. Some implementations also support a signed cancel message that a relayer can submit on behalf of the signer.
​

EIP-3009 binds the recipient into the signature; a phished EIP-3009 signature can only send to the named recipient. ERC-2612 sets an allowance with no recipient binding; a phished permit can drain to any spender-controlled address. For payment flows where the recipient is the load-bearing piece of trust, EIP-3009 is safer.
​

Permit2 itself is a separate framework. Permit2 wraps tokens with universal signature-based transfer, but it doesn't translate EIP-3009 signatures. A token holder using EIP-3009 calls the token's own function directly, not through Permit2.
​