Blind Signing: How Crypto Signers Approve Transactions They Cannot Read

On 21 February 2025, three people at Bybit approved a transaction on the exchange's Ethereum cold wallet. Their screens showed a normal transfer. Minutes later about 401,000 ETH, worth roughly $1.4 billion, was gone. The keys were never stolen. The signers produced valid signatures for a transaction they could not read.

That is blind signing. It is the gap between what a person approves and what their device actually signs, and it is behind several of the largest crypto thefts of the last two years.

What blind signing means

Every blockchain transaction is authorised by a signature over a hash. The wallet takes the transaction fields, hashes them, and signs the hash with the private key. The chain checks that signature and executes the fields.

Blind signing happens when the device holding the key cannot turn those fields into something a person can read. A hardware wallet asked to sign an unfamiliar contract call often shows only a hash, or a long string of hex, plus a warning. The signer has two choices: trust whatever screen asked for the signature, or refuse.

There are three common forms:

In each case the key is safe and the signature is valid. What fails is the person's ability to know what they agreed to.

How the Bybit transaction worked

Bybit's cold wallet was a Safe multisig. Moving funds needed several owners to sign the same Safe transaction, identified by its Safe transaction hash.

According to the investigations published after the theft, attackers compromised a Safe{Wallet} developer machine and planted malicious JavaScript in the Safe web interface, set to trigger only for Bybit's wallet. When Bybit's signers opened a routine transfer, the page displayed the transfer and asked their devices to sign a different transaction.

The signed transaction, recorded on chain at nonce 71, had three features that a decoder would have flagged at once:

• Operation 1, delegatecall. In a Safe, delegatecall runs another contract's code with the Safe's own storage. That code can rewrite the owner list and the pointer to the Safe's implementation.
• An unknown target. The call went to a contract the attacker had deployed, which is not one of Safe's official libraries.
• A harmless-looking function name. The calldata used the selector for transfer(address,uint256). Under delegatecall the name means nothing. The attacker's contract used it to overwrite storage slot 0 and point the Safe at a malicious implementation.

All three signatures on that transaction were of the eth_sign type, which means the signers' devices signed a bare hash. The FBI attributed the theft to North Korea's TraderTraitor group on 26 February 2025.

The same pattern elsewhere

Bybit was the largest case, and it followed a pattern seen before:

The US, Japan and South Korea attributed WazirX and Radiant to North Korea in a joint statement in January 2025, and the FBI attributed DMM Bitcoin to the same TraderTraitor group. These attacks are planned against specific signers, often months ahead.

Off-chain signatures are blind signing too

Blind signing is also how most retail wallets get drained. Token standards let a holder sign an off-chain message, a permit, that authorises another address to spend tokens later. Uniswap's Permit2 and EIP-2612 permits both work this way.

A phishing site asks for "a signature to log in" or "to verify your wallet". The wallet shows an EIP-712 message that the user does not read closely, or a hash. The signed permit goes to a drainer, which submits it on chain and moves the tokens. No transaction was ever sent from the victim's wallet, which is why victims often say they "only signed a message".

Why hardware wallets do not solve it

A hardware wallet keeps the private key off the computer. That defeats malware that steals keys. It does nothing against a computer that asks the device to sign the wrong thing, unless the device can show what that thing is.

For simple transfers, devices display the recipient and amount. For contract calls and typed data, they rely on parsers. When a parser exists for the contract, the device can "clear sign": it shows the function and arguments in plain language. When it does not, the device falls back to blind signing and displays hashes.

Ledger authored ERC-7730, a JSON format that describes how to display a contract's calls and messages, and an Ethereum Foundation working group now maintains a public registry of these descriptors. Clear signing coverage is growing, but it covers listed contracts. A malicious contract written last week will never be in the registry, which is exactly the case that matters.

How to defend

The working defence is to treat the screen that requested the signature as untrusted, and to check the hash yourself.

1. Recompute the hash independently. Take the raw transaction fields, on a second device that did not produce the request, and compute the hash yourself. For a Safe this means the EIP-712 domain hash, message hash and Safe transaction hash. If they match what your hardware wallet displays, you are signing the fields you just reviewed. The Safe Transaction Verifier does this in a browser, checks the result against the Safe contract's own getTransactionHash(), and can replay the Bybit transaction to show what it flags. The command-line tool safe-tx-hashes-util does the same offline.
2. Decode before you sign. Read the target, the function and the arguments. For a multisig, two flags are hard stops: delegatecall to anything other than the multisig's official libraries, and any change to owners, threshold, modules, guards or the implementation.
3. Simulate. Run the exact transaction through a simulator and look at the state changes. A routine transfer does not change a wallet's implementation address.
4. Separate the signing machine. Signers of large wallets should use a dedicated device for signing, with no email, browser extensions or chat. Radiant's signers were compromised through malware on everyday work machines.
5. Refuse unreadable signatures. Turn off blind signing on your hardware wallet by default and turn it on only for a specific, verified transaction. For retail users: never sign a message to "log in" on a site you reached from a link, and review existing token approvals regularly.
6. Add on-chain friction. Timelocks, spending limits and transaction guards give a team time to notice a malicious transaction before funds move. On Safe 1.3.0 and later, a guard can reject delegatecall to unlisted contracts before execution. Bybit's wallet ran Safe 1.1.1, which predates guards.

Frequently asked questions

Is blind signing always dangerous? It is risky by design, because you cannot confirm what you approve. Some DeFi interactions still require it on devices without a parser for that contract. The safe practice is to enable it for a single transaction you have verified independently, then disable it again.

Why did Bybit's signers not notice? Their interface showed a normal transfer, the request came through their usual process, and the device showed only a hash. Without an independent hash computation, nothing in their view was wrong.

Does a multisig protect against this? A multisig protects against one stolen key. If every signer reviews the transaction on the same compromised interface, the attacker only needs to fool that interface once, and every signer approves the same malicious payload.

What is the difference between blind signing and clear signing? Clear signing means the device that holds the key decodes the transaction and shows the function and arguments in readable form. Blind signing means it shows only a hash or raw data, so you rely on another screen to tell you what it is.

Related guides

• DeFi Security: How to Protect Your Funds
• Smart Contract Vulnerabilities
• Cryptocurrency Security Guide
• How Digital Signatures Work
• What Is Phishing