Permit signatures: the approval that isn't a transaction

An on-chain token approval is a transaction: you pay gas, and a contract gets the right to move your tokens. Token approvals explains why those permissions linger long after you've forgotten them.

Permit signatures grant the same kind of permission without a transaction. No gas, nothing in your history — just a "Sign" button. That's why they've become a favourite technique of wallet drainers.

What a permit is

A permit is an off-chain message, formatted under the EIP-712 typed-data standard, that says: "I allow this address to spend up to this amount of this token, until this time." You sign it; you don't send it. Whoever holds the signature can later submit it to the chain themselves, paying the gas, and the allowance takes effect.

There are two common forms:

• EIP-2612 permit. Built into the token contract (many stablecoins and newer tokens support it). The token checks the signature and records an ordinary allowance, exactly as if you'd sent an approve transaction.
• Uniswap Permit2. A separate contract many apps use for any ERC-20. You approve Permit2 once on-chain, often for an unlimited amount; after that, apps get access through signed Permit2 messages, and those allowances live inside Permit2, not the token.

Both save a transaction and let apps bundle "approve and swap" into one step. The problem is how a signature feels: a transaction prompt looks like money moving, a signature prompt looks like logging in.

Why drainers love them

A fake airdrop, mint or "claim" page asks you to connect, then shows a signature request. You sign, nothing appears to happen, and you close the tab. Minutes later the attacker submits your permit, making their address the spender, and calls transferFrom to take the tokens. You never sent a transaction, there was no gas warning and nothing to cancel, yet your balance is gone.

The fields that matter

If a typed-data request appears, look for these fields in the message section:

• spender — who receives the right to spend. If it's an address you don't recognise rather than a known app's contract, stop.
• value (or amount) — how much. A huge number such as 115792089237316195423570985008687907853269984665640564039457584007913129639935 means unlimited.
• deadline (or expiration / sigDeadline) — until when the signature can be used. Years ahead is a red flag.
• nonce — a counter so each signature works only once. It doesn't make a permit safe.

domain.name and verifyingContract tell you which token (or Permit2) it applies to, and primaryType gives the game away: Permit, PermitSingle, PermitBatch and PermitTransferFrom are all spending permissions.

"Sign in" pages that ask for typed data

Genuine sign-in requests are usually plain-text messages naming the site, your address and a nonce; signing a message covers what those prove. A login has no reason to include a token contract, a spender, an amount or a deadline.

So if a page says "sign in to continue" or "verify your wallet" and the request is structured typed data with a Permit-like primaryType, treat it as an approval request wearing a login costume. Reject it.

Revoking a permit

It depends on whether the signature has been used:

• Used EIP-2612 permit — it's now a normal on-chain allowance on the token. Revoke it like any approval, by setting it to zero. Revoking token approvals from SSP walks through checking and removing them.
• Permit2 allowances — these sit in the Permit2 contract. Revoking the token's approval to Permit2 cuts off every app that relies on it; revocation tools that understand Permit2 can also remove individual spenders.
• Signed but not yet used — the signature stays valid until its deadline or until its nonce is used up. It can be cancelled by consuming that nonce on-chain first (for EIP-2612, by submitting a harmless permit of your own; Permit2 has functions to invalidate nonces), but that's a race against someone who already holds the signature. Moving the tokens to a safe address is often faster. The reliable defence is not to sign in the first place.

How SSP handles typed data

SSP's EVM accounts are ERC-4337 smart accounts approved by two devices, which changes the picture.

What you see. In SSP Wallet, a typed-data request (via WalletConnect) shows the requesting site, your address and network, and the full EIP-712 data as formatted JSON. There's no permit-specific decoding — no "this lets X spend unlimited USDC" summary — so read the fields above yourself. SSP Key then shows a one-line summary with the domain name and primaryType (for example, "Typed data signature for USD Coin (Permit)"), with the raw data behind a toggle. Both devices must approve before anything is signed.

Whether permits apply. Most EIP-2612 permits are checked with ecrecover, which only works for an ordinary single-key address, so smart accounts like SSP's EVM vaults can't satisfy it. Support for permit-style signatures from smart accounts varies by app, so treat every typed-data request as if it will work.

The honest summary

A permit is an approval delivered as a signature: free, silent and fully capable of emptying a balance once someone submits it. Read the spender, value and deadline before signing, be suspicious of any "sign in" that carries them, and revoke allowances — on the token or in Permit2 — that you no longer need.

SSP's two-device approval gives you a second look, and SSP Key names the domain and type, but neither decodes a permit for you — the reading is still up to you.