Coldcard之后,我们该如何理解自托管
- Key Takeaway: The Coldcard firmware random number generator flaw exposed vulnerabilities in hardware wallets, yet the value of self-custody remains undiminished. Its core lies in users retaining on-chain final authorization and the independent ability to migrate. The choice between custody and self-custody requires a risk trade-off based on real-world conditions, and product makers must bear the responsibility for reliable default design.
- Key Elements:
- A Coldcard firmware integration error caused some devices to bypass hardware-based random number generation, using a predictable path instead. This meant the seed phrase was inherently compromised from the point of generation, and careful management by users afterward could not mitigate the flaw.
- The incident shattered the cognitive shortcut that "hardware/offline/open-source equals secure." Since average users cannot audit firmware line by line, reliable default paths should be the fundamental responsibility of security products.
- OKX saw significant capital inflows, and CZ cited River's historical data to claim that "exchange custody is safer than self-custody." However, early loss data is difficult to attribute accurately, and loss figures weren't adjusted for scale, making them insufficient for measuring current risk.
- Custody reduces the burden of personal key management, but increases dependence on an institution's continued operation and solvency. Self-custody, on the other hand, preserves an independent path to recover and migrate assets via compatible tools if a platform fails.
- The value of self-custody lies in the arrangement of control, not absolute control over external conditions. Users need to confirm backups are recoverable and understand what they're authorizing, but these skills can be built gradually and should not become an exam for everyone to become a cryptography expert.
- Product makers should verify critical paths and respond transparently to issues. Security comes from reliable default design. Both users and institutions must clearly understand the risks they bear and the capabilities they retain.
Following the Coldcard incident, a question has resurfaced: if hardware wallets can also fail—and may even harbor vulnerabilities from the very moment keys are generated—why should we custody our own assets at all?
Our assessment is that self-custody remains important. It gives users the ultimate authority over on-chain operations and preserves the possibility of independent migration when platforms or services fail. Coldcard hasn't changed that value, but it has forced us to re-examine "how to securely hold control."
Security Can't Be Judged by a Single Label
According to the official Coldcard announcement and Block's technical analysis, a firmware integration error caused some devices to bypass the hardware random number generator as intended, instead falling back to a predictable software random number path. On the surface, the mnemonic phrases appeared normal, but they may have failed to meet the required security standard from the very moment of key generation.
In numerous public cases, users didn't click phishing links or leak their mnemonic phrases—they simply created wallets following the product's default process. The problem occurred at the source of key generation, and no amount of careful custody afterward could close that gap.
This incident shatters a common cognitive shortcut: hardware, offline operation, or open-source code can all enhance security, but no single label constitutes a security conclusion on its own. Ordinary users cannot audit firmware line by line. Making the default path reliable is precisely the responsibility that security products should bear.

After the incident, OKX reported significant capital inflows to its platform. CZ subsequently cited a set of historical data, arguing that "statistically, keeping assets on an exchange is safer than self-custody." It's not surprising that this statement has gained traction.
Established custodial institutions can invest more resources in building professional security and recovery systems. For those lacking experience in key management, delegating this responsibility to institutions may indeed reduce the difficulty and risk of managing keys alone. Acknowledging this doesn't diminish the value of self-custody—it brings the discussion back to the real circumstances users face.
But historical loss figures can hardly provide a definitive answer for today. The River research CZ cited also indicates that early BTC permanent loss data is difficult to attribute accurately, with the vast majority occurring before 2020; exchange losses are equally impossible to fully tally, and some reimbursements haven't been deducted. These cumulative figures haven't been adjusted for asset size or holding duration. They show that both approaches have experienced massive losses, but they're insufficient to measure today's actual risk.
More importantly, such comparisons typically only count whether "assets were lost," yet rarely address "whether assets can be withdrawn when needed" or "whether users can exit when a platform fails." Custody can reduce the burden of personal key management, but it also makes users dependent on institutions to continue operating, fulfill redemption obligations, and provide account access.
Self-Custody Preserves an Alternative Path
Self-custody is essentially an arrangement of control. For common self-custody accounts, users hold the private key or the critical conditions required to complete signatures, and wallet developers or other service providers cannot unilaterally execute valid authorization.
As long as users retain valid keys or backups, even if the original wallet ceases operations, accounts can typically be recovered through compatible tools; when users need to transfer assets or use on-chain applications, they don't have to wait for a platform to enable withdrawals first.
This independent path is the most important value of self-custody.
It certainly has boundaries. Network and contract rules can still affect asset usability. What self-custody preserves is that the final authorization for on-chain operations need not depend entirely on a single institution—not absolute control over all external conditions.
This value isn't obvious when platforms are operating normally. It's a bit like a backup: it doesn't make daily operations faster, but when the original path fails, it determines whether users still have options.

Therefore, there is no one-size-fits-all answer between custody and self-custody. For those who aren't yet equipped to securely manage keys, choosing a carefully vetted custodial service is a reasonable option; for those seeking to reduce dependence on a single institution, establishing an independently recoverable and migratable path is equally important. The key isn't taking sides, but clearly understanding what risks you've delegated and what capabilities you've retained.
Control Shouldn't Be a Burden Users Bear Alone
Users holding their private keys doesn't mean product providers can offload security responsibilities. Ordinary users cannot verify the entire process of a device from key generation to firmware build. Products need to validate critical paths, ensure anomalies are exposed in a timely manner, and respond transparently after issues occur. Security should come from reliable default design, not depend on users uncovering hidden technical risks.
Users also need to confirm that backups can indeed restore, understand what they're authorizing before signing, and know in advance how to migrate if primary tools fail. But these capabilities can be built gradually. Self-custody shouldn't be a qualification exam demanding everyone immediately transfer all assets, nor should it require everyone to become cryptography experts.
For imToken, supporting self-custody starts with making this choice more reliable. Users need to understand what they're authorizing, know how to recover, and be able to migrate to compatible tools when necessary. Only then does control become more than just a slogan.
The Coldcard incident hasn't made self-custody irrelevant—on the contrary, it has made security responsibilities more concrete. The next phase is figuring out how to make security, recovery, and user experience more reliable while preserving user control.
Users can choose custody, and they can leave custody when needed; they can hold control without bearing all the complexity alone. That is the significance of revisiting self-custody after Coldcard.


