Blind signing means approving a transaction or message without being able to see what it does: a long hexadecimal string, a hash on a hardware wallet screen, or a request that hides the real recipient. It is the weak spot most wallet drainers exploit. A user thinks they are logging in or claiming an airdrop, and instead signs an approval that lets an attacker move their tokens. Preventing blind signing is a shared job for the dApp that asks for the signature and the wallet that displays it.
How Attacks Abuse Blind Signing
- Approval phishing: an unlimited token approval or
setApprovalForAllto an attacker's contract. - Permit phishing: an off-chain permit signature that costs no gas and looks harmless, but authorises spending.
- Malicious calldata: a function call whose real effect differs from what the website claims.
- Address poisoning: lookalike addresses planted in the transaction history.
Prevention in Your dApp
- Use EIP-712 typed data with meaningful field names, never raw hashes or hex messages.
- Request exact approval amounts and short validity periods instead of unlimited, permanent approvals.
- Bind login messages to your domain with Sign-In with Ethereum, so they cannot be replayed on a phishing site.
- Explain each request in your interface before the wallet pops up.
Prevention in Your Wallet
- Transaction simulation: show the expected balance changes ("you send 1,000 USDC, you receive nothing") before signing.
- Decoding of calldata and typed data into readable actions, with the verified contract name.
- Risk warnings for unlimited approvals, new or flagged contracts, permits and transfers to lookalike addresses.
- Clear signing on hardware wallets, so the device itself shows the action. See hardware wallet signing.
Frequently Asked Questions
Is signing a message always safe because it costs no gas?
No. Signed messages such as permits can authorise token transfers. Gas-free does not mean risk-free.
What is clear signing?
The opposite of blind signing: the wallet or device shows the action in readable form, such as the token, amount and recipient, so the user knows what they approve.
Can simulation be wrong?
Simulation shows the result against the current state. Contracts that behave differently later can still surprise, so simulation is combined with warnings and limited approvals.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
Part of our work on signatures and signing and wallet development.
Make Every Signature Readable
Tell us what your users sign today. We will make those requests clear in your dApp or wallet, and harder to abuse.