Clear Signing vs Blind Signing: how to know what you’re actually signing

A hardware wallet protects your private key, but that does not mean its screen will always tell you, in plain language, exactly what you are signing. When you use a dApp, the browser may show a familiar action — a transfer, swap, or approve — while the hardware wallet receives the underlying transaction data. If the device cannot decode that data, you may be left with a hash, raw data, or a generic warning. That gap is what Clear Signing is designed to address.

The consequences are easy to see in the Radiant Capital and Bybit incidents. At Radiant, malware compromised the computers of at least three developers. The signers saw the transaction they expected on screen, but the infected machines altered the data before it reached the hardware wallets. They ultimately produced three valid signatures for a malicious transaction, and roughly $50 million was drained from the protocol.

The Bybit incident involved a different compromise of the environment used to manage its multisig cold wallet. Malicious JavaScript misled the signers about the transaction they were approving: instead of a routine transfer, they authorized a change to the logic of the multisig cold wallet. The attacker then moved roughly $1.46 billion in assets. The attacks were technically different, but they exposed the same problem: the interface on your computer cannot be treated as the final source of truth. Below, we will look at what Clear Signing actually verifies and what you should check on the device before you approve a request.

What a hardware wallet actually signs

When you use a dApp, the transaction is first prepared by software on your computer or phone — Ledger Wallet, Trezor Suite, MetaMask, Rabby, or another interface connected through WalletConnect, for example. The transaction data is then sent to the hardware wallet, where the private key signs it.

The hardware wallet does not see the website itself. It does not know what the browser button says or which address you just checked on your monitor. That is why the device screen is there for more than approving a request: it is where you verify the operation the device is actually being asked to sign.

Before getting into Clear Signing, it helps to separate a few concepts that are often mixed together:

• A transaction vs a message signature. A transaction is broadcast to the network and can immediately change a balance or contract state. An EIP-712 signature is created off-chain and costs no network fee at the time of signing, but it can later be used to authorize something such as a Permit or Permit2 permission.
• approve vs transfer. transfer moves tokens. approve gives another address or contract permission to spend them later. After a malicious approve, your balance may look unchanged even though the permission has already been granted.
• Signing vs broadcasting. The hardware wallet creates the signature. The software on your computer or phone broadcasts the signed transaction to the network.
• A dangerous permission does not mean your seed phrase leaked. If you approve a malicious approve, the private key can remain safely inside the hardware wallet while the contract still receives permission to spend tokens. Other signatures can move assets immediately or change the configuration of a smart account.

For a deeper look at these mechanisms, see our guide to Approve, Permit, Permit2 and WalletConnect. It explains how token permissions work and why disconnecting WalletConnect does not revoke something you have already authorized.

Clear Signing means the device can decode the request and show a human-readable action — for example, Approve USDC, the amount, the address receiving the allowance, or the recipient. With Blind Signing, those details are not available and the screen may show a hash, raw data, or a generic warning instead. Either signature can be cryptographically valid. The practical difference is whether you were able to verify the meaning of the request before approving it.

Radiant and Bybit: when the interface did not match what was signed

On October 16, 2024, Radiant Capital lost about $50 million. The attack began with the compromise of computers used by at least three developers. During what appeared to be a normal transaction, the malware altered the data sent to the hardware wallets even though the operation looked legitimate in Safe, the multisig wallet interface, and in Tenderly, a transaction simulation and debugging service. The goal was to collect three valid signatures for a malicious transferOwnership transaction and take control of critical Radiant contracts. Mandiant later linked the attack with high confidence to UNC4736, a DPRK-linked threat cluster.

On February 21, 2025, Bybit faced a different version of the same trust problem. The Safe{Wallet} environment — the platform the signers used to manage the multisig wallet — was compromised, and malicious JavaScript showed them an expected transaction while they were actually authorizing a change to the logic of an Ethereum multisig cold wallet. The attacker then moved roughly $1.46 billion in assets, including more than 400,000 ETH.

Multisig does not add much protection in this situation if every signer is relying on the same compromised interface and cannot independently verify the request on their device. Multiple people can end up approving the same altered transaction.

ERC-7730: how a wallet can show what you are signing

To show something meaningful such as “Approve 100 USDC,” a wallet needs to know how to interpret the data for that specific contract. On EVM networks, one of the standards used for this is ERC-7730 (Structured Data Clear Signing Format).

A JSON descriptor is created for a contract to explain how its transactions should be presented. The wallet can then identify fields such as the amount, token, address, and action inside the calldata and render them in a form a person can actually review.

ERC-7730 was created on February 7, 2024. As of September 2026, it is still a Draft EIP, but it is already used by production tooling and the Clear Signing registry. In May 2026, the Ethereum Foundation began coordinating the open Clear Signing registry infrastructure as part of its broader security work.

The absence of an ERC-7730 descriptor does not automatically mean Blind Signing. Wallets can decode some operations with their own built-in parsers. You fall back to a hash or raw data when the device cannot interpret the request through ERC-7730 or its own decoding logic.

ERC-8176 is a related proposal for attestations that help wallets verify where an ERC-7730 descriptor came from and how it is tied to a contract. The goal is for the device to display information derived from the transaction itself, not simply repeat whatever the website claims you are signing.

How Clear Signing works on Ledger and Trezor

Ledger

Ledger has supported Clear Signing since 2023. For ERC-7730, support is available through Ledger Wallet over WalletConnect, its built-in Web3 browser, Ledger Wallet Button, and compatible third-party wallets. Whether Clear Signing is available depends not only on the device, but also on the interface used to connect it to the dApp.

The Ethereum app also has a setting called Blind signing. If a particular dApp genuinely requires it, you can enable the setting for that interaction and turn it off again afterward. There is no reason to leave it enabled permanently.

Ledger also uses Transaction Check. Before signing, the transaction can be simulated and the device receives an authenticated risk report. This adds another layer of protection, but it does not replace reviewing the transaction details on the hardware wallet itself. If the device shows an action you did not intend, reject the request.

Trezor

In September 2026, Trezor added ERC-7730 Clear Signing support. It is available on Trezor Safe 7, Safe 5, Safe 3, and Model T running Universal Firmware 2.12.4 or later. There is no separate switch to enable: supported transactions are decoded automatically through Trezor Suite, WalletConnect, and Trezor Connect.

Trezor Clear Signing covers Ethereum and EVM-compatible L2s and sidechains, but a supported ERC-7730 descriptor is required for a particular smart contract. Early supported protocols included 1inch, Aave, Hyperliquid, Lido, LiFi, and OpenCover. If the device cannot decode the operation, it falls back to the usual hash and Blind Signing warning. Trezor Model One does not support ERC-7730 Clear Signing.

MetaMask and Rabby

MetaMask, Rabby, and other software wallets can also decode transactions, run simulations, and warn about suspicious permissions. The difference is that all of this still happens on the same computer or phone where the dApp is open. If you are using a hardware wallet, you should still verify the details on its own screen rather than relying only on the browser.

Bitcoin, Solana, and other networks

ERC-7730 is designed for the EVM ecosystem, so it does not apply to Bitcoin, Solana, or Cosmos. Those networks have their own transaction formats and decoding logic.

For example, Ledger still documents Blind Signing for some more complex Solana dApp interactions. This does not apply to every Solana transaction: standard operations can often be displayed normally. What you see depends on the action and the version of the Solana app installed on the device.

Clear Signing does not guarantee a safe transaction

Clear Signing helps you understand the request, but it does not decide whether the contract itself is trustworthy. An unfamiliar dApp can ask for unlimited access to your USDC, and the device may correctly show Approve, the spender, and the allowance. If you did not intend to grant that permission, you should reject it even when every field is decoded correctly.

Transaction-decoding code can have bugs as well. In 2026, Trezor fixed an issue where Clear Signing for an ERC-20 transfer or approve could fail to display a non-zero ETH value being sent in the same transaction.

In August 2026, Ledger Donjon published three more security bulletins involving transaction verification before signing:

• LSB-023. Under certain conditions, the device could display one set of parameters while signing another. Protection was added to the Ethereum app in version 1.22.2, with the underlying SDK fix included in v26.6.1.
• LSB-024. When processing a large array, the device could display only part of the data even though the signature covered the full structure. The fix was included in Ethereum app 1.22.3.
• LSB-025. In a swap flow, an expected payment could be replaced with an approve using the same parameters. This issue was also fixed in Ethereum app 1.22.3.

Ledger reported no evidence that these three issues had been exploited against users. They did not expose the Secure Element or private keys. You should still keep both the device firmware and the blockchain apps installed on it up to date.

What to do if the device only shows a hash

Sometimes a device simply cannot decode an operation: the contract may be new, the format may be unusual, or the blockchain app may not support it yet. In that case, you are back to Blind Signing. If the device only shows a hash, do not rely on the browser alone — verify the data independently before signing.

For more complex operations, such as an EIP-712 signature or a Safe multisig transaction, you can calculate the hash independently and compare it with the value shown by the device. Safe uses safeTxHash, and Cyfrin provides a tool called safe-hash for this purpose. If you suspect the computer may be compromised, calculating the hash on that same machine defeats the point; use another trusted device.

If the hashes match, the hardware wallet received the same data you calculated independently. That still says nothing about whether the transaction itself is safe — a malicious transaction can have a perfectly correct hash. ERC-8213 proposes a standardized way to make this kind of verification easier. Trezor 2.12.4 can already display a calldata digest, although this is not yet supported universally across wallets.

Simulation in Tenderly or in the wallet itself can also help by showing the state changes expected from a transaction. It should not be your only check, however. Radiant Capital used Tenderly, and the attackers still managed to alter the data at the signing stage.

What to check before signing

Ledger and Trezor present transaction details differently, but the same checks matter before you sign:

1. Network. If you are working on Arbitrum but the device shows Ethereum mainnet, do not approve the transaction until you understand why.
2. Address or contract. For meaningful amounts, compare the full address against an independent source. Checking only the first and last few characters is no longer enough: address poisoning and deliberately generated look-alike addresses can make a malicious address appear familiar.
3. Action. Transfer, Approve, Swap, or Set delegation should match what you intended to do in the dApp. If you expected a swap but the device shows approve, stop and verify the request first.
4. Token and amount. Check them together, and pay particular attention to unexpected decimal precision.
5. approve limit. Check whether you are granting access to only the amount needed or creating an unlimited allowance.
6. Spender and Permit / Permit2 deadline. Verify who is receiving permission to spend your tokens, how much they can spend, and when the authorization expires.
7. Delegation / EIP-7702. If you did not intend to delegate the account to a contract, reject the request. EIP-7702 can change how an ordinary EOA behaves. In a USENIX Security ’26 study covering seven networks, researchers identified 924 malicious contract accounts associated with EIP-7702; confirmed losses in the analyzed incidents exceeded $2.3 million.
8. An unexplained hash or raw data. If you cannot verify it independently, reject the request and find out why the device is not showing a readable description.

If you are still choosing a hardware wallet, ERC-7730 Clear Signing is currently supported on Trezor Safe 3, Safe 5, Safe 7, and Model T, but not Model One. On Ledger, support depends on the blockchain app, connection method, and dApp. Standard Bitcoin transactions do not need ERC-7730 because Bitcoin wallets use their own transaction format to display the address and amount.

What to do if you already signed something you do not understand

First, determine what you actually authorized. A signature by itself does not reveal your seed phrase or private key. The next step depends on the request: an approve or Permit2 signature may leave an active permission, a transfer or swap may already have moved assets, EIP-7702 may have installed a delegation, and a smart-account transaction may have changed wallet settings.

If the issue is a token permission, review active approve allowances and Permit2 permissions through revoke.cash or the block explorer for your network, and revoke anything you do not recognize. For EIP-7702, check separately for an active delegation. Revoking on-chain permissions requires a network fee.

If you are unsure what the signature did and the address holds an amount you cannot afford to lose, consider creating a new wallet on another trusted device and moving the assets after checking the old address. If there is any reason to believe someone may have seen your seed phrase, do not continue storing funds under that seed.

The key takeaway

A hardware wallet isolates the private key, but it cannot decide whether a signing request is safe. Before approving anything, read what the device itself is showing you. Clear Signing makes that easier, but it is not available for every transaction.

Before signing, verify the network, address or contract, action, token, and amount. If the device only shows a hash and you do not know how to verify it, reject the request and find out why the transaction cannot be decoded first.