Blind Signing: When Your Wallet Shows Hex

You bought a Ledger. You moved your NFTs off the exchange, set up the seed phrase ritual, and felt, for the first time, actually in control of your assets. Then a DeFi protocol asked you to approve a transaction and the device screen showed: Data Present. Or raw hex. Or a hash with no decoded fields.

Congratulations — you just blind-signed. The cryptographic security held. Your private key never left the secure element. And you still had no idea what you approved.

This is the gap that costs people real money. Not the hardware. The readability.

What blind signing actually means

A hardware wallet has one job beyond storing keys: show you what you are about to authorize so you can make an informed decision. When that display breaks down — when the device renders a transaction hash, a "Data Present" prompt, or raw ABI-encoded hex instead of decoded human-readable fields — you are blind-signing.

The term is precise. It does not mean the signing is insecure in the cryptographic sense. Your key is still isolated. The secure element still produces a valid signature. But the human at the approve button cannot evaluate the payload. You are approving something, you just do not know what.

Blind signing is not an edge case. It is the default state whenever you interact with a smart contract whose calldata the device cannot decode.

Why calldata is opaque

Every smart-contract interaction encodes a function call into calldata: a 4-byte function selector followed by ABI-encoded arguments. To a device that does not know the contract's ABI, this is a binary blob. There is no way to extract "transfer 0.5 ETH to address 0x…" from raw bytes without a lookup table telling you what each byte means.

This is not a bug. It is how the EVM works. The ABI is off-chain knowledge.

For simple ETH transfers, the display is trivial — amount and recipient. For ERC-20 approvals the path is well-worn. But the NFT ecosystem runs on contracts like Seaport, Permit2, and platform-specific auction mechanisms that encode layered structs, dynamic arrays, and nested approvals. Without explicit decoding logic for each contract, the device falls back to showing you the hash.

Before you read further: if you have not worked through signature types in the NFT context, do that first. Understanding the difference between eth_sign, personal_sign, and signTypedData is the prerequisite for everything below.

The old model: per-protocol plugins

Ledger's original answer to calldata opacity was the plugin system. For each major protocol — Uniswap, Paraswap, OpenSea — a separate plugin installed on the device provided decoding logic. The plugin knew the ABI fragment and could render decoded fields on screen.

This worked for the top dozen protocols. It did not scale. The plugin had to be audited, compiled for the device architecture, and shipped as firmware. The NFT and DeFi ecosystem ships new contracts constantly. The plugin backlog became a permanent structural lag between what users needed and what the device could safely display.

The result was a standing instruction to users: enable blind signing if you want to use anything outside the plugin list. Which most people did, because they had no alternative.

ERC-7730: clear signing at the standard layer

ERC-7730 is an open Ethereum standard that decouples ABI knowledge from device firmware. Instead of shipping a plugin per protocol, a protocol publishes a JSON descriptor — a structured file that tells any conforming wallet how to display each function's arguments in human-readable form. The wallet fetches or bundles the descriptor and renders decoded fields without bespoke firmware.

The standard launched its first version in 2024. The Generic Parser — which handles arbitrary contract calls using the descriptor format — shipped in 2025. ERC-7730 v2, with Ethereum Foundation governance involvement, is in progress as of 2026.

Ledger maintains a public registry at github.com/LedgerHQ/clear-signing-erc7730-registry. As of April 2026 it covers more than 40 protocols: 1inch, Aave, OpenSea, Uniswap, Permit2, Lido, Paraswap, Morpho, OKX, WalletConnect, Rarible, Safe, Tether, Ethena, and others. Coverage is expanding, but it is not universal. Contracts outside the registry still produce opaque calldata on devices that rely on it.

The practical takeaway: if a protocol you want to use is in the registry, your device can decode and display its calls clearly. If it is not, you are back to the same decision: skip it, or enable blind signing and accept the display limitation.

Hardware screen evolution

The device's physical display matters because clear signing is only useful if you can read what the device renders. Larger, higher-contrast screens reduce the chance you skip past decoded fields without reading them.

Ledger's current lineup: the Stax uses an E Ink display in a credit-card form factor. The Flex has a 2.8-inch Gorilla Glass color touchscreen. The Nano Gen5 and the Nano Classics (S Plus, Nano X) retain smaller screens but receive ERC-7730 plugin updates. All run EAL6+ Secure Screens, meaning the display itself is part of the trusted execution boundary.

Trezor released the Safe 5 in Q4 2024: a 1.54-inch color touchscreen at 240×240 resolution with Gorilla Glass 3, EAL6+. The Safe 7, shipping in 2025, moves to a 2.5-inch screen at 520×380 resolution, 700 nits, with Bluetooth 5.0 and THP transport encryption. The Safe 7's display is 62% larger than the Safe 5's — enough real estate to show complex decoded structs without truncation.

Bigger screens are a meaningful ergonomic improvement for clear signing. They do not automatically decode arbitrary calldata. The decoding logic still needs to exist — whether via plugin, ERC-7730 descriptor, or firmware support — before the screen has anything intelligible to display.

For the full attack-surface context around hardware device choices, see the hardware wallet threat model.

The toggle: off by default, catastrophic when misused

Both Ledger and Trezor ship with blind signing disabled by default. On Ledger, you enable it inside the Ethereum app settings. On Trezor, the equivalent toggle lives in the advanced settings of the device's coin configuration.

The toggle exists because legitimate use cases require it: interacting with contracts outside the ERC-7730 registry when you consciously accept the display limitation. The problem is that once the toggle is on, the device will approve any hex payload you present to it without complaint. It cannot distinguish between a routine swap and a drain.

The attack chain is direct. A phishing site renders a convincing interface. It pushes a WalletConnect session or direct injection to your wallet. The payload is complex calldata — Seaport order, Permit2 authorization, setApprovalForAll — that a device with blind signing enabled will display as a hash. The user sees the hardware device prompt, reads it as confirmation that the operation is hardware-secured, and approves. The drain executes.

Ledger has noted publicly that billions of dollars have moved out of wallets through this exact pattern. The hardware security was present throughout. The failure was the human approval of an unreadable payload.

For a comprehensive look at how drainer contracts exploit the approval model, read NFT scams and wallet drainers.

What you can actually verify on the screen

When a transaction request reaches your device, run through this checklist before confirming:

Is the interaction decoded? You should see discrete fields: contract address, function name, argument names and values. If you see a hash, hex, or a generic "Data Present" / "Unknown contract" label, you are in blind-signing territory.

Does the contract address match? Even with decoded fields, verify the contract address against the protocol's official documentation. Clear signing shows you what the calldata encodes — it cannot detect a correctly-encoded call to a malicious clone.

What is the scope of the approval? setApprovalForAll grants unlimited transfer rights to an operator address. Any decoded transaction showing this function should trigger scrutiny regardless of how legitimate the interface looks.

Do the values make sense? A Permit2 authorization with an expiry of type(uint256).max is granting indefinite access. A decoded Seaport listing with a price of 0 is gifting the NFT. Read the numbers.

The rules

1. Keep blind signing off unless you have a specific, understood reason to enable it. Convenience is not a reason. Treating it as a permanent setting is the condition that makes drain attacks trivially easy.

2. Verify the contract address against official sources before every new protocol interaction. ERC-7730 clear signing shows you what is encoded — it does not authenticate the contract. A correctly decoded call to the wrong contract is still a drain.

3. Never approve a transaction that shows raw hex or a generic data prompt from a site you navigated to from a link. Type the URL directly or use a trusted bookmark. If the device cannot decode the call, do not approve it in a high-urgency, link-driven context.

4. Treat setApprovalForAll as a maximum-scrutiny operation. There are legitimate uses, but the function grants unlimited operator rights. Read the operator address. If you do not recognize it, reject.

5. Re-enable blind signing only for the duration of the specific operation that requires it, then turn it off. Leaving it on permanently is equivalent to removing the prompt entirely.

6. Check whether the protocol you are using is in the ERC-7730 registry before interacting. If it is, confirm that your device firmware is current enough to use the Generic Parser. If it is not, weigh the risk of proceeding without decoded display.

7. Pause on any transaction your device cannot display in full. The hardware wallet exists to give you a trustworthy display. When that display degrades to hex, the hardware wallet's primary value proposition — human verification — is gone. The secure element remains, but you are operating without its most important protection.