Glossary

Blind Signing

Blind signing occurs when a user approves a transaction on a signing device without being able to fully verify the transaction details.

Key Takeaways

  • Blind signing means approving a transaction when your signing device cannot parse or display the full transaction details: you see only a hash or raw hex data instead of a human-readable summary of what you are authorizing.
  • It is a leading cause of crypto theft: attackers exploit blind signing through phishing attacks, compromised front-ends, and malicious token approvals that drain wallets even when the private key itself is never exposed.
  • Clear signing initiatives like EIP-712 and ERC-7730 aim to solve this by letting hardware wallets display decoded, human-readable transaction details before the user confirms.

What Is Blind Signing?

Blind signing occurs when a user approves a transaction on a signing device without being able to fully verify the transaction details. Instead of seeing the recipient address, the amount, and what the transaction actually does, the user sees only a cryptographic hash, raw hexadecimal data, or a truncated summary that omits critical information.

The term is most commonly associated with hardware wallets interacting with complex smart contracts on EVM-compatible blockchains. When a hardware wallet cannot parse the transaction payload, it falls back to displaying the raw data and asks the user to approve something they cannot meaningfully verify. The user is effectively signing blind.

This creates a dangerous paradox: the hardware wallet secures the private key, but the user can still authorize a malicious transaction. Key security becomes meaningless if the signing process itself can be subverted.

How It Works

To understand blind signing, it helps to understand how transaction signing normally works on a hardware wallet:

  1. A software wallet (on a computer or phone) constructs a transaction
  2. The software wallet sends the transaction data to the hardware wallet for signing
  3. The hardware wallet displays the transaction details on its own trusted screen
  4. The user reviews the details and confirms or rejects
  5. If confirmed, the hardware wallet signs the transaction with the private key and returns the digital signature

Step 3 is where blind signing occurs. If the hardware wallet cannot decode the transaction payload into human-readable fields, it shows raw data instead. For a simple ERC-20 token transfer, the raw calldata looks like this:

0xa9059cbb
000000000000000000000000recipient_address_here
0000000000000000000000000000000000000000000000000de0b6b3a7640000

A user looking at this on a small hardware wallet screen cannot determine whether they are sending 1 token to a friend or approving unlimited spending to an attacker's contract. The function selector 0xa9059cbb means transfer(address,uint256), but the device does not decode it. An attacker could substitute 0x095ea7b3 (the approve function) with an unlimited allowance, and the user would see no difference on screen.

What the Device Displays

During blind signing, different hardware wallets show different levels of information:

  • Some display only a hash of the transaction data, with no decoded fields at all
  • Some show the target contract address and the raw hex payload, which most users cannot interpret
  • Some display the ETH value being sent but not the calldata, which means a zero-value approval transaction looks harmless

In all cases, the user lacks sufficient information to make an informed decision. Confirming under these conditions is blind signing.

Why It Matters

Blind signing has been at the center of some of the largest crypto security incidents. The risk is not theoretical: billions of dollars have been lost because users approved transactions they could not verify.

Real-World Incidents

Several high-profile attacks have exploited blind signing vulnerabilities:

  • In February 2025, attackers compromised a Safe front-end developer's machine and injected a malicious interface during a Bybit multisig signing ceremony. The signers saw a legitimate-looking transaction on their screens while their hardware wallets received a different payload. Over 400,000 ETH was redirected to attacker-controlled addresses.
  • In October 2024, the Radiant Capital protocol lost approximately $50 million after multiple developer devices were compromised, allowing attackers to manipulate the Safe wallet front-end. The compromise was undetectable during manual UI reviews.
  • In December 2023, an exploit in the Ledger Connect Kit library affected users who were blind-signing EVM dApp transactions, leading to approximately $600,000 in losses. Ledger subsequently announced plans to phase out blind signing.

These incidents share a pattern: the hardware wallet's key security was never breached. The attack exploited the gap between what the user thought they were signing and what the device actually signed.

Common Attack Vectors

Attackers exploit blind signing through several methods:

  • Malicious token approvals: a dApp requests an unlimited spending allowance, which looks identical to a legitimate approval when displayed as raw hex
  • Compromised front-ends: attackers modify a trusted dApp's interface to display one transaction while submitting a different one to the hardware wallet for signing
  • Phishing attacks: fake websites mimic legitimate dApps and prompt users to blind-sign malicious transactions such as NFT listings for zero value
  • Man-in-the-middle attacks: malware on the host computer intercepts and modifies transaction data between the software wallet and the hardware wallet

Clear Signing: The Solution

Clear signing is the opposite of blind signing: the signing device decodes the transaction and displays human-readable details such as the action being taken, the recipient address, token amounts, and the network. The user can verify exactly what they are authorizing before confirming.

EIP-712: Structured Data Signing

EIP-712 introduced a standard for signing typed, structured data on Ethereum. Instead of signing an opaque hash, users sign data that includes named fields and a domain separator. This allows hardware wallets to display fields like "Approve 100 USDC to Contract 0x1234..." instead of raw hex.

However, EIP-712 has limitations. It requires dApp developers to implement the standard, and many older or custom contracts do not support it. Even when implemented, the structured data can still be too complex for users to fully verify on a small screen.

ERC-7730 and the Clear Signing Standard

The Ethereum community has developed further standards to address blind signing. ERC-7730 defines a JSON format for describing transaction intent in human-readable terms. A registry of metadata files maps contract functions to plain-language descriptions, so hardware wallets can look up and display what a transaction does even for complex interactions.

In May 2026, the Ethereum Foundation launched an official Clear Signing standard built on ERC-7730 and ERC-8176 (an integrity verification layer). The working group includes major hardware wallet manufacturers and software wallet providers. The goal is to make blind signing unnecessary for all common transaction types.

Bitcoin vs. EVM Chains

Blind signing is significantly less common in Bitcoin transactions than in EVM-based chains, primarily because of differences in transaction structure.

Why Bitcoin Transactions Are Easier to Verify

Bitcoin uses the UTXO model, where transactions have a straightforward structure: inputs (which coins are being spent) and outputs (where they are going and how much). A hardware wallet can parse a Bitcoin transaction and display the recipient address, the amount being sent, the change address, and the fee with high confidence.

The PSBT (Partially Signed Bitcoin Transaction) format defined in BIP 174 further improves this by providing all the metadata a signing device needs to verify and display the transaction, including previous transaction outputs, derivation paths, and scripts.

Bitcoin's scripting language is intentionally limited compared to Ethereum's Turing-complete smart contracts. This means there are far fewer transaction types to decode, and hardware wallet firmware can realistically support clear signing for virtually all standard Bitcoin transactions.

Where Bitcoin Blind Signing Can Still Occur

Even on Bitcoin, blind signing risks exist in certain scenarios:

  • Complex Bitcoin Script spending conditions that the hardware wallet firmware does not recognize
  • Newer transaction types like Taproot script-path spends that some older devices cannot parse
  • Bitcoin Layer 2 protocols that embed custom data in transactions, such as Taproot Assets or Ordinals inscriptions

Layer 2 solutions like Spark take a different approach by operating off-chain with cooperative signing, reducing the need for complex on-chain transactions that might trigger blind signing on hardware devices.

Risks and Considerations

Understanding blind signing risks is essential for anyone using self-custody wallets:

  • Never approve a transaction you cannot read on the device screen: if the hardware wallet shows only a hash or raw hex, treat it as a red flag
  • Verify the transaction on the device itself, not on the computer screen: compromised software can display correct information on your monitor while sending different data to the hardware wallet
  • Review and revoke token approvals regularly: even if you blind-signed an approval in the past, you can revoke it before an attacker uses it
  • Use wallets and dApps that support clear signing: check whether your hardware wallet firmware supports EIP-712 or ERC-7730 metadata for the dApps you use
  • Keep firmware updated: hardware wallet manufacturers continuously add clear signing support for new transaction types and contract standards

For a deeper look at hardware wallet security, see the research article on Bitcoin hardware wallet attack vectors.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.