Permit2: Complete Guide to Token Permissions Done Safely (2026)

If you have used Uniswap, 1inch, CowSwap, MetaMask Swaps or any modern DeFi aggregator in the last two years, there is a very high chance you have already signed a Permit2 message without realizing it. Permit2 is the universal token permission system built by Uniswap Labs in November 2022, and by 2026 it has quietly become the most widely integrated approval contract in all of crypto, sitting at the exact same address 0x000000000022D473030F116dDEE9F6B43aC78BA3 on every major EVM chain.

Permit2 was designed to fix the broken user experience of legacy ERC-20 approvals: the endless "Approve" then "Swap" double-transaction flow, the dangerous unlimited approvals that linger forever, and the fragmentation caused by stablecoins like USDC, USDT and DAI each implementing permit differently (or not at all). It does this by introducing signature-based, time-bound, transferable approvals that work across every ERC-20 token, regardless of whether the token itself supports EIP-2612 permit.

But here is the catch every crypto user needs to internalize in 2026: when you approve Permit2 once for a token, you are granting Permit2 the right to move that token, and any dApp integrated with Permit2 can then request a signature to spend it. That single approval becomes a master key shared across the Permit2 ecosystem. Used properly, this is an enormous UX win and a real security upgrade. Used carelessly, a single malicious signature can drain a wallet in seconds. This guide explains exactly how Permit2 works, how it differs from EIP-2612, which wallets and protocols support it in 2026, how much gas you actually save, the security implications nobody talks about clearly, and the precise revoke process when something goes wrong.

What Is Permit2 in Crypto?

Permit2 is an audited, immutable smart contract deployed by Uniswap Labs at the deterministic address 0x000000000022D473030F116dDEE9F6B43aC78BA3 across Ethereum mainnet, Arbitrum, Optimism, Polygon, Base, BNB Chain, Avalanche, Blast, Linea, zkSync Era, Scroll, Celo and dozens of other EVM networks. It acts as a universal allowance and signature-based transfer layer that sits between your wallet and any dApp that needs to spend your ERC-20 tokens.

In the traditional flow, every protocol asked you for a separate approve() transaction for every token. If you used 10 different dApps with USDC, you paid gas for 10 separate approvals and exposed yourself to 10 separate spender contracts. Permit2 collapses that into a single, shared, programmable approval layer. You approve Permit2 once for a token (an on-chain approve call to the ERC-20). After that, any integrated dApp can request a gasless signature from your wallet, and Permit2 will pull the tokens directly through its permitTransferFrom function, subject to the limits and deadline you signed.

Critically, Permit2 supports two distinct permission models:

• AllowanceTransfer - a persistent allowance with an amount cap and expiration (similar to traditional ERC-20 approval, but managed inside Permit2). Used by Uniswap Universal Router and most swap UIs.
• SignatureTransfer - a one-shot signed permission with a nonce that can only be consumed once. The signature itself authorizes a single transfer. Used by CowSwap, UniswapX, 1inch Fusion and most intent-based protocols.

This dual model is why the same contract powers both classic swaps and modern intent-based MEV-protected trading.

Why Token Permissions Exist: The ERC-20 Approval Problem

To understand why Permit2 matters, you need to understand the original sin of ERC-20: a smart contract cannot move your tokens without your explicit permission. This is good for security but terrible for UX, because every interaction with a DeFi protocol requires two on-chain steps.

The first step is the approve(spender, amount) transaction, where you grant a specific contract the right to pull a specific number of tokens from your wallet. The second is the actual interaction (swap, deposit, stake). Each step pays gas fees, and on Ethereum mainnet that doubled the cost of every first-time swap.

To save gas and friction, almost every dApp defaulted to requesting an unlimited approval (the special value 2^256 - 1). That meant a single approval gave the contract the right to drain your entire balance of that token, forever, until you manually revoked it. If that contract was ever exploited, upgraded maliciously, or replaced by a fake clone, every wallet that ever approved it was at risk.

The 2022 BadgerDAO front-end attack ($120M) and the recurring drainer-kit campaigns of 2023-2025 all leveraged forgotten unlimited approvals. By 2026, blockchain analytics firm Chainalysis estimated that more than $2.4 billion in active unlimited approvals are still sitting on lost or compromised wallets, waiting to be exploited.

Permit2 vs EIP-2612: The Critical Difference

EIP-2612 was the first attempt to fix the two-transaction approval problem. Introduced in 2020 and ratified into many newer ERC-20 tokens (DAI, USDC since 2023, MATIC, AAVE, COMP, UNI, and most modern stablecoins), it adds a permit() function directly to the token contract, allowing approvals via off-chain EIP-712 signature instead of an on-chain transaction.

EIP-2612 is elegant but has one fatal limitation: the token contract itself must implement it. USDT, WBTC, the original WETH, every memecoin launched without forethought, and tens of thousands of long-tail tokens do not support EIP-2612 and never will, because their contracts are immutable. Even when supported, every implementation is slightly different, which forces dApps to maintain custom logic per token.

Permit2 solves this by being token-agnostic. Because Permit2 holds the actual allowance internally (after you approve it once on the underlying ERC-20), it can offer EIP-2612-style signed permissions for any ERC-20 token in existence, including ones whose creators are long gone.

The trade-off is straightforward. EIP-2612 is fully gasless from day one but only works for tokens that support it. Permit2 needs one initial on-chain approval (to itself, the Permit2 contract) per token, but then every subsequent interaction with any integrated dApp is gasless and signature-only. For an active DeFi user who touches USDC across 5-10 protocols a month, Permit2 wins decisively. For a one-off swap of a token that already supports EIP-2612, native permit is slightly cheaper.

How Permit2 Actually Works: The Three-Step Flow

The mechanics of Permit2 are easier to understand once you see the flow of a typical swap on Uniswap or 1inch in 2026. There are exactly three steps the first time, and only one step every time after that.

Step one is the only on-chain approval you ever need. You call approve(PERMIT2_ADDRESS, type(uint256).max) on the ERC-20 token itself. This costs gas, but it happens exactly once per token per wallet, regardless of how many dApps you later use.

Step two happens in your wallet UI every time you start using a new integrated dApp (or after a deadline expires). The dApp constructs an EIP-712 typed-data message specifying the spender (the dApp's router), the amount, a deadline (usually 30 minutes from now), and a nonce. You sign it. No gas, no on-chain footprint. The signature lives off-chain until it is used.

Step three is the swap or deposit itself. The dApp submits a single transaction that includes your signature, calls Permit2, which verifies the signature and pulls the tokens, and then immediately executes the swap. One transaction, one gas payment, one user click.

Supported Wallets and Protocols in 2026

Permit2 adoption has expanded dramatically since launch. As of 2026, the major integrations include the following.

Wallets That Render Permit2 Cleanly

• MetaMask (since v11.1, late 2023) - shows spender, amount and deadline with a clear "Permit2" label, plus a warning when signing for unfamiliar contracts.
• Rabby Wallet - the gold standard for Permit2 transparency. Decodes the signature, identifies the dApp, simulates the outcome, and flags suspicious spenders by reputation.
• Coinbase Wallet - integrated Permit2 prompts with risk scoring via the Blockaid partnership.
• Phantom (EVM mode) - clear typed-data display with signature simulation.
• Rainbow, Zerion, Uniswap Wallet, Trust Wallet, OKX Wallet, Binance Wallet - all natively integrate Permit2 in their swap interfaces.
• Ledger Live + Ledger devices (firmware 2.4+) - clear-signs Permit2 messages on-device, showing token, amount and spender on the secure screen.
• Trezor Safe 5 - full Permit2 clear-signing via Suite v25.2.

Major Protocols Using Permit2

• Uniswap Universal Router - the original integration, default for every swap on app.uniswap.org.
• UniswapX - intent-based MEV-protected swaps, uses SignatureTransfer exclusively.
• 1inch Aggregation Router v6 and 1inch Fusion+ - cross-chain intents.
• CowSwap - MEV-protected batch auctions, has used Permit2-style signatures since 2023.
• 0x Protocol / Matcha - aggregator with native Permit2 support.
• OpenSea Seaport 1.6 - NFT marketplace using a Permit2-style flow for token payments.
• Blur, Magic Eden - NFT marketplaces.
• LiFi, Across, Socket, Squid Router - cross-chain bridges.
• Pendle, Curve UI, Balancer Vault - integrated for swap routing.
• Most modern lending and yield optimizers on Base, Arbitrum and Optimism.

If you want to see whether any specific dApp uses Permit2, look for the spender field in the signature prompt. If it shows the canonical Permit2 address 0x000000000022D473030F116dDEE9F6B43aC78BA3 as either the spender or as the contract you are calling, you are interacting with Permit2.

Real Gas Savings: The Numbers

Permit2 was sold as a UX improvement, but the actual gas savings depend on how often you reuse the approval. Here is the realistic math for an active DEX user in 2026.

A traditional first-time swap on Uniswap V3 with a non-permit token (say WBTC) required two transactions: approve() (~46,000 gas) followed by the swap (~150,000 gas). On Ethereum mainnet at 20 gwei with ETH at $3,500, that is about $13 for the approval alone, on top of the $42 swap. Total first interaction: ~$55.

With Permit2, the first interaction is: one-time approve(Permit2, max) (~46,000 gas, identical) + signature (free) + swap with permit2TransferFrom embedded (~170,000 gas including the extra Permit2 logic). Total first time: roughly the same, ~$58.

The real win comes on the second swap, on any other dApp. With legacy ERC-20, you pay another $13 approval. With Permit2, you pay nothing extra: just a signature plus the swap. Across 10 different dApps in a month, Permit2 saves you roughly 9 approval transactions, worth $100-130 on Ethereum mainnet at typical 2026 gas prices.

On Layer 2s, the absolute dollar savings are small, but the cumulative number of avoided transactions is huge. On Ethereum L1, Permit2 can easily save a heavy user over $1,000 per year. The convenience of never having to "approve" again is itself worth the migration.

The Security Implications Nobody Talks About Clearly

Here is the part most Permit2 explainers gloss over. Permit2 makes repeated interactions safer because every signature is amount-capped and time-bound. But it also creates new attack surfaces that did not exist with legacy approvals. You need to understand all three.

1. The "One Approval Grants Permit2 To All Integrated dApps" Reality

When you call approve(Permit2, unlimited) on USDC, you are not approving any individual dApp. You are approving the Permit2 contract itself, which then acts as a permission gateway for every integrated protocol. Any dApp that asks you to sign a Permit2 message can move your tokens, up to the amount and within the deadline you sign.

This is generally safer than separate unlimited approvals (because each signature has limits), but it concentrates risk on your signing behavior. A drainer site that gets you to sign a single Permit2 SignatureTransfer for your full USDC balance, with a 5-minute deadline and the attacker's address as recipient, will drain you in one click. The wallet popup looks almost identical to a legitimate one.

2. Phishing Through Off-Chain Signatures

This is the single biggest danger in 2026. Because Permit2 signatures are gasless and look like harmless "message signing", many drainer campaigns disguise them as login requests, captcha verifications, "wallet connect" prompts or NFT mint signatures.

Read our dedicated guide on address poisoning and burner wallet hygiene for the broader defensive playbook.

3. The Inco-Drainer and Lazy-Drainer Variants

Throughout 2024 and 2025, several drainer kits (Inferno Drainer, Pink Drainer, Angel Drainer) developed sophisticated Permit2 exploitation playbooks. The typical sequence: malicious site detects your wallet, scans your token balances and existing approvals, and serves up the most profitable Permit2 SignatureTransfer prompt it can craft. Some kits even chain a Permit2 signature with a legitimate-looking ETH transfer to disguise the drain.

By 2026, Chainalysis attributed over $290M in self-custody losses to off-chain signature drainers since the start of 2024, and a meaningful share of that volume specifically exploited Permit2 SignatureTransfer.

4. What Permit2 Does Better Than Legacy

To be fair, Permit2 also adds genuine security upgrades:

• Mandatory deadlines - every signature expires. Legacy approvals never do.
• Amount caps - well-built dApps request only the exact amount you swap, not unlimited.
• Nonce ordering - SignatureTransfer nonces can only be consumed once, so an attacker cannot replay an old signature.
• Lockdown function - Permit2 includes a built-in lockdown() method that lets you instantly zero out multiple permissions in one transaction (we cover this in the revoke section).
• Audited code - Permit2 has been audited multiple times (ABDK, OpenZeppelin) and the contract is immutable, so it cannot be upgraded into a vulnerability.

When to Use Permit2 vs Native Permit vs Classic Approval

Most users do not get to choose: the dApp picks the flow. But understanding which is in play tells you what to verify in the wallet popup.

How to Revoke Permit2 Approvals: The Complete Process

Revoking Permit2 is more nuanced than revoking a legacy approval, because you have two layers of permission to consider: the underlying ERC-20 approval to the Permit2 contract, and the internal allowances Permit2 holds for individual dApps. You may need to clear either or both.

Method 1: Revoke.cash (Recommended)

Revoke.cash has been the standard tool since 2021 and added full Permit2 support in early 2024. Visit revoke.cash, connect your wallet, and the dashboard will show two separate tabs:

• ERC-20 Approvals - includes the master approval from your wallet to 0x000000000022D473030F116dDEE9F6B43aC78BA3 (Permit2). Revoking this kills Permit2's ability to move that token for ALL dApps. Use this when you want a full reset.
• Permit2 Allowances - shows every internal allowance Permit2 has granted to specific dApps (Uniswap Universal Router, 1inch, etc.) with amounts and expirations. Revoke individual ones here if you only want to cut off a specific dApp.

Each revoke is an on-chain transaction that costs normal gas. On Ethereum mainnet that is $5-15 per revoke; on L2s it is cents.

Method 2: Native Permit2 Lockdown

The Permit2 contract has a built-in lockdown() function that revokes multiple AllowanceTransfer permissions in a single transaction. Most dApp UIs do not expose this directly, but advanced users can call it via Etherscan's "Write Contract" tab or via Foundry/cast.

For SignatureTransfer (one-shot signatures), the equivalent is invalidateUnorderedNonces() or invalidateNonces(), which marks specific nonce ranges as unusable so any pending malicious signature becomes invalid.

Method 3: Uniswap and Other dApp UIs

The Uniswap interface has a "Token allowances" section in the wallet menu that shows current Permit2 allowances and lets you revoke them with one click. Rabby Wallet has the same feature built into its allowance manager. MetaMask Portfolio added Permit2-aware revocation in early 2025.

Practical Permit2 Safety Checklist (2026 Edition)

This is the operational checklist every active DeFi user should internalize.

Permit2 Across the Multichain Landscape

One of Permit2's quiet superpowers is its same-address deployment across chains. The contract lives at 0x000000000022D473030F116dDEE9F6B43aC78BA3 on Ethereum, Arbitrum, Optimism, Polygon, Base, BNB Chain, Avalanche, Blast, Linea, zkSync Era, Scroll, Mantle, Celo, Polygon zkEVM, Mode, Fraxtal and several more. This was achieved using deterministic deployment via CREATE2 and a vanity-mined salt that produced the leading zeros (which themselves save a small amount of gas due to EVM call data pricing).

The practical implication for users: a Permit2 signature for USDC on Arbitrum is structurally identical to one on Polygon, and any dApp that integrates Permit2 on one chain can replicate the integration trivially on others. This is part of why Permit2 became the de facto standard so quickly.

However, your approvals are chain-specific. Approving Permit2 for USDC on Arbitrum does NOT carry over to Polygon. You will approve once per chain per token. This is also why Revoke.cash and similar tools require you to switch network manually to see and revoke approvals on each chain.

How Permit2 Interacts With Account Abstraction (ERC-4337)

With the rise of account abstraction through ERC-4337 and EIP-7702 (live since Pectra in 2025), some have asked whether Permit2 is becoming obsolete. The short answer is no, and the two systems complement each other.

Account abstraction handles transaction-level improvements: gas sponsorship, batched calls, social recovery, session keys, and removing the need to hold ETH for gas. Permit2 handles token-level permissions: who can move which token, how much, for how long.

In practice, a modern smart-account wallet on Base or Arbitrum in 2026 might batch a Permit2 approval with the first swap into a single user operation, paying gas in USDC via a paymaster. The user signs one userOp, the bundler submits it, and the on-chain result is identical to the three-step flow but compressed into one experience. ERC-4337 makes Permit2 feel gasless on day one, but Permit2 still provides the underlying permission semantics.

Common Permit2 Mistakes That Get Wallets Drained

These are the failure patterns appearing repeatedly in 2026 drainer victim reports.

• Blind-signing because the wallet does not decode. Older wallets, third-party browser extensions, and outdated hardware firmware show "Sign Message" with a hex blob. Always upgrade to a wallet that decodes Permit2 typed data.
• Ignoring the amount field. Drainer prompts often request the full balance. A legitimate swap of 100 USDC will show 100, not 50,000,000.
• Reusing one main wallet for everything. If your main wallet has approved Permit2 for $100K of USDC and you absent-mindedly sign a malicious Permit2 message, your USDC is gone.
• Confusing "Sign In With Ethereum" with Permit2. SIWE is a short, human-readable text. Permit2 is typed data with tokens, amounts and deadlines. If you see token info, it is not a login.
• Approving Permit2 unlimited on tokens you barely hold. If you only ever swap small amounts of LINK, set the underlying approval to a reasonable cap, not infinity.
• Forgetting old chains. An Permit2 approval on a chain you barely use (say Polygon zkEVM from 2023) can still be exploited if drainers send you to a malicious site on that chain.

Permit2 in 2026: Where It Is Heading

Looking forward, Permit2 is becoming foundational infrastructure rather than a Uniswap-specific feature. Three trends are worth watching.

First, cross-chain Permit2. Protocols like LiFi, Across and Squid are extending Permit2-style intents to cross-chain swaps, where you sign once on the source chain and a solver handles the bridging and execution on the destination chain. This is enabled by Permit2's same-address deployment.

Second, wallet-native Permit2 UIs. Rabby's allowance manager, MetaMask Portfolio's risk-based revocation, and Coinbase Wallet's auto-revoke for stale approvals are starting to treat Permit2 as a first-class object in the wallet, not just a generic signature.

Third, standardization beyond Uniswap. There is an active EIP discussion (EIP-7702 plus follow-up proposals) about formalizing Permit2-style universal permission semantics into the Ethereum standard, which would make Permit2 the canonical approval primitive across the entire ecosystem.

For users, the practical takeaway is simple: Permit2 is not going away. Learning to read its signatures, manage its approvals, and revoke when needed is now a baseline self-custody skill, on par with backing up a seed phrase or knowing how to use a hardware wallet.

Final Thoughts: Smarter Permissions, Same Responsibility

Permit2 is one of the most impactful pieces of DeFi infrastructure built in the last five years. It genuinely improves UX, saves real money on gas for active users, brings amount caps and deadlines to every approval, and gives the entire ecosystem a single, audited, immutable permission layer that works with every ERC-20 token across every major EVM chain.

But it is not a silver bullet. The same properties that make Permit2 powerful (gasless signing, universal integration, persistent allowances) also make it the favorite tool of off-chain signature drainers. Every Permit2 message you sign is a transferable authorization. If you sign carelessly, you lose carelessly.

The mental model that keeps wallets safe in 2026 is simple. An on-chain transaction is a payment. A signature is a check. Both move money. The signature just does it more quietly. Treat every Permit2 prompt with the same scrutiny you would give to manually entering a recipient address and an amount, because functionally that is exactly what it is.

Use a wallet that decodes the data. Read the spender, the token, the amount, and the deadline. Use burner wallets for risky exploration. Audit and revoke monthly. Use a hardware wallet for material balances. And when something feels off, reject the signature and start over from the dApp UI yourself. Done right, Permit2 is the safest, smoothest token permission system crypto has ever shipped. Done wrong, it is the fastest way to lose a wallet.

Frequently Asked Questions