What Is Blind Signing? Why You Should Never Sign What You Can't Read

Blind signing is approving a transaction or message that your wallet cannot display in human-readable form — raw calldata, an opaque hex blob, or a bare 32-byte hash instead of a plain statement of what the signature authorizes. It is not a cryptography failure: the signature is perfectly valid and carries full authority on-chain, so signing unreadable data grants permissions you never inspected, which is why nearly every wallet drainer is built around it. The remedy is clear signing — the wallet decoding the request into a sentence you can check, and simulating it to preview which assets would actually move — plus one habit no software can supply for you: reject anything you cannot read. Because a signature is the exact moment authority transfers, it also matters that the key producing it is yours alone: the WATS Hot Wallet is non-custodial across Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, so nothing moves without a signature you personally approved.

What is blind signing?

Blind signing is any approval where the request and its display have come apart. The chain executes whatever the signed bytes say; your screen is the only place where your intent and the actual content can be compared. When the screen shows hex, that comparison is impossible — and attackers build for exactly that impossibility.

The gap is one of information, not of math. A signature does not encode "I agreed to swap 100 USDC"; it encodes "this key authorizes these bytes." Whether those bytes mean a swap, an unlimited approval, or an off-chain order that sells your NFT for nothing is a question only the interface can answer — and blind signing is what happens when the interface declines to answer it.

Where blind signing shows up

Blind signing is not a single feature — it is a family of situations where the display fails the data. The usual suspects:

Request type	What you typically see	Risk
eth_sign	A raw hash or hex blob	Critical — unverifiable by design; refuse always
Raw typed data (EIP-712)	Structured fields — spender, amount, deadline	High when the meaning is unclear — a readable field is not an understood one
Contract transaction	A decoded action, or raw calldata when the wallet cannot decode it	Depends entirely on the wallet's decoding
Hardware hash-only screen	Only a hash on the device display	High — the device confirms presence, not understanding

The pattern across all four rows: risk tracks readability. Wherever the rendering thins out, the danger thickens.

Why is eth_sign so dangerous?

Among signing methods, eth_sign is the purest form of the problem: it asks your wallet to sign an arbitrary 32-byte value, displayed to you as raw hex, with none of the prefixing that marks a message as "just a message." Because the input carries no domain separation, it could be anything — including the hash of a transaction that moves assets out of your account. There is no way, even for a careful expert, to verify the request from the prompt alone; it is unverifiable by design. That is why major wallets have deprecated or removed the method entirely, and why the practical rule has no exceptions: as of 2026, a site requesting eth_sign is either dangerously outdated or actively hostile, and both answers mean reject.

What does a hardware wallet actually show you?

A hardware wallet keeps keys offline and shows requests on a screen malware cannot alter — but that screen is only as useful as what gets rendered on it. For contract interactions the device does not understand, many devices historically fell back to displaying just a hash, behind a settings toggle literally named blind signing. Confirming a hash on a trusted screen proves you pressed the button; it proves nothing about what you approved. The promise of hardware security is what you see is what you sign — a promise that quietly collapses when what you see is thirty-two bytes of noise. Hardware isolation protects the key, not the decision.

How do drainers exploit blind signing?

A drainer kit is, before anything else, a signing-experience attack. The site looks like a mint page, an airdrop claim, or a support portal; the request it fires is an unlimited token approval, a setApprovalForAll covering an entire NFT collection, or an off-chain Permit or order signature that moves assets later without any further prompt. What all of these share is presentation: the victim signed a request they could not read — or read but did not understand — and the drain followed. The full playbook is covered in what a wallet drainer is, and the approval mechanics — including why one gasless signature can empty a token balance — in token approvals and Permit explained. Both arrive at the same root cause: the theft happens at the moment of signature, and blind signing is what makes that moment survivable for the attacker.

What is clear signing — and how far has it come?

The industry's answer is clear signing — the principle that a wallet must translate every request into terms a human can verify before it asks for a signature. As of 2026 it rests on two mechanisms. Decoding: the wallet recognizes the contract and function being called and renders it as a sentence — approve token X, spender Y, amount unlimited — with efforts like ERC-7730 building open metadata registries so even hardware-wallet screens can display contract calls in human terms instead of a hash. Simulation: the wallet, or a service it calls, runs the transaction against current chain state before you sign and previews the outcome — which assets leave, which arrive, which approvals change. Simulation is a prediction, not a guarantee — state can shift between preview and inclusion, and a hostile contract can behave differently once mined — but a preview showing your NFTs leaving for an unknown address stops most drains cold. Adoption is still uneven across wallets and chains as of 2026, so check what your own wallet actually renders for a routine action before you trust it to warn you.

Practical rules: treat unreadable as untrusted

You do not need to read calldata to stay safe — you need habits that make unreadable requests fail closed:

• Never approve an eth_sign request. There is no legitimate mainstream use left for it — treat the request itself as the red flag.
• Prefer wallets that decode and simulate. If your wallet shows raw hex for a routine action, that is a wallet problem worth switching over.
• Read the fields that matter in typed-data requests: spender, amount, deadline, operator. An unlimited amount or an unknown spender is a stop sign.
• Keep hardware blind-signing modes off unless you understand exactly why one specific transaction needs it — and turn it back off after.
• Connect deliberately. Most bad requests arrive through hasty connections — the routine in how to connect a wallet to a dApp safely keeps the front door guarded.
• Unreadable equals untrusted. Rejecting a signature costs nothing but a retry. A wrong signature can cost everything. The asymmetry decides for you.

Where WATS fits

Blind signing is a display problem. Decoding and simulation can render a request in readable terms, but no wallet — WATS included — can decide on your behalf whether the request is one you actually want. What a wallet does settle is who controls the key that turns that decision into authority. The WATS Hot Wallet is fully non-custodial: you hold the keys, WATS never holds a key, and no transfer leaves your account without a signature you approved on Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana or TON. That cuts one whole category of risk — nobody can sign for you — while leaving the reading discipline above squarely yours.

The WATS NFC Metal Card sits in the same honest place. It does not store private keys and it does not decode calldata: it is a tap-to-authenticate device with a unique card ID, paired to exactly one device, that authenticates to keys living in the WATS apps. That adds a physical factor — something you hold, not just something on your screen — but it cannot make an unreadable request readable. Nothing can, except the prompt itself.

So treat the two halves separately. The reading half is a habit: never sign what you cannot read, and reject anything that arrives as bare hex. The custody half is a choice you make once — keep your keys in a non-custodial wallet, and keep signing authority where it belongs. Install the WATS Hot Wallet, turn every unreadable prompt into an automatic reject, and pair a WATS NFC Metal Card to your device if you want a physical factor authenticating you to the keys in your WATS apps.