Signature phishing: before you "just sign," read what it's asking you to hand over

When your wallet throws up a window asking you to "sign," don't assume it's safe just because there's no gas and no transfer right now. Some signatures only prove control of an address. Others, such as permits and signed orders, can authorise later action while creating no on-chain record at the moment you sign. So the question isn't "does this cost money," but "what does this actually authorise?" If the origin, method and fields do not match the action you deliberately started, close it and begin again from an official bookmark you verified independently.

This piece is only about that instant — the signature window is up and you haven't tapped confirm. We cover how a malicious link or fake QR walks you to this window separately in fake QR code approval scams; here we answer one thing — the window is already in front of you, so how do you read it, line by line?

Why is "just signing" easier to fall for than sending a payment?

With a payment, you can see everything clearly: the recipient address, the amount, the gas — in black and white, and wrong numbers make you hesitate. A signature is the opposite. It hides the most dangerous thing behind the most harmless-looking surface.

Three things make the difference. First, no gas: an off-chain signature doesn't hit the chain and costs no fee, so you lose the natural brake of "this will cost me." Second, nothing moves right now: after you sign, your balance is untouched, and no "funds left your account" alert appears — it feels like nothing happened, but that authorisation is now in their hands, and they can wait minutes or days and clean you out when you're not watching. Third, it may not be a login at all: phishing sites love to dress an approval up as "sign to verify" or "sign to unlock," so you think you're doing something small and safe. By the time you notice the funds are gone, you can't recall ever "sending" anything — because you didn't send, you signed.

The three faces signature phishing wears

Same playbook, but it usually appears in one of these three forms:

• permit / Permit2 (off-chain approval signatures). The classic one. A permit uses a signature in place of a gas-paying "approve" transaction and can authorise a spender to move tokens up to a limit. Permit2 is an approval-management contract used by many dApps, but a Permit2 signature can move a token only if that wallet has already given the Permit2 contract sufficient on-chain ERC-20 approval for that token. Having used or not used a particular interface such as Uniswap is not the test; the relevant condition is the actual token allowance to Permit2. A phishing site hides the request behind "Sign to claim / continue," so inspect the contract, token, spender, amount, expiry and nonce rather than trusting the button label.
• Blind signing: a hex string you can't read. The window contains nothing but a long 0x string your wallet can't decode into readable text, and asks you to "sign." You simply don't know what you're agreeing to — behind it could be a transaction or the hash of an approval. It might be the old eth_sign method, or structured data the wallet can't parse, or a raw non-text message; which one it is doesn't matter, what matters is that you can't read it. eth_sign was dangerous enough that MetaMask removed the method outright in v12.3.0, taking the old settings toggle with it, and most other mainstream wallets block it by default. So the switch scammers talk you into flipping today is on the hardware-wallet side — which gets its own section below.
• Listing / approval signatures dressed up as a "login." In the NFT world, a signature can authorise a listing or order that sells an NFT under terms you did not intend. Whether it can ultimately transfer the NFT depends on the relevant marketplace operator or conduit already having valid approval for that collection, such as setApprovalForAll; merely having listed somewhere before is not the legal or technical test. Check the order fields, marketplace contract and current operator approvals.

Before you sign, read the window line by line

When what you're signing is structured data like a permit (technically EIP-712), most wallets today will break the content into readable fields instead of dumping a raw string. That means you have a real chance to understand what it's asking you to approve before you tap confirm. The table below lays out the fields most worth watching in an approval-type signature window:

The deadline row is the one most often misread, so it's worth spelling out: it bounds how long the signature can still be submitted, not how long the approval lasts. Once a plain permit is submitted within that window, the allowance it creates is permanent and never expires on its own. So a deadline of thirty minutes doesn't mean "the risk lasts half an hour" — it only means they have to act within half an hour. (Permit2 has a separate expiration field, and that one does bound the allowance.)

Boiled down to one line: any time the window combines a party, a token and a number, or the whole thing is a 0x string you can't read, treat it as "I'm about to sign an authorisation to move my assets." An amount marked "unlimited" is worse still — that hands over your entire balance of that token. If you can't tell which kind it is, close the window and start again from your own saved official bookmark: missing one reward costs you nothing, and signing wrong can cost the whole wallet. Don't skip that first row either — our domain checker exists to compare it character by character.

What should a login signature contain?

For a standard Sign-In with Ethereum (SIWE) request, compare the message with the action you just initiated. It normally lists the requesting domain, your wallet address, URI, chain ID, nonce and issued-at time, and may also contain an expiry and resources. The browser origin must match the message’s scheme and domain. The URI identifies the resource that is the subject of the signing and should be checked separately against the relying party’s expected value and purpose.

A SIWE login normally has no spender, token, allowance or amount, but that absence is not proof of safety by itself. EIP-712 is a general structured-data format that can describe login messages, permits, orders and many other actions. Inspect the primaryType and actual fields, and reject the request if the origin, purpose or data do not match the exact action you deliberately started.

Hardware wallets, and that "blind signing" switch

If you use a hardware wallet like a Ledger, there's one setting to watch closely: blind signing. When what you're signing is data the device can't fully display, it stops you and asks you to first turn "blind signing" on in the settings before it will sign. What that switch really means is: "I know I can't read this, but I'm willing to sign anyway."

Scammers' favourite scripts revolve around that exact switch: "before you claim, please turn blind signing on in your wallet settings," or "the transaction failed because blind signing is off — turn it on and it'll work." The moment you comply, you've switched off your hardware wallet's last line of defence with your own hands, letting it sign, without blinking, something you can't read.

The practical rule: keep blind signing off as your default. Some legitimate dApps may still require it when a hardware wallet cannot provide Clear Signing, so the prompt is not proof by itself that the site is phishing. It is nevertheless a high-risk red flag: proceed only when you independently reached the official URL and verified the contract, method, recipient, amount and purpose through a trusted source. If the device cannot show what you verified, close the request rather than relying on the page that asked you to weaken the check.

Already signed: why your approval checker shows nothing

Read this section to the end, because this is the step most people get wrong without ever realising it.

First determine what has already happened. Check recent on-chain transactions, token approvals and asset movements. A malicious permit may still be unsubmitted, in which case an approval dashboard may show nothing; or it may already have been submitted, in which case you may see a new allowance or transfer. A clean dashboard is not proof that a leaked signature is invalid.

So the first three things to do, in this order:

• Disconnect and stop signing anything. Cut off the channel they use to keep pushing windows at you.
• Respond to submitted activity. If the signature has already created a live allowance, revoke that allowance. If assets have moved or you cannot confidently identify the exposure, move remaining at-risk assets to a fresh wallet and preserve transaction hashes and screenshots.
• Use the correct invalidation path. ERC-2612 permits and Permit2 do not share one universal recovery button. Permit2's AllowanceTransfer uses stored allowances and ordered nonces, with functions including invalidateNonces. One-time SignatureTransfer uses unordered nonces and invalidateUnorderedNonces, and does not create a second-layer standing allowance. Revoking the token's ERC-20 approval to Permit2 can cut off Permit2 transfers for that token, but obtain instructions from the verified project documentation or a qualified responder rather than visiting a random dApp merely to “refresh a nonce.”

As for the old approvals you've accumulated over time — those really are sitting on-chain, and a checker works perfectly well for them, so review them regularly and revoke what you don't recognise. How to check and revoke them one by one is laid out step by step in our wallet approval review and revoke guide. Keep the distinction clear: that guide handles approvals that are already on-chain, while the signature you just gave away isn't — and the two need different treatment.

One more warning: at this point, an "I can recover your lost funds" DM or support account is almost always a second layer of the scam, using your panic to charge you again. What you should actually do is preserve the evidence — when it happened, the site's URL, the wallet address, a screenshot of the window, and the transaction hash of any suspicious transfer that follows — then work through Scammed? The first 4 things to do. If reporting it is warranted, that material is what you'll need. Don't pay another stranger.

FAQ

How do I tell a login signature from an approval signature at a glance?

A standard SIWE login message normally lists the requesting domain, wallet address, URI, chain ID, nonce and issued-at time, and may also include an expiry and resources. It usually contains no spender, token, allowance or amount, but “no token and no amount” is not proof of safety on its own: the browser origin must match the message’s scheme and domain; the URI identifies the resource that is the subject of the signing and must separately match the relying party’s expected value and purpose. signTypedData is only an EIP-712 structured-signing method, not an approval by itself; inspect primaryType and the actual fields. Reject any mismatch in origin, purpose or fields.

My wallet shows an unreadable hex string (0x...) and asks me to sign. Can I?

Do not sign. You cannot verify the contents on the wallet or hardware device; it could be a transaction, approval, order or other raw data. MetaMask removed eth_sign in v12.3.0. Hardware-wallet blind signing can also appear on legitimate dApps that do not yet support Clear Signing, so being told to enable it is a high-risk red flag, not proof by itself that a site is phishing. Unless you can independently verify the official URL, contract, method, recipient and amount, close the window.

I already signed a permit. What is the first thing to do?

Disconnect the suspicious site and stop signing for it, then check recent on-chain transactions, token approvals and whether assets have moved. If the malicious signature has already been submitted, revoke any live allowance and move remaining assets to a new wallet; if the dashboard is clean, that still is not proof of safety because the signature may be unused. ERC-2612 and Permit2 use different invalidation paths. Do not visit a random dApp merely to refresh a nonce; if you cannot invalidate safely, moving at-risk assets is the safer choice.

I checked an approval dashboard and it is completely clean. Am I safe?

No. Approval tools mainly read on-chain allowances. An unsubmitted permit will not appear, and Permit2’s one-time SignatureTransfer does not create a second-layer standing allowance. Check recent on-chain activity and asset changes, then whether the token still approves Permit2 or another spender. A clean result only means the tool sees no standing approval at that moment; it does not prove a leaked signature is invalid. Move at-risk assets if you cannot invalidate safely.