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 offchain 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, why dozens of DeFi apps have made it the default approval flow for 2026, and how institutional custodians are wiring Permit2 signatures into their policy engines.
​

Token approvals became a bottleneck because every ERC-20 contract requires a separate onchain approve() transaction before any spender can move tokens. Users pay gas per approval, leave dormant allowances active, and accumulate standing authority across dozens of contracts. That model worked in 2015 with two or three apps per token. It does not scale to the multi-chain stack of 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 replaces per-spender onchain approvals with a single approval to one universal contract, then handles every subsequent authorization through EIP-712 signatures. Users approve Permit2 once per token. From that point forward, every individual application authorization is an offchain signed message validated atomically inside the main transaction, with no additional approval gas.
​

Permit2 is a singleton contract deployed at the same address on every EVM chain Uniswap supports. 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.
​

Permit2 exposes three core functions, permit, transferFrom, and permitTransferFrom, split across two authorization modes. AllowanceTransfer handles standing, deadline-bound allowances. SignatureTransfer handles one-shot, nonce-scoped transfers. Both modes carry mandatory deadlines, which means every authorization auto-expires without any revoke transaction from the user.
​

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.
​

Permit2 is not only a UX upgrade. It is the authorization primitive that decouples consent from settlement. The signature captures user intent offchain. The eventual transferFrom happens onchain when a router, solver, or batcher decides to settle. That separation is the same one that powers solver networks, batched fills, and intent-based execution at scale.
​

Framed this way, Permit2 turns a token approval from a transaction into a portable authorization artifact. A signed permit can be relayed, bundled, routed across venues, or held by a settlement layer until conditions are met. The deck-narrative reframe: Permit2 is the execution-layer primitive that lets institutional custody and solver-filled intent rails share the same authorization surface, turning token approvals into a policy artifact instead of an onchain transaction.
​

This is why permit-style authorization keeps showing up in intent-based architectures, account abstraction stacks, and cross-chain settlement designs. The signature is the unit of consent. Everything else is plumbing.
​

For MPC and HSM custodians, the move from onchain approvals to EIP-712 permit signing rewires the policy stack. Treasury operators using Fireblocks, Anchorage Digital, and similar platforms can route Permit2 messages through the same transaction authorization policies that govern token transfers. The signature itself becomes the gated artifact.
​

In practice this means a treasury desk can pre-authorize solver-filled flows without broadcasting an approve() per venue. The custodian's policy engine evaluates the EIP-712 payload, checks the spender against an allowlist, enforces deadline and amount caps, and records an auditable signature event. Because the permit is deadline-bound and nonce-scoped, the audit trail is self-expiring and replay-resistant. Compliance teams get a structured policy artifact instead of a perpetual onchain allowance to monitor.
​

The integration requirement is EIP-712 typed-data parsing inside the custodian's signing flow plus signature-screening logic that recognises Permit2 domain separators. Major custodians have shipped that support over the last year as stablecoin treasury movement, multi-chain orchestration, and solver-routed payments became live institutional workflows.
​

Permit2 and ERC-2612 solve the same UX problem with different surface areas. ERC-2612 adds a permit() function to each individual token contract, which means coverage depends on token-by-token opt-in. Permit2 is a singleton contract that wraps any ERC-20, so coverage is universal the moment a user approves it as a spender.
​

The older ERC-2612 standard, often called Permit1, 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.
​

Permit2 is the default approval path for the Uniswap Universal Router and is integrated by most major DEX aggregators, intent protocols, and cross-chain settlement layers. Adopters include 1inch, CoW Swap, 0x, several bridge frontends, and Layer 2 routers that inherited Uniswap's integration. SignatureTransfer in particular has become the standard authorization layer for solver-filled fills.
​

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 against a stablecoin market sitting at roughly $315.3B as of Q2 2026.
​

Beyond Uniswap, the adopters include 1inch, CoW Swap's intent protocol, 0x, 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.
​

Permit2's security model trades dormant infinite allowances for signature phishing risk. Deadline-bound permits and nonces eliminate the largest historical exploit category, the standing approval that outlives its purpose. The remaining attack surface is the EIP-712 signing prompt itself, where a malicious site can request a destructive permit.
​

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.
​

Integrating Permit2 means treating the singleton contract as the spender for ERC-20 approvals and then constructing EIP-712 typed messages for each application authorization. The Uniswap repository ships Solidity interfaces, a reference SDK, and example flows for AllowanceTransfer, SignatureTransfer, and batched permits across multiple tokens.
​

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.
​

Permit2 functions as the authorization substrate for cross-chain intent settlement. SignatureTransfer's one-shot, nonce-scoped permits map directly onto the solver-fill model: a user signs an intent, a solver pulls funds on the source chain using the permit, and the destination-chain delivery is settled separately. No standing allowance is required at any venue.
​

In ERC-7683 cross-chain intent 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.
​

For institutional flows this matters because the permit, not a per-venue approval, becomes the unit that custodial policy engines evaluate. Routes like Eco Routes consume SignatureTransfer permits as one authorization mechanism when batching stablecoin movement, giving treasury desks a way to onboard solver-filled stablecoin flows without rewriting custody policy per integration.
​

Permit3 extends the Permit2 model to multi-chain authorization, letting a single signed message cover spend authority across several chains. The direction is clear across the ecosystem: approvals are moving from gas-costing onchain transactions to cheap, bounded, cross-chain signatures that compose with account abstraction and intent settlement.
​

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 orchestration stacks and other intent layers.
​

For developers building in 2026, supporting Permit2 is table stakes. The interesting work is how permit-style authorization composes with account abstraction, paymasters, and intent settlement to make token movement feel like signing an email rather than executing a transaction. For institutional builders, Permit2 and Permit3 are the bridge between retail UX and the policy-gated execution rails that custodians and treasury platforms already operate.
​

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. MPC and HSM custodians including Fireblocks and Anchorage support EIP-712 typed-data signing through their policy engines, which lets treasury operators authorize Permit2 messages under the same allowlists, amount caps, and approval workflows that govern regular transfers. The signature itself becomes the auditable policy artifact, deadline-bound and nonce-scoped, with signature-screening applied before broadcast.
​

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 can assume a single permit interface everywhere.
​