Blind Signing: Hardware Wallet Vulnerabilities and the ERC-7730 Standard

A Co-Signer, a Hardware Wallet, and $1.5 Billion Gone

On 21 February 2025, a Bybit co-signer connected their hardware wallet to approve what appeared to be a routine Safe multisig transaction. The device's screen showed what it always shows for unfamiliar contract calls: raw hexadecimal data. Hundreds of bytes. Unreadable. The co-signer had no way to verify what those bytes encoded. They approved the transaction.

It was not routine. Attackers - attributed to the Lazarus Group by on-chain analysts and multiple intelligence firms - had compromised the Safe front-end served to Bybit's signers and silently replaced a malicious implementation contract address inside the transaction payload. Three co-signers approved it across three hardware devices. Within minutes, the attackers drained approximately $1.5 billion in ETH and liquid staked ETH from cold storage.

The cryptography held. The private keys were never compromised. The hardware wallets worked exactly as designed. The attack worked because the signers approved a transaction they could not read - and the device that exists precisely to protect their keys had no way to show them what was inside it. If you are running a multisig treasury today and your signers use hardware wallets, this is your exposure profile too.

What a Hardware Wallet Actually Shows You

A hardware wallet stores your private key in a tamper-resistant environment. Signing happens inside the device. The key never leaves. Even if your host computer is fully compromised, an attacker cannot extract the key and sign independently. That is the core guarantee - and it is solid.

The limitation is display. For native currency transfers, your hardware wallet shows you the recipient and amount. For ERC-20 transfers, most wallets decode the token name, amount, and recipient into human-readable form. That is clear signing - you see exactly what you are authorising.

For complex smart contract interactions - arbitrary function calls, DeFi protocol operations, Safe multisig proposals, EIP-712 typed data - most hardware wallets have no built-in decoding layer. The device receives ABI-encoded calldata and shows it as-is: a hex string. A Safe transaction upgrading a multisig implementation contract looks identical on your hardware wallet screen to a Safe transaction executing a routine treasury payment. Both render as opaque byte sequences. You cannot tell them apart.

You then face a binary choice: approve the hex on the basis of trusting the interface that built the transaction, or reject it and stop using the protocol. For active DeFi participants interacting with complex protocols every day, normalising approval of unreadable calldata becomes the default. That normalisation is the attack surface. Once you accept that your hardware wallet will always show unreadable data for certain transaction types, any attacker who compromises the software layer above your wallet - the dApp front-end, the multisig UI, the browser extension - can change any parameter of the transaction without triggering your suspicion.

Documented Losses Linked to Blind Signing

Look at the pattern across these incidents. In every case, a software layer between you and the blockchain - a dApp front-end, a multisig UI, an npm package, a browser script - was compromised or manipulated. In every case, the hardware wallet signed what it was given without being able to present human-readable context. In every case, the signer had no independent verification mechanism. The hardware wallet that exists to isolate signing from compromised software was defeated not by cryptographic attack but by information asymmetry.

The Radiant Capital incident shows exactly how this plays out in practice. A developer's machine was compromised through a trojanised PDF sent via Telegram. The malware intercepted Safe transaction data in the browser, replacing legitimate payloads with malicious ones while displaying the correct parameters in the UI. Three hardware wallet signers approved. The devices showed them the actual bytes they were signing - the malicious bytes - but those bytes were unreadable. Ledger later confirmed that had ERC-7730 clear-signing descriptors been in place, the display discrepancy would have been visible to the signers.

Why Hardware Wallets Cannot Decode Calldata

Understanding the root cause is important because it tells you why individual hardware wallet manufacturers could not solve this alone and why ERC-7730 is the right architecture.

On Ethereum, a smart contract function call is ABI-encoded: the first four bytes are a Keccak-256 hash of the function signature, followed by the packed parameters. The on-chain contract contains only compiled bytecode. The function signatures and parameter names that give the encoding its meaning exist only in source code and separately published ABI JSON files. The blockchain itself does not carry human-readable ABI data.

Your hardware wallet, receiving calldata to sign, has only those bytes. To display them meaningfully, it needs to know which contract is being called, what the function selector maps to, and how the parameters should be interpreted. None of that is derivable from the bytes alone. The firmware would need to either carry embedded ABI data for every contract it might encounter (impossible to keep current), query an external service (breaks the air-gap security model), or rely on the host software to supply decoding information it can independently verify. That third approach is exactly what ERC-7730 provides.

Before ERC-7730, hardware wallet manufacturers addressed this partially by maintaining internal registries of function selectors for common DeFi protocols. This worked for Uniswap swaps and AAVE deposits. It did not scale - the DeFi ecosystem deploys thousands of new contracts daily, and anything outside the registry defaulted to blind hex display. You were protected for the handful of popular protocols and exposed everywhere else.

ERC-7730: Clear Signing Descriptors

ERC-7730, developed collaboratively by Ledger and the broader Ethereum community and formally introduced in 2024, is the solution to this problem. It defines a JSON-based specification for clear signing files - off-chain descriptor documents that tell hardware wallets how to decode and display specific contract interactions in human-readable form.

A clear signing descriptor maps a contract address and function selector to a set of display instructions. It tells the wallet which fields to show, how to label them, what format transformations to apply (for example, converting a raw uint256 representing a USDC amount into a decimal with the token symbol), and what the overall transaction intent should look like. For a Uniswap V3 exactInputSingle call, the descriptor produces a display of "Swap 100 USDC for ETH, minimum received: 0.042 ETH, slippage: 0.5%." Your hardware wallet shows you that, not hex.

The security model rests on distribution and verification. Descriptor files are published to a public registry - maintained initially by Ledger at github.com/LedgerHQ/clear-signing-erc7730-registry - and wallet firmware fetches and verifies descriptors before applying them. The registry is auditable. Your protocol team can submit descriptors for your own contracts. Hardware wallet manufacturers can review and sign descriptor files to attest to their accuracy.

For typed data and off-chain signatures (EIP-712), ERC-7730 extends to cover structured data schemas, enabling hardware wallets to display permit approvals, gasless signatures, and governance votes in human-readable form rather than as raw hashes. This matters more than it might seem: a large fraction of phishing-based crypto theft specifically targets EIP-712 signatures, because users have been conditioned to approve unreadable typed data hashes without thinking.

One critical design decision in ERC-7730 makes it immediately actionable for your team: descriptors are off-chain and opt-in. No on-chain changes are required. Existing contracts - including contracts already deployed - can be covered by descriptors written after deployment. You can publish a descriptor for a contract you shipped two years ago and your users benefit the next time they sign a transaction on a wallet that supports the standard.

ERC-8213: The Bytes-Level Fallback

ERC-7730 is powerful but contingent: it requires that a descriptor exists for the specific contract being called. Even with active community contribution to the registry, coverage will always have gaps - newly deployed contracts, private or institutional contracts, long-tail protocol interactions. ERC-8213 closes that gap.

ERC-8213, authored by Patrick Collins of Cyfrin, defines a bytes-level fallback standard that enables a baseline level of clear signing for any contract interaction, even those with no ERC-7730 descriptor. It specifies a mechanism by which contracts can expose machine-readable metadata about their own function interfaces, enabling hardware wallets and signing tools to extract and display at least partial human-readable context from any transaction - without relying on an external registry.

The practical result is a layered fallback architecture. When your hardware wallet processes a transaction:

1. ERC-7730 descriptor available: Full clear signing - every parameter displayed with labels, formats, and intent summary.
2. No ERC-7730 descriptor, ERC-8213 implemented: Partial clear signing - function name, parameter types, and any metadata the contract exposes via the ERC-8213 interface displayed in structured form.
3. Neither standard implemented: Blind signing - raw hex displayed, you bear the full interpretation burden.

ERC-8213 significantly raises the floor for every contract that implements it. A contract that publishes nothing to the external registry but implements ERC-8213 still enables a hardware wallet to display "Calling: upgradeTo(address newImplementation) with newImplementation = 0x..." rather than an opaque byte string. That display would not have prevented a Bybit-scale loss on its own - the attacker substituted the address itself - but it would have made the address parameter visible to the signer and enabled manual verification against an expected value.

Collins' position on this is direct: "Blind signing is solved. The question is whether the ecosystem deploys the solution." That question falls on your team.

The Trillion Dollar Security Initiative

In 2025, the Ethereum Foundation launched the Trillion Dollar Security Initiative - a coordinated effort to harden the Ethereum ecosystem's security infrastructure to a standard commensurate with its ambition of holding a significant fraction of global value. Clear signing occupies its user-facing transaction security domain, and the initiative's position is unambiguous: "What You See Is What You Sign" (WYSIWYS) must become the baseline standard for any Ethereum transaction involving user authorisation. Blind signing is classified as an unresolved systemic vulnerability, not an acceptable product limitation.

As of mid-2026, Ledger Nano X/S+, Ledger Stax, and Ledger Flex support ERC-7730 clear signing for a growing registry of contracts. Trezor has ERC-7730 integration on its roadmap. Keystone and Gridplus Lattice1 have indicated support timelines. Safe and Gnosis are actively integrating clear signing into their signing flows. The ecosystem is moving. Your protocol's descriptors need to be in that registry before your users need them.

What Your Protocol Team Needs to Do Now

Do not wait for hardware wallet manufacturers to cover your contracts in the registry. You can act right now, unilaterally, and your users are protected as soon as wallet firmware picks up the standard.

Publish an ERC-7730 descriptor for every user-facing contract function. The descriptor format is well-documented, the tooling is available, and the Ledger registry accepts pull requests. If your protocol processes significant daily volume through user-signed transactions, you have a material security obligation to publish descriptors. Start with the functions that move funds, modify permissions, upgrade contracts, or change critical parameters. A descriptor file for a well-documented function can be written in under an hour.

Implement ERC-8213 in newly deployed contracts. For contracts deployed after ERC-8213's ratification, implementing the interface is low-effort and raises the security floor for users whose wallets have not yet loaded a specific ERC-7730 descriptor. It also provides a permanent fallback that does not depend on registry coverage.

Audit your signing flows for UI substitution attack surface. Bybit, WazirX, Radiant Capital, and BadgerDAO all shared one pattern: the UI layer above the hardware wallet was compromised or manipulated, and the hardware wallet signed what it was given. Review every surface where transaction construction occurs: your front-end, backend services constructing Safe proposals, scripts used in key ceremonies. Apply content security policies, subresource integrity, and integrity verification for any data passed to signing flows.

For multisig operations: enforce independent transaction verification. Every signer in your multisig quorum should independently reconstruct and verify the transaction hash from raw parameters before signing - not from the UI that presented it. For Safe multisig: verify the Safe transaction hash, the to address, the data field, and the operation type against expected values through an independent channel. This single procedural control would have prevented both the Bybit and Radiant Capital incidents.