The message on your Ledger Nano S reads: 0x23b872dd. Below it: 000000000000000000000000, and then 24 more bytes you're scrolling through. This is transferFrom(address,address,uint256) — a token transfer from one address to another. But unless you already know that function selector by memory, you're looking at uninterpretable bytes and deciding whether to press confirm.
This is blind signing. It is the default experience for a significant fraction of DeFi transactions on hardware wallets, and it remains a live risk even as hardware wallet software has nominally improved. Understanding why blind signing persists, what the actual attack surface looks like, and what the real mitigations are requires getting into the specifics — not the marketing framing.
Why hardware wallets show raw hex instead of decoded calldata
Hardware wallets like Ledger Nano S and Nano X have a hardware-side application layer (the Ethereum app, the Solana app) that handles transaction parsing and display. Decoding a transaction's calldata into human-readable form requires the app to know the function signature — specifically, the ABI mapping from the 4-byte function selector to the parameter types. The app can only display decoded calldata for contracts whose ABI is registered in its metadata system.
Ledger maintains a CAL (Contract Address List) — a registry of known contracts with their ABIs that the Ethereum app uses for display. If a contract is in the CAL, you see "Transfer 500 USDT to 0xAbCd..." on the device screen. If it's not in the CAL, you see the raw ABI-encoded calldata as hex bytes. For most DeFi interactions — DEX routers, yield aggregators, newer protocols, custom contracts — the contract is not in the CAL. You are blind-signing.
The Nano S's 128×32 pixel display makes this worse. Even for CAL-registered contracts, complex calldata with multiple parameters requires scrolling through many screens at low character density. Under time pressure — when a trade needs to go out before slippage expires, or when a co-signer is waiting — most users stop reading before they've seen all the relevant fields. Confirming a Safe EIP-712 message in full on a Nano S can require 20+ button presses through nested struct fields. Almost nobody does this every time.
Why the "enable blind signing" checkbox exists — and what it actually enables
Ledger's settings include an explicit "Allow blind signing on EVM chains" toggle. This toggle exists because some transaction types — particularly EIP-712 typed data for protocols not in the CAL — cannot be processed at all without it. If you want to use Permit2-based approvals, certain DEX aggregator flows, or any protocol with non-trivial EIP-712 structured data on a less-common chain, you will at some point be asked to enable blind signing.
The toggle is not granular. It's on or off. When it's on, every signing request that falls outside the CAL proceeds with a hash-only display — a 32-byte hash that you confirm without knowing what it represents. This is functionally equivalent to pre-EIP-712 signing: you're approving a hash, not a transaction. The hardware wallet's security guarantee reduces to "the hash was generated by this device from the input the software provided" — which only helps you if the software is trustworthy and hasn't been compromised.
Attack patterns that exploit blind signing
The most straightforward exploit is direct: a phishing site presents a legitimate-looking interface for a popular protocol. When you connect your wallet and initiate a transaction, the site constructs calldata that transfers your tokens to the attacker's address instead of the intended destination. Your wallet shows the function selector and raw hex — you confirm, the tokens move to the attacker.
The less obvious pattern involves EIP-712 permit abuse. Permit and Permit2 allow off-chain signatures to authorize token spending — no on-chain approval transaction needed. A malicious site requests an EIP-712 signing session for what it displays as a "login" or "verify wallet" operation. The actual payload is a Permit2 signature authorizing the attacker's address to transfer all tokens from your wallet. On a device showing only the hash, you have no way to distinguish a Permit signature from a login nonce. On a device showing the decoded EIP-712 fields, you'd see the spender address and the permitted amount — and presumably notice that it's not a benign message. But if you're past the confirmation habit of actually reading the fields, even decoded display doesn't protect you.
A third pattern is specific to multi-call transactions. Protocols that batch operations use multicall or custom batch execution contracts — the calldata for the outer call contains encoded sub-calls. The device displays the outer function selector, not the inner operations. Even with CAL registration of the outer contract, the inner calldata is opaque. Attackers who can inject additional calls into a batch transaction — for instance, by compromising the front end after a legitimate domain was established — can add a token drain operation to a batch that the user believes contains only their intended swap or liquidity operation.
The gap that EIP-7702 and new standards don't yet close
Newer account abstraction standards and improved wallet firmware have improved the situation at the margin — Ledger Stax's larger display makes scrolling through EIP-712 fields more practical, and the Ethereum app's native EIP-712 support on current firmware versions handles more protocols without hash fallback. But two gaps remain that these improvements don't close.
First, the CAL coverage problem doesn't go away with better hardware. New protocols, forked contracts, and chain-specific deployments will always outpace the CAL update cycle. Hardware that's excellent at displaying registered contract data still falls back to hash display for unregistered contracts, and the DeFi ecosystem adds contracts faster than any registry can keep up with.
Second, even decoded display requires the user to actually read and verify the decoded output. The security benefit of a Stax display over a Nano S display is real but depends on the habit of verification. A trader who has confirmed hundreds of transactions by glancing at the operation name and amount — without checking recipient address, chain ID, or spender permissions — has conditioned themselves to approve transactions with less information than the display is providing. Better display doesn't change that habit automatically.
We're not saying hardware wallets have failed — signing with a hardware wallet remains materially safer than signing with a hot wallet or browser extension key storage for most threat models. The point is that "hardware wallet" and "safe signing" are not synonyms. The safety comes from the verification habit, and blind signing is the condition where that verification is structurally impossible regardless of habit.
What actually reduces blind signing risk
The practical mitigations, in order of impact:
- Disable blind signing by default. Re-enable it only for specific sessions when required, and re-disable immediately after. Leaving it permanently on removes the friction that causes you to notice when a request should be readable but isn't.
- Decode calldata before the hardware wallet prompt. Before you confirm on the device, verify the decoded function call and parameters from an independent source — a block explorer's transaction decoder, or a signing surface that pre-decodes the calldata against the contract ABI. If the pre-decode and the device display disagree, do not confirm.
- For EIP-712 requests: read the full domain separator. Specifically verify
chainIdandverifyingContract. A permit or order signature with the wrong chain ID or spender is an exploit payload, not a benign message. - For high-value transactions: slow down deliberately. The confirmation habit of "glance and press" is a behavior pattern exploiters depend on. An attacker constructing a phishing payload hopes you confirm before you've read to the part that would have stopped you.
The fundamental problem is that the attack surface requires you to do something active — read and verify — at a moment when the system architecture is not forcing you to. Hardware wallets were designed to be the verification layer between the software you can't fully trust and the signature you're about to produce. That design only works if you use the verification capability the device provides, at every confirmation, including the boring routine ones.