You connect your wallet to a website. A popup appears: “Sign this message to verify you’re the owner.” No gas fee. No transaction. Just a signature — like a digital thumbs-up. You click sign.
It wasn’t a verification. It was an authorization. By signing, you granted a smart contract permission to spend your tokens. Minutes later, your wallet is drained — and you never approved a single transaction in the traditional sense.
This is the crypto signature scam, and it’s the single most effective attack vector in Web3 today. According to Chainalysis, signature-based phishing drained over $295 million from 324,000+ victims in 2023 alone, and the pace has only accelerated.
BLUF: In crypto, a signature isn’t just a “login” or “verification” — it can authorize token transfers, contract approvals, and spending permissions. Scammers exploit the fact that users treat signatures casually (“no gas = no risk”). Every signature variant (personal_sign, eth_sign, signTypedData, Permit2) has different risk profiles. Before signing anything: (1) verify the requesting site is legitimate, (2) use a wallet that decodes what you’re signing, (3) when in doubt, don’t sign.
Why Signatures Are Dangerous
In traditional web apps, “signing” or “authenticating” is harmless — you’re proving your identity without transferring anything. The worst outcome of a compromised login is someone reading your data.
In crypto, signatures are legally binding authorizations. When you sign with your private key, you’re producing cryptographic proof that you approved specific data. If that data encodes a transaction, your signature is all an attacker needs to execute it on-chain.
The core misunderstanding: users assume “no gas fee = no risk.” They think if they’re not sending a transaction (paying gas), nothing can happen. This is wrong:
| Signing Method | Gas Cost | Can It Drain Your Wallet? |
|---|---|---|
| Send transaction | Yes (you pay gas) | Directly — transfers funds |
personal_sign | Free | Indirectly — can be used as proof in some protocols |
eth_sign | Free | Yes — can sign serialized transactions |
signTypedData_v4 (EIP-712) | Free | Yes — can grant token allowances (Permit, Permit2) |
Every free signature method except personal_sign can be weaponized to drain your wallet.
The Five Signature Scam Variants
Variant 1: Fake Verification (personal_sign abuse)
The scammer asks you to “verify wallet ownership” with a personal_sign request. The message looks like:
Sign this message to verify you own this wallet.
Nonce: 8x4k2m9This particular variant is usually safe — personal_sign adds a prefix that prevents transaction forgery. But there are two risks:
- Some protocols use personal_sign for authorization — the signature might be used to authorize an action in a smart contract that checks signature validity (like a meta-transaction relay).
- Replay attacks — if the nonce is predictable, a captured signature could be replayed on a protocol that accepts it.
How to identify: The wallet should show readable text, not hex data. If the message looks legitimate and comes from a trusted site, it’s probably safe. If it comes from an unknown site, don’t sign.
Variant 2: Permit Signature Phishing (EIP-2612)
The scammer asks you to sign an EIP-2612 permit message for an ERC-20 token that supports permit (like USDC, DAI, or UNI). The signature grants the attacker an allowance on your tokens.
Your wallet might show:
Permit:
Token: USDC
Spender: 0x7a3f...
Value: unlimited
Deadline: far futureOr it might show raw EIP-712 typed data that you can’t easily read.
Once you sign, the attacker submits the permit on-chain and immediately transfers your tokens. No gas was charged to you — the attacker pays the gas to execute the permit.
Real-world impact: Permit signature phishing is one of the most common drain methods. ScamSniffer documented thousands of victims who lost USDC, DAI, and other permit-compatible tokens through this vector.
Variant 3: Permit2 Signature (Universal drain)
The most devastating variant. If you’ve used Uniswap or any protocol integrated with Permit2, a single Permit2 signature can grant the attacker allowance on all tokens you’ve approved through Permit2 — not just one.
This is how the $68 million WBTC attack worked. The victim signed a Permit2 message they believed was a routine verification, and the attacker drained their entire WBTC balance.
See our Permit2 exploit guide for the full technical breakdown.
Variant 4: eth_sign (Raw Transaction Signing)
The scammer sends an eth_sign request that contains a serialized transaction. You think you’re signing a verification message, but you’re actually signing a transaction that approves or transfers your tokens.
This is the hardest variant to detect because the payload is raw hex — no human-readable content. See our eth_sign phishing guide for details.
Variant 5: setApprovalForAll via Disguised Transaction
The scammer constructs a transaction that calls setApprovalForAll(attackerContract, true) on an ERC-721 or ERC-1155 contract. This grants the attacker permission to transfer all your NFTs of that type.
The transaction might be disguised inside a multi-call or batched with other actions. On a hardware wallet with blind signing enabled, you see only raw hex data.
Real-world impact: The NFT sector has been hit hardest by this variant. Many high-value BAYC, Moonbirds, and Azuki NFTs have been stolen through setApprovalForAll phishing.
The Signature Scam Playbook
Regardless of the technical variant, the social engineering follows a consistent pattern:
Phase 1: Distribution
| Channel | Method | Example |
|---|---|---|
| Hacked verified account replies | ”We’re airdropping! Claim at [fake domain]“ | |
| Discord | Compromised server announcements | ”Bot migration — re-verify at [fake domain]“ |
| Telegram | Direct messages to active group members | ”You won the raffle — claim at [fake domain]“ |
| Google Ads | Sponsored results for DeFi keywords | ”Uniswap” ad → phishing copycat |
| NFT spam | Airdropping fake NFTs with URLs in metadata | Free NFT → “redeem at [fake domain]“ |
Phase 2: The Fake Site
The phishing site is a pixel-perfect clone of a legitimate protocol. Key differences are invisible without inspection:
- Domain:
uniswap-app.ioinstead ofuniswap.org(extra subdomain) - Domain:
aavé.cominstead ofaave.com(homoglyph é) - SSL: Valid Let’s Encrypt certificate (anyone can get one)
- Content: Scraped from the real site, including branding and copy
Phase 3: The Signing Prompt
The site connects to your wallet and immediately requests a signature. The framing is always “low-stakes”:
- “Verify wallet ownership”
- “Claim your airdrop”
- “Authenticate session”
- “Sign to continue”
- “Prove you’re human”
No mention of token approvals, spending permissions, or transfers. The wallet may or may not decode the actual content of the signature.
Phase 4: The Drain
The attacker submits your signature on-chain. Depending on the variant:
- Permit/Permit2: Allowance registered →
transferFrom()called → tokens moved - eth_sign: Signed transaction broadcast → executes on-chain
- setApprovalForAll: NFT approval registered → attacker transfers NFTs
Total time from signature submission to irreversible transfer: seconds.
How to Verify What You’re Signing
The Wallet Decode Test
Before signing, check what your wallet shows:
| What You See | Risk Level | What It Means |
|---|---|---|
| Readable text (“Sign in to…”) | Low | Probably personal_sign — safe if trusted source |
| Decoded function + parameters | Medium | Read carefully — check spender, amount, function |
| EIP-712 structured data | Medium | Check all fields — especially spender and amount |
| Raw hex data (0x…) | High | Could be eth_sign or undecoded transaction — do not sign |
| Nothing intelligible | Critical | Blind signing — do not sign |
The Simulation Test
Use a wallet or extension that simulates the signature’s outcome:
- Rabby Wallet: Shows “You will lose X tokens” before you sign
- Pocket Universe: Browser extension that flags dangerous signatures
- Blockaid: Security layer integrated into several wallets
- MetaMask Snaps: Install security Snaps for simulation
If the simulation shows any asset loss, do not sign — no matter what the site claims.
The Domain Check
Before connecting your wallet, verify the domain character by character:
| Check | How |
|---|---|
| TLD match | .com vs .io vs .xyz |
| Homoglyphs | Look for non-ASCII characters (é, а, о, і) |
| Extra characters | uniswap-app vs uniswap |
| Subdomains | app.uniswap.io vs uniswap-app.io |
| Bookmark | Navigate from a saved bookmark, not a link |
Use our address risk scoring API to check if the site’s smart contract address has been flagged.
The Burner Wallet Defense
The most robust defense against all signature scams:
- Main wallet: Holds your significant assets. Never connected to unfamiliar sites.
- Burner wallet: A separate wallet for interacting with new/untrusted dApps. Fund only with what you need.
If a scammer tricks your burner wallet into signing a malicious message, they can only drain the small amount you funded it with. Your main wallet is untouched.
Important: Never approve Permit2 or unlimited token approvals on your main wallet. If you need to use Permit2-enabled protocols, do it from a wallet with limited token balances.
Frequently Asked Questions
Q: I signed something and now I’m worried. How do I check if I was scammed?
A: Check your wallet on revoke.cash for any unfamiliar approvals. Check Etherscan for recent transactions you don’t recognize. If you see unknown allowances or outgoing transfers, immediately move all remaining assets to a fresh wallet.
Q: Is “Sign In With Ethereum” (SIWE) safe?
A: Yes, when implemented correctly. SIWE uses personal_sign with a standardized message format (EIP-4361). It’s designed to be safe — the signature proves identity without authorizing transactions. But verify the requesting domain matches the site you intended to visit.
Q: What’s the difference between signing and sending a transaction?
A: Sending a transaction (eth_sendTransaction) is an on-chain action — you pay gas, the transaction executes immediately. Signing (eth_sign, personal_sign, signTypedData) is off-chain — it produces a cryptographic proof that can be used later. Signatures are “free” to create but can be just as dangerous as transactions.
Q: Can I cancel a signature?
A: No. Once you’ve signed, the signature is valid forever (for most methods). The only defense is to move assets before the attacker uses the signature. For Permit2 permits, the nonce is single-use — but you can’t rely on that because the attacker will submit it quickly.
Q: Do hardware wallets protect against signature scams?
A: Only partially. Hardware wallets force you to physically confirm the signing, which adds a pause for reflection. But if you confirm the signature on the device, the attack succeeds. Hardware wallets can’t tell you whether a signature is malicious — they can only show you the data (which may be raw hex if blind signing is enabled).