Blind signing is approving a transaction the device can show only as a hash or raw hexadecimal data. Clear signing is approving one the device has decoded into plain terms: the action, the token, the amount and the destination. The difference matters at one moment only, the final approval screen before a swap, a deposit or a token approval. The case usually cited to show what is at stake is the Bybit theft, which Ledger Academy puts at $1.5 billion and links to blind-signing risk.
Clear signing does not make a hardware wallet safe in general. It makes a device honest about contracts that someone has described to it. For those contracts, the screen shows what is being signed. For everything else, the device is back to hex, and the signer's judgment is back to guesswork. Before a deposit, then, the question is not which wallet is being used. It is whether the contract being called is covered.
How the device decides what to show
A DeFi transaction reaches the device as calldata: a function selector and its arguments, encoded as hex. The device holds the key and signs whatever it is given. In SecureWorld's summary, "A hardware wallet protects the key. It signs what you approve." The key is safe in either mode. What changes between the two modes is the text on the screen.
To turn calldata into readable text, the device needs a description of that contract's functions: which argument is the recipient, which is the amount, and which token it refers to. ERC-7730 is the shared format for these descriptions. It started at Ledger and was later handed to the Ethereum Foundation, which announced the resulting Clear Signing standard on May 12, 2026. Its contributors include Ledger, Trezor, MetaMask, WalletConnect and Fireblocks. Descriptors are published in a public registry at clearsigning.org and can be reviewed before wallets trust them. An attestation layer lets independent auditors confirm that a descriptor matches what the contract does.
So the sequence runs as follows. The app sends calldata. The wallet looks for a descriptor for that contract. If it finds one, the device's own screen shows the decoded fields. For a permit, SecureWorld lists these as action, token, spender, amount, deadline and chain. If there is no descriptor, there is nothing to decode against.
Coverage, from the makers' own statements:
- Trezor launched Clear Signing on September 7 to 8, 2026. It works on the Safe 7, Safe 5, Safe 3 and Model T, but not on the Model One. It runs automatically through Trezor Suite, WalletConnect and Trezor Connect. Launch descriptors came from 1inch, Aave, Lido, Tether, LiFi and Hyperliquid. Trezor states that a contract must have a published, supported descriptor for decoding to work.
- Ledger introduced a Generic Parser in 2025, which removed the need for a separate plugin for each dApp. It rolled out ERC-7730 Version 2 in April 2026. The sources consulted here do not list coverage for individual models such as the Flex or Nano X. They also do not describe how the blind-signing setting in Ledger's Ethereum app behaves when no descriptor exists.
- Keystone: none of the sources behind this page document the decoded screens on the Keystone 3 Pro, so its coverage is not stated here.
The registry grew by about 28% between May and the end of July 2026, according to CryptoBriefing. That is fast growth from a starting point nobody has published, which makes it an encouraging figure rather than a reassuring one.
Three losses that came through the screen
Bybit, 2025: $1.5 billion. Both the Ethereum Foundation and Ledger cite it as the defining blind-signing loss, and The Cryptonomist calls it the largest documented hack tied to the practice. The sources used here do not describe the signing steps in detail, so this page makes no claims about them.
WazirX: about $235 million, which Ledger Academy attributes to blind signing at the Indian exchange.
Phantom phishing on Solana, May 2025: $1.5 million from 80 victims. This is the retail version of the same problem, per Ledger. The mechanism CryptoBriefing describes is simple: the computer screen shows one transaction while the device is handed another. Only a device that decodes independently can reveal the mismatch.
The permit scheme described in a Singapore Police Force advisory adds a delay. The signature is captured during a compromised video call and submitted weeks later. Balances look untouched in the meantime, and approval checkers cannot see a permit that has not yet reached the chain.
Not the same as readable
Ledger's EIP-712 glossary describes three levels, not two. The middle level, transparent signing, is the one most often mistaken for clear signing.
| Transparent signing | Clear signing | |
|---|---|---|
| Basis | EIP-712 typed data | A descriptor defining exactly what is displayed (ERC-7730) |
| What appears | Hex converted to readable fields | The action, token, amount and recipient, labeled |
| Remaining gap | Key details can hide behind technical jargon | Only as accurate as the descriptor |
The strongest objection is in that last cell. A descriptor is a claim about a contract, and a malicious or careless one could mislead a signer on a trusted screen, which is arguably worse than hex that nobody trusts. The objection is fair, and it is the reason the registry has review and attestation. It does not reverse the conclusion. A reviewed description can be checked and blamed if it is wrong. A hash cannot be checked by the person approving it at all.
Before the next approval
The practical check is small. If the device shows a named action, a token and an amount, the contract is covered, and those fields should be compared with the intended action. If it shows hex, the device has nothing to say, and the decision rests on the source of the request. Signing during an unsolicited call or from a link in a message is the pattern behind most of the cases above, and it falls under the basic approval hygiene this blog covers separately. Wallet drainer losses fell from $494 million in 2024 to $83.85 million in 2025, according to DeepStrike. Nobody has yet shown how much of that fall is owed to decoded screens.
A hex string on a trusted screen is the device reporting that it does not know what it is signing, and the right response is to treat that as a refusal, not as a formality.
Comments
No comments yet. Be the first to comment!
Leave a Comment