EIP-2612 permit() only works for tokens that actually implemented it — and most older tokens (including USDT, and USDC for years) did not. Uniswap's Permit2 is a single canonical contract that retrofits permit-style, signature-based approvals onto EVERY ERC-20. You grant one max approval of a token to Permit2 once, then authorize individual apps with off-chain signatures forever after.
1// You approve Permit2 ONCE per token (a normal ERC-20 approve):2token.approve(PERMIT2, type(uint256).max);34// Afterwards, apps use your signatures via Permit2. Two modes:5// 1) AllowanceTransfer: ongoing allowance WITH an expiration6// 2) SignatureTransfer: one-shot, single-use transfer7struct PermitTransferFrom {8TokenPermissions permitted; // token + amount9uint256 nonce;10uint256 deadline;11}
The model decouples the on-chain approval (given once, to Permit2) from per-app authorizations (given as signatures). Crucially, Permit2 allowances carry an EXPIRATION timestamp, so they auto-revoke — a major safety upgrade over the 'infinite approval that lives forever' pattern that has drained so many wallets.
Trade-off: Permit2 becomes a single contract holding approval to many of your tokens, so it concentrates risk in one place. It is one of the most heavily audited contracts in DeFi, and the expirations plus ordered/unordered nonce schemes limit exposure — but it is still a single target worth understanding before you approve it.
1// Apps request a SignatureTransfer signature, then call Permit2,2// which performs transferFrom on your behalf:3// permit2.permitTransferFrom(permit, transferDetails, owner, signature)4// You never send an on-chain approve to the app itself.
Connect your wallet to mark this lesson as complete
Earn 25 EFFORT tokens