For years, hardware wallets have been treated as the gold standard for protecting cryptocurrency. By keeping private keys off internet-connected devices, they shut out a whole class of threats, from malware to phishing. But recent attacks have exposed a gap in that model: a well-protected key offers little defense if the person using it can’t tell what they are signing.
The Bybit hack in February 2025 made that painfully clear. North Korea’s Lazarus Group compromised a developer’s machine at Safe{Wallet}, the multisig platform Bybit used to manage its Ethereum cold wallet, and injected malicious code into the signing interface.
Bybit’s signers saw what looked like a routine transfer. What their hardware wallets actually signed was a change to the wallet’s underlying logic that handed control to the attackers. Roughly $1.5 billion in ETH was stolen, the largest crypto theft on record at the time.
The keys were never extracted. The devices did exactly what they were designed to do. That raises an uncomfortable question for the industry: how much protection does cold storage provide if users can’t independently verify what they authorize?
As smart-contract wallets, multisig accounts and complex onchain operations become the norm, the answer increasingly depends on three things working together: transparent software, inspectable hardware and transaction verification that happens on the device itself.
Why Isn’t Cold Storage Enough?
A hardware wallet’s job is simple. It generates and stores private keys on a dedicated device, away from the computer or phone that connects to the internet. When a transaction needs signing, the connected app sends the data to the device, which signs it internally and returns the signature without ever exposing the key.
That design makes it very hard for remote attackers to steal keys. It does nothing to stop a user from approving a malicious transaction. A hardware wallet can keep a key perfectly isolated while still signing a transaction that drains funds, changes account permissions or grants a malicious contract access to assets.
Blind signing is when a hardware wallet asks a user to approve a transaction it can’t display in readable form, showing raw contract data or incomplete details instead of a clear account of what the transaction will do. When the screen on the connected computer is also compromised, as it was at Bybit, the signer has no trustworthy view of the transaction anywhere.
Bybit was not an isolated case. In October 2024, attackers drained roughly $50 million from lending protocol Radiant Capital using a similar playbook. Malware on three developers’ devices showed legitimate-looking transactions in the Safe interface, while the hardware wallets were signing a transfer of contract ownership. Each signer approved what they believed was routine.
None of this means hardware wallets are ineffective. It means offline key storage is only half the job. For anyone managing large holdings, multisig accounts or DAO treasuries, the other half, verifying intent, matters just as much.
Why Open Source Matters
There is also the question of what runs inside the device. Most users have no visibility into how their hardware wallet works. They rely on the manufacturer to write secure firmware, generate keys properly and make sure the physical components behave as advertised.
Open-source development replaces some of that trust with inspection. When firmware is public, independent researchers can review the code, find vulnerabilities and propose fixes. Open-source hardware extends the same idea to circuit-board designs and component layouts, and in some cases lets technically capable users build their own devices.
Transparency is not the same as security, however. Open code can still contain bugs, and public hardware designs do nothing to stop a tampered component from entering the supply chain. Independent audits, secure manufacturing and ongoing maintenance remain essential.
Publishing code also isn’t the same as making a device verifiable. Reproducible builds close part of that gap by letting anyone compile the firmware from source and confirm the result matches the binary the manufacturer ships. The goal is security that can be examined and tested, not security users are asked to take on faith.
What Makes a Hardware Wallet Trustworthy?
No single feature does it. A trustworthy device combines several layers.
Secure key generation and storage. Keys should be created in a protected environment and never leave it. Secure elements add hardware-level resistance to physical extraction attacks, but a secure element on its own guarantees little. How it is implemented, and how it interacts with the surrounding hardware and firmware, matters just as much.
Firmware transparency. Firmware governs how the device handles keys, processes transactions and communicates with other devices. If it can’t be inspected, users have to trust the manufacturer. Public source code helps most when it comes with documented build and verification procedures.
Transaction verification. This is the most overlooked requirement. A device should do more than confirm it received a transaction; it should show what the transaction will do, including transfers, token approvals, contract calls and changes to account permissions.
Supply-chain integrity. Even a well-designed device can be compromised before it reaches the user, through swapped components or tampering during manufacturing. Inspectable hardware and manufacturing controls belong in the same conversation as firmware security.
What Is Clear Signing?
Simple transfers are easy to display: a recipient and an amount. Smart-contract interactions are not. A single transaction can bundle token approvals, transfers, contract calls and ownership changes, and multisig wallets routinely batch several operations together. Raw calldata means little to most users, and even experienced developers struggle to read it without context.
Clear signing is the alternative: the hardware wallet decodes the transaction and shows, in plain language on its own screen, what it will actually do. Where that translation happens is the crucial part. If the computer or browser is compromised, nothing it displays can be trusted. The hardware wallet has to interpret the transaction independently and present its own account of what will happen.
The industry is starting to standardize this. ERC-7730, a format first proposed by Ledger and now stewarded by the Ethereum Foundation, lets developers describe how their contracts’ functions should be displayed, so any compatible wallet can show the same readable summary instead of raw data. The more wallets and applications adopt a shared format, the less clear signing depends on any single vendor.
On-device decoding won’t stop every attack, particularly ones involving unfamiliar contracts or malicious application logic. But it gives signers a real chance to catch something suspicious before they approve it, which is exactly what Bybit’s signers lacked.
Ambire Ice: One Approach in Practice
These ideas are already shaping new hardware. On October 30, self-custodial wallet developer Ambire unveiled Ambire Ice, an open-source hardware wallet built for Ambire and Safe smart accounts. It joins a small but growing group of open-source signers, including Trezor and Keystone, whose firmware outsiders can inspect.
Rather than pitching Ice primarily as offline key storage, Ambire has centered the design on transaction verification. The device reconstructs Safe transactions itself and displays each action on its screen, so signers can review transfers, token approvals and batched operations before approving them. It also warns when a transaction would change a Safe’s owners, signature threshold or modules. According to Ambire, it blocks DELEGATECALLs to unknown contracts unless they appear on an allowlist, which targets the type of call used in the Bybit attack.
On the hardware side, Ice pairs secure elements from NXP and Infineon to guard against different kinds of physical attacks. A physical switch disconnects USB data and cuts power to Bluetooth, enabling fully offline signing through animated QR codes, while USB and Bluetooth remain available for those who want them. The firmware is a fork of Trezor’s open-source codebase; Ambire says the hardware designs and board files are open to inspection, and a transparent enclosure lets users see the internal components for themselves.
Taken together, the design reflects a broader shift: pairing isolated key storage with transaction-level verification and a hardware and software stack that outsiders can check. None of these features makes a device immune to attack, and Ambire’s claims will still need independent testing. Their value lies in giving researchers and users more to inspect and verify.
Self-Custody Is About More Than Private Keys
The crypto industry has spent years teaching users to protect their seed phrases and keep their keys offline. That advice still holds, but the complexity of today’s onchain activity has opened a new gap. A hardware wallet that guards keys but can’t clearly communicate what a user is authorizing leaves the most consequential step, the decision to sign, resting on trust.
Open-source firmware, inspectable hardware, sound key generation and on-device transaction decoding each address part of that gap. None is sufficient alone. Together, they make a device’s security assumptions easier to examine and challenge.
The goal is no longer just to keep private keys offline. It is to give users good reason to trust what happens when they press “sign.”
(Photo by Mariia Berezovsky on Unsplash)
