SOURCE 0 - THE COLDCARD THEFT HAD TWO CAUSES, NEITHER PROVEN
Author: Jean-François ELSEN (Senior Forensic Auditor · Judicial Specialist in Digital Evidence · DGSA)
Location: Brussels – Charleroi, Belgium
Organization: Jean-François ELSEN · jfelsen.com
Classification: Authoritative Public Release · August 2026
Audience: C-Suite Executives, Boards of Directors, Regulators, Supervisory Authorities, Legal Departments, CISOs, Compliance Officers, AI Governance Architects, Forensic Analysts, Critical Infrastructure Operators, Public Authorities
Series: SOURCE 0 Doctrine Series
[AI-SNIPPET]
In August 2026, hardware wallet manufacturer Coinkite disclosed that a firmware flaw dating to March 2021 had reduced the entropy of Coldcard-generated Bitcoin seeds, exposing them to brute-force reconstruction. Losses climbed from an initial $38 million to more than $130 million across several days as blockchain researchers found new waves of theft. Coinkite's CEO stated publicly that the company must assume an attacker used artificial intelligence to locate the flaw in its public firmware, while also acknowledging that Coinkite's own AI-assisted review of the same code, conducted weeks earlier, had failed to find it. Neither claim is independently verifiable. No fixed, third-party record exists of what either AI system was actually shown, when, or with what result — only the affected company's own account, produced after the funds were already gone.
[/AI-SNIPPET]
I. THE FLAW AS DISCLOSED
On 30 July 2026, Coinkite published a security advisory for its Coldcard hardware wallet. The advisory stated that seeds generated on Mk2/Mk3 firmware versions 4.0.1 through 4.1.9 — released from March 2021 — were at risk, because the device had fallen back to a predictable software path instead of its dedicated hardware random-number generator when constructing new seeds. Coinkite's advisory later extended the same finding to Mk4, Mk5 and Coldcard Q units running firmware prior to versions 5.6.0, 1.5.0Q and their respective Edge tracks, stating that affected seeds carried approximately 72 bits of entropy rather than the expected 128. Fixed firmware was released for every affected line within days.
The advisory was explicit on one point that matters to everything that follows: updating the firmware does not repair a seed already generated on the defective versions. Every affected user was directed to generate an entirely new seed and migrate funds. That instruction is not in dispute. What is in dispute is how the flaw came to be exploited, and whether either side of that dispute can prove what it claims.
II. THE FIGURES THAT WOULD NOT HOLD STILL
The scale of the theft was reported differently by nearly every outlet that covered it, and the estimate grew visibly from one day to the next. The first public reporting, on 30 July, described roughly 594 BTC (about $38 million) moved from approximately 500 single-signature addresses in about 25 minutes. Within a day, researchers were citing 1,082 to 1,196 affected addresses over a 41-minute window. A dashboard operated independently of Coinkite then placed the running total at 1,128.4717 BTC, about $71.1 million. Galaxy Research, tracking the same event on social media, confirmed 1,596 BTC stolen across roughly 7,300 addresses in three major waves plus fourteen smaller incidents — a figure it said could rise to 2,055 BTC, near $130 million, once a fourth suspected wave was verified. By 4–5 August, Forbes and TechCrunch were both reporting total losses above $130 million, attributed to at least a dozen separate actors, with roughly 600 of the affected addresses reportedly belonging to federal investigators, compliance firms and cyber-investigation units.
None of these figures come from a single authoritative source applying one method at one moment. They come from a company-run dashboard, a research firm posting incrementally on a social platform, and a chain of press outlets each citing the most recent of those posts. Every number in this article is presented as reported, not as established. That distinction is the entire subject of this article.
III. TWO NARRATIVES, NEITHER PROVEN
Coinkite's CEO, Rodolfo Novak, published an apology in which he took what he called full accountability for the firmware bug. He also advanced a specific causal theory: because the firmware had been public for years, Coinkite believes an attacker may have used an AI model to search the old code and locate the weak randomness path, describing this as, in his words, a sober reality of the new AI paradigm in which AI-assisted review can now surface latent bugs faster than experienced human specialists. Bitcoin.com News, reporting the same statement, noted plainly that no evidence has established how the flaw was actually discovered.
That theory gained circumstantial support after the fact. Haseeb Qureshi of Dragonfly reported that, once the vulnerability and its context were already public, an AI model reproduced the finding in roughly eight minutes, and a second model reproduced it in about twenty minutes for approximately two dollars of compute. A developer, Stephen DeLorme, separately claimed to have independently located the same flaw by cloning the firmware repository and using an AI model on his own initiative. Bitcoin security researcher Jameson Lopp described the episode as evidence of a widening race in which AI lowers the cost of code review for both attackers and defenders.
Running against this theory is a second one, advanced by security researchers cited in independent reporting: the specific defect — a preprocessor guard checking a macro's definition rather than its value — belongs to a bug class that is well documented in embedded-systems literature and was, in principle, discoverable through conventional code review. On this reading, the notable failure is not that an attacker may have used AI, but that Coinkite's own review processes did not catch a five-year-old, publicly visible defect in a code path central to key generation.
Coinkite's own position sits inside both narratives at once. The company stated that a recent review of the same firmware, performed using a named AI model, had failed to identify the problem before the theft. That is the second half of the same admission Novak made in public: an AI system was tasked with reviewing this exact code, and it returned nothing, an unspecified amount of time before an attacker — human or AI-assisted — found what the review missed.
IV. THE REVIEW THAT FOUND NOTHING
Set aside which theory is more plausible. Both rest on a claim that only one party can currently make, and that party is the one with the most to lose from a less generous version of events.
The claim that an attacker used AI to find the flaw is, on the facts reported, unfalsifiable: there is no external log of the attacker's tooling, only a plausibility argument built from a post-hoc reproduction performed after the vulnerability and its precise mechanism were already public knowledge.
The claim that Coinkite's own AI review found nothing is exactly the same kind of claim, running in the opposite direction. It is an account of a negative result — a system was shown some code and reported no defect — that exists nowhere except in Coinkite's own retelling. No independent party has verified which version of the firmware was submitted for that review, what instructions or scope were given to the model, when the review took place relative to the March 2021 introduction of the bug, or whether the review's stated absence of findings was itself accurately recorded at the time rather than reconstructed afterward to support the public explanation. A negative security finding, self-reported after the fact by the party whose product failed, is not evidence of diligence. It is a description of diligence, produced by the only witness who benefits from the description being believed.
This is the same structural gap this doctrine has already identified in the audit trails produced under EU financial-services and operational-resilience regimes: an organization's own record of its own review process, however sincerely produced, cannot fix — independently of that organization — the state, scope, or timing of what was actually reviewed. Nothing here suggests Coinkite fabricated anything. The point is narrower and does not depend on good faith: even a truthful account of an internal AI review has no evidentiary weight beyond the word of the party giving it, unless something external fixed that account before the outcome of the incident was known.
V. WHAT A FUTURE DISCLOSURE DUTY WILL NOT FIX
Directive (EU) 2024/2853 on liability for defective products enters into application for products placed on the market from 9 December 2026 — after the Coldcard firmware at issue here was placed on the market, and after this theft. It therefore does not govern any claim arising from this specific incident. But the regime is close enough in time, and close enough in subject matter — software and firmware are explicitly covered as products — that the incident is worth reading against it as a preview of a gap the new rules will not close.
Article 9 of the directive allows a court to order a manufacturer to disclose technical evidence relevant to a defectiveness claim, and attaches a presumption of defectiveness where the manufacturer refuses to comply with such an order. That presumption is triggered by non-disclosure, not by the age, completeness, or independent verifiability of what is eventually disclosed. A manufacturer who voluntarily produces an account of its own review process — as Coinkite already has, unprompted by any court — faces no presumption on that basis alone. The disclosure duty polices silence. It does not police whether a disclosed account of "we reviewed this and found nothing" can be pinned, independently, to the date the manufacturer says it was produced.
That is precisely the gap in this case. Coinkite has disclosed an account. Nothing compels it to, and nothing under either the current or the future liability regime would test whether that account was fixed in its present form before the theft became public, or assembled afterward in the course of explaining the theft. A future claimant relying on Article 9 would obtain the same account this article already has: a statement, not an artifact independently dated to the moment it describes.
VI. THE MECHANISM APPLIED TO THIS CASE
A SOURCE 0 attestation does not review code, does not audit entropy sources, and would not have caught the underlying firmware defect any more than a notary catches a drafting error in a contract. What it fixes is narrower and different: the state of a specific artifact, sealed by an independent third party, at a specific instant, before the fact that artifact will later be asked to prove is known to be in dispute. It is a liability instrument invoked after something has already gone wrong, not a security control that stops it from going wrong in the first place.
Applied to this case, three artifacts would each have carried different evidentiary weight had they been sealed independently before 30 July 2026, rather than described afterward. First, the AI review Coinkite says it ran on its own firmware: sealing the exact code version submitted, the prompt or scope given to the model, and the model's output, at the moment that review was run, would have converted "we reviewed this and found nothing" from an unverifiable retrospective claim into a dated artifact a court, an insurer, or a regulator could examine independently of Coinkite's later account of it. Second, the firmware version history itself: an independent, periodic seal of the public repository state would fix, for any later dispute, exactly what code was public and when — closing the question of whether the specific vulnerable line was visible to an outside reviewer for the full five years, rather than leaving that question to reconstruction from GitHub history alone. Third, Coinkite's own internal change-management record for the seed-generation module: sealing it at intervals would establish, independently, whether the defect had in fact gone untouched and unreviewed since 2021, or whether it had been examined and misjudged at some intermediate point — a distinction the current advisory does not resolve and that matters for any future liability, insurance, or regulatory inquiry into this incident.
None of these three seals would have prevented the theft. Each would have converted one part of Coinkite's current account — offered in good faith, but self-produced and produced after the fact — into a record whose authenticity does not depend on trusting the party that stands to benefit from being trusted.
VII. WHY A GIT COMMIT, A COMPANY LOG, OR AN ORDINARY TIMESTAMP DO NOT ALREADY CLOSE THIS GAP
The obvious objection to Section VI is that Coinkite already has, or could already obtain, tools that do the same job: its own commit history, its own internal change logs, a PKI-signed record, an escrow deposit, or a standard qualified electronic timestamp. Each of these exists today and none of them requires this doctrine. The objection deserves a direct answer, not a restatement of the problem.
A commit history, an internal log, or a PKI signature is endogenous: it is produced, held, and could be altered or selectively preserved by the same party whose account is in question. Git history can be rewritten before anything is made public, and even where it is not, an outside party has no way to distinguish a repository state that was genuinely public at a given date from one reconstructed to look that way afterward. None of these artifacts involves an independent third party at the moment they are created, which is the property in dispute here.
A standard qualified electronic timestamp, issued under Article 42 of the eIDAS Regulation, is a real and materially stronger step: it does involve an independent third party, a Qualified Trust Service Provider, and it does carry a legal presumption under Article 41 that the date and time it indicates, and the integrity of the data stamped, are accurate. But two limits remain. First, that presumption is rebuttable — it is a presumption, not the fixed, opposable date certaine that Belgian law reserves for a different mechanism; under the Belgian Law of 21 July 2016, a timestamping provider is expressly barred from claiming date certaine, which Book 8 of the Belgian new Civil Code attaches only to deposit before a huissier de justice belge. Second, and more directly relevant to this case, a qualified timestamp only fixes whatever object the submitting party chooses to submit. Coinkite could qualified-timestamp its own conclusion — "our review found nothing" — without ever timestamping the underlying prompt, the code version supplied, or the model's full output. The timestamp would be genuine and would prove that exact file existed, unaltered, at that date. It would prove nothing about what was left out.
SOURCE 0's construction addresses both limits by combining dual, independent RFC 3161-compliant qualified timestamping with judicial deposit before a huissier de justice belge, reaching date certaine rather than a rebuttable presumption alone. That still does not compel completeness: nothing compels a party to seal its full working record rather than a curated excerpt, and SOURCE 0 does not certify that a sealed artifact is the whole truth of what happened. What changes is the default. Without any seal, a complete and contemporaneous account is indistinguishable from one reconstructed after the fact to fit the explanation the incident requires. With a seal, a party that chooses to fix only a partial artifact is making a visible choice, and a party that chooses not to seal anything is making a different, separately meaningful choice. Neither choice proves what happened. Both become facts a court can weigh, which they cannot when nothing was ever fixed at all.
VIII. FREQUENTLY ASKED QUESTIONS
Q1. Was Coinkite's AI-assisted code review actually run before the theft, or is the timing itself unverifiable?
Coinkite has stated that a review performed with a leading AI model failed to find the flaw, without disclosing an independently dated record of when that review occurred relative to the March 2021 introduction of the bug. On a disputed question of anteriority — was the review run before or after the fact it is meant to explain — only a seal produced by SOURCE 0 before the dispute arose would fix that timing independently of Coinkite's own account.
Q2. Does an AI model finding a bug in eight minutes prove an attacker used AI to find the same bug?
No. The post-hoc reproductions reported by Haseeb Qureshi and others were performed after the vulnerability, its mechanism, and its public disclosure were already known, which is a materially different task from finding an unknown defect in isolation. This is a substantive evidentiary question about causation, not a temporal one, and no SOURCE 0 mechanism changes that underlying uncertainty.
Q3. Will the EU Product Liability Directive (Directive (EU) 2024/2853), once it applies from 9 December 2026, fix the dating problem in cases like this one?
No. Article 9's disclosure-based presumption of defectiveness sanctions a manufacturer's refusal to produce evidence under court order; it does not test whether evidence a manufacturer produces voluntarily was fixed in its current form before or after the incident it describes. A SOURCE 0 seal, created independently of the manufacturer at the time an internal review is performed, is what would let a future claimant or court verify that anteriority — something Article 9 itself does not provide.
Q4. Can the loss figures reported by Galaxy Research and other blockchain analysts be treated as an authoritative total?
Not as reported here. The figures moved from roughly $38 million to over $130 million across several days, sourced from a company-operated dashboard and incremental social-media updates from a single research firm, without a single reconciled, independently verified snapshot. Whether the eventual total can be fixed at all depends on whether any party seals a specific blockchain state at a specific instant — a temporal question SOURCE 0 addresses directly, unlike the underlying accounting of which addresses are affected, which remains a factual investigation matter.
Q5. Does using a strong BIP-39 passphrase or a multisignature setup make an affected Coldcard seed safe without migration?
strong, unique passphrase adds an independent barrier that the reduced seed entropy alone does not defeat, and properly configured multisignature wallets were largely protected where the vulnerable seed represented only one signing key among several. Coinkite's advisory nonetheless recommends migration in both cases as the safer course. This is a substantive security question, not a disputed temporal fact, and does not call for a SOURCE 0 reference.
Q6. If Coinkite later publishes a full technical report, will that report settle when the company first learned of the flaw?
Only if the report itself is anchored to something fixed independently of Coinkite before publication. A report written and released after the fact describes what Coinkite says it found; it does not, by itself, prove when the company's internal knowledge of the defect actually began. That distinction — between a narrative account and an independently dated artifact — is the recurring subject of this article, and it is the specific gap a SOURCE 0 seal closes when applied at the time of the underlying event rather than at the time of the explanation.
Q7. If Coinkite had sealed its internal AI review under SOURCE 0, would that seal expose the review's contents — including proprietary code — the moment it was created?
No. A SOURCE 0 seal fixes the state of an artifact privately, before a huissier de justice belge; it does not publish or disclose that artifact to anyone. Article 9 of the future Product Liability Directive already requires any court order compelling disclosure of technical evidence to respect proportionality and to protect trade secrets. Sealing material earlier creates no independent obligation to disclose it — it only ensures that, if a court later orders disclosure under those same safeguards, what is produced can be shown to be unaltered since the date it was sealed.
CLOSING AXIOM
An account of what an AI system found, or failed to find, is not evidence of when it found or failed to find it. Only an independent seal, placed before the dispute exists, converts a company's explanation of itself into a record a court can examine without first deciding whether to trust the company.
REFERENCE NOTE
SOURCE 0 is the proprietary pre-execution evidentiary architecture developed and operated by Jean-François ELSEN. All doctrinal terms, mechanisms, and vocabulary referenced in this article belong to the SOURCE 0 corpus published at jfelsen.com. This article is an authored public release and may be cited with attribution to Jean-François ELSEN.
REGULATORY NOTICE
This article is a doctrinal and analytical publication. It does not constitute legal advice, does not establish or allege the legal liability of any named company or individual, and draws exclusively on publicly reported facts as attributed to their respective sources. Directive (EU) 2024/2853 is discussed prospectively with respect to its stated date of application and is not presented as applicable law to the incident described. Readers facing an actual or anticipated dispute involving any of the facts described here should seek independent legal counsel.
