Signature Phishing: Theft Without a Transaction
A signed message costs no gas, appears in no block, and can authorise the movement of everything you hold.
Priya Raman · 2 min read
Most people treat a transaction as consequential and a message signature as trivial. Attackers rely on that distinction.
The mechanism
Certain standards allow token approvals to be granted by a signed message rather than an on-chain transaction. The signature is collected off-chain and submitted by someone else, who pays the gas.
From the user’s perspective: no fee, no confirmation wait, nothing appears in their transaction history. The wallet shows a request to sign a message and the message is typically a block of structured data that means nothing to a non-developer.
From the attacker’s perspective: an approval identical in effect to an on-chain one.
Why it is more dangerous than a transaction
No cost signals consequence. A transaction costs gas, which prompts a moment of attention. A signature costs nothing.
Nothing appears on-chain until it is used. The victim’s transaction history shows no approval, so a later review of activity reveals nothing.
The content is unreadable. The structured data contains the spender, the amount and the deadline, and few wallets present it in a form a user can evaluate.
The delay breaks the connection. The attacker can hold the signature and use it later, so the drain arrives with no obvious cause.
The variants
Permit approvals. Grant a spender permission for a specific token and amount.
Permit2 and batch approvals. A single signature authorising multiple tokens, which is convenient by design and correspondingly dangerous.
Delegation signatures. In some account systems, a signature can grant broader control than a token approval.
Blind signing of arbitrary data. Where the wallet cannot decode the message and shows a hash.
What the wallet should show
Good wallets now decode these requests and display the spender address, the token, the amount, and the expiry in readable form. Some also warn when a signature grants unlimited allowance.
If your wallet shows an undecoded blob, treat every signature request as though it grants full control, because you cannot verify that it does not.
The defences
Read the decoded request. Spender, token, amount, deadline. If the amount is unlimited, that is a decision rather than a default.
Treat message signatures exactly as you treat transactions. Same pause, same verification.
Prefer wallets that decode and simulate. This is a genuine differentiator between wallet products.
Use a separate wallet for connecting to sites. A signature can only authorise what the signing address holds, so the structural defence applies here as it does everywhere else.
Review approvals including those granted by signature. Block explorer approval tools show the resulting allowances once used, and revocation works the same way.
The summary
The absence of a gas fee is not evidence that nothing consequential is happening. It is the specific property that makes this attack effective.
For the portion of holdings kept at a venue such as platforms with a real complaints process, signature phishing is not applicable at all, because there is no key to sign with. That is a real distinction between the tiers and a reason the working balance is the safest place for money you are actively moving.
Move any remaining funds to a wallet with a newly generated seed phrase before anything else. Then revoke token approvals, and report the incident to your local authorities and the exchange involved. Do not pay anyone who promises to "recover" your coins. That is a second scam, aimed at victims of the first.