Why I Have to Be Careful with Every Signature Inside a dApp

There is a line that veterans repeat constantly — “signatures are more dangerous than transfers”. Newcomers often do not get it: a transfer obviously moves assets, while a signature is just clicking a button with no gas spent, so how can it be worse? The answer is that a “signature” in Web3 is not the casual “I agree” gesture it sounds like — it can grant a permanent, unbounded right over your assets. This article walks through what actually happens behind each signature so the next time a signing popup appears, you have a clear risk map in your head.

First, what a signature actually is

Wallet signatures come in two broad classes, and mixing them up is where most beginners get hurt.

Class one is a transaction signature — you initiate something that changes on-chain state (transfer, swap, mint, stake), your private key signs the transaction data, the signed payload is broadcast to the network, and miners or validators confirm it. This signature must spend gas because it actually writes into a block.

Class two is a message signature — your private key signs an arbitrary string. It is not broadcast, not written on-chain, costs no gas. dApps often use it to prove “you actually control this address” — like a “Sign in to …” message at login. But this kind of signature can also carry authorization semantics and approve an effectively permanent right to spend your assets without you realizing.

The critical realization is that no gas does not mean no consequence. The other side can take the signature, call certain contract functions on-chain, and transfer your assets directly. For deeper mechanics see wallet primer.

Signature types and their risk levels

Lined up by risk level, the common types are:

• personal_sign / eth_sign simple message signature — moderate risk. A clearly human-readable “Sign in to MyDApp” is lower risk. A blob of hex or random bytes is likely a transaction disguised as a message, extremely high risk.
• EIP-712 structured signature — risk depends on contents. EIP-712 lets the wallet render field names so you can see “approve 100 USDC to 0x…” instead of raw hex, but recent phishing kits deliberately design EIP-712 field names to look like “login” while actually being a permit authorization.
• permit signature (ERC-2612 / Permit2) — extreme risk. This signature directly authorizes the counterparty to spend specific tokens within a time window without you spending any gas to authorize, and it has been the main carrier of the 2024–2025 phishing wave.
• approve / setApprovalForAll transaction signature — high risk. The classic “unlimited allowance” carrier — once signed, the counterparty contract can transfer that token (or the entire NFT collection) at any future point.

Why “gasless signatures” are actually the most dangerous

The instinct says “real transactions are the ones that spend gas”, but after permit signatures appeared that instinct flipped. The permit signature was designed to smooth the UX — instead of paying gas for approve and then gas for swap, you sign a single message and the frontend submits the signature alongside the swap to save a gas hop.

Attackers exploited this — they craft an EIP-712 popup that looks like a login or a normal approval, while underneath it is a permit authorization to the attacker address. Once you sign, the attacker calls the permit function on-chain and then calls transferFrom to drain the token. You spent zero gas, you saw no “transfer confirmation”, yet the asset is already gone.

That is the underlying logic of “gasless signatures are the most dangerous”. For the practical attack patterns and defensive moves, see MetaMask phishing defense.

A pre-signature self-check list

Whatever the signature type, walk a self-check list before signing. The core of the list is — do not let you sign “by feel”.

• Check the domain — is the requester domain in the popup a dApp you recognize? Any lookalike phishing variants (“unisawp.org”, “metarnask.io”)?
• Check the request type — is it transaction, personal_sign, or eth_signTypedData_v4? Be extra cautious on the latter two.
• Check the contents — for EIP-712 the wallet will render structured fields. Do words like spender, approve, permit, value appear? If they do, suspect an authorization signature.
• Check token address and amount — if token address or value fields appear, confirm the token is one you intend to authorize and the amount is reasonable (infinity or uint256.max is extremely dangerous).
• Check the counterparty address — is the spender a contract or an EOA? Contracts must be verified as legitimate protocol addresses; an EOA (especially one without ENS or labels) is almost certainly phishing.
• If unsure, refuse to sign — the final line of defense. If you are unsure, close the popup. If you are unsure, close the popup. If you are unsure, close the popup.

Pair this with approval hygiene tools

Pre-signing checks alone are not enough — you also need periodic “approval cleanup”. A wallet carrying dozens of dangling approvals is a key ring left on the ground.

A few things to do:

• Periodically clean approvals via revoke.cash or Etherscan’s Token Approvals page to revoke approvals you no longer use.
• Separate large holdings from daily interaction wallets — the main wallet connects to no dApps, the daily wallet handles DeFi, so a bad signature blast radius is contained.
• Use a wallet with simulation support — Rabby, Frame, and the new generation render the simulated execution before signing — see Rabby vs MetaMask comparison.
• Sign large operations on a hardware wallet — the device screen shows the signature contents independently, blocking a man-in-the-middle rewrite — for context see hardware wallet supply chain risk.

A few real-world scenarios

Mapping the principles onto common cases.

Scenario one — you click an airdrop site and it pops a “Sign to claim airdrop” message. Open the signature contents. If it is a personal_sign with a human-readable “Claim airdrop for 0x…” and the site is a confirmed official domain, the risk is moderate. If the EIP-712 has fields like spender or permit, close it immediately — classic airdrop phishing. For airdrop participation strategy see improving airdrop eligibility strategy.

Scenario two — you swap on Uniswap and a Permit2 signature pops up. This is expected, because Uniswap’s Permit2 is a legitimate token authorization mechanism. But verify — the spender should be Uniswap’s Permit2 contract address (verifiable in the Uniswap docs), value should not be uint256 max, and the deadline should not be too far out. For protocol background see Uniswap primer.

Scenario three — a friend sends a “high-yield farming” link asking you to sign a setApprovalForAll. Close it. setApprovalForAll lets the contract move every NFT in that collection, a classic NFT phishing carrier.

Treat signatures like signing contracts

Compress everything into a single mental model — clicking a sign button inside a dApp is equivalent to signing a contract you have not read. You would not sign random paperwork in real life, and you should not sign signatures lightly on-chain. The “no gas” and “message” labels lull users into relaxing, which is exactly the state attackers want. Each time a signature popup appears, walk the checklist above, wait three seconds before deciding — three seconds rarely costs you anything important, but one day they will block a wallet-emptying loss. This article is not investment or custody advice.