In 2022, OpenSea users lost millions of dollars in NFTs overnight. Not because their wallets were hacked. Not because someone guessed their password. They were asked to sign a transaction, they signed it, and everything was gone.
The attack exploited blind signing — and it is still one of the most common ways crypto is stolen today.
What blind signing actually means
When you send ETH or approve a token transfer, your wallet needs your cryptographic signature. That signature proves you authorised the transaction. The question is: what exactly are you signing?
In an ideal world, your wallet shows you a clear, human-readable description: "Send 0.5 ETH to 0x71C7…3Fab." You read it, you recognise it, you sign.
Blind signing is the opposite. Your wallet shows you raw hexadecimal data — a long string of letters and numbers — and asks you to approve it anyway. You have no idea what the transaction actually does. You are signing something you cannot read.
That hex string above is a perfectly valid ERC-20 transfer. It could also be a call to drain your entire wallet. Without decoding it, you cannot tell the difference.
Why wallets allow it at all
Blind signing exists because not every smart contract interaction can be automatically decoded into plain English. Early wallets had no transaction decoding at all — you were always signing blind. Over time, better wallets added ABI decoding for common operations, but many still fall back to showing raw data for anything unusual.
Some wallets add a warning when they detect unreadable data. A few add a checkbox: "I understand the risk." But they still let you proceed.
The core problem
A warning is not protection. If a user is already in a phishing flow — under urgency pressure, on a fake site that looks identical to a real one — they will click through the warning. The warning is ignored by exactly the people who most need it.
How phishers exploit it
The most common blind signing attack follows a predictable pattern:
- Fake opportunity. You receive a message about a free mint, an exclusive airdrop, or an urgent "security verification" on a site that looks exactly like a real project.
- Wallet prompt. The site triggers a signing request in your wallet. It shows unreadable hex data, or a vague description like "contract interaction."
- Approval. You approve it, thinking you're claiming your NFT or verifying your wallet.
- Drain. You just signed a transaction that calls
setApprovalForAll— granting the attacker's contract unlimited permission to transfer every asset in your wallet.
The entire attack takes under 30 seconds. By the time you realise something is wrong, the assets are gone and the transaction is irreversible.
The setApprovalForAll attack in detail
setApprovalForAll is a legitimate ERC-721 and ERC-1155 function designed to let marketplaces like OpenSea move your NFTs on your behalf when you sell them. It grants a specific address — the operator — permission to transfer any token in your wallet, for any amount, at any time.
When phishers trick you into signing setApprovalForAll with their malicious contract as the operator, they do not need your private key. They just transfer everything, immediately, using the permission you just granted them.
This is why the OpenSea hack worked. Victims signed a gasless listing order that looked like a routine marketplace action. It was actually an approval that let the attacker claim their NFTs for free.
Why "just be careful" is not enough
The advice most people give is: check the contract address, read the transaction carefully, only sign things you understand. This is correct advice. It is also unrealistic for most people in most situations.
Phishing sites are extraordinarily convincing. They use the real project's logo, copy, and domain structure — sometimes with a single transposed character. Urgency pressure ("claim in the next 10 minutes") degrades decision-making. And raw hex data is unreadable by design — no amount of "being careful" lets you decode it without tools.
The technical knowledge required to independently verify a hex-encoded smart contract call is substantial. Expecting every holder to acquire that knowledge is not a security model — it is a blame-shifting exercise.
How Heldby handles it
Heldby takes a different approach: if a transaction cannot be described in plain English, it is refused. Not warned. Not given a scary checkbox. Refused.
This covers:
- Raw
eth_signcalls over non-human-readable data personal_signover arbitrary bytes- Any contract interaction whose ABI cannot be decoded to a plain description
There is no override. This is a deliberate product decision — not a missing feature. The set of legitimate transactions a typical ETH holder needs to sign is small and entirely describable in plain language. Refusing everything else eliminates an entire class of attacks.
What Heldby shows instead
Before every transaction, you see a plain-English description: the action, the amount, and the recipient. For a standard ETH transfer: "Send 0.5 ETH to 0x71C7…3Fab." If Heldby cannot produce that description, the transaction is blocked — full stop.
What you can do right now
- Never approve a transaction that shows raw hex data without a clear plain-English explanation.
- Be extremely suspicious of any unsolicited signing request — even if the site looks legitimate.
- If you have previously granted unlimited approvals to contracts, audit and revoke them at revoke.cash.
- Treat any "urgent" signing prompt as a red flag, not a reason to move faster.
Blind signing is not going away — it is built into how Ethereum signing works at the protocol level. The only reliable protection is a wallet that refuses to participate.