💧EIP-3009 & Standards Comparison
To implement x402 in a way that is user-friendly (gasless for end users) and secure, Madness adopts EIP-3009. Below is a concise comparison between EIP-3009 and commonly used token/authorization patterns.
Summary table
ERC-20 transfer()
Direct transfer
User
~45k gas
✅
User pays gas every time
Simple but user must hold native gas token and pay each TX.
ERC-20 approve() + transferFrom()
Allow DApp to spend
User (approve) + Relayer/DApp (transferFrom)
~90k total (2 TX)
✅
Approve step required (UX friction)
Common for DApps, but requires allowance management & two TXs.
EIP-712 (signing)
Off-chain signature (general)
User signs off-chain
~0 (off-chain)
❌
Low on-device friction, still needs on-chain relay
Signing format used as basis for gasless flows (e.g., 2612, 3009).
EIP-2612 (permit)
Approve via signature
Relayer/contract submits
~50k (single on-chain)
✅
Removes approve TX but still requires token/relayer orchestration
Good for reducing approve UX; still primarily about allowances.
EIP-3009 transferWithAuthorization()
Off-chain signed authorization for transfer
Relayer submits (pays gas)
~50k (relayer pays)
✅
Gasless for user (user signs only)
Off-chain signature + on-chain execution → enables gasless transfers and per-request payments.
*Gas estimates are illustrative and depend on chain conditions; they’re intended to show relative cost/complexity. Why EIP-3009 fits x402
Gasless UX for users: Users only sign a message (EIP-712 format); a relayer executes on-chain and pays gas. For x402 micro-payments this is critical because charging users gas for many tiny payments would be infeasible.
Authorization model: EIP-3009 carries the payment intent in an off-chain signed payload (amount, recipient, validity window, nonce). This fits perfectly with x402’s model of “payment required” → “signed payment authorization” → “on-chain settlement.”
Atomicity & on-chain finality: Unlike purely off-chain schemes, EIP-3009 settlements are on-chain (the relayer calls the token contract), meaning payments are verifiable and final — necessary when servers must unlock data only after confirmed payment.
Simple integration for dApps: No allowance dance, no extra approve transactions. dApps and relayers can accept EIP-3009 authorizations and settle them reliably.
Integrating x402 powered by EIP-3009 gives Madness the ability to support seamless, gasless, per-request payments making it one of the first DeFi platforms to combine web-native payments (x402) with on-chain settlement.
This unlocks a new era of programmable web interactions from pay-per-request data feeds to AI agents that pay autonomously, all secured and verified on-chain.
Last updated