Signing without a transaction: the messages that empty wallets

People have learned to be careful with transactions, and to treat signing as something else entirely. A transaction shows a fee, appears in your history, and feels like a decision. Signature requests feel like logging in.

That gap is the reason drainer sites prefer signatures.

Three kinds of signature

Sign-in messages. A site asks you to sign a plain sentence — a nonce, a domain, a timestamp — to prove you control an address. This is what EIP-4361, "Sign-In with Ethereum", standardised. Harmless by design: the message is human-readable text and authorises nothing on-chain.

Typed data. EIP-712 defines a structured format so a wallet can display the fields of what you are signing rather than a hash. This is the mechanism behind permit, order signing on marketplaces, and most legitimate gasless flows. It is also the mechanism behind most drainers, because a structured message is still a message and most people do not read the fields.

Raw signing. eth_sign asks you to sign an arbitrary 32-byte hash with no context at all. A signed hash can be a transaction. Every major wallet now warns loudly about this or disables it; treat any site requesting it as hostile without further investigation.

Permit: an approval with no transaction

EIP-2612 adds a permit function to a token. Instead of sending an approve transaction and paying gas, you sign a typed message containing the spender, the amount and a deadline. Anyone can then submit that signature to the token contract, which grants the allowance.

The end state is identical to an approval. The difference is the experience:

• No gas. Nothing prompts you to think about cost.
• No pending transaction. Nothing appears in your wallet activity.
• No on-chain record until used. The signature can sit unused for as long as the deadline allows.

A permit signature for an unlimited amount, with a deadline years away, is a blank cheque that produces no evidence until it is cashed.

Permit2

Uniswap's Permit2 generalises the idea to tokens that never implemented EIP-2612, by having you approve one canonical contract and then authorise individual spenders with signatures. It is genuinely useful and widely integrated.

It also means one approval to Permit2 plus one signature is enough to move tokens, so the signature step deserves the attention people currently reserve for approvals. Check the spender and the amount in the typed data, and check the deadline — a short expiry limits the damage of a signature you should not have given.

What to check before signing anything

1. Does the request cost gas? If not, it is a message, and messages can still authorise transfers.
2. Can your wallet decode it? A wallet showing named fields is showing you EIP-712 typed data. A wallet showing a bare hash is showing you nothing, and you should decline.
3. Read the fields. Spender, amount, deadline, and the domain the message is bound to. The domain should be the site you are on.
4. Does the amount match the action? Selling one NFT does not require authorising a collection. Swapping 50 USDC does not require an unlimited permit.
5. Is the deadline reasonable? Minutes or hours for a trade. Years is not a trade.

The useful instinct is to stop treating "no gas fee" as "no consequence". They were never the same thing, and the interfaces do not make the difference obvious.

After the fact

A permit signature you have given cannot be revoked directly — there is nothing on-chain to revoke until it is used. What you can do is invalidate it:

• Many permit implementations use a nonce. Performing another permit or approval on the same token advances the nonce and invalidates outstanding signatures.
• For Permit2, revoke the Permit2 allowance on the token, which removes its ability to move funds regardless of any signature.
• Where the value is significant and the signature may already be out, moving the tokens to a fresh address is the decisive option.

The general lesson is the same one approvals teach: the dangerous signatures are the ones that keep working after you have stopped paying attention.

What is signing, and why is it not sending?

Signing is producing a cryptographic proof that you approved a piece of data with your private key. Sending is broadcasting a transaction that changes state and costs a fee. The two feel similar in a wallet dialog and are not the same act — which is precisely the gap drainer sites work in.

Which signature is which?

Signing costs nothing in five of the six rows, and in three of them it authorises a transfer. "No fee" and "no consequence" were never the same property.

How do you invalidate one you regret?

There is nothing on-chain to revoke until the signature is used, so the options are indirect:

• Advance the token's permit nonce by performing another approval, which invalidates outstanding signatures.
• Revoke the Permit2 allowance on the token, removing its ability to move funds regardless of any signature.
• Move the tokens to a fresh address where the value justifies it.

Before signing anything, four questions: does it cost gas, can your wallet decode it, who is the spender and how much, and does the amount match what you came to do. More in wallet security, transaction safety and scam prevention.

The habit that covers all of it

Stop treating a missing fee as a missing consequence. Before signing anything: does it cost gas, can the wallet decode the fields, who is the spender, how much, and what is the deadline. Five questions, under a minute, and they cover every request in the table above including the ones nobody has invented yet.

A signature you cannot explain is a signature to decline. There is no cost to refusing and no way to undo signing. None of this requires reading Solidity. It requires reading four fields in a dialog you were going to click anyway, which is a much smaller ask than the amount most people are signing away.

Why wallets cannot fix this for you

A wallet can decode typed data and show you the fields, and the good ones do. What it cannot do is know whether authorising a spender is what you intended, because that depends on what site you are on and what you came to do — information the wallet does not have.

Some wallets now warn on unlimited permits and on requests from domains they do not recognise. Those warnings are worth heeding and are not a substitute for reading, because a hostile site can be new and a legitimate one can be unfamiliar. The decision stays with the person who can see both halves, which is you.