Entropy Collapse: Your Private Key May Not Have Been Random Since Day One

This article was originally only available to members of the Zhihu column "Crypto Reference"; I am now making it permanently public.

Because this matter is time-sensitive—affected addresses are being cleared in bulk, and knowing a day earlier means one day less exposure. Keeping it behind a paywall benefits no one.

Please read it thoroughly, check against Section 6 to confirm whether you are on the list, and forward it to anyone who may be affected.

------------ Below is the main text ------------

In 41 minutes, 1,196 addresses were emptied. The common characteristic of the victims is that they have not moved their coins since 2021. Everything you have done for self-custody—offline storage, fragmented backups, passphrases, multi-signature—protects the life of this key; but no one has gone back to check its origin. The birthplace of the key leaves no trace: entropy collapse is completely unobservable on-chain; it could have been true for five years, and you cannot find out today.

1. That 41 Minutes

On July 30, 2026, a series of strange transactions appeared on the Bitcoin chain.

The strangeness lies not in the amounts but in the rhythm and targets. In 41 minutes, 1,196 addresses were emptied. These addresses are unrelated to each other, scattered across different years, countries, and usage habits. The only commonality is that most of their owners have not moved these coins since 2021. Cold storage, long-term holding, textbook discipline.

By August 2, the number tracked by Galaxy Research was approximately 1,367 Bitcoins, about 88.6 million USD, and over 4,500 addresses. The public forensic site coldcardentropy.org later registered a total of 6,657 unique source addresses under six levels of evidence—of which the first wave of coordinated cleaning involved 500 transactions, totaling 594.47722484 BTC, accurate to eight decimal places.

On July 30, Coinkite admitted the reason: their Coldcard hardware wallets had been generating private keys incorrectly since March 2021.

This statement requires a pause to grasp its weight. It’s not that the wallet was hacked, the mnemonic was leaked, or someone got hold of the device. It’s that every key generated by these wallets, functioning normally every day since they left the factory, was weaker by dozens of orders of magnitude than it should have been. Moreover, this issue had been true since March 2021, and from that day until July 30, 2026, no one, no on-chain data, and no device could indicate that it was true.

The vast majority of people—including many seasoned players who treat self-custody as a belief—understand the risks of self-custody as follows: the private key is in your hands, so the risk is also in your hands; as long as you do not leak the mnemonic, do not fall for phishing, do not switch devices, and are not threatened with a wrench, your coins are safe. All defenses are built around the "custody" aspect.

I believe a more accurate understanding is that the most vulnerable point of self-custody is not in custody but in generation—at the moment that key is born. And unlike custody risks, generation risks are a form of "time-dimensional trust assumption": it could have been false at some point in the past, and at any subsequent moment, you cannot discover it through observation. The colder your cold wallet, the longer the exposure period.

2. The Birth Certificate of the Key

Let’s throw away all the technical jargon.

Your mnemonic is essentially a string of random numbers. The word "random" carries all the security—because the private key space of Bitcoin is so vast that security does not come from any lock or password, but from one thing: no one can guess that string of yours.

So where does this string of random numbers come from? There is a dedicated chip in hardware wallets that generates true random numbers based on physical noise—thermal noise, circuit jitter, and other uncertainties inherent in the physical world. It produces 128 bits of randomness, meaning there are 2 to the power of 128 possibilities, more than the atoms in the universe. That’s why you can safely store your coins on a piece of paper with 24 words written on it.

The issue this time is that due to a miswritten compile switch, that physical noise chip was never called. The device reverted to using a pseudo-random number generator in software—a formula-derived thing that looks very random but can be completely recalculated. The result is that Mk2/Mk3 models only produced about 40 bits of effective randomness.

How small is 40 bits? About a trillion possibilities. It sounds like a lot, but for an ordinary computer willing to run for a few days, a trillion is an afternoon’s work.

For example

You bought a high-end safe, and the manufacturer promised that the lock core has 128 bits of combinations. You placed it in the basement, welded it to the wall, and buried the key in three parts in three cities. Five years passed, and the safe has never been tampered with, the welds are intact, and all three parts of the key are present. Then one day you open the basement, and the safe is empty.

The reason is: there was a switch set incorrectly on the manufacturer’s production line, and the lock core of your batch of safes actually only had 40 bits of combinations. The safe was not tampered with—it was opened with a duplicate key. And this has been true since the first day it left the factory. All the protections you implemented over the past five years—welding, fragmentation, off-site storage—protected against the possibility of the safe being tampered with, while this safe never needed to be tampered with.

What’s more troubling is that there are no signs of this issue. The safe won’t make noise, the lock won’t loosen, and you won’t see any anomalies during your annual checks. The only moment you can know is when it is opened.

This is the core of this issue: we are accustomed to checking the life of a key but have never gone back to check its birth. And the birthplace leaves no trace.

3. A #ifndef That Triggered Five Years

3.1 The Fuse Installed Backwards

In March 2021, Coldcard underwent a fundamental migration—switching cryptographic operations to the well-tested libsecp256k1 in the Bitcoin core ecosystem and introducing its own libNgU library. This was a quality improvement, and the motivation was entirely legitimate.

The problem arose from a piece of protective code that came with this migration. In random.c (libngu, lines 22-31), the developer wrote a safeguard: if the hardware random number generator was not enabled at compile time, it would directly report an error and stop the compilation. This safeguard used the C language preprocessor directive:

#ifndef MICROPY_HW_ENABLE_RNG

#error "Hardware random number generator required"

#endif

The meaning of #ifndef is "if this macro has not been defined." The intention of the person writing this safeguard was that as long as someone forgot to turn on the hardware random number, the compilation would fail, and the accident could not happen.

However, in the actual firmware configuration, this macro was defined, and its value was 0.

The C language #ifndef only asks "has it been defined or not," not "what is the value." Defining it as 0 is still considered defined. Thus, this safeguard determined that "it has been defined, everything is normal," and #error was never triggered, allowing the compilation to proceed smoothly—while the value of 0 precisely means "hardware random number not enabled."

The fuse was installed backwards. It checks whether "the switch component is present" rather than "whether the switch is turned ON."

As a result, the compiler included the software fallback PRNG that comes with MicroPython. That upstream code can be traced back to May 2018, and in the context of MicroPython, it is a reasonable fallback; it just was never intended for Bitcoin private keys.

From that moment on, every Coldcard running the affected firmware, when the user pressed "generate new seed," was running this software formula instead of that physical noise chip.

3.2 How Small is Forty Bits

Coinkite’s own technical review provided the following numbers:

• Mk2/Mk3 → Effective search space approximately 40 bits (should be 128 bits)
• Mk4/Mk5/Q → Effective search space approximately 72 bits (security elements SE1/SE2 mixed in some independent entropy, providing partial mitigation)

The affected firmware versions are Mk2/Mk3 from 4.0.1 to 4.1.9 (fixed version 4.2.0), Mk4/Mk5 below 5.6.0 (Edge line below 6.6.0X), Q below 1.5.0Q (Edge line below 6.6.0QX).

There is a data discrepancy that must be pointed out here

Coinkite’s official stance states that Mk4/Mk5/Q is 72 bits, while an analysis cited by Blockhead on August 3 stated that only about 32 bits actually entered the final seed.

The difference between these two numbers is not a small discrepancy; it is a difference of forty orders of magnitude. 72 bits is secure today—global computing power combined cannot exhaust it in the short term; 32 bits, however, is weaker than Mk3’s 40 bits and can be cracked in a matter of minutes. One number determines whether "Mk4 users can migrate at ease" or "Mk4 users are currently being swept."

So far, the observed actual sweeps have concentrated on single-signature addresses from the Mk3 era, which supports Coinkite’s 72-bit stance directionally. But I must remind you that this does not constitute proof. Attackers will certainly first sweep the batch with the lowest cost. This matter itself is a footnote to the theme of this issue—when a hypothesis is unobservable, "not having an incident yet" is never evidence that "an incident will not happen."

3.3 Open Source Was Present the Whole Time, Yet Did Not Stop It

This is the part where paid readers should pause the most.

Coldcard is open-source firmware. It has a public code repository, community reviews, and reproducible builds—this should be the highest configuration that security audits can provide. It was present the whole time, yet did not stop it.

There are three layers to the reason, each more counterintuitive than the last.

First Layer: The line of code in the source looks correct

The reviewer reads #ifndef MICROPY_HW_ENABLE_RNG + #error and gets the impression that "there is protection here." The flaw is not in the logic of this line, but in its relationship with the build configuration in another file. Code reviews are conducted file by file, function by function; this bug resides in the gaps between files.

Second Layer: Reproducible builds prove "consistency," not "correctness"

The promise of reproducible builds is that anyone can compile the exact same binary from the same source code, ensuring that vendors haven't secretly inserted anything malicious. This promise was fully realized in this incident—everyone could reproduce the same binary, which contained a software pseudo-random number generator. Reproducible builds guarantee that "what you have is what was compiled from the source," but they never guarantee that "what was compiled from the source is what you think it is."

Third Layer—this layer is the most critical: the function signatures of the two random number implementations are identical

Coinkite explicitly noted this in their review: the hardware RNG and the software fallback PRNG look exactly the same externally. This means that even if someone were to reverse-engineer the binary and check the call paths, they would see the same function names and the same set of parameters. To discover the issue, one must trace which target file the symbols ultimately resolved to—an action that almost no one would take during a routine audit.

Coinkite's fix precisely corroborates this point: the new version explicitly excluded the MicroPython fallback PRNG object and added RNG symbol verification at build time—if the board-level target file does not provide rng_get(), or if the fallback implementation has not been completely excluded, the compilation fails outright. In other words, it wasn't just that line of code that was fixed; it was transforming the "unobservable" into the "observable at compile time."

Another intriguing detail: Coinkite speculated that this latent flaw, which had been hidden for five years, might have been discovered by an AI model during the review of open-source firmware. Coinkite founder NVK stated, "AI-assisted code reviews can now find latent bugs faster than the most seasoned experts in the industry."

This statement has two sides. The good side is that such long-dormant hypothetical flaws are becoming discoverable in bulk for the first time. The bad side is that attackers have access to the same tools, and they do not need to responsibly disclose their findings first. All open-source code that has remained unchanged for a long time and involves cryptographic primitives has just entered a new era of risk.

4. This play has been performed three times

The weight of membership is highlighted in this section. Entropy collapse is not a new invention in the encryption industry; it is a classic accident that repeatedly occurs in cryptographic engineering, and each time, the shape is remarkably similar.

4.1 A line of deleted code, silent for twenty months

In September 2006, a Debian maintainer deleted two lines of MD_Update(&m, buf, j); in md_rand.c while packaging OpenSSL. The motivation for the deletion was entirely well-intentioned: these two lines would read uninitialized memory, causing debugging tools like Valgrind and Purify to continuously raise alarms. One of the lines even had the comment /* purify complains */ next to it.

The problem is that these two lines do different things in different contexts. The original author only protected the truly problematic line with #ifndef PURIFY; the maintainer deleted both lines.

As a result: the entire random number seed pool became ineffective, and the only remaining "random" source was the process ID. The default process ID limit in Linux is 32,768. This means that all SSH keys, SSL certificates, and encryption keys generated using Debian and its derivatives had only about thirty thousand possible combinations.

This flaw was discovered by Luciano Bello on May 13, 2008, remaining silent for about 20 months. During those 20 months, no server reported any errors, no handshake failures occurred, and there were no signs of issues. All generated keys were mathematically, format-wise, and usage-wise indistinguishable from truly secure keys.

4.2 A thirty-two-bit clock, silent for six years

This time, it directly affected Bitcoin and was the closest to the current incident in shape.

From versions 3.0.0 to 3.6.0 of Libbitcoin Explorer (command-line tool bx), the bx seed command used the Mersenne Twister algorithm to generate seeds—this PRNG only used a 32-bit system clock for seeding. A single 256-bit seed request actually yielded only 32 bits of entropy, about 4.3 billion possibilities, which consumer-grade hardware could exhaust in a few days.

Timeline: Introduced in October 2016 via PR#559, released with 3.0.0 in March 2017, began being exploited in May 2023, a large-scale coordinated theft occurred on July 12 (approximately 29.65 BTC), discovered during emergency response on July 21, publicly disclosed on August 8, numbered CVE-2023-39910.

Ultimately, over 2,600 affected wallets were identified on the Bitcoin mainnet, with over $900,000 stolen across multiple chains including BTC, ETH, XRP, DOGE, SOL, LTC, BCH, and ZEC.

Note the two numbers: latent for over six years; completely invisible on-chain—before the theft, these wallets looked indistinguishable from any normal wallet.

4.3 This time, the failure occurred at the end of the trust chain

The mechanisms of the three incidents are almost isomorphic: a well-intentioned engineering change → entropy source silently replaced → long-term latency → one day, mass harvesting occurs. But this time, there are three substantial differences, each moving in a worse direction.

First, the location has changed

The Debian incident occurred at the operating system packaging layer, while the Milk Sad incident occurred in a command-line tool—both had "upstream/downstream" considerations, and users at least theoretically had other options. Coldcard, however, is a device specifically designed to eliminate trust. The entire value proposition of hardware wallets is "do not trust any software environment, trust this dedicated hardware." When the endpoint of the trust chain itself has issues, there is no next link to fall back on.

Second, the exposure period is positively correlated with user behavior, but inversely

This time, the profile of the victims is "those who haven't moved their coins since 2021"—that is, the ones with the best discipline and adherence to best practices. The longer you lock your coins away without moving them, the longer your exposure period, and the more likely you are to be on the list. Debian's keys can be rotated, SSL certificates have expiration dates; Bitcoin seeds are not rotated, generated once, and used for life.

Third, the discovery method has changed

The Debian incident was discovered by a researcher's chance finding, the Milk Sad incident was traced back through emergency responses after the theft. This time, it may have been actively scanned out by AI. This means that the rate of discovery for such flaws is structurally increasing—the good news is that existing landmines will be gradually cleared, but the bad news is that those clearing the mines and those stepping on them have the same map.

5. Which numbers can bear weight, and which cannot

Divided into four levels by strength, separating company statements from third-party verifications.

Level One: Economic verification (already occurred on-chain facts, the hardest)

• First wave of coordinated cleanup → 1,196 addresses emptied within 41 minutes; 500 transactions, 594.47722484 BTC | Source: coldcardentropy.org forensic dataset, 2026-07-30
• As of August 2, cumulative → approximately 1,367 BTC, about $88.6 million, over 4,500 addresses | Source: Galaxy Research tracking, reported by Blockhead, 2026-08-03
• Forensic dataset scale → 6,657 unique source addresses across six evidence levels | Source: coldcardentropy.org, 2026-08
• Victim profile → concentrated on cold storage addresses that have not moved since 2021 | Source: cross-referenced by multiple reports, 2026-07-31

Level Two: Manufacturer statements (technical root cause, authoritative but requires cross-checking)

• Root cause → random.c (libngu, lines 22-31) guarded by #ifndef MICROPY_HW_ENABLE_RNG, firmware defined the macro as 0, #error not triggered | Source: Coinkite technical review, 2026-07/08
• Introduction timing → March 2021 libNgU migration; upstream MicroPython fallback code traceable back to May 2018 | Source: same as above
• Entropy value → Mk2/Mk3 approximately 40 bits; Mk4/Mk5/Q approximately 72 bits | Source: same as above
• Audit blind spots → two RNG implementation function signatures are the same, binary review cannot distinguish | Source: same as above
• Fix method → explicitly exclude fallback PRNG object + RNG symbol verification at build time, absence leads to compilation failure | Source: same as above

Level Three: Key data with disagreements (must be judged independently)

• True entropy value of Mk4/Mk5/Q → Coinkite claims about 72 bits, third-party analysis claims only about 32 bits entered the final seed | Source: Coinkite review vs Blockhead, 2026-08-03. A difference of forty orders of magnitude directly determines the urgency for this batch of users; as of publication, no public reconciliation has been seen between the two parties.

Level Four: Opinions and speculations (the softest, cannot bear weight)

* Coinkite speculates that the flaw may have been discovered during the review of open-source firmware by AI models; NVK claims that the speed of AI-assisted reviews has surpassed that of the most experienced human experts. * Independent researchers believe that multisig composed entirely of affected devices remains vulnerable, requiring a majority of unaffected signers—this is a third-party assessment, not an official statement from Coinkite.
An Illusion That Must Be Dispelled ---------
Many people breathed a sigh of relief upon seeing "the fixed firmware has been released." Coinkite has made it very clear—upgrading the firmware will not modify or fix seeds that have already been generated. The firmware version governs the keys generated in the future, not the one that has already been created. This is the easiest statement to misinterpret in this incident, and also the most costly one.
6. Prioritizing by Urgency: Who Must Act Today =================
No matter how attractive the proposition, the safety of the reader's coins must come first. Prioritized from highest to lowest urgency.
First Tier · Immediate Migration ----------
Single-signature seeds generated on Mk2/Mk3 with firmware versions 4.0.1 to 4.1.9, and at that time without added dice entropy or BIP39 Passphrase. This tier is the one currently being targeted. The judgment criterion is the firmware version running on the device when the seed was generated, not when you purchased the device.
Second Tier · Migration as Soon as Possible ----------
Seeds generated on Mk4/Mk5/Q before their respective fixed versions. As long as the discrepancy between 72-bit and 32-bit remains unresolved, act on the worst-case assumption—this type of discrepancy should always be handled conservatively.
Third Tier · Likely Safe, but Worth Verifying -----------------
* Seeds generated elsewhere and imported into Coldcard—Coinkite confirms these are not within the scope of the current issue, as they are not products of this generator. * Seeds generated with at least 50 instances of fair, independent, and never recorded or leaked dice entropy—Coinkite states these are not affected by this issue. * TAPSIGNER, OPENDIME, SATSCARD are not affected. * Mk1 and Mk2 have not been officially included in Coinkite's statement.
Multisig users should pay special attention to this point ------------
Multisig composed entirely of affected devices is not safe. Multisig protects against single points of theft, failure, or coercion, but it does not protect against "all signers' keys originating from the same faulty generator." This is the most easily overestimated layer of defense in this incident—you need a majority of unaffected signers, not just "I have multisig, so I'm fine."
Three Reminders About Migration Itself -----------
First, migration is a risky action. Bitcoin Well's reminder is very apt: losses caused by hasty migration may occur faster than the problem you are trying to avoid. Errors such as miswriting backups or failing to verify the receiving address on the device screen will not disappear just because your new seed entropy is perfect. The correct order is: install the verified fixed firmware → generate a new seed → record and verify backups → verify the receiving address on the device screen → first send a small test transaction → after confirming receipt, migrate the balance → do not destroy old backups until the full amount is confirmed.
Second, do not engage with any "seed recovery services." After such incidents, a batch of scammers claiming to help you recover assets will inevitably appear, and they only want one thing.
Third, you can use the local query at coldcardentropy.org to verify addresses—it clearly states that the query is completed locally in the browser, not uploaded or recorded, and only requires the input of public addresses; never input mnemonic phrases, private keys, Passphrases, PINs, or wallet export files. But remember the site's own disclaimer: not hitting does not equal safety.
7. Who Has Been Burdened by This Incident ===============
First, the risk has shifted from "user operations" to "the vendor's construction pipeline," but the responsibility has not shifted along with it. -------------------------------------
All variables that users can control—storage, backup, offline, discipline—have failed in this incident. The variable that truly determines life and death is something a user cannot observe or audit: the value of a macro during vendor compilation. In the narrative of self-custody, losses are borne by the user: no deposit insurance, no customer service, no rollback. Self-custody gives you control over your assets but also transfers some risks that you cannot control.
Second, the "open-source auditable" label has been re-priced. --------------------
The value of open source is real, but this incident has drawn a clear boundary: open source guarantees that "the code can be viewed," but does not guarantee that "someone has looked at the viewable parts." When defects reside in the build configuration or in the symbol resolution of two identically named functions, the default action of community review does not cover that layer. In the future, when you see "open source, reproducible builds" as a security selling point, you should ask: who is checking the symbol resolution? Are there assertions during the build period?
Third, costs have been transferred to the most disciplined individuals. -----------------
This is the most stinging aspect of this incident. Those who frequently trade, often change wallets, and keep coins on exchanges have managed to avoid the issue. Meanwhile, those who generated once in 2021, locked them in a basement, and haven't touched them for five years are precisely the ones on the list. When the exposure period of risk is positively correlated with holding time, long-termism itself becomes a risk factor. This is not a moral issue; it is a structural issue—but it will indeed change some people's understanding of "cold storage."
Fourth, this is not an isolated case but a trend line that is taking shape. ---------------------
Looking at the incidents throughout July 2026: approximately $200 million, 34 cases. Among them, AFX Trade $24.15 million (validator keys), Ostium $18 million (oracle signer keys), Triple-A $11.8 million (hot wallet), WEMIX $6.25 million (owner key)—all related to keys and permissions; while traditional contract vulnerabilities only accounted for Wanchain $10 million, Bonzo Lend $9.05 million, Verus Bridge $7.54 million. Blockaid's statistics show that over $1 billion in crypto projects were stolen in the first half of 2026. The attack surface has structurally shifted from "contract errors" to "issues with the source, storage, and authorization chain of keys." Entropy collapse is the extreme form of this trend line: it is not that keys were stolen, but that they were never truly generated randomly.
8. A Fair Word for Coinkite ===================
Let’s fully articulate the strongest rebuttal.
The strongest counterargument: This is a controlled engineering accident with clear boundaries, insufficient to support the conclusion that "self-custody risks exist in the generation phase." ------------------------------------------------
The elaboration is as follows: the boundaries of the defect are very clear—specific vendor, specific model, specific firmware range; users employing dice entropy or Passphrases are unaffected; imported seeds are unaffected; Coinkite acknowledged the incident on the same day and released a fixed firmware the next day, publicly disclosing a complete technical review, with a response speed that is above average in the industry. More importantly, this precisely demonstrates that the open-source ecosystem is functioning: defects were discovered, disclosed, and repaired, with the entire process being publicly verifiable. The $88.6 million relative to Bitcoin's total market value, or even relative to the $1 billion stolen in the first half of 2026, is not considered large. As for Mk4/Mk5/Q, the 72-bit is safe for the foreseeable future, and the vast majority of users are not actually on the front lines.
My Perspective ----
I acknowledge every fact in this rebuttal, and I even believe the response speed is commendable—there are few vendors in this industry that admit on the same day, fix the issue the next day, and publicly disclose the complete root cause.
But it avoids the real statement of the proposition: the issue is not "how big is this loss," but "do we have a way to know it exists before the next loss occurs?"
Debian was silent for 20 months, Milk Sad for 6 years, Coldcard for 5 years. In all three incidents, none were discovered by "monitoring anomalies"—two were found by chance through code review, and one through retrospective analysis after a theft; this time it may rely on AI scanning. Throughout the entire silent period, all dashboards were green. This is not a matter of luck; it is that such assumptions are inherently unobservable in design: a seed with insufficient entropy looks identical to a perfect seed on-chain, on-device, and in any monitoring.
Therefore, my conclusion is not "hardware wallets cannot be used"—on the contrary, hardware wallets remain the most reasonable choice for the vast majority of people, and I do not intend to push anyone towards exchanges. My conclusion is a structural judgment: > The security of a system depends on its weakest assumption; and the manageability of a system depends on how many of these assumptions are observable. The crypto world has spent enormous energy over the past decade on "making attacks harder," with almost no investment in "detecting failures when assumptions fail." Entropy collapse is merely the first sufficiently costly sample in this void that compels attention.
Scam Check (Explaining the Mechanism Does Not Equal Endorsement, This Section Must Be Written) ---------------------
Coinkite is a Canadian company that has been established for many years, with founder NVK publicly active under his real name, open-source products, a public code repository, and reproducible builds. On the day of the incident, they acknowledged it, released a fixed firmware the next day, and published a technical review down to the file and line number. There are no issues of running away, anonymous teams, or malicious backdoors—on the contrary, precisely because it is the most transparent in the industry, this incident deserves everyone's serious attention: if such engineering practices can remain silent for five years, those vendors who do not open-source, do not create reproducible builds, and do not disclose root causes will only be in worse situations, and you will never know.

What readers need to be reminded of is the secondary risks of accidents: anyone who actively contacts you, claiming they can help you detect or recover assets, and asking for your mnemonic phrase or wallet files, is a scammer. The biggest opportunity created by this incident is not on-chain, but in social engineering.

---

Five Questions to Ask Before Trusting Any Asset System

This is what we really need to deliver this time. Compress the proposition into five questions and take them to any system you want to entrust your assets to—wallets, bridges, oracles, custodians, stablecoins, L2s, multi-signature solutions.

---

First Question: Where does the randomness come from? Is there evidence that it was actually invoked?

Don’t ask, "Is hardware randomness used?" Ask, "What happens if hardware randomness is not invoked?" The correct answer is only one: compilation failure or startup failure. Any design that "silently falls back to software implementation" is waiting for a morning five years from now. Criterion: Are there assertions during the build or runtime, rather than just comments and documentation promises?

---

Second Question: If the source code is correct, does that mean the compiled binary is correct?

Reproducible builds prove that "everyone produces the same thing" but do not prove that "the produced thing is correct." The defect this time lives right in this gap. Criterion: Besides reproducible builds, is there symbolic verification—i.e., verifying which implementation the key functions ultimately resolve to? Be especially wary of two implementations sharing the same function signature: this is a natural blind spot in audits.

---

Third Question: Are there values that should be dynamically obtained but are hard-coded instead?

Entropy sources are one category, and hard-coded constants are another. The "oracle hard-coded the price as $1.00" we saw in the stablecoin incident last time, and this time's "fallback to a fixed formula for randomness" are the same disease: a quantity that should reflect the external real state is replaced with an unchanging quantity, and the system does not report an error because of it. Criterion: List all values in the system that "should change but you have never seen change" and ask one by one why.

---

Fourth Question: Who can sign? Has this set changed silently?

The signer set, admin privileges, upgrade keys—changes to these often do not produce any user-visible events. In the incidents from July, AFX Trade, Ostium, and WEMIX all fell at this layer. Criterion: Are there on-chain events for changes, is there a time lock, is there a third party that can independently verify the current set?

---

Fifth Question (Meta Question, Most Important): If this assumption is false, will the system tell me? If not, how long has it been false, and can I find out?

Run the answers to each of the first four questions through this filter again. Observable risks are engineering problems; unobservable risks are existential problems. The former can rely on monitoring and response management, while the latter can only be made observable during the design phase—there are no remedial measures afterward.

---

The core of this framework is a perspective shift: changing the question of security audits from "Are there vulnerabilities in the code?" to "Which assumptions, if false, will the system not alert?" The former question has infinitely many answers and can never be fully investigated; the latter question usually has no more than ten answers, and once written down, each can be transformed into an assertion.

---

Where I Might Be Wrong

"Actually Not New" Argument

"Weak randomness leading to key compromise" is classic textbook content in cryptographic engineering, and both Debian and Milk Sad have included it in their case studies. If this issue only discussed this step, it should be eliminated directly by the "I already knew" test. The increments are in three places, and readers can judge whether they are sufficient: first, unobservability as an independent dimension—not "will it go wrong," but "if it goes wrong, will there be a signal?" This dimension is largely absent in mainstream security discussions; second, the boundaries of reproducible builds—it proves consistency rather than correctness, and combined with similarly named functions leading to symbolic blind spots, this is something even many security practitioners take for granted; third, the counterintuitive inference that exposure time is positively correlated with holding duration, which directly overturns the intuition that "the longer cold storage lasts, the safer it is." If you have already thought through these three points, this issue is indeed ineffective for you.

---

The Strongest Alternative Paradigm

Perhaps I got the causality reversed: the real lesson is not "trust assumptions are unobservable," but "do not bet 128 bits of security on a single implementation." From this perspective, the answer is not observability, but redundancy—using two independent sources of entropy XORed together, using multi-signatures from devices of different vendors, using self-contained dice entropy. If the future industry solutions primarily evolve along the lines of redundancy rather than observability, then the focus of my framework is misplaced. This is the path I believe is most likely to overturn this proposition.

---

Looking Back Three Years Later at the Most Likely Cause of Death

AI-assisted audits will eliminate a large number of existing defects of this type within two years, entropy collapse will become a historical term, and "unobservable trust assumptions" will be proven to be a self-dissolving problem—the advancement of tools will directly make it observable. The probability of this is not low. My defense is: as the speed of mine clearance increases, the attackers' scanning speed is also increasing in sync, and they have no disclosure obligations. The net effect, whether good or bad, is too early to conclude now.

---

Which Current Data Might Be False Prosperity

Two. First, "observed cleanups concentrated on Mk3 single-signature"—this likely only reflects the cost ranking of attackers, rather than the real security margins of Mk4/Mk5/Q, treating it as evidence that "new models are fine" is dangerous. Second, the figure of $88.6 million itself—it only counts what has already been moved, not what has already been exposed; the difference between the 6,657 unique source addresses registered on coldcardentropy.org and the final losses represents the stock that has not yet been harvested, not the safe stock.

---

Twelve Months Later, Come Back to Reconcile

Fall into the prediction ledger. Do not predict prices, only predict structural behavior.

---

Core Prediction (12 Months)

In the next 12 months, there will be observable structural changes in the industry’s handling of "entropy and key generation"—at least one mainstream hardware wallet manufacturer will publicly introduce assertions for entropy sources during the build or runtime (rather than just promising to use hardware RNG), and at least one more cryptographic primitive-level defect that has been lurking for over three years will be discovered by AI-assisted audits (regardless of whether it causes losses). Meanwhile, major incidents throughout 2026 will still primarily focus on keys/permissions/generation layers rather than contract logic layers.

---

Three-Month Observation Indicators (Until 2026-11)

• Whether the final loss of the Coldcard incident remains at the level of 1,400 BTC or continues to spread to the 6,657 addresses registered on coldcardentropy.org
• Whether Coinkite and third parties publicly reconcile on the 72-bit/32-bit divergence of Mk4/Mk5/Q
• Whether other hardware wallet manufacturers issue self-inspection statements, and whether the statements say "we used hardware RNG" or "we added build period assertions"—the wording difference is the first question of this issue
• Whether there is a large-scale social engineering scam targeting the victims of this incident

---

Six-Month Observation Indicators (Until 2027-02)

• Whether any manufacturers write entropy source assertions and symbolic verification into publicly available build processes or audit reports
• Whether multi-signature solution providers begin to explicitly require "signers from different vendors/different entropy sources"
• Whether another defect related to entropy or key generation that has been lurking for over three years appears

---

Twelve-Month Observation Indicators (Until 2027-08)

• Whether the number of historical defects discovered by AI-assisted audits significantly increases, and whether the disclosing party is researchers or attackers leading the way
• Whether the proportion of keys/permissions/generation layers in incident statistics continues to be higher than that of contract logic layers
• Whether there are regulatory or industry standard requirements for "entropy source verifiability"

---

Falsification Conditions (I Acknowledge)

1. In the next 12 months, if mainstream manufacturers' responses generally remain at "changing RNG implementations/strengthening code reviews" without any introducing publicly verifiable assertions for build or runtime → it indicates that "observability" is not a solution actually adopted by the industry, the focus of this framework is misplaced, and the practical value of the proposition is overestimated;
2. If major incidents in the next 12 months are again primarily due to contract logic vulnerabilities (accounting for more than the key and permission layers) → it indicates that the July sample was just short-term noise, and the judgment direction of "structural migration of attack surfaces" is incorrect;
3. If the controversy over Mk4/Mk5/Q is ultimately confirmed to be 32-bit and widely swept, while I judged its urgency to be lower than Mk3 based on the 72-bit caliber → I made a mistake in the most critical operational judgment, and even if the proposition itself holds, I must publicly correct it.

---

Disclaimer

This article does not predict any asset prices and does not constitute any investment or trading advice. The specific manufacturers and products mentioned in the text are only used to illustrate technical mechanisms and risk structures, and do not represent commercial evaluations or recommendations, nor does it imply that other products are safer. The migration steps in the text are public information organization and do not constitute personalized security advice; any operation involving private keys and mnemonic phrases may cause irreversible asset losses, please refer to the official guidance of the manufacturers and bear the decision-making responsibility yourself. Anyone asking you for mnemonic phrases, private keys, Passphrases, or wallet export files is a scam.

• Technical Deep Dive into the Entropy Issue, Coinkite Official Blog --- random.c (libngu lines 22--31) #ifndef MICROPY_HW_ENABLE_RNG guard failure, macro defined as 0, migration introduced in March 2021, upstream MicroPython fallback code traceable to May 2018, Mk2/Mk3 approximately 40 bits, Mk4/Mk5/Q approximately 72 bits, two RNG implementation function signatures are the same, fix method is to exclude fallback objects + build-time symbol verification: https://blog.coinkite.com/entropy-technical-backgrounder/
• Affected and fixed versions: Mk2/Mk3 4.0.1--4.1.9 (fixed 4.2.0), Mk4/Mk5 < 5.6.0 (Edge < 6.6.0X), Q < 1.5.0Q (Edge < 6.6.0QX); "Upgrading firmware will not modify or fix already generated seeds": same as above and Coinkite announcement, 2026-07-31

Third-party Reports and Evidence

• COLDCARD Entropy Incident --- Address Check and Evidence --- six levels of evidence, 6,657 unique source addresses, first wave of 500 transactions 594.47722484 BTC, local browser queries do not upload, "not hitting does not equal safe": https://coldcardentropy.org/
• A five-year-old Coldcard bug let hackers guess bitcoin wallet keys, Coinkite confirms, Blockhead, 2026-08-03 --- As of August 2, approximately 1,367 BTC / approximately $88.6 million / over 4,500 addresses, Galaxy Research tracking; third-party analysis claims Mk4/Mk5/Q only about 32 bits enter the final seed: https://www.blockhead.co/2026/08/03/coldcard-hardware-wallets-shipped-with-broken-randomness-for-five-years-coinkite-confirms/
• Coinkite Releases Fixed Firmware After Coldcard Bug; AI Likely Involved In The Breach, Bitcoin Magazine, 2026-07-31 --- Fixed firmware version, NVK's statement on AI-assisted review, over $70 million within 24 hours: https://bitcoinmagazine.com/business/coinkite-releases-fixed-firmware-after-coldcard-bug-ai-likely-involved-in-the-hack
• Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes, The Hacker News, 2026-08 --- 1,196 addresses in 41 minutes: https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
• COLDCARD Vulnerability: What Owners Need to Know, Bitcoin Well --- Affected determination based on firmware version at seed generation, exceptions for importing seeds and 50 dice entropy, TAPSIGNER/OPENDIME/SATSCARD not affected, multisig composed entirely of affected devices remains vulnerable (third-party research), migration steps and reminder that "rushed migration poses greater risks": https://bitcoinwell.com/coldcard-vulnerability

Historical Precedents

• Random Number Bug in Debian Linux, Schneier on Security, 2008-05 --- md_rand.c two lines MD_Update deleted, /* purify complains */ comment, introduced in September 2006, discovered by Luciano Bello on May 13, 2008, unique random source degraded to process ID, Linux default limit 32,768: https://www.schneier.com/blog/archives/2008/05/random_number_b.html
• Milk Sad Full Disclosure (CVE-2023-39910), milksad.info --- Libbitcoin Explorer 3.0.0--3.6.0, bx seed using Mersenne Twister + 32-bit clock seeding, introduced in October 2016 via PR#559, released with 3.0.0 in March 2017, exploited since May 2023, approximately 29.65 BTC stolen on July 12, 2023, discovered on July 21, 2023, disclosed on August 8, 2023, mainnet 2,600+ wallets, cross-chain losses over $900,000, dormant for six years with no on-chain visibility: https://milksad.info/disclosure.html

Trend Evidence (July 2026 Concurrent Incidents)

• July 2026 Crypto Hacks: Nearly $200M Lost Across Wallets, DeFi and Bridges --- Approximately $200 million for the month, 34 incidents; AFX Trade $24.15 million (validator keys), Ostium $18 million (oracle signer keys), Triple-A $11.8 million (hot wallet), WEMIX $6.25 million (owner key), Wanchain $10 million, Bonzo Lend $9.05 million, Verus Bridge $7.54 million: https://cryip.co/july-2026-crypto-hacks-nearly-200m-lost-wallets-defi-bridges/
• Blockaid: Over $1 billion stolen from crypto projects in the first half of 2026, cited by Cryptoticker weekly report, 2026-08: https://cryptoticker.io/en/crypto-news-today-weekly-wrap-august-2026/