Permit2 is a token approval contract from Uniswap Labs that lets any ERC-20 token behave like it has built-in gasless approvals. Instead of sending a separate approve() transaction every time a new contract needs to spend your tokens, you sign one approval to Permit2 and then authorize individual applications with off-chain signatures. The result: fewer transactions, lower fees, and a dramatically shorter path from "I want to swap" to "swap complete."

If you have used Uniswap's router in the last year, you have already used Permit2 without realizing it. This guide breaks down what the contract actually does, how it differs from the older ERC-2612 Permit1 standard, what the security tradeoffs look like, and why dozens of DeFi apps have made it the default approval flow for 2026.

Every ERC-20 token contract ships with an approve() function. When you want a smart contract, such as a DEX router, a lending pool, or a bridge, to move your tokens on your behalf, you call approve(spender, amount) first. That single transaction costs gas, requires the wallet to sit idle while it confirms, and creates a standing allowance that outlives the interaction.

The ERC-20 specification was written in 2015 for a world of two or three applications per token. In 2026, a typical user might grant approvals to twenty different contracts across five chains. Each approval is a separate fee, a separate confirmation, and a separate piece of standing authority that attackers can exploit if any one contract is compromised.

Two problems compound. First, users pay for every new approval even before they do anything useful. Second, because revoking approvals is itself a gas-costing transaction, most users leave old allowances active indefinitely. Drainer attacks in 2022 and 2023 exploited exactly these dormant approvals.

Permit2 is a singleton contract deployed at the same address on every EVM chain Uniswap supports. Users approve Permit2 once per token, for unlimited amount, and from that point forward every individual application authorization happens off-chain through a signed message.

When you interact with an app that integrates Permit2, the app asks you to sign a structured EIP-712 typed message specifying the spender, amount, deadline, and nonce. That signature sits in the transaction calldata. When the transaction executes, Permit2 validates the signature, checks it against your stored allowance, and transfers tokens directly to the application, all in a single atomic call.

The user experience: one historical approval transaction per token, then signature-only interactions forever after. The onchain cost of approving a new spender drops from roughly 46,000 gas to zero because the permit happens inside the main transaction's gas budget.

The contract exposes three primary functions: permit, transferFrom, and permitTransferFrom. Two permit flavors cover the main use cases.

AllowanceTransfer is the standing-allowance mode. You sign a permit granting a spender a specific amount for a specific deadline. That allowance persists across multiple transferFrom calls until it is spent or expires. This is what DEX routers use for multi-step swaps.

SignatureTransfer is the one-shot mode. The signature authorizes exactly one transfer, to a specific recipient, for a specific amount, with a unique nonce. Once consumed, the nonce cannot be replayed. This is ideal for escrow, auctions, and intent-based systems like UniswapX, where a user's signed intent is filled by a third-party solver.

Because every permit carries a deadline timestamp, approvals auto-expire. That single design choice eliminates the largest category of approval-related exploits: the dormant infinite allowance.

The older ERC-2612 standard, often called Permit1, added a permit() function directly to individual token contracts. It works well for tokens like DAI or USDC that implemented it, but it requires every token to opt in. Thousands of legacy ERC-20 tokens will never be upgraded.

Permit2 solves the coverage problem by moving the permit logic into a universal contract. Any ERC-20 that exists today, including the ones that predate ERC-2612 by years, becomes permit-compatible the moment a user approves Permit2 as its spender.

The tradeoff is an extra layer of indirection and a single point of trust. If Permit2 itself were compromised, every user who approved it would be exposed simultaneously. Uniswap Labs has taken that seriously: the contract is immutable, audited multiple times, and cannot be upgraded by any party.

The Uniswap Universal Router made Permit2 the default approval path in late 2022. Every swap through the Uniswap web app or the UniswapX intent system routes through Permit2. That alone accounts for billions of dollars in weekly volume.

Beyond Uniswap, the adopters include 1inch, CoW Swap, 0x, CoW Swap's intent protocol, major bridges, and most Layer 2 DEXs that inherited Uniswap's router integration. For intent-based architectures, Permit2 is effectively the standard token-authorization layer because SignatureTransfer's one-shot permits map cleanly onto the solver-fill model.

Cross-chain systems use Permit2 as well. Eco's intent orchestration reads Permit2 allowances as one of several authorization mechanisms when batching stablecoin transfers, alongside the cross-chain Permit3 extension.

The security story has two sides. On the upside, deadline-bound permits eliminate the infinite-allowance exposure that made approval drainers the single largest DeFi loss category in 2022. Nonces prevent signature replay. Auto-expiration cleans up stale authorizations without any action from the user.

On the downside, Permit2 concentrates trust. A user who approves Permit2 for USDC once has authorized Permit2 to move any amount of USDC on their behalf, and now relies on the contract's correctness and on wallets displaying permit signatures accurately. Signature phishing remains the primary attack surface: if a user signs a malicious EIP-712 message, a bad actor can drain tokens in one transaction.

Practical hygiene: keep wallet firmware current so EIP-712 parsers can show human-readable permit contents, never sign a permit from an unverified URL, and use allowance-tracking tools like Revoke.cash to audit standing Permit2 allowances periodically.

The Permit2 repository on GitHub ships with Solidity interfaces, a reference SDK, and example integrations. The general integration pattern looks like this:

The Uniswap Permit2 documentation covers gas-optimization patterns, nonce management strategies, and how to handle batch permits that cover multiple tokens in one signature. Most DEX and bridge SDKs abstract this away; you only touch the raw interface if you are building a new router or a custom settlement contract.

The SignatureTransfer mode is a natural fit for ERC-7683 cross-chain intents. In those systems, a user signs an intent describing what they want (a token on a destination chain, for example), and a solver fills the intent by moving the user's tokens on the source chain. The solver does not need a standing allowance; it needs one-shot authorization, which is exactly what SignatureTransfer provides.

This is why Permit2 has become part of the plumbing for intent-based routing. When an orchestrator like Eco Routes selects between rails to move stablecoins across chains, SignatureTransfer permits are one of the authorization mechanisms that let solvers pull source-chain funds atomically without prior setup.

The team behind Permit2 has been iterating on Permit3, which extends the model to cross-chain contexts: a single signed authorization that spans multiple chains, letting a user grant a permit on Ethereum that a contract on Base or Optimism can consume. That work is progressing through Ethereum research channels and has early adoption in Eco's orchestration stack and other intent layers.

The broader direction is clear: approvals are moving from gas-costing, per-interaction transactions to cheap, bounded, cross-chain signatures. Permit2 is the first widely deployed piece of that shift. For developers building in 2026, supporting Permit2 is table stakes; the interesting work is how permit-style authorization composes with account abstraction and intent settlement.

Permit2 itself is immutable, audited, and widely used, so approving it for unlimited amount is considered low-risk from a contract perspective. The residual risk is signature phishing, a malicious site tricking you into signing an EIP-712 permit. Mitigate this with a current wallet that shows human-readable permit contents and by tracking active permits via tools like Revoke.cash.

EIP-2612 adds a permit function to each individual token contract, so only tokens that implemented the standard support gasless approvals. Permit2 is a separate contract that works for any ERC-20, including legacy tokens that will never add EIP-2612 support.

You pay gas once, for the initial ERC-20 approval to Permit2. After that, every permit signature is validated inside the main transaction's gas budget, so there is no extra gas cost per-approval. The app you are interacting with still pays gas for its own transaction.

Yes. Every permit carries a deadline, and AllowanceTransfer permits can be overwritten by signing a new permit with a zero amount. For immediate revocation, call lockdown on the Permit2 contract, which invalidates all permits for a given spender in one transaction.

Yes. Permit2 is deployed at the same address on Ethereum mainnet, Base, Arbitrum, Optimism, Polygon, and most other EVM-compatible chains. The cross-chain address consistency is deliberate so that integrators and intent protocols like Eco Routes can assume a single permit interface everywhere.