The Coldcard Hack

How a five-year-old build error turned a trusted hardware wallet into predictable keys, and what it really teaches about generating, operating, and governing secrets.

Thibault de Lachèze-Murel
Thibault de Lachèze-Murel
| 29 min read

In the early hours of July 30, 2026, Bitcoin began leaving wallets that no one had touched in years. Onchain analysts watched a single address sweep roughly 594 BTC, about 38 million dollars, from close to 500 wallets in about twenty-five minutes. The waves continued over the following days. By early August, Galaxy Research put the confirmed total near 1,600 BTC drawn from around 7,300 addresses, with some estimates running higher still. No victim clicked a phishing link. No malware was found on any device. No seed backup leaked. The wallets had been generated on Coldcard hardware devices, one of the most respected names in Bitcoin self-custody, and the flaw that doomed them had been present in shipped firmware since March 2021.

This is the most instructive security event of the year, and the reason is not that the hardware was weak. In every physical respect, the devices did their job. The lesson sits one layer beneath the hardware, at the moment a key is created, and it applies to every custody model and every vendor, including the one writing this analysis.

DFNS builds core banking infrastructure for institutions that issue, move, and govern onchain assets, so this piece is not written from a neutral position. The aim is to explain what actually failed, in enough technical detail to be useful to the engineers who will be asked hard questions this week, and then to be precise about which parts of the DFNS design address this class of failure, which parts make it materially harder, and which parts still depend on things no cryptography can guarantee on its own. The DFNS analysis of the Bybit Safe incident last year took the same approach, because honest analysis is more persuasive than confident assertion and it holds up better over time.

Why entropy is the foundation everything else rests on

A private key is a secret number, and its entire security rests on a single property. Nobody else can produce the same number. That property is decided once, at the instant the key is generated, by the quality of the randomness feeding the process. Everything a wallet does afterward assumes the key came from somewhere genuinely unpredictable. Every signature, every address derivation, every backup inherits that assumption. If it is false, none of the machinery built on top of it can recover.

Entropy is the technical term for that randomness, and it is measured in bits. A standard twelve-word Bitcoin recovery phrase is meant to encode 128 bits of entropy. The number matters because bits are exponents rather than increments. A 128-bit seed can take any of 2^128 possible values, a figure with thirty-nine digits, and searching that space is not a question of budget or patience. It is thermodynamically out of reach, requiring more energy than the sun will radiate across its entire lifetime. This is the quiet reason hardware wallets can work at all. A properly generated seed remains safe even when the device design is public, the firmware is read line by line, and the manufacturer is completely untrusted. Its security comes from mathematics rather than from secrecy.

This also means that entropy sits above every other choice in the stack, and that is the deepest lesson of the incident. A hardware security module, a trusted platform module, a secure element, a phone’s secure enclave, or a multi-party computation protocol can each run the highest-quality, fully audited cryptography and still hand back a worthless key if the randomness feeding it is weak. The form factor does not decide the outcome, and neither does the sophistication of the cryptography. Without sound entropy at the moment of generation there is no secure key, and every signature, backup, and derivation that follows is arranged around a number the attacker can also produce.

That same fact explains why entropy is the single most dangerous place for a wallet to fail. Reducing the randomness does not weaken the lock in some gradual way. It shrinks the number of keys that could possibly exist down to a set a computer can simply work through. The history here is long and repetitive. Debian’s OpenSSL suffered a catastrophic entropy loss in 2008. Android’s SecureRandom failed in 2013 and cost Bitcoin users directly. The Profanity vanity-address tool was found predictable in 2022, and the Milk Sad flaw in the Libbitcoin library followed in 2023. In each case, keys that looked perfectly random had been drawn from a pool small enough to enumerate, and in each case the industry announced that the lesson had been absorbed. The Coldcard incident is that same lesson delivered once more, this time inside a device whose entire purpose is to get this one step right.

Anatomy of a silent failure

Because Coldcard runs on open-source firmware, independent researchers were able to reconstruct the failure while the theft was still visible on the chain. Coinkite, the manufacturer, confirmed the vulnerability the same day and shipped fixed firmware for every affected model within about two days. The account below draws on Coinkite’s own technical backgrounder and on an independent root-cause analysis published by the bitcoin engineering and security teams at Block. The two accounts describe the same mechanism, and it is worth walking through slowly, because each stage failed in a way that generalises well beyond this one product.

The hardware generator that stopped being used

Every Coldcard contains a hardware true random number generator, a dedicated circuit built to produce genuine physical randomness. Using that circuit correctly is the device’s core promise. In March 2021, a firmware change quietly stopped the seed-generation path from reaching it.

The change arrived as part of a migration to a new cryptographic library. Seed creation moved away from the function wired directly to the hardware generator and toward a more general call that resolved, through a chain of build configuration, to a software pseudo-random generator inherited from the MicroPython project. The intended hardware generator remained inside the firmware the whole time, and it still worked. After the migration it was simply used for less important tasks, while the one operation that mattered most, the creation of the seed, quietly drew from software instead.

The single character that let the wrong code compile

The root cause turns out to be almost too small to see. Block traced it to a preprocessor guard inside the library, a compile-time check whose job was to stop the build if the hardware generator had been switched off. The guard tested only whether a configuration flag was defined at all. It never tested whether that flag was actually set to on. Coinkite had deliberately defined the flag as zero, because the company intended to route randomness through its own hardware wrapper rather than through MicroPython’s path. A value of zero still counts as defined, so the guard was satisfied. The build completed with no error and no warning, and seed generation bound itself to the software generator.

The board configuration file shows the trap in plain sight, setting the flag to zero alongside a comment explaining that Coldcard supplies its own version of the code. The intention behind that line was entirely correct. What undid it was a guard elsewhere that checked for the existence of a setting rather than its value, and that single mismatch became a five-year vulnerability.

The software generator standing in for a secret

The generator that took over was a small pseudo-random routine. It produces numbers that look random but follow a fixed recipe from a starting value, which means that feeding it the same starting value produces the same output every time. On the older Mk2 and Mk3 devices, that starting value came from the chip’s fixed serial number combined with its timer registers, sampled once at startup and never refreshed with new randomness afterward. None of those inputs is a secret. The serial number is fixed device metadata that partly appears in the USB identifier, and the timer values are either observable or constrainable within a narrow range. Once an attacker knows those inputs and the sequence of calls the device made, the entire stream of output becomes deterministic.

The practical result is a collapse in strength. Coinkite estimates the effective search space on the Mk3 at roughly 40 bits, against the intended 128. Forty bits corresponds to about one trillion possible seeds. That sounds enormous by everyday intuition, but a single modern graphics processor performs billions of the relevant operations every second, which places a trillion candidates within trivial reach. The gap between 40 bits and 128 bits is therefore not a modest reduction in safety. It is the whole distance between a secret and a short computation.

The secure elements whose output was thrown away

The newer Mk4, Mk5, and Q devices tell a subtler story, and for security engineers it is the more uncomfortable one. These models carry secure-element chips that generate high-quality randomness, and the firmware does mix that randomness into the seed process. The problem lies in how little of it survives. Block’s analysis shows that the reseed step kept only four bytes, thirty-two bits, of the secure-element output, and that it reset only a single word of the generator’s internal state. However good the secure elements are, the surrounding code truncated their contribution to at most 2^32 distinguishable outcomes. Coinkite estimates the resulting effective entropy at roughly 72 bits.

Seventy-two bits is meaningfully stronger than forty, and it is not something a consumer machine brute-forces over a weekend. Block is careful, though, to warn that even its ceiling near 2^73 does not represent genuine 73-bit cryptographic security, because the underlying timer inputs are correlated with one another and partly observable rather than independent and freshly sampled. A well-resourced adversary with purpose-built hardware is the relevant threat at that level, and 72 bits still sits far below the 128-bit target that places a key beyond any foreseeable technology. The general principle is worth stating directly. A hardware root of trust protects nothing if the code around it discards most of what that hardware produces.

How a weak seed becomes a stolen coin

It is worth being explicit about the step that connects a randomness bug to an empty wallet, because it is what makes this class of failure so unforgiving. A public Bitcoin address, or an extended public key, functions as a validation oracle. An attacker who suspects that seeds were drawn from a small pool can generate each candidate seed in turn, derive its addresses, and check them against the public chain. When a derived address matches one that holds funds, the attacker has just confirmed the private key and can sign a spend. Nothing about this requires the physical device, the recovery card, or any interaction with the victim. The blockchain itself supplies the answer key, and the search runs entirely on the attacker’s own machines. This is why the drained wallets included addresses that had been dormant since 2021. Age offered no protection, because the weakness lived in the key itself rather than in any recent activity.

Why every safety check missed it

What makes this incident genuinely instructive is that several checks did exist, and each one failed in a way that teaches something.

The health checks tested statistics rather than origin. The firmware verified that the seed bytes looked varied and that consecutive outputs differed from one another. A deterministic generator passes both tests without difficulty, because looking varied and being unpredictable are separate properties, and only the second one protects money. A sequence can pass every statistical test a spreadsheet could run and still be entirely reproducible by anyone who knows the recipe.

The hashing concealed the weakness rather than repairing it. Seed material was passed through SHA-256 before use, a step described as reducing bias. Hashing a low-entropy input cannot add randomness. It only redistributes the same small number of possibilities more evenly across the output range. A pool of 2^40 inputs produces at most 2^40 outputs, however uniform they appear afterward. In effect the hashing made weak entropy statistically indistinguishable from strong entropy, which is close to the worst possible outcome, since it removed the very irregularities that might otherwise have raised an alarm.

The review confirmed presence rather than reachability, and this is the detail every engineering team should sit with. Coinkite states plainly that its prior review had confirmed the correct generator existed in the compiled firmware, but that the review never verified which implementation the seed path actually reached across the two libraries involved. The right code was on the device the entire time. It was simply never called for the one operation that mattered. Confirming that a security control is present in a build is a different thing from confirming that the control runs when it is needed, and the distance between those two statements is exactly where this vulnerability lived.

Openness helped, though more slowly than the theory predicts. Coldcard’s firmware and the libngu library at the centre of the incident had been public since 2021. Open source is a genuine prerequisite for verifiable security, but it is not the same thing as security that has actually been verified. Publishing code distributes the opportunity to audit it, yet it does not guarantee that anyone takes that opportunity, and it is especially weak against a reachability failure like this one, where the correct generator sits in plain sight in the source tree and only a reader who follows the build configuration discovers that a different function is the one actually called. Five years of public availability produced no audit that followed the randomness all the way from its source to the finished seed. Coinkite’s own working theory is that an attacker eventually did precisely that, possibly assisted by an AI model reading the old firmware, only weeks after the company had run a similar AI-assisted review of its own code that found nothing of the kind. Attackers and defenders now reach for the same tools, and the advantage falls to whoever asks the exact right question first. This time it was not the defender.

The remediation makes the same point in reverse. Coinkite had not ignored this exact risk. It deliberately disabled the software path and added a compile-time guard meant to stop the build if that path was ever pulled in, but the guard checked only whether a configuration macro was defined rather than what value it held, so it never fired. Fixing it correctly turned out to be genuinely subtle. The first correction Coinkite pushed to the library broke every Coldcard firmware build and had to be reverted the next day, and the guard that finally held has to test two separate conditions at once to be safe. A change of that delicacy, sitting directly on the generation of every key, is exactly the class of code that recurring external review exists to catch before it ships, rather than after more than a thousand Bitcoin have moved.

How far the weakness spread inside the device

One further technical point deserves attention, because it illustrates the cost of concentrating on a single source of randomness. The same software generator did not only produce wallet seeds. Block’s analysis notes that it also fed the generation of standalone paper-wallet keys, the masks used when splitting a seed into random shares, the ephemeral keys used for device cloning and encrypted USB sessions, key-transfer features, two-factor secrets, and generated passwords. Each of these features inherited the same entropy limit, because each ultimately drew from the same stream. A weakness introduced at one point therefore radiated outward across an entire product surface. This is the practical signature of concentrated design. When one component is trusted to supply randomness for everything, a single defect in that component becomes a defect everywhere at once.

Why “cold” stopped being a useful word

In physical terms the devices behaved exactly as advertised. The air gap held. Secure boot held. The tamper protections held. But none of it mattered, because the attacker never needed to touch a device at all. When a seed is drawn from a pool small enough to search, the adversary reconstructs it on their own hardware and spends the funds from anywhere in the world. The victims’ wallets were offline throughout. Their keys were never truly private.

This deserves to be said plainly, because it overturns an assumption the industry has repeated for a decade. The word “cold” describes whether a device is connected. It says nothing about whether the key that device holds was sound in the first place. An air gap is a real control against a real threat, namely the theft of a secret that genuinely exists and is worth stealing. It offers nothing at all against a secret that was already weak at the moment of its creation. The offline property that so many people trusted was simply never the property under attack.

It is worth pressing the vocabulary a step further, because the term itself has quietly become misleading. Almost nothing that markets itself as “cold” is permanently disconnected from the world. A signing device receives a transaction and returns a signature, whether that exchange happens over a cable, through scanned QR codes, or across a memory card, and at that moment information crosses the boundary in both directions. Firmware is updated. Addresses are exported. The gap is a discipline about when and how a device connects rather than a wall that never opens. Treating “cold” as a synonym for “safe” has encouraged a comfortable and collective belief that offline automatically means secure. This incident is the clearest available evidence that the belief was never true. The more honest mental model has nothing to do with temperature. A device is only ever as trustworthy as the process that generated its keys and the controls that govern how it is used, whether it is connected or not.

Two details from Coinkite’s own guidance close the point and lead directly into the deeper principle. Users who added their own independent dice rolls during seed creation are considered safe, because entropy that the device could not reduce made the device’s internal weakness irrelevant. And a firmware update cannot repair a seed that was already generated, because the randomness was already spent when the seed was born. The only remedy is to abandon the affected key and move the funds to a fresh one before the attacker arrives. Both facts point the same way. When a single source of randomness decides everything, introducing a second independent source is a genuine defence, and once that single source has failed there is no fix short of evacuation.

The debates the incident revived and why most of them ask the wrong question

Within days the incident was pulled into three long-running arguments. Each of them is being framed in a way that misses what actually failed.

Custodial versus non-custodial is the wrong axis

The loudest reaction cast the episode as a verdict on self-custody itself. Onchain data showed Bitcoin flowing from personal wallets back toward exchanges, reversing the move into self-custody that had followed the FTX collapse in 2022. By early August, exchange reserves had climbed by roughly 17,500 BTC as holders moved funds off the affected wallets. Several prominent voices read the shift as vindication for professional custody. Metaplanet’s CEO argued that self-custody asks individuals to shoulder every operational risk alone, and pointed to his own company’s reliance on regulated custodians with multi-party controls and independent oversight. Analysts at Cantor and FRNT expected the exploit to lift demand for regulated products such as spot ETFs. Figures such as Eric Balchunas framed the episode as evidence that self-managed keys are simply too risky for the average investor. These voices also raise a genuinely concrete asymmetry. A holder who loses coins from a regulated, insured custodian may have a recovery claim, whereas a holder who lost coins from a Coldcard has no product-liability framework to fall back on and little practical prospect of collecting damages from a hardware startup.

The counter-camp answered with equal conviction. Onchain analyst Willy Woo maintained that self-custody remains the only route to genuinely sovereign ownership, and was careful to add that he holds nothing against ETFs while insisting that Bitcoin belongs in its own category as bearer property. Others in that camp made the narrower and stronger point that a single firmware error at one manufacturer does not invalidate the entire premise of holding one’s own keys.

Both camps are arguing past the actual failure. The Coldcard problem was not a flaw in the concept of self-custody. It was a flaw in one manufacturer’s implementation of one step, the generation of the seed. The identical class of bug, a weak or mis-wired source of randomness, could live just as easily inside a custodian’s key ceremony, an exchange’s signing stack, or the custody provider sitting underneath an ETF. Nothing about holding keys on someone else’s behalf makes randomness automatically sound. The trait that actually separated the wallets that survived from the wallets that were drained had nothing to do with who held them. It had to do with how the keys were made. Setups that spread trust across several independent devices and several independent sources of randomness came through intact, whether they were operated by individuals or by institutions. The useful question is therefore not custodial against non-custodial. It is concentrated against distributed, and unverified against verified. The most telling reaction came from the founder of a Bitcoin financial-services firm who spent the weekend helping affected holders move funds, including people who were not his customers, and who observed that those users were not abandoning self-custody at all. They were migrating toward arrangements in which no single compromised device can put the funds at risk. That instinct is the correct one, and it points well beyond the custodial debate.

Hardware Wallet versus MPC misses the weakness they share

The incident also revived the familiar contest between hardware security modules and multi-party computation, with each camp presenting its own approach as the answer. The debate is comfortable and largely beside the point, because the Coldcard failure struck at something both approaches depend upon.

A hardware wallet is a hardened, tamper-resistant box that generates and guards keys behind a strong physical and logical boundary. It is excellent at protecting a key that already exists. It does not, by itself, guarantee that the key was generated from sound randomness, and a sound cryptographic library fed by a broken entropy source will faithfully produce broken keys inside a very strong enclosure. Multi-party computation, implemented well, does hold a real structural advantage against this specific failure, which the next section takes up. But it is not automatically immune either. MPC is software implementing subtle cryptography, and MPC libraries have shipped serious flaws before. The TSSHOCK and BitForge disclosures of 2023 turned implementation bugs in widely deployed MPC libraries into full key extraction. The Coldcard incident was, at bottom, sound cryptography wrapped inside a broken integration, and MPC has no special exemption from that pattern. The honest comparison is therefore not HSM against MPC as slogans. It is a question of which architecture reduces dependence on any single implementation, any single device, and any single source of randomness, and of how rigorously each implementation has actually been verified in practice.

The dice-roll workaround is not a security model

Coinkite’s guidance that self-supplied dice rolls neutralise the bug is both technically correct and quietly revealing. It is correct because manually added entropy is something the firmware cannot reduce, so it repairs the weak point from outside the flawed process. It is revealing because the recommended safeguard for a device sold as the secure default is to ask users to roll physical dice, correctly, at least fifty times, and to do so with dice that, as more than one observer pointed out, are not designed to be cryptographically fair in the first place. Casa CEO Nick Neuman put the objection simply, calling it a non-starter for the overwhelming majority of people. A security model that depends on end users performing a manual entropy ritual, and performing it flawlessly, is not one that scales beyond a small population of experts. The correct lesson is not that everyone should roll dice. It is that sound randomness has to be guaranteed by the system itself, so that no user is ever placed one imperfect ritual away from losing everything.

Defining the failure precisely and what interrupts it

Precision is what makes a failure preventable, so it is worth stating this one exactly. A single implementation, running in a single environment, took one draw from one source of entropy, and that single draw fully determined the secret. Every downstream control inherited the resulting weakness, and none of them was able to detect it after the fact.

The DFNS architecture was designed against each part of that sentence. What follows is not a claim that this failure is impossible on DFNS infrastructure. It is a description of which specific controls break the attack path, followed by an equally specific account of what still remains at risk.

The choices a wallet makes for you

The failure has a general remedy too, or rather several, and they are worth naming before turning to any single architecture. The common thread is to stop depending on one source of randomness. Deployment and hardware can be diversified, so that keys and signatures draw on more than one independent generator and no single faulty component decides an outcome. Signing can be hardened with hedged or deterministic nonce schemes, which derive the per-signature nonce from the private key and the message so that it does not depend on a random generator alone, and fold in fresh randomness on top of that as a second safeguard. These particular techniques protect the moment of signing rather than the moment of generation, so they would not have saved the Coldcard seeds, which were weak before any signature existed. The instinct behind them is the point. No single generator, implementation, or draw of randomness should ever be solely responsible for a secret.

What the incident exposes is how rarely the holder is in a position to apply that instinct. Whatever the form factor, hosted or software or hardware or some combination of them, the provider is trusted to make all of these choices correctly, and to make them out of the user’s sight. A hardware wallet makes the situation most acute, because it selects the entropy source, the library, the integration, and the build on the owner’s behalf while exposing almost none of it. The user is left to trust that every one of those decisions was sound, with no practical way to check the one that matters most. That is the same concentration described earlier in this analysis, restated one level up, and it is where the DFNS design begins.

Keys that are never created whole

On DFNS infrastructure a private key is never generated, stored, or reconstructed as a single object at any point in its lifecycle. This holds when the key is first created, each time it is used to sign, and in the way it is backed up. Keys come into existence through distributed key generation across independent parties running in separate environments, each contributing randomness drawn from its own hardware and operating system. The protocol combines those contributions in such a way that the resulting key is uniformly random as long as even one participant’s entropy is sound.

Set that condition beside what happened in July. On a single device, one broken generator poisons every key it will ever produce. In distributed generation, one honest generator among several is enough to keep the final key unpredictable. An attacker who wants to bias a DFNS key cannot quietly compromise a single source of randomness and wait. They would need to compromise all of the participating sources, across different environments, at the same moment, and do so without being detected by any of the other parties.

This is also the precise difference between splitting a key and distributing trust, a distinction the Bybit analysis drew and this incident reinforces. A seed that is sharded after it has been created, or backed up in fragments, was still born whole, in one place, from one draw of randomness. Sharding protects a backup from theft. It cannot travel back in time and add entropy to a birth that already happened with too little of it. A key that is never assembled has no single moment of creation for an entropy bug to poison.

A lesson the multisig users learned the hard way

There is a sharp corollary to this point buried in Block’s analysis, and it matters for anyone who assumes that requiring several signatures is by itself a defence against this kind of flaw. Block observed that a multisignature arrangement built entirely from vulnerable Coldcard devices remained fully exposed, because every key in the arrangement had been generated by the same defective process. Requiring several signatures protects against the loss or theft of one device. It does nothing when the weakness sits underneath all of the devices at once. A quorum only helps when the members of that quorum fail independently. The same reasoning explains why distributing key generation across genuinely separate environments, rather than replicating one implementation several times, is what actually breaks the failure. Independence is the property that does the work, and simply multiplying identical parts does not create it.

Signatures produced without ever holding the key

Signing on DFNS follows the same rule as generation. The threshold signature protocol, known as KU25, was designed with Jonathan Katz and published for open scrutiny in IACR Communications in Cryptology. It produces signatures through cooperation between parties that never hold the private key in one place. The random nonce inside each ECDSA signature, which is historically the other great graveyard of randomness failures, is generated jointly under the same guarantee, so no single party’s randomness decides the outcome of a signature any more than it decided the key. This is the multiparty form of the hedging instinct described earlier. Because the nonce never rests on any one party’s random draw, a single degraded generator cannot reproduce it or leak the key.

Publishing the protocol openly is a deliberate choice rather than a marketing gesture, and the reasoning connects directly to this incident. The failures in this field are almost never in the underlying mathematics. They are in the code and in the integration around it, exactly as they were here. The only discipline that has reliably caught that category of error is external, adversarial review of a specification that anyone can read. KU25 is public and peer-reviewed, and it was presented, together with the DFNS work on multiparty coordination, at the NIST threshold cryptography workshop this year.

Controls enforced at the moment of signing

Around the cryptography sits the part of the system an institution can actually inspect. On DFNS a signature is the last step of a governed pipeline rather than the raw output of a device. A request is authenticated with credentials bound to the caller’s hardware, evaluated against policy at the moment of execution, held for quorum approval where policy requires it, screened, and logged, all before any key material engages at all. The July incident reinforces a principle that predates it. Controls that live in procedure, and that are checked periodically by people, can drift silently for years, in exactly the way an uncalled generator drifted here. Controls that are bound to the signing path itself behave differently, because a failure in them stops the transaction rather than passing unnoticed.

Rotation instead of evacuation

Because keys exist as distributed shares rather than as a single seed, a compromise has a remedy that falls well short of flight. Shares can be rotated proactively, which invalidates the old material without changing the public key and without moving a single asset. It is worth comparing that directly with the position an affected Coldcard holder found themselves in this week, where the only available option was to generate a new seed and race the attacker to a fresh address. Some of those races were lost before the advisory was even published. The point generalises. The ability to rotate is what separates a contained incident from a permanent loss, and an architecture that has no way to invalidate a compromised secret without moving funds has quietly made evacuation its only response.

What this architecture assumes and what still remains

An analysis that only scrutinises another company’s failure is marketing rather than security, so the same discipline has to be turned inward.

Threshold cryptography restructures risk. It does not abolish it. The security of the DFNS model rests on a stated assumption, which is that an attacker does not simultaneously compromise a threshold of independent key shares, or the authentication and orchestration layer that governs them. Distribution raises the cost of that attack from a single silent compromise to several coordinated compromises across independent environments, with detection surface in between them. That is a large increase in difficulty. It is not an infinite one, and any vendor who suggests otherwise should be met with skepticism.

Implementation risk is real, and it belongs to DFNS to carry. As already noted, threshold signing has been broken in practice before. Those failures lived in the code and the integration rather than in the underlying mathematics. A distributed design reduces reliance on any single implementation, but it does not remove the obligation to build that implementation correctly, to publish it, and to have it audited on a recurring basis. External audits at DFNS are recurring events, treated as an ongoing requirement rather than a one-time milestone. Recurring, adversarial external review is the specific control that answers the question five years of open availability left unanswered at Coldcard, which is not whether the right code is present but whether it is the code that runs. One direct consequence of the July incident deserves to become standard practice across the whole industry, this company included. Verifying that every source of entropy is genuinely reached at runtime, rather than merely present somewhere in the build, should be treated as a named control and tested as rigorously as any other.

Governance remains load-bearing, and it extends to the customer. DFNS infrastructure will faithfully sign whatever passes authentication and policy. An organisation that configures a single approver, protects it with a weak credential, and sets no limits has built a vulnerability that no cryptography underneath it can offset. This is why the platform ships conservative defaults and treats policy design and credential hygiene as part of the security boundary rather than as an afterthought. A permissive configuration should be read as a finding that needs correcting.

The discipline around randomness is not something to be complacent about either. Every signing party in the system still needs sound entropy from hardened sources in its own environment. The architecture is designed to tolerate all but one of those sources failing at once. The correct posture is to operate as though that tolerance did not exist, because the clearest single lesson of July is that the failure a team has confidently excluded on paper is often the one that arrives quietly through the build system.

Compressed into one honest summary, the DFNS design prevents any single machine, person, source of entropy, or vendor component from determining or possessing a key. It makes coordinated compromise materially harder by forcing an attacker to operate across independent environments with detection between them. It can contain what a single hardware seed cannot, through policy enforced at signing, transaction screening, and share rotation. And it still depends on correct implementation, sound operations, and sensible customer configuration. A vendor who waves away that final sentence is selling comfort rather than security.

Five questions worth asking any provider

For anyone holding institutional assets on any infrastructure, this one included, a short list of questions tends to extract more truth than any certification badge.

Where does the entropy come from at the moment a key is created, and how many independent sources actually contribute to it. What evidence exists that the generation path really reaches those sources at runtime, rather than the sources merely existing somewhere in the product. When a component, a credential, or a share is compromised, can keys be rotated without evacuating the funds. Which controls are enforced at the moment of signing, rather than reviewed only after the fact. And who outside the vendor has independently verified all of the above. A provider whose answer reduces to a request to be trusted has, in effect, already answered.

The Coldcard incident will be filed by many as a hardware story. It is really a story about concentration. One draw of randomness, taken once, in one place, by one implementation, was trusted for five years by everyone downstream, precisely because no one could see it. Security claims are only worth anything when the assumptions behind them survive contact with a real adversary. Cryptography is only ever as strong as the system that generates, operates, and governs the keys. The industry keeps buying stronger boxes, and the more durable answer is to build systems in which no single moment, and no single component, is ever in a position to lose everything.

Sources

Technical analysis

Loss figures and on-chain data

Custody debate and reactions

On reducing entropy risk in signatures

Contact us