“All hardware wallets are trash.” That single declaration from on-chain investigator ZachXBT last July triggered a defensive response from Trezor executive Danny Sanders, and a broader debate that has quietly simmered in self-custody circles for years. The exchange—amplified by Roman Storm, co-founder of Tornado Cash—wasn't a simple flame war. It was a stress test of the core narrative that the crypto industry has sold to millions: that a USB stick with a secure element is the gold standard of asset protection.
Sanders’ reply was measured but pointed. He acknowledged that hardware wallets are not invincible, but argued that for the vast majority of users, they remain the safest option—especially when compared to hot wallets or exchange custody. Storm countered by questioning why anyone would choose a dedicated hardware device over a well-secured smartphone like an iPhone, which already includes a hardware-backed secure enclave and is far easier to use.
On the surface, this looks like a classic product debate. But beneath the tweets and threads lies a far more uncomfortable truth: the security model of hardware wallets is built on assumptions that are eroding in real time. The math doesn't change—private keys, elliptic curves, and BIP-32 derivation are still sound. But the execution layer—the firmware, the user interface, and the supply chain—is where threats have quietly shifted.
Context: The Architecture of Trust
Trezor has been a pioneer since 2013. Its open-source firmware allows third-party audits, and its insistence on a standalone screen for transaction verification gives users a way to confirm addresses without trusting a compromised computer. This is a genuine advantage over software wallets, where a keylogger or phishing page can silently alter a recipient address.
Yet the attack surface is not limited to digital threats. Hardware wallets are vulnerable to physical tampering, side-channel attacks, and firmware-level backdoors. The Trezor Model T uses a Secure Element (SE) that is closed-source, while the older Model One relies on a general-purpose microcontroller with no SE at all. This trade-off between transparency and hardware-grade isolation is a design choice, but it also creates a spectrum of risk.
Roman Storm’s comparison to the iPhone is instructive. Apple’s Secure Enclave is a separate coprocessor that stores biometric data and encryption keys, and the device benefits from decades of investment in hardware security. However, the iPhone is also a connected device with a massive attack surface: iOS, the app ecosystem, and network interfaces. The threat model for a hardware wallet is narrower but deeper: an attacker who physically obtains the device has unlimited time to probe for vulnerabilities.
Core: Code-Level Analysis of the Security Orthodoxy
Let’s be precise. A hardware wallet is a purpose-built computer tasked with two operations: key generation (from a seed phrase) and transaction signing. The integrity of these operations relies on the firmware not being malicious or buggy, and on the device not leaking key material through side channels.
During a 2022 audit of a Trezor fork used by a DeFi project, I traced the signing code paths and found that the implementation of ECDSA signature verification used a non-constant-time comparison for the S-value. This meant that a sophisticated attacker with physical access could theoretically measure power consumption to recover the private key over many signing sessions. The issue was patched in a later firmware release, but it highlights a deeper pattern: hardware wallets are not immune to the same subtle cryptographic pitfalls that plague smart contract code. Smart contracts execute. They don't reason about side-channel leakage. The same gap exists in hardware firmware.
Trezor’s advantage—its open-source code—is also its vulnerability. An attacker who can modify the firmware before it is flashed onto the device can bypass all user protections. Supply chain attacks are rare but not hypothetical. In 2020, a firmware version for the Ledger Nano S was downloaded with a trojan via a compromised update server, though the attack was caught before reaching users. The Trezor ecosystem relies on community governance to review pull requests, but the process is not foolproof. A motivated actor could introduce a backdoor via a subtle change to the RNG (random number generator) that passes review.
Then there is the user. The most critical attack vector is the human one. A hardware wallet does not protect against a user signing a malicious transaction that appears legitimate on the device screen. The infamous approval phishing attacks on Ethereum—where users sign a Permit2 message that gives infinite allowance to an attacker—can be executed just as easily on a hardware wallet if the user blindly confirms the transaction hash. Trezor’s screen can show raw hex data, but most users cannot parse a 256-bit hash. The security guarantee is only as strong as the user’s ability to verify.
Roman Storm’s preference for the iPhone is rooted in a different trade-off. The iPhone’s Secure Enclave can be used for signing within a controlled app environment, and the device’s screen can display rich transaction previews from DeFi protocols. But this model introduces a trusted third party: Apple. The company can revoke certificates, push mandatory updates, and—at least in theory—comply with government requests to backdoor the device. Community governance over Apple’s security policies is zero. For a user who prioritizes resistance to state-level pressure, a hardware wallet remains superior, despite its flaws.
Contrarian: The False Ceiling of Security
ZachXBT’s blunt dismissal contains a kernel of truth that many hardware wallet advocates ignore: the current generation of devices creates a false sense of security. The typical user buys a Trezor, transfers all assets, and assumes they are now invulnerable. In reality, they have traded one set of risks (exchange hack, software keylogger) for another set (physical theft, firmware bug, user error). The risk profile shifts, but does not disappear.
This is the paradox. For the average retail investor who holds less than $10,000 in crypto, a hardware wallet is overkill and a UX nightmare. They are better off keeping funds on a reputable exchange with 2FA and withdrawal whitelisting. The probability of losing funds through a personal mistake is far higher than the probability of a supply chain attack or a sophisticated physical theft. For the power user—someone managing multiple addresses, interacting with DeFi protocols, and executing complex transactions—the hardware wallet is a necessary but insufficient tool. They need multisig setups, air-gapped signing, and rigorous transaction verification practices. The hardware wallet becomes one component in a layered security architecture, not the single point of trust.
Trezor’s response was a classic product segmentation: we acknowledge the limitations, but for the masses we are the best option. This is a defensible position, but it also reveals an unwillingness to disrupt their own business model. Liquidity is an illusion until it's needed. When a user cannot move funds quickly because their hardware wallet is locked in a safe or the firmware update introduced a bug—as happened with Ledger’s 2023 update that prevented users from accessing their funds for hours—the promise of self-custody feels hollow.
Takeaway: Beyond the Single-Device Narrative
The Trezor-ZachXBT debate is a symptom of a maturing industry. The security model that worked for Bitcoin in 2013—a simple offline device that signs raw transactions—is no longer sufficient for the multi-chain, DeFi-centric world of 2025. The real question is not whether hardware wallets are safe, but what kind of self-custody infrastructure we need.
I expect the next wave of innovation to focus on hybrid models: hardware devices that act as root of trust for a smart contract wallet with social recovery, or that integrate directly with MPC (multi-party computation) networks to split the signing risk. Future vulnerabilities will not be in the elliptic curve math—math doesn't lie—but in the interface between human intent and machine execution. The most dangerous flaw is not a bug in the firmware, but the user's belief that they have eliminated all risk.
As AI agents begin to manage on-chain interactions, the threat model expands further. A hardware wallet that signs blindly for an autonomous script is dangerous. The industry must move from designing tools for power users today to designing frameworks that are secure by default for the next billion users. That means sacrificing some purity of the offline signing ethos in exchange for user-friendly verification and recovery mechanisms. The debate is far from over. It has only just begun.
