EIP-2612 (Permit) is an Ethereum standard that lets a user authorize a token transfer by signing an off-chain message instead of submitting an on-chain approval transaction. The benefit was supposed to be gas savings — no separate approve transaction, the permit signature travels with the actual transfer. The cost has been that signature-phishing now dominates as the leading crypto-loss vector in 2025-2026.
What a Permit signature actually does
The user signs an EIP-712 typed message stating: "I authorize address X to spend up to Y of token Z from my address, expiring at time T." The signature is valid evidence on chain; anyone holding the signature can submit it to the token contract, and the contract recognizes the authorization without requiring a prior approve transaction.
From a UX standpoint, this is elegant: one signature, no gas, no separate transaction. From an attack standpoint, this is disastrous: the signature looks like a meaningless cryptographic blob in the wallet UI, the user has no intuition that signing it is equivalent to handing over a custodial relationship for that token at that address.
The Permit2 evolution
Uniswap launched Permit2 in late 2022 as an upgraded permit system. Permit2 introduces a single approval contract that any application can use, with more granular controls (per-transaction limits, batch operations, expiration nonces). The same signature-based phishing attack vector applies, with the added wrinkle that Permit2 signatures can be valid across many tokens at once.
By mid-2024, Permit2 had become the dominant approval mechanism on Uniswap and many other Ethereum dApps. The Chainalysis 2025 mid-year report attributed roughly 60% of approval-phishing losses to Permit2-style signatures.
The attack pattern in 2026
The user lands on a fake interface — sometimes a cloned DEX, sometimes a phishing "claim airdrop" page, sometimes a compromised legitimate dApp. The interface requests a wallet connection, then prompts a "signature" rather than a transaction. The signature, in the wallet's UI, looks like a hash or a string of typed-data fields.
If the user signs, the attacker collects the signature and waits — often days — before submitting it. The delay is intentional: it breaks the user's mental association between "I signed something weird three days ago" and "my USDC just disappeared."
What actually defends
Three layers:
First, read every off-chain signature. The EIP-712 typed-data display in Rabby Wallet, MetaMask (with the May 2024 update), and modern Ledger and Trezor firmware shows the structured fields of a Permit signature in human-readable form. If you see "spender" set to an address you do not recognize, do not sign.
Second, prefer DEX aggregators that do not use signature-only approval flows. 1inch uses standard on-chain approval (more gas, more friction, but visible in the user's transaction history). Some smaller DEXes have similar configurations.
Third, regularly revoke. Run revoke.cash once per quarter and revoke every Permit2 allowance you cannot identify. This is the operational equivalent of "auditing your approvals."
The hardware-wallet caveat
Hardware wallets do display EIP-712 signatures, but the display quality varies. Ledger Nano S Plus shows the structured data on a small screen; Trezor Safe 5 shows it in larger text on the color touchscreen. Whichever device you use, slow down for typed-data signatures — the attack window is the second or two between "this looks fine, press confirm" and "actually that was a malicious approval."
Further reading: setApprovalForAll, Phishing, revoke.cash.