If your hardware wallet shows only a hash, or a generic prompt such as "Data Present" or "Contract Data", instead of a readable amount, token and recipient, you are being asked to blind sign. The device cannot decode the transaction, so it cannot show you what you are authorising. Your computer or phone screen may be showing you something else, so it cannot settle the question either. The safe default is to decline. Approve only when you have checked the request another way, and only from a wallet that holds little.
What blind signing is
A smart contract call is a function name plus its arguments, encoded as raw data. The wallet can display that data in readable form only if it knows how to decode it. When it does not, it falls back to showing a hash or a placeholder. Coin Bureau's explainer (updated December 19, 2025) defines blind signing this way: approving a transaction when the wallet shows only a hash or a generic prompt such as "Data Present" or "Contract Data", not readable details.
The problem is old. The Ethereum standard for signing structured data, EIP-712 (created 2017, now Final), was written because "signed messages are an opaque hex string displayed to the user." EIP-712 lets wallets display typed fields instead of a hex blob. It does not help when the device has no way to interpret the contract being called.
Ledger says blind signing is turned off by default on its devices and must be turned on by hand. It compares signing a transaction you cannot read to "signing a blank check."
Clear signing: the fix, and where it stops
Clear signing means the device decodes the request and shows the real action on its own screen. Trezor gives "Swap 1,000 USDC for ETH" as an example, with tickers, decimals and the counterparty address.
On Ethereum and EVM chains, clear signing now runs on ERC-7730, the "Structured Data Clear Signing Format." It is a JSON format, created on February 7, 2024 and still a Draft on eips.ethereum.org. It attaches display information, such as labels, token formats and intents, to contract calldata and EIP-712 messages. Ledger says governance of ERC-7730 has moved to the Ethereum Foundation and that a V2 arrived in 2026. Ledger gives no date for the governance move.
The limit is coverage:
- Trezor: a contract "must have a published ERC-7730 descriptor in the registry" before the device can decode it. Otherwise it falls back to the hash or "Data Present" with a warning. Clear signing needs Universal firmware 2.12.4 or later on the Model T, Safe 3, Safe 5 or Safe 7.
- Ledger developer docs: "If no descriptor exists for the target contract, the signer falls back to blind signing." Both the wallet and the dApp must support ERC-7730 for the details to display.
You can therefore see clear-signed and blind-signed prompts in the same session. A blind prompt does not by itself mean something is wrong, but it does mean the device cannot vouch for the request.
Should you approve this signing request?
Answer what your hardware wallet shows and how the request reached you to see what the article's checks suggest.
What does your hardware wallet's own screen show for this request?
- A readable action: amount, token and recipient → next question
- Only a hash, or a generic prompt such as "Data Present" or "Contract Data" → next question
- I already signed something I now think was malicious → Act fast to limit the damage
Do the details on the device match what you meant to do, with the amount limited to what the transaction needs?
- Yes, I recognise every detail and the amount is limited → The device shows a readable match
- No, I don't recognise something, or it asks for an unlimited allowance → Decline the request
Did you start this request yourself, on the app's real site, rather than from a link sent in a private social media message?
- Yes, I started it on the real site → next question
- No, or I'm not sure → Decline the request
Can you confirm the request another way, for example by comparing the transaction hash on the device with one computed independently?
- Yes, I confirmed it independently → next question
- No, I can't confirm it → Decline the request
Are you signing from a separate wallet used for dApp activity that holds only the funds needed?
- Yes, a separate low-balance wallet → Proceed only with care
- No, this wallet holds my main funds → Move to a separate wallet first
The device has decoded the request and it matches your intent. Approve only the amount the transaction needs, and review your token approvals regularly.
Trezor's guidance is to decline if you don't recognise the details on the device. Never sign a request you didn't start, and don't approve an unlimited allowance.
A blind prompt means the device cannot vouch for the request, even after your checks. Limit the amount, keep the wallet separate from your main funds and review approvals afterwards.
Approvals are per wallet, so a drained dApp wallet cannot touch a vault that never connects to dApps. Ledger and Coin Bureau both recommend a separate wallet that holds only the funds needed.
A signed and executed transaction cannot be reversed. Revoke the approvals for the affected token and contract, treat the wallet as compromised and move remaining funds to a new, clean address.
This follows the article's checklist for EVM chains and Ledger and Trezor devices only; it cannot inspect a real transaction or tell whether a specific request is safe.
How attackers use it
Unlimited token approvals
Under the ERC-20 standard, approve lets a spender "withdraw from your account multiple times, up to the _value amount." Coin Bureau calls one attack the most common: a drainer contract gets the user to approve an unlimited amount (usually the maximum uint256 value), then sweeps the tokens later. The theft can come days after the signature.
Off-chain permit signatures
EIP-2612 permit (Final) lets a token holder grant an allowance by signing an EIP-712 message instead of sending a transaction. Anyone can then submit that signature to the token contract. A signature that costs no gas and sends nothing can still hand over spending rights.
A compromised computer
The device screen matters because the host screen can lie. Two large incidents show how this happens:
- Radiant Capital, October 16, 2024. Radiant's post-mortem, as reported by crypto.news (the original on Medium could not be retrieved), says malware on the devices of at least three developers showed "legitimate transaction data" in the Safe interface while malicious transactions were signed in the background. Losses were "upwards of $50 million." The report recommends "avoiding blind signing for critical transactions."
- February 21, 2025. The FBI attributes the theft of about $1.5 billion in virtual assets from a cryptocurrency exchange to North Korea's "TraderTraitor" activity. Safe said the attack came through a "compromised Safe{Wallet} developer machine resulting in the proposal of a disguised malicious transaction," as reported by The Block on February 26, 2025.
In both cases the signers used multisig setups with hardware wallets, and the interface they trusted showed a harmless-looking request.
What to check before you approve
- Read the device, not the browser. Trezor's guidance is to decline if you don't recognise the details on the device. The device shows the real transaction even when a compromised frontend displays something else.
- Treat a hash or "Data Present" as a stop sign. Ask why this contract isn't clear-signed. Approve only if you can confirm the request another way.
- Check the site and the request's origin. Ledger advises confirming you are on the app's real site and treating links sent in private social media messages with suspicion. Never sign a request you didn't start.
- Limit the amount. Approve only what the transaction needs, not an unlimited allowance.
- Separate your wallets. Ledger and Coin Bureau both recommend a separate wallet for dApp activity that holds only the funds needed. Approvals are per wallet, so a drained burner wallet cannot touch a vault that never connects to dApps.
- For advanced users: Ledger notes its Ethereum app can show the transaction hash for every transaction. You can then compare it with a hash computed independently using a third-party tool.
- Review approvals regularly. The Etherscan Token Approvals page lets you review and revoke ERC-20, ERC-721 and ERC-1155 approvals. Revoking an ERC-20 approval means calling
approve()again with the amount set to 0. Coin Bureau suggests a monthly review for heavy DeFi users and quarterly for lighter users.
If you think you signed something malicious
A signed and executed transaction cannot be reversed. Coin Bureau's steps:
- Revoke the approvals for the affected token and contract.
- Treat the wallet as compromised.
- Move remaining funds to a new, clean address.
Act fast, because a drainer can use an approval at any time.
Limitations: this guide covers EVM chains and Ledger and Trezor devices; other chains and wallets handle signing differently, and no source reviewed measures how often blind signing leads to losses.
