A recent wallet security incident has reignited an important conversation about the foundations of self-custody. Researchers linked a firmware flaw in a hardware wallet to the rapid sweeping of more than 1,100 Bitcoin addresses, representing an estimated $70 million in digital assets. The affected devices included a hardware random number generator (RNG) designed to provide high-quality entropy, but a firmware integration error caused wallet seeds to be generated using a predictable software pseudorandom number generator (PRNG) instead. As a result, attackers were able to reconstruct candidate wallet seeds offline.
The incident demonstrates that secure hardware alone does not guarantee secure self-custody. Every stage of a wallet's security architecture, from entropy generation and firmware to key management and transaction signing, must work together correctly. More importantly, it raises a broader question. Rather than asking how one implementation failed, we should ask how wallet architectures can be designed to remain secure even when individual components do not. The incident offers three lessons for building more resilient self-custody systems.
Lesson 1: Security Is an End-to-End Property
The first lesson is that wallet security cannot be judged by any single component. A hardware random number generator, a secure chip, or a well-designed cryptographic algorithm can all be implemented correctly, yet the wallet as a whole can still be compromised if another part of the security chain fails.
Modern hardware wallets rely on multiple layers working together, including entropy generation, firmware, key generation, private key management, and transaction signing. Each layer depends on the integrity of the previous one. A weakness introduced at any stage can undermine the protection provided by every other layer, regardless of how secure those individual components may be.
This is why secure self-custody requires an end-to-end approach to security. Hardware, firmware, and cryptographic protocols must work together as one integrated system. A wallet is only as secure as the chain that generates, protects, and uses its cryptographic keys.
Lesson 2: Eliminating the Single Point of Failure
The deeper issue is architectural. Every affected wallet was a single-signature wallet, generated on a single device, and depended on a single software path to create its private key. That meant one implementation flaw was enough to compromise the wallet. In traditional wallet architectures, one device, one private key, and one implementation determine the security of all the assets.
Multi-Party Computation (MPC) takes a fundamentally different approach. Instead of relying on a single device to generate and protect a complete private key, MPC distributes cryptographic operations across multiple independent participants, each independently generating and protecting its own key share. No participant ever possesses the complete private key, and transactions are signed collaboratively without reconstructing it.
This changes the security model. Compromising one participant, whether through weak randomness, a software vulnerability, or another implementation flaw, is no longer enough to compromise the wallet. An attacker would need to compromise multiple independent key shares simultaneously, making attacks significantly more difficult. Rather than depending on one device to work perfectly, MPC builds resilience directly into the wallet architecture.
Lesson 3: Building Trust with Verifiable Hardware
Building resilient wallet architecture is only part of the solution. Self-custody also depends on the ability to verify the technologies responsible for generating, protecting, and using cryptographic keys. While open-source firmware improves transparency, it is only one layer of the security stack. The hardware beneath it remains the root of trust, yet it is often hidden from independent inspection.
This creates a fundamental gap between the ideals of crypto and today's hardware security model. Most secure elements are developed as closed systems, with proprietary implementations protected by non-disclosure agreements. Although users can inspect the software running on their devices, they are still expected to trust the silicon responsible for generating entropy, protecting key material, and performing security-critical operations. For an industry built on the principle of "Don't trust, verify," that leaves an important part of the trust chain beyond verification.
CrossBar believes verification should extend beyond software to the hardware itself. Publishing hardware and software specifications or RTL is only the first step. The real goal is meaningful verification by enabling security-critical hardware to be independently inspected, audited, and verified by the broader community. MPC and verifiable hardware solve different trust problems. MPC removes the single point of failure by ensuring no complete private key ever exists in one place. Verifiable hardware ensures the foundation responsible for generating and protecting those key shares can be independently verified rather than simply trusted. Together, they reflect CrossBar's vision for the future of self-custody: resilient by design, verifiable by default.
In Conclusion
The lessons from this incident extend far beyond a single firmware bug. They point toward a future where wallet security is no longer defined by the strength of any individual component, but by the resilience and verifiability of the entire system.
At CrossBar, we believe resilient self-custody rests on two complementary principles. MPC removes single points of failure by ensuring no complete private key ever exists in one place. Verifiable hardware extends the principle of "Don't trust, verify" beyond software to the silicon responsible for generating and protecting cryptographic keys. Together, these principles create self-custody systems that are designed to withstand failures while giving users greater confidence in the technologies securing their digital assets.
As the industry continues to evolve, the next generation of self-custody will be defined by architectures that are resilient by design and built on verifiable foundations.
—The CrossBar Team