Permit2 and EIP-2612: The New Approval Frontier

If you’ve used Uniswap, 1inch, or any modern DEX in the past year, you’ve probably encountered a new kind of approval flow. Instead of the familiar “Approve” transaction followed by a swap, you signed a message in your wallet and the swap just… happened. No separate approval transaction. No gas for the approval step.

That’s Permit2 at work. And while it’s a genuine improvement in user experience, it introduces a new class of risk that most users don’t yet understand.

The Problem Permit2 Solves

Classic ERC-20 approvals have a well-known friction: before a DEX can move your tokens, you must send an on-chain approve transaction. This costs gas, takes time, and creates a persistent, often unlimited, allowance that lingers until you manually revoke it.

Uniswap Labs created Permit2 as a universal approval manager. The idea: you approve Permit2 once per token, and from that point forward, any dApp that integrates with Permit2 can request access through a signed message rather than a separate on-chain transaction.

EIP-2612 is the underlying standard that makes this possible. It adds a permit function to ERC-20 tokens, allowing approvals via off-chain signatures rather than on-chain transactions.

How Permit2 Works

1. One-time approval: You send a single on-chain approve transaction granting the Permit2 contract access to a specific token. This is the only gas you pay for approvals.
2. Signed permits: When a dApp wants to move your tokens, it asks you to sign a typed message (EIP-712). This signature specifies: which token, how much, which spender, and an expiration timestamp.
3. Execution: The dApp submits your signature to the Permit2 contract, which verifies it and transfers the tokens in a single transaction.

The result: fewer transactions, lower gas costs, and approvals that expire automatically.

The New Risks

Permit2 is better designed than legacy approvals, but it creates new attack surfaces:

Signature phishing

Because Permit2 approvals are off-chain signatures, they don’t appear as on-chain transactions in your wallet history. A phishing site can ask you to sign a Permit2 message that grants an attacker access to your tokens — and because it’s just a signature, not a transaction, many users don’t scrutinise it carefully.

The signed message is valid even if you close the phishing site. The attacker can submit it later, at their convenience.

Batch permissions

Permit2 supports batch permits — a single signature can authorise access to multiple tokens at once. A malicious dApp could bundle permissions for every token in your wallet into one signature request. If you sign without reading, you’ve approved everything in one click.

The Permit2 “superapproval”

When you first approve Permit2 for a token, you’re typically granting it an unlimited allowance. This means the Permit2 contract can move any amount of that token, subject only to the individual signed permits. If the Permit2 contract itself were compromised, all tokens you’ve approved to it would be at risk.

How to Protect Yourself

• Read every signature request carefully. Your wallet will show you the EIP-712 typed data. Look for: the spender address, the token, the amount, and the expiration. If any field looks wrong, reject it.
• Never sign Permit2 messages on unfamiliar sites. Phishing sites can present themselves as legitimate dApps. Bookmark your trusted dApps and only sign from those bookmarks.
• Audit your Permit2 approvals. Tools like AllowanceGuard scan for Permit2 allowances alongside classic ERC-20 approvals. If you’ve approved Permit2 for tokens you no longer use, revoke the base approval.
• Prefer short expiration times. When a dApp lets you choose, set permit expirations to hours or days, not months. Most legitimate dApps submit the signature immediately.
• Check for batch requests. If a signature request covers multiple tokens, that’s unusual. Legitimate dApps typically request one token at a time. Multiple tokens in a single permit is a red flag.

The Bigger Picture

Permit2 and EIP-2612 represent a genuine improvement to the approval model. Expiring, scoped, gasless approvals are what the ecosystem has needed for years. But better UX also means more sophisticated attack vectors. The security hygiene doesn’t change — it just moves from on-chain transactions to off-chain signatures.

The rule remains the same: understand what you’re signing before you sign it.