A hardware wallet protects the key, not the decision
The device does exactly what it promises: the private key never leaves the secure element. What it cannot promise is that the thing you approved on a small screen is what the transaction does.
Why can't a Ledger or Trezor screen protect you from a malicious dApp?
Because its security model is key isolation, not semantic verification. Rendering a contract call meaningfully needs the interface definition, address context, an understanding of what a permit grants, and screen area. A device deliberately built not to be a general-purpose computer has none of those.
- Key isolation and semantic verification are separate problems. Hardware wallets solve the first well and cannot solve the second.
- Blind signing warnings are accurate and get dismissed, because the alternative is being unable to transact.
- Moving the rendering to a layer that can parse, and binding the signature to that rendering, keeps the device doing what it is good at.
Part of Digital asset custody
What the device is actually for
A hardware signer has one core security property: the private key is generated in and never leaves a secure element, and signing requires physical confirmation.
That defeats a large class of attacks. Malware on the host cannot extract the key, cannot sign without physical presence, and cannot silently authorise anything. These are genuine and valuable properties.
| Threat | Hardware wallet |
|---|---|
| Key theft from a compromised host | Prevented |
| Silent signing by malware | Prevented — physical confirmation required |
| Key extraction from the device | Resistant by design |
| Signing a transaction that does something other than displayed | Not addressed |
Why the last row is hard
Rendering a contract call meaningfully requires several things a constrained device does not have.
- The contract's interface definition, to decode calldata into named parameters.
- Address context, to say whether a destination is a known exchange, a treasury, or an unknown contract.
- Semantic understanding, to explain that a permit grants unlimited spending authority rather than transferring a specific amount.
- Screen area, to show all of it without the user scrolling through dozens of small screens.
Each requires storage, compute and display the device does not have, and adding them would make it a general-purpose computer — which is the thing it was designed not to be.
Why the warning fails
When the device cannot parse, it says so. That message is honest and it is also the last thing between the user and a transaction they want to make.
- It appears for most interactions with anything non-trivial, so it becomes routine
- It offers no path other than proceed or abandon
- The user has already decided to make the transaction; the device is the last step
- The warning describes the device's limitation, not a specific risk with this transaction
A warning that fires almost always and offers no alternative is not a control. It is a disclaimer, and it functions as one.
Moving rendering where it can work
The right layer is one with the resources to decode and the ability to be verified independently.
# The signing layer renders; the device signs a digest.
statement = decode_and_render(payload) # full decode, all fields
digest = sha256(JCS(statement))
# Device displays the digest and a short human summary;
# the user reviews the full statement on a capable screen
# that is NOT the application that built the payload.
# Before broadcast, an independent verifier recomputes
# decode_and_render(payload) and compares to the signed digest.The device keeps doing key isolation and physical confirmation. The rendering happens where there is room for it. The independence of the verifier is what stops a compromised application from rendering a lie.
The honest limitation of that design
If the machine displaying the statement is compromised, it can display something false. This is the same trusted-display problem the hardware wallet was trying to solve by having its own screen.
Two things reduce it. Rendering on a device separate from the one that built the transaction — a phone, when the transaction originated on a laptop — means a single compromise is insufficient. And independent verification before broadcast catches a mismatch even when the display was wrong.
Neither is perfect. Both are better than a small screen showing a hash.
What custody teams should do today
- Treat blind signing as a refusal condition for material transactions, not a warning to acknowledge.
- Decode transactions with tooling independent of the interface that built them, and compare the results.
- Simulate against forked state and review the resulting balance and permission changes, which is closer to what the user actually cares about.
- Render on a device that is not the one that constructed the payload.
- Restrict the contracts your flows can interact with to a reviewed allow-list, so the arbitrary-contract problem largely disappears.
The fifth is the one that changes the shape of the problem. Most institutional flows interact with a small, stable set of contracts, and accepting arbitrary ones is a choice rather than a requirement.
Why the warning does not function as a control
When the device cannot parse a call it says so. That message is honest, and it is the last thing between the user and a transaction they have already decided to make. It fires on most non-trivial interactions, offers no path other than proceed or abandon, and describes the device's limitation rather than a specific risk with this transaction. A warning that fires almost always and offers no alternative is a disclaimer, and behaves like one.
| Requirement | Why the device lacks it |
|---|---|
| Contract interface definition | Storage for thousands of ABIs that change |
| Address context | A registry mapping addresses to known entities |
| Semantic understanding | Knowing a permit grants ongoing spend authority, not a transfer |
| Screen area | Showing all of it without dozens of scroll steps |
Objections and honest limits
“So hardware wallets are pointless.” No — they should be used. Key isolation and physical confirmation defeat a large class of attacks, and in the largest custody incidents no key was ever stolen. That is the measure of how well they do their job.
“Rendering elsewhere just moves the trusted display problem.” Partly. Rendering on a device separate from the one that built the transaction means a single compromise is insufficient, and independent verification before broadcast catches a mismatch even when the display was wrong. Neither is perfect; both beat a hash on a small screen.
For institutional flows the shape of the problem changes: most teams interact with a small, stable set of contracts. Accepting arbitrary ones is a choice, and an allow-list removes most of this surface. See the payload flip for what happens when it is not.
What a custody team can do this week
- Treat blind signing as refusal, not warning. For any material transaction. A warning to acknowledge is not a control.
- Decode with independent tooling. Code that shares nothing with the interface that built the payload, and compare.
- Simulate against forked state. Show signers the balance and permission diff, which is what they actually care about.
- Render on a second device. Not the machine that constructed the transaction.
- Restrict to a reviewed contract allow-list. Most institutional flows use a small stable set; arbitrary contracts are a choice.
Terms used here
- Key isolation
- Generating and holding a private key inside a secure element so it never leaves, and requiring physical confirmation to sign.
- Blind signing
- Approving a transaction the device cannot parse, so the human confirms a hash rather than an effect.
- Permit
- A signed approval granting a contract ongoing authority to move tokens. Structurally a signature, consequentially a standing permission.
Frequently asked questions
Are hardware wallets not worth using? They are, and they should be. Key isolation and physical confirmation defeat a large class of attacks. They simply do not address semantic verification.
Why can't the device parse contracts? It would need interface definitions, address context, semantic understanding and screen area — which means becoming a general-purpose computer, the thing it was designed not to be.
Why doesn't the blind signing warning work? It fires almost always, offers no alternative path, and describes the device's limitation rather than a specific risk. That makes it a disclaimer, not a control.
What is the highest-leverage change for institutions? An allow-list of reviewed contracts. Most institutional flows use a small stable set, so accepting arbitrary contracts is a choice rather than a requirement.
Should we stop using hardware wallets? No. Key isolation and physical confirmation are valuable and effective. They simply do not address whether the payload matches the display.
What is the single highest-leverage change for institutions? An allow-list of reviewed contracts. It converts the arbitrary-contract problem into a bounded one.
Where this fits in Manav
Manav moves the rendering to a layer with room for it, hashes the canonical statement, and has an independent verifier recompute that hash from the payload before broadcast. The device keeps doing key isolation, which is what it is good at.