Approval and Signature Security: Read Every Signature, Manage Every Approval

Token approval is a core mechanism of the ERC-20 standard: you allow a contract (the spender) to move tokens out of your address, up to a limit you set. DEX swaps, staking, lending — nearly every DeFi operation is built on top of it. Permit-style offline signatures let an “approval” be signed without spending gas, yet with exactly the same force as an on-chain approval. Understanding approvals and signatures is the first lesson in understanding on-chain asset risk.

What an Approval Is

How the Mechanism Works

Take a DEX swap as an example: you approve USDC to the DEX’s router contract (with the limit set to this trade’s amount), then initiate the swap — the contract calls transferFrom to pull the USDC out and push the new token in. Without the approval mechanism, every transfer would need you present to sign; with it, a contract can compose operations together (this is also the foundation of DeFi composability). The cost: the approval’s lifetime outlives the single transaction — whatever part of the limit went unused stays in force until you revoke it or overwrite it with a new approval.

A Comparison of the Three Approval Functions

There are in fact three commonly used on-chain approval entry points, each behaving differently: approve(spender, amount) — the standard approval; it sets a limit and can be revoked at any time with approve(spender, 0); increaseAllowance/decreaseAllowance — a non-standard function (not part of the EIP-20 spec; removed from OpenZeppelin in v5), and Scam Sniffer’s annual report lists increaseAllowance among phishing signature types; permit() (EIP-2612) — replaces the on-chain approve with an offline signature, with identical effect. What the three share: they all “authorize a spender to pull tokens”; they differ in entry point and revocation method. Phishing abuse concentrates in the signature types the annual report lists (Permit and increaseAllowance both appear in its statistics) — when identifying a malicious request, don’t look at “which function” but at “who is being approved, and how much.”

The Approval Race Condition

ERC-20’s approve has a famous race condition: in the gap between approving A and changing the approval to B, A can still pull tokens under the old limit. The EIP-2612 document explicitly notes that the standard EIP-20 approval race condition (SWC-114) applies equally to permit. What this means for users: when changing an approval, first reduce to 0 and then set the new value, or approve only the exact amount needed — this compresses the race window to a minimum; the more practical version is the periodic checkup — stale old approvals are exactly what should be revoked anyway.

The Two Faces of Approvals and DeFi Composability

The approval mechanism is the bedrock of DeFi composability: a DEX aggregator can call multiple pools at once and a yield strategy can auto-compound, all because “a contract is authorized to act in your place.” The other side of the same coin: your funds are exposed to the combined risk of every contract you have ever approved — if any single link fails (a contract bug, a governance takeover, a key compromise), the existing approvals are ready-made channels. Once you grasp this duality, “minimal approvals plus periodic cleanup” stops being a safety tip and becomes part of the basic cost structure of participating in DeFi.

Unlimited Approvals

An unlimited approval upgrades “I agree to this transaction” into “I agree to my entire balance being moved at any time.” It is popular because it saves gas and hassle — no re-approval for each interaction. Its risk: once the approval takes effect it stays in effect, and the contract side (or whoever breaks into the contract) can pull your tokens at any moment.

Three Sources of Risk

A malicious contract: the contract you approved is itself malicious — the limit is your maximum loss. A hacked contract: the April 2023 SushiSwap incident — the router contract failed to validate an external parameter, and the attacker drained assets via users’ existing approvals (BlockSec’s post-incident analysis: users who approved the RouteProcessor2 contract lost their assets). Residual approvals: you no longer use the protocol, but the approval is still hanging there — “signed once and forgotten” is the most common source of exposure. What the three share: the loss happens after the approval, unrelated to what you were doing at that moment. Scam Sniffer’s 2024 report puts phishing-signature losses at about $494 million for the year; in the 30 large cases above $1 million, Permit accounted for about 56.7% of losses and setOwner 31.9% — which is why approval risk management is the first lesson of on-chain security.

A Worked Example of Approval Exposure

Exposure = approval limit × remaining validity × counterparty risk. Example: you granted protocol A an unlimited USDC approval — your exposure equals all the USDC in your wallet, until you revoke; three months later protocol A is breached, and your loss equals all the USDC in your wallet at that moment. Compare minimal approval: the same interaction, with the limit set to this trade’s amount — three months later protocol A is breached, and your loss is zero (the approval was consumed long before). The actionable takeaway from this example: exposure is a variable you can actively manage through your choice of limit, not fate.

The Real-World Friction of Minimal Approvals

To be honest, minimal approvals come with three real frictions: some frontends check the unlimited box by default (you have to change it manually); certain strategies (auto-compounding, limit orders) need a standing approval to work; re-approving costs gas. The response (editorial advice): change the frontend settings wherever they can be changed; for protocols that force unlimited approvals, judge whether the exposure is worth handing over (use a small test wallet); write the trade-off between gas cost and exposure cost into your cost ledger — in most scenarios, the gas for a few small approvals is far below the loss from one unlimited approval detonating.

The Defense Stack

1. Minimal approvals: ethereum.org’s security guide states it plainly — approve only the amount the trade needs, and refuse unlimited limits;
2. Periodic checkups: use revoke.cash to review your approval list, prioritizing three kinds — unlimited limits, old dates, and projects you don’t recognize;
3. Revocation: re-approve the same spender with an amount of 0 (the ERC-20 mechanism), or use revoke.cash’s one-click revoke;
4. Architectural backstop: concentrate approvals in your interaction wallet; the storage wallet carries zero approvals.

Unlimited Approvals vs. Phishing Approvals: One Ledger

The losses from unlimited approvals and from phishing approvals are often conflated, but their “timelines” differ. Phishing approval: the signature you were tricked into signing hands over the exposure outright — the loss follows the phishing immediately. Unlimited approval: a normal approval you signed voluntarily, whose exposure lies dormant until the day the contract goes wrong — the loss arrives months after the signature. This timeline difference shapes the defense design: phishing is fought with “recognition in the moment” (signature review), unlimited approvals with “periodic management” (regular checkups) — a user who only reviews signatures will still trip over an approval from three months ago. Neither mechanism can be dropped.

Permit and Permit2

The Permit signature is an optional extension of ERC-20 (EIP-2612): it lets users sign an approval message offline, without sending an on-chain transaction. It solves a real experience problem (saving one gas payment) and creates an entirely new attack surface (a free, weakly-labeled phishing signature with the full force of an approval).

The Standard’s Design and Its Attack Surface

EIP-2612’s design is rigorous: the signature carries a deadline expiry field and an incrementing nonce to prevent replay; anyone may submit the transaction (a relayer model — originally intended to let users pay gas in tokens rather than ETH). But the same properties are a gift to scammers: the signature costs nothing, and there is no barrier to submitting it. Scam Sniffer’s 2024 annual report recorded that, in the 30 large cases above $1 million, Permit accounted for about 56.7% of losses — first among signature types.

Why Wallet Warnings Are Weak

The reality Revoke.cash’s documentation points out: where Permit is supported, wallets (such as MetaMask) usually do not pop the explicit on-chain approve-style warning — users may think they are merely “logging in to a website.” This is tied to how EIP-712 is presented: the interface for structured messages varies from wallet to wallet, and the position of the spender/amount fields is not fixed. This pushes the entire duty of “reading the signature” onto the user’s side — and makes “if you can’t read it, don’t sign” a reasonable default. Add two psychological mechanisms and the scam is complete: authority — the phishing page clones the real project, and the user is in a “doing legitimate business” mindset; low vigilance — no approval warning pops up and no gas is spent, so the user’s defensive baseline drops to “logging in” level. The defense does not lie in recognizing the interface (interfaces can be faked); it lies in a content obligation: make “reading the spender and the value” an unskippable step — no matter what the popup looks like or how legitimate the page appears. This is the key shift of moving the line of defense from “spotting the fake interface” to “verifying the real content”: the former is a cat-and-mouse game; the latter is a repeatable process.

The Data: Where Permit Sits in the Phishing Statistics

Scam Sniffer’s 2024 annual report: in the 30 large cases above $1 million, Permit-type signatures accounted for roughly 56.7% of losses, first among signature types. Permit-style signatures are a permanent mainstay of phishing theft — the habit of reading signatures is not a one-time lesson but ongoing practice.

Permit2 vs. Standard Permit

Permit2 is an approval system introduced by Uniswap that generalizes “offline signature approvals” to all tokens — standard Permit (EIP-2612) requires the token contract itself to implement permit(), whereas Permit2 bypasses that limitation through a universal approval contract. For the user’s risk model, the core of the two is identical: an offline signature = an approval that can be executed later. When you see the word Permit2, treat it as the same class of risk.

How to Read Signatures When Claiming Airdrops

Signature safety at the airdrop claim stage, in one sentence: a signature is an approval, and a free signature is too. EIP-2612’s Permit mechanism makes “an offline signature carrying the force of an approval” a standard capability — it saves gas and feels smooth, and it also turns “just signing something” into the most dangerous sentence in crypto.

Two Kinds of Actions at Claim Time

An on-chain claim transaction: you initiate the transaction, pay gas, and the tokens arrive — the transaction’s contents are readable in your wallet. An offline signature: the Permit type — the signature itself is free, but once submitted on-chain its effect is identical to an approve (setting an approval limit and emitting an Approval event). The safety difference between the two lies in warning strength: Revoke.cash’s documentation notes that most wallets do not show the same explicit warning for Permit as they do for an on-chain approve, so users may think they are merely logging in. The risk exposure, however, is exactly the same — any tokens within the approval limit can be pulled.

The Verification Method

Before signing, read three fields of the EIP-712 structured message: spender (who is being approved — the protocol you are interacting with, or an unknown address); amount (how large the limit is — minimization principle, refuse unlimited limits); function name (what permit/approve/setApprovalForAll each implies). Add a domain check (enter through official channels), and these four things make up the complete check for a claim signature. In 2024’s 30 large cases above $1 million, Permit-type signatures accounted for about 56.7% of losses (Scam Sniffer’s figures).

A Full Signature-Verification Drill

Practice “reading signatures” on a testnet at nearly zero cost: find a testnet token that supports Permit, run one approval interaction, and in the EIP-712 message your wallet pops up, compare each field against the EIP-2612 text — owner (your address), spender (the approved party), value (the limit), deadline (the expiry time), nonce. Once you have practiced on a real message, the deviations in a phishing message (the spender is an unknown address, the value is abnormally large, the deadline is absurdly long) become obvious at a glance. Use an isolated wallet for the drill, and there is no real risk at any point.

Quick Reference: Signature Types in Claim Scenarios

The signatures/transactions you will meet during an airdrop claim, ordered by how often they appear: an ordinary claim transaction (on-chain mint/transfer, costs gas, contents readable); a Permit signature (a gas-free approval with the same force as approve); a Permit2 signature (the generalized approval system, same class of risk); setApprovalForAll (a full NFT approval — high danger the moment it appears); a plain message signature (login/proof of address ownership — it does not itself approve anything, but beware of the combo scam that dresses an approval signature up as a login screen). How to use this reference: when a popup appears, classify it first; each class has its own verification checklist — for plain messages check the domain, for approvals read the fields, for transactions read the contents.

Three Hard Rules Bound to the Claim Scenario

One: claiming does not need an approval limit — a legitimate claim transfers tokens directly to you; a “claim” that asks you to approve is either a precondition for some later step (read it carefully before deciding) or phishing. Two: an offline signature = a future approval — under EIP-2612, a free signature can just as well become a pass for moving your tokens. Three: if you can’t read it, you don’t understand it — for any EIP-712 field you cannot fully read, rather give up the claim (a genuine airdrop you missed can be reclaimed from the official entry; a malicious approval has no do-over).

What to Do After a Theft

First, Classify the Theft

The first step in handling a theft is to determine “what exactly was lost.” Revoke.cash’s “You’ve Been Scammed, Now What?” lays out three scenarios, each with its own path:

• Multiple assets vanishing across multiple chains, or an incoming native token (such as ETH) being swept away immediately — your seed phrase or private key has been compromised. There is nothing left to “re-lock”; the correct move is to abandon these addresses: first scan the computer you normally use for malware (reinstall the system if necessary) and change your important passwords; then create a new wallet (prefer a hardware wallet) and move any remaining assets into it. The transfer is a race — sweeper bots watch the compromised address and sweep away any newly arriving assets immediately; when the balance is large, Revoke.cash suggests contacting the Flashbots Whitehat Hotline for white-hat assistance.
• Multiple approved assets pulled away by the same contract (such as OpenSea, Blur, or Permit2-related contracts) — a marketplace signature scam: the block explorer usually shows no direct transfer, only function calls like MatchOrders or BulkExecute. This is a one-off event; after revoking the relevant approvals, the wallet can continue in use.
• Only one specific asset being moved — an approval was likely exercised: check the approval list first, and revoke any unfamiliar approval; if there is none, it may have been a direct transfer.

Already Signed? Two Situations

The signature has not yet been activated on-chain: you can try to cancel it on the Signatures tab of your revoke.cash account page. But be clear-eyed: scammers submit the signature on-chain as fast as they can, so this step is usually very difficult. Also, because signatures are offline, revoke.cash cannot know what you actually signed — the page shows only “potential signatures” — so act there only when you are quite sure you signed something malicious (needlessly canceling is not dangerous, just a waste of gas).

The signature has been activated on-chain: the approval is now in force, and from here it is handled exactly like an ordinary approve — revoke it in the approvals panel. For approval- and signature-type scams, Revoke.cash’s position is that revoking the relevant approvals is enough and a wallet migration is generally unnecessary — on the precondition that, per the previous section, you have first confirmed the seed phrase and private keys were not compromised.

Recovery Expectations for Stolen Assets

The expectation to establish: stolen assets are almost never recoverable on-chain, and anyone claiming they can “help you recover them” is most likely a scammer — “recovery services” are themselves a common entry point for a second scam. Filing a report still has value: you can submit records to local law enforcement and the exchanges involved, preserving a chain of evidence (the source page also mentions that a freeze is theoretically possible, but do not treat it as an expectation).

Common Mistakes

• Treating “approved a well-known protocol” as a permanent exemption: protocols get upgraded, get hacked, and get abandoned by you — the SushiSwap case of April 2023 shows that legitimate protocols can be breached too; approval exposure does not fully track protocol reputation;
• Not checking the chain on the approval confirmation screen: in a multichain wallet you can approve on the wrong chain — the approval is recorded on that chain’s ledger;
• Mistaking “the limit is used up” for “the approval has expired”: the record of a fully-used approval remains — the next approval takes effect at its new limit, and the history is there to remind you that it exists;
• “I revoked and now I have to approve again — what a waste”: the gas for revoke-plus-re-approve-on-demand is the insurance premium of exposure management — over a year it is far below one exposure incident;
• Managing ERC-20 approvals but not NFTs: setApprovalForAll’s full approval is the same kind of long-term exposure (per Revoke.cash’s documentation: pass false to revoke);
• “Anything supporting Permit is a legitimate project”: legitimate projects use Permit to improve the experience; phishing projects use it too — the mechanism is neutral; the person using it is not;
• Treating the deadline as a safety mechanism: the deadline is only the signature’s validity window — within it the approval can be activated at any time; expiry means “void,” not “protection”;
• Guarding only against small signatures: whenever you read an abnormally large limit, refuse to sign no matter how legitimate the page looks;
• Treating “no gas needed” as a safety signal: Permit’s entire risk is built precisely on being free — gas has nothing to do with risk;
• Reading only the popup title and not the message body: the EIP-712 message body is the full content of the approval — the title can lie; the fields cannot;
• Relaxing for “well-known projects”: phishing impersonates precisely the well-known projects — signature verification does not care how famous the project is;
• Signing halfway through because reading is a hassle: a signature is consent in the legal sense — “if you can’t read it, don’t sign” is the option that is always valid.

Risk Disclosure

This article is not investment advice and does not point to any specific project. Approvals are an ERC-20 standard mechanism, and revocation operations cost gas; Permit support varies by token (most tokens do not implement it), and wallet presentation evolves with versions — defer to the standard’s original text and the current interface of the wallet you use. The share and loss figures for signature phishing change with each year’s statistical methodology; defer to the latest version of the source pages.