Permit2

What is permit2?

Permit2 is a smart contract system from Uniswap Labs that standardises how wallets and apps handle token approval for ERC-20 tokens, including approvals created by onchain transactions and approvals created by offchain signatures. Instead of each token implementing its own “permit” logic (or forcing users to approve every new app), Permit2 provides a shared approval layer with features like expirations, nonces, and batch permissions. Because many wallet-draining incidents start with users unknowingly granting dangerous approvals, Permit2 is often discussed in the context of crypto wallet scams and how to avoid them.

At a high level, Permit2 sits between your wallet and the app that wants to move your tokens. You can authorise spending in two main ways: (1) set an allowance onchain (similar to a normal ERC-20 approval, but recorded in Permit2), or (2) sign a typed message that Permit2 can verify onchain to create or update an allowance. Unlike traditional unlimited approvals that can linger for years, Permit2 permissions can include an amount limit and an expiration time, and they use nonces to reduce replay risk. It also supports batching, so a single signature can cover multiple tokens or multiple permissions.

Uniswap Permit2

In the Uniswap ecosystem, Permit2 is commonly used to streamline swaps and other multi-step actions where an app needs temporary access to tokens. The typical flow is: you sign a Permit2 message that authorises a specific spender (often a router contract) to spend up to a defined amount of a token until a deadline, and then the router executes the swap and pulls the tokens via Permit2. This reduces repeated approvals across different Uniswap routers and can make approvals more consistent across tokens that don’t support native permits. Importantly, it changes what you should look for in wallet prompts: you may be signing a permission that affects Permit2 allowances rather than the token’s own allowance mapping.

EIP-2612 permit

EIP-2612 is the widely used “permit” standard that lets an ERC-20 token accept an offchain signature to set its allowance (so you don’t need a separate approval transaction). The catch is that EIP-2612 must be implemented by each token contract, and implementations vary (or don’t exist). Permit2 complements this by offering a universal, token-agnostic permit-style experience: the signature is verified by the Permit2 contract, not by the token itself. Conceptually, EIP-2612 updates allowances inside the token contract, while Permit2 updates allowances inside Permit2. For users, both can feel similar (“sign to approve”), which is why understanding signature phishing and approval phishing is critical: a signature can still grant meaningful spending power if you approve the wrong spender or sign a message you don’t understand.

Why permit2 matters

Permit2 matters because it makes approvals more controllable and more uniform across the ERC-20 landscape: apps can request time-bounded, amount-bounded permissions, and users can avoid leaving broad approvals open-ended. It also helps developers reduce friction by batching permissions and supporting tokens that lack EIP-2612, which can improve UX without forcing users into multiple transactions. That said, Permit2 doesn’t eliminate risk—attackers can still trick users into granting permissions to malicious spenders, and confusing signing prompts can enable approval phishing or signature phishing. The practical takeaway for crypto wallet scams and how to avoid them is to treat any approval or signature request as a security decision: verify the spender address, limit amounts, prefer expirations, and revoke permissions you no longer need.