Off-chain signatures, on-chain losses: the anatomy of approval phishing

For years the standard advice to Web3 users was to read transactions carefully before confirming them. Attackers adapted. Many of today’s phishing pages never ask for a transaction at all. They ask for a signature, which costs nothing, appears nowhere on-chain at the time, and in a poorly designed wallet looks no more dangerous than signing in.

This primer explains how signature-based approvals work, why they are attractive to phishing operations, and what wallets, applications and users can each check. It describes a well-documented technique in general terms; it does not analyse any specific campaign.

From transactions to signatures

The ERC-20 standard requires two steps for a contract to move a user’s tokens: an approve transaction from the user, then a transferFrom by the approved spender. Each approval is an on-chain transaction that costs gas and leaves a visible record.

EIP-2612 added permit: the user signs a structured message off-chain, and anyone can submit that signature to the token contract to set the allowance. EIP-712 defines how such messages are typed, hashed and displayed, binding them to a specific contract and chain through a domain separator. Uniswap’s Permit2 extends the idea to any ERC-20 token: users approve the Permit2 contract once, then grant individual spenders allowances or one-time transfers by signature, including batches covering several tokens at once.

These designs are a genuine improvement for usability, and the cryptography is sound. The risk lies in how the request is presented and understood.

Anatomy of a permit request

1// An EIP-2612 permit request as a phishing page would present it.2// Addresses are illustrative.3const request = {4  domain: {5    name: "Example USD",6    version: "1",7    chainId: 1,8    verifyingContract: "0x1111111111111111111111111111111111111111", // the token9  },10  primaryType: "Permit",11  types: {12    Permit: [13      { name: "owner", type: "address" },14      { name: "spender", type: "address" },15      { name: "value", type: "uint256" },16      { name: "nonce", type: "uint256" },17      { name: "deadline", type: "uint256" },18    ],19  },20  message: {21    owner: "0x2222222222222222222222222222222222222222",    // the victim22    spender: "0x3333333333333333333333333333333333333333",  // the attacker23    value: (2n ** 256n - 1n).toString(),                       // unlimited24    nonce: "0",25    deadline: (2n ** 256n - 1n).toString(),                    // never expires26  },27}

Everything an attacker needs is in the message: their own address as spender, an unlimited value, and a deadline that never arrives. Once the user signs, the attacker submits permit and then transferFrom, often in quick succession and sometimes through a contract that does both in one transaction. The user’s first on-chain trace of the event is the transfer out.

Why it works on careful users

• No gas, no confirmation screen. Users trained to scrutinise transactions may treat signatures as harmless, and some sites present them as a login step.
• Unfamiliar data. A typed-data prompt shows field names and hexadecimal addresses. Few users know which field matters or recognise the spender.
• Batched scope. A single batch signature can cover several tokens, so one mistake can affect a whole portfolio.
• Legitimate lookalikes. Real applications request permits too. The request on a phishing page can be structurally identical to the one on the genuine site; only the spender differs.

The request does not always come from an obviously fraudulent site. Lookalike domains, sponsored search results and messages that impersonate a project’s support channel are common entry points. More damaging still is a compromised frontend: if an attacker can alter the scripts a legitimate application serves, through a compromised dependency, a hijacked DNS record or a breached hosting account, the malicious request appears on the genuine domain, in the familiar interface, at the moment users expect to sign something. For that reason, frontend integrity is part of the same threat model. Pinned dependencies, subresource integrity for third-party scripts, strict content security policies and monitoring of DNS and certificate changes all reduce the chance that a real site starts asking for the wrong signature.

Signature types to recognise

What wallets and dApps can do

Most of the protection has to come from software, because the decision a user is asked to make is otherwise unreasonable. Wallets can decode known typed-data schemas and present them in plain language, identify well-known spender contracts, and warn on the patterns phishing relies on.

1// Illustrative wallet-side checks before a typed-data signature is shown.2const MAX = 2n ** 256n - 1n3const DAY = 86_400n4 5type Flag = { level: "warn" | "block"; reason: string }6 7export function permitFlags(td: TypedData, knownSpenders: Set<string>, now: bigint): Flag[] {8  const flags: Flag[] = []9  const m = td.message10 11  // EIP-2612 Permit, or Permit2 PermitSingle (fields nested under "details")12  const spender = String(m.spender ?? "").toLowerCase()13  const amount = BigInt(m.value ?? m.details?.amount ?? 0)14  const expiry = BigInt(m.deadline ?? m.details?.expiration ?? 0)15 16  if (!td.primaryType.startsWith("Permit")) return flags17  if (!knownSpenders.has(spender))18    flags.push({ level: "warn", reason: "Spender is not a contract this site normally uses" })19  if (amount >= MAX / 2n)20    flags.push({ level: "warn", reason: "Grants an effectively unlimited allowance" })21  if (expiry > now + 30n * DAY)22    flags.push({ level: "warn", reason: "Permission stays valid for more than 30 days" })23  if (BigInt(td.domain.chainId) !== BigInt(currentChainId()))24    flags.push({ level: "block", reason: "Signature is for a different network" })25 26  return flags27}

Applications that legitimately request signatures can make phishing easier to spot by contrast:

• Request the exact amount needed, not an unlimited allowance, unless the user opts in.
• Use short deadlines and expirations measured in minutes or hours.
• Publish the spender contracts the application uses so wallets can recognise them.
• Never describe a permit as a login, verification or “gasless claim”.

Binding signatures to intent

Protocol designers can reduce the value of a stolen signature by making it useful only in the context it was requested for. A permit that grants a general allowance is valuable to anyone who holds it. A signature that authorises one specific action is far less so.

Permit2’s signature-transfer mode supports an additional “witness”: application data, such as the details of an order, that is included in the signed message and checked by the contract that consumes it. A signature produced for one trade cannot then be replayed to authorise a different transfer. Order-based protocols that settle through their own contracts achieve the same effect by having users sign the full order rather than an allowance. In both cases the wallet can also show users exactly what they will give and receive, which is easier to judge than an abstract spending limit.

Cancelling a signature before it is used

A user who realises they have signed a malicious permit sometimes has a narrow window to act. EIP-2612 permits include a nonce, and each successful permit call consumes the owner’s current nonce. A signature for a nonce that has already been used is invalid. Submitting any valid permit for the same token, even one that grants a zero allowance to an address the user controls, therefore invalidates an outstanding signature that has not yet been submitted. Allowance-style signatures in other systems often have equivalent mechanisms for invalidating nonces.

In practice the window is often seconds, because automated tooling submits stolen signatures immediately. That is why prevention at signing time matters far more than any recovery step, and why monitoring services that watch for a new, unknown spender receiving permits from many unrelated accounts can be valuable to wallets and token issuers alike.

What users can check

When a site asks for a signature, three questions cover most cases. Who is the spender, and is it the application’s published contract? How much does it allow, and for how long? Why does this action need my tokens at all? A site offering an airdrop, a mint or a login has no reason to request authority over balances.

Allowances that already exist can be reviewed and revoked. Token allowances are revoked by approving zero for the spender; Permit2 allowances are managed through the Permit2 contract itself. Periodic reviews matter most for accounts that hold significant balances.

Conclusions

Signature-based approvals improve usability, and they move the decisive moment of an approval off-chain, where it costs nothing and leaves no trace until it is used. Phishing operations exploit exactly that gap.

The defences are layered: wallets that decode requests and warn about risky ones, applications that request the minimum scope and duration, frontends whose integrity is monitored, and users who read the spender, the amount and the deadline. Signature replay across EVM chains covers the contract side of binding signatures to a single use.

Recommendations