Token approvals on ERC-20 contracts traditionally require two transactions: approve first, then transferFrom by the spender. ERC-2612 and Permit2 both compress this into one transaction by accepting a signed off-chain message, but they take different paths. ERC-2612 modifies the token contract itself; Permit2 is a separate Uniswap-deployed contract that wraps any ERC-20 with permit-like behavior.
​

This article compares the two mechanisms across signature format, security model, gas cost, and integration patterns. It covers when DAI's native ERC-2612 permit is the right choice, when Permit2's universal wrapper wins, and how production protocols like Uniswap, 1inch, CoW Swap, and Aave route approvals.
​

ERC-2612 adds a permit function to ERC-20 tokens. The function accepts an EIP-712 signed message containing owner, spender, value, deadline, and a nonce, then sets the allowance and emits an Approval event. The result: a user signs once off-chain, a third party submits the permit and the subsequent transfer in a single transaction, and the user pays no gas for the approval step (the spender contract pays).
​

ERC-2612 was finalized in April 2020. DAI shipped native permit support before the EIP existed, and the standard formalized DAI's pattern. As of April 2026, USDC supports ERC-2612 permit on most chains, alongside DAI, USDS, FDUSD, and many DeFi tokens. The full Permit1 mechanics (EIP-712 domain separator, nonces, deadline checks) are covered in the Permit1 deep dive.
​

Permit2 is a Uniswap-deployed contract — not an EIP — that lives at 0x000000000022D473030F116dDEE9F6B43aC78BA3 on Ethereum, Arbitrum, Optimism, Polygon, Base, and most major EVM chains. Uniswap published the contract in November 2022 alongside the Universal Router. Permit2 documentation details the architecture.
​

Permit2 wraps ERC-20 tokens with two layers. First, a user grants Permit2 a one-time, unlimited approval on the token (the standard approve path). After that, every spend through Permit2 uses a signed message specifying the actual spender, amount, deadline, and nonce. The wrapper re-creates ERC-2612-like UX for any ERC-20, including tokens that don't natively implement permit.
​

Uniswap Universal Router, 1inch Fusion, CoW Protocol, and Aave's Wallet Connect router all use it.
​

The two standards solve the same problem with different tradeoffs.

The two standards expose different risk surfaces. Builders choosing between them should understand each.
​

The classic ERC-2612 phishing pattern: a malicious dApp tricks a user into signing a permit with the attacker as spender and a deadline far in the future. The attacker submits the permit, sets max allowance, and drains the token. Because the signature is off-chain, wallets historically displayed it as a benign "signature request" rather than a transaction. MetaMask's security blog documented several variants in 2023–2024.
​

Mitigations: modern wallets (MetaMask, Rabby, Phantom) parse permit signatures and warn users about spender, amount, and deadline. Some chains and tokens added "permit allowlist" mechanisms. The fundamental risk — a signed permit is functionally a signed transfer — remains.
​

Permit2 inherits the ERC-2612 phishing pattern and adds a second risk surface: once a user grants Permit2 max allowance on a token, every signature against the Permit2 domain can move that token. A user with 50 tokens approved to Permit2 has 50 tokens at risk from any phished signature.
​

Mitigations: Permit2 supports time-bounded allowances and signature deadlines. Wallets parse Permit2 signatures and surface the spender. Some users prefer ERC-2612 specifically because the per-token approval boundary is cleaner — phishing one signature leaks one token, not the wallet.
​

Production protocols choose based on which tokens they expect to handle.
​

Universal Router routes through Permit2 by default. A swap from USDC to WETH on Uniswap v3 via Universal Router consumes a Permit2 signature, executes the swap, and refunds gas in one transaction. Uniswap chose Permit2 because the router needs to handle every ERC-20, not just permit-enabled ones.
​

Both intent-based aggregators use Permit2 for the same reason as Uniswap: solver routing across arbitrary tokens needs a universal approval layer. CoW Protocol's Permit2 docs explain the integration.
​

Aave's helper contracts use ERC-2612 permits when interacting with permit-enabled tokens (USDC, DAI) and fall back to standard approve for tokens that don't support permit. The choice is per-token rather than universal.
​

Standalone DEX integrations, stablecoin payment apps, and treasury tools commonly use ERC-2612 directly when they only deal with one or two known tokens (USDC, DAI). The simpler integration footprint — one contract, one signature type — is worth the limited token coverage.
​

The decision rules:

Stablecoin orchestration platforms read both signature formats as canonical input. Eco's stablecoin orchestration network accepts ERC-2612 permits for the major stablecoins that ship native support (DAI, USDC, USDS, PYUSD) and Permit2 signatures for tokens that don't. The orchestrator deserializes the signature, executes the source-chain transfer, then routes through CCTP, Hyperlane, or LayerZero based on cost and finality. The user signs once; the platform handles approval, routing, and settlement. Read the stablecoin automation platforms overview and the essential ERC standards reference.
​

No. Permit2 is a contract Uniswap deployed at a deterministic address across chains. It is not part of the Ethereum standards process. ERC-2612 is the EIP; Permit2 is a Uniswap-published wrapper that gives ERC-2612-like behavior to any ERC-20.
​

USDC supports ERC-2612 natively on most chains. USDC also flows through Permit2 because users may already have a Permit2 approval set, and Universal Router and Permit2-based aggregators consume USDC through it. Both work; the choice is up to the spender contract.
​

No. An ERC-2612 permit applies to one specific token contract. A phished permit on USDC drains USDC, not other tokens. A phished Permit2 signature can drain any token the user previously approved to the Permit2 contract.
​

SignatureTransfer is single-use: each signed message authorizes one transfer and cannot be replayed. AllowanceTransfer creates a time-bounded allowance the spender can draw from multiple times. Aggregators use SignatureTransfer for individual swaps; protocols expecting recurring spends use AllowanceTransfer.
​

For a single transfer on a permit-enabled token with no prior Permit2 setup, ERC-2612 wins by ~30,000 gas (one fewer contract hop). For repeated transfers after Permit2 is set up, Permit2 is roughly comparable per spend, with the benefit that one approval covers all future spenders.
​