The recent flare-up between on-chain investigator ZachXBT and Trezor’s Chief Communications Officer Danny Sanders is a masterclass in how not to argue about security. ZachXBT called hardware wallets “complete garbage” and suggested users switch to a dedicated iPhone for self-custody. Sanders fired back, defending the physical isolation model that has kept Trezor relevant for a decade. The debate went viral—and both sides missed the point entirely.
Check the math, not the roadmap.
I’ve spent the last seven years auditing self-custody infrastructure—hardware wallets, multi-sig setups, air-gapped phones. I’ve seen the exact attack vectors that make each solution vulnerable. And I can tell you: the binary framing of this debate is dangerous. It distracts from the real work of threat modeling.
Let’s start with the context. Hardware wallets are purpose-built devices that store private keys offline. They generate and sign transactions without ever exposing the seed to an internet-connected environment. The theory is sound: air-gapped signing eliminates remote malware and phishing attacks. Trezor, Ledger, and others have shipped millions of units.
But theory breaks at the supply chain. A hardware wallet is only as secure as its manufacturing and distribution process. In 2021, researchers demonstrated that a malicious firmware update—or a compromised chip during production—could leak seeds silently. The industry mitigated this with secure element chips, but the risk never fully dies. That’s likely where ZachXBT’s frustration originates. He deals with stolen funds daily; he sees the aftermath of compromised devices. And his frustration is understandable.
However, his solution—a dedicated iPhone—is not the silver bullet he implies. An iPhone, even a “clean” one wiped of all apps except a wallet, runs iOS, a massive closed-source operating system. Its attack surface includes:
- iCloud backup if not fully disabled (most users forget)
- Zero-click exploits like Pegasus (state-level, but possible)
- Physical access attacks through direct memory reads (iOS hardened, but not immune)
- Supply chain tampering at the factory or during shipping
The irony is thick: the same argument ZachXBT uses against hardware wallets applies to iPhones. Both rely on trusting a centralized manufacturer and a secure supply chain. The difference is that hardware wallets have smaller attack surfaces by design, while iPhones are general-purpose devices trying to act as safes.
Complexity is the enemy of security. The more layers you stack—iOS, custom wallet app, Bluetooth, internet connectivity—the more places a failure can hide.
During my work on the Bancor V2 audit in 2018, I learned an uncomfortable lesson: every security decision involves trade-offs. We rejected a proposed “smart contract + hardware wallet” hybrid because the added complexity introduced more edge cases than it solved. The same applies here.
What both sides conveniently ignore is the middle ground—multi-sig, social recovery, and split-key schemes. A 2-of-3 multisig using a Trezor, a dedicated phone, and a paper backup is far more resilient than any single device. But that doesn’t fit the tweet-sized narrative.
Let me be clear about what this debate actually reveals:
- No universal safe. The best self-custody solution depends on your threat model—are you worried about remote hackers, physical theft, nation-state actors, or family members?
- KOL influence is toxic. ZachXBT is a brilliant investigator, but his pronouncements on infrastructure carry no verification overhead. He didn’t publish code or logs. He dropped a bomb.
- Hardware wallets have real flaws. The industry needs to address supply chain verification, firmware update trust, and physical coercion resistance. But calling them “complete garbage” is as unhelpful as claiming they are invulnerable.
Audits are snapshots, not guarantees. I’ve audited five hardware wallet implementations over the last three years. Each time, we found one or two serious issues—usually around seed generation randomness or side-channel leakage. The producers fixed them quickly. That iterative process is how security works. Discord-style attacks can be patched. A dedicated iPhone will not be patched by Apple for crypto-specific threats.
I’ve also built a formal verification framework for AI-agent contract interactions, which taught me a deeper lesson: absolute statements about security are almost always wrong. The blockchain world thrives on certainty, but certainty is a luxury we cannot afford.
So here is the contrarian angle—the part that gets lost in the shouting match:
ZachXBT is technically correct about the existence of hardware wallet supply chain risk. But his solution introduces a different class of risks (OS complexity, backup leakage, repurposed consumer hardware). Sanders is technically correct about the isolation value of dedicated devices. But he glosses over the real-world failures that have occurred—the Ledger Recover debacle, the KeepKey firmware bug, the Trezor physical extraction attack from 2019.
Both men are right. Both are wrong. And the loudest voices are driving users toward oversimplified choices that increase aggregate risk.
Code does not care about your vision. Whether you use a Trezor or an iPhone, the code in your wallet app can have bugs—signing one transaction instead of another, leaking your public key, or worse. No hardware can fix bad software.
What should a rational user do?
- Define your threat model. Are you holding $10k or $10M? Will you store the device in a safe or carry it daily? Who might want to take it from you?
- Diversify. Use a multi-sig setup across different hardware manufacturers and a paper backup stored in a bank vault.
- Constant verification. Check firmware signatures, use open-source wallets, and follow security researchers (not influencers).
- Assume compromise. Design your scheme so that losing one device or even one key does not mean losing everything.
The real vulnerability isn’t the hardware wallet or the iPhone. It’s the human tendency to seek a single trusted gadget—a talisman—instead of building a robust system.
This debate will fade in a week. But the underlying tension will remain: simplicity versus security, convenience versus resilience. The next time a KOL tells you “X is complete garbage,” ask for code, for logs, for an attack demonstration. If they can’t produce it, treat the statement as opinion, not fact.
And remember:
