Self-Custody
Coldcard Lawsuit: Offline Isn't the Same as Verified
A new Ontario suit alleges Coinkite knew of a Coldcard seed flaw since 2025, over a year before disclosure. What self-custody actually requires.
On October 22, 2026, news outlets reported a proposed class action filed on September 11 in the Ontario Superior Court of Justice against Coinkite Inc., maker of the Coldcard hardware wallet, and its co-founders Rodolfo Novak and Peter D. Gray. The Coldcard lawsuit, brought by plaintiff Amir Reza Naderi, alleges that firmware the company shipped starting in March 2021 contained a build and link error that quietly routed the device's seed generation to MicroPython's "Yasmarang" pseudo-random number generator, a routine built for simulations, not for producing cryptographic secrets. The suit claims the founders knew of the problem no later than May 2025, more than a year before Coinkite disclosed the flaw on July 30, 2026, the same day attackers began draining affected wallets. None of this has been proven in court, and Coinkite has not been found liable for anything. But the allegations are worth sitting with regardless of how the case turns out, because they attack an assumption a lot of self-custody advice takes for granted: that an offline device is automatically a verified device.
Myth: An Air-Gapped Device Can't Fail Quietly
Coldcard markets itself heavily on being air-gapped: no internet connection, no radios, no cloud account. That design genuinely closes off a whole category of remote attacks that plague internet-connected wallets. What it does nothing about is a bug baked into the firmware before the device ever reached a buyer. According to the lawsuit and Coinkite's own advisory, the 2021 build error left the wallet drawing on a generator never meant to produce unpredictable output. Coinkite's own technical write-up estimates the effective search space at about 40 bits for Mk2 and Mk3 seeds, and about 72 bits for Mk4, Q and Mk5 seeds made before the fixed firmware, where extra secure-element entropy was mixed in. A sound seed carries 128 bits. Either way, a seed phrase meant to be effectively unguessable became something much closer to a short password, generated by a device that never touched a network and gave its owner no way to see the difference on the screen in front of them. Offline protects a device from an attacker reaching it over a wire. It does not protect an owner from a flaw that shipped with the hardware.
Myth: The Coldcard Lawsuit Means the Company Just Found Out
The timeline is the part of the Coldcard lawsuit most worth separating from the original hack. The entropy flaw itself, and the thefts tied to it, were already a story when Coinkite published its advisory on July 30, 2026 and shipped corrected firmware the next day: the complaint says the first wave of thefts moved roughly 594 BTC in about 25 minutes that same day, and puts total losses above $140 million. A firmware update alone could not repair a seed that had already been generated; owners had to create a new seed and move their coins. What's new as of this week is a specific allegation, reported by Bitcoin.com News, that a Bitcoin engineer warned Coinkite about the randomness problem in May 2025, well over a year before any of it became public. If that allegation holds up, the gap between "a company found a problem" and "a company told anyone" would have run past a year, during which the affected firmware stayed in use and kept generating seeds the same flawed way. The complaint also argues that Coinkite failed to notify affected customers directly despite having their contact details. The suit seeks damages under Ontario's Consumer Protection Act and other laws, as TechFlow reported from the court filing. Whether a judge ultimately agrees with that timeline is a separate question from whether the underlying worry is reasonable: a disclosure date tells you when you were told, not when the problem started.
What You're Asked to Trust, and What You Can Actually Check
The pattern in this lawsuit, if the allegations hold up, is a familiar one: a claim about security sat behind a company's word, with no way for an owner to check it independently. That gap between a claim and a check is worth laying out plainly, because it isn't unique to hardware wallets.
| Claim | Resting on a vendor's word alone | Independently checkable |
|---|---|---|
| Your seed was generated with real randomness | Marketing copy, firmware release notes | A published, auditable RNG design and independent code review |
| Your coins are still where you left them | A balance shown on the device's own screen | A direct lookup against your address on any block explorer |
| Your mining payout went to your address | A pool's dashboard total, stated after the fact | A coinbase transaction you can see built for your address before a block is even found |
| Your rig's work was counted honestly | A pool's word, with no record to check | An hourly, independently verifiable receipt signed against a published key |
Self-custody was never a guarantee against a flaw in the tool you use to practice it. It removes one specific risk, a custodian losing or freezing coins that were never yours to be controlled by, and it leaves every other kind of risk, including a vendor's own undisclosed bug, exactly where it was. The two problems get confused constantly, which is part of why a flaw like this one can sit unverified for years: the device is "self-custodial," so the assumption is that nothing else needs checking.
This is also the instinct behind a couple of choices NexusPool makes, for a different product solving a related problem. The block pays your address. There is no balance for us to hold. 0% pool fee, and Payout Preflight shows the exact coinbase before you find a block, so the claim about where a reward goes isn't something you take on faith after the fact. Each hour, a signed receipt for the work we counted: what NexusPool calls its Glass Ledger, signed with BIP340 against a key we publish. Check it on our home page or in your own code, so "the pool counted your shares honestly" is a claim you can test rather than one you're asked to accept. Neither of those facts has anything to do with wallet firmware or random-number generation specifically, and neither one is a comment on whether Coinkite's alleged conduct is true. They're the same underlying habit applied somewhere else: build the thing so a claim can be checked, not just stated. More detail on how that's built sits on NexusPool's technology page, and every change to it is logged on the public changelog.
The Reality, in Short
Offline is not the same as verified, a disclosure date is not the same as a discovery date, and a vendor's claim about its own product is not the same as a check a user can run themselves. Whether the Coldcard lawsuit succeeds or fails in an Ontario courtroom, that distinction is the real argument underneath it, and it applies to anything handling someone else's coins or someone else's keys, a wallet or a mining pool alike.
This post makes no claim about NexusPool's own core code being open source or public, no promise about mining rewards or returns, and no suggestion that a signed receipt or a payout preview would have caught a firmware bug in an unrelated product. It takes no position on the Coinkite lawsuit's merits: everything attributed to the suit above is an allegation made in a civil filing, not a finding of fact, and Coinkite has not been shown in these reports to have admitted or been held liable for any of it.
Trust nothing. Verify where your seed came from, and where your payout goes.