Token-auth strategies

A buyer paying with an ERC-20 needs to authorize the Boson Diamond (or a facilitator) to pull tokens. There are four ways to do this; x402 supports all of them. Picking the right one is a trade-off between buyer signature count and token support.

For the canonical reference, see Concepts → Signing → Token-auth meta-tx.

Strategy	Sig count	Token support
ERC-3009 (receive-with-authorization)	1	USDC, EURC, some others
EIP-2612 (Permit)	1	DAI, many ERCs
Permit2 (Uniswap's)	1	Any ERC-20, via Permit2 contract
Plain approve + commit	2	Any ERC-20

Decision tree

ERC-3009

The buyer signs a ReceiveWithAuthorization payload. The Diamond's executeMetaTransactionWithTokenTransferAuthorization pulls the tokens and executes the call atomically.

EIP-2612 Permit

The buyer signs a Permit payload that grants the Diamond allowance with a deadline. The Diamond consumes the permit + executes the call.

Permit2

Permit2 is a separate contract (Uniswap's). It can hold authority over any ERC-20 the user has approved Permit2 for. Then the buyer signs a Permit2 envelope per use.

The Permit2 contract address is fixed per chain. See Networks → Contract addresses.

Plain approve + commit

Two transactions. The buyer:

Calls IERC20.approve(diamond, amount).
Calls commitToOffer.

Two wallet confirmations. Use only when other strategies aren't available.

Configuring preferences

On the buyer client:

preferredTokenAuth: ["ERC3009", "Permit2", "Permit", "approve"]

The client picks the first one the seller advertises.

Common gotchas

Permit2 requires a one-time setup: the user must approve Permit2 itself for each token. After that, individual uses are gas-less authorizations.
EIP-2612 doesn't work for USDC. USDC has its own non-standard permit. Use ERC-3009 instead.
The chain matters. Permit2 is deployed at the same address on most EVMs but not all. Check.