The Coldcard Mk3 seed generation flaw sat in shipped, open source, audited hardware for five years. We wrote about the damage last week. What nobody had explained until now was how it survived that long. Kraken’s security chief gave the answer this week, and it is worse than a missed line of code: the auditors verified that the intended random number generator was present. They did not verify that it was being called.
Read that again, because it is the most important sentence published about crypto security this year. The good component was in the codebase. It just was not on the execution path.
TL;DR
- Kraken’s security chief says the five year Coldcard entropy bug escaped detection because auditors confirmed the intended RNG existed, not that it was actually invoked.
- Presence and invocation are different claims, and almost every audit in crypto verifies the first while marketing implies the second.
- Randomness is uniquely vulnerable to this gap, because a dead RNG produces output that looks exactly like a live one.
- Crypto gaming runs the identical model, and worse: “integrates Chainlink VRF” is a statement about presence that says nothing about whether the VRF word determines your result.
- On-chain settlement turns invocation from an auditor’s assertion into a transaction record you can query yourself, with the platform out of the path.
Presence is not invocation
An audit is a snapshot taken by someone reading code. A good auditor confirms the right library is imported, the right function is defined, the constants are sane and the entropy source is a reputable one. All of that is a claim about what exists in the repository.
What determines your security is a different claim entirely: which code actually ran when your key was generated, or when your bet was settled. Those two claims come apart the moment there is a second path, a fallback branch, a debug flag left in a build, or an initialisation that silently fails and falls through to something weaker.
In most of software, that divergence gets caught. If the wrong crypto path runs, signatures fail to verify. If the wrong key schedule runs, decryption returns garbage. The system tells you loudly.
Randomness never tells you. A weak entropy source returns a number that looks precisely like a strong one. There is no failing test, no exception, no corrupt output. Coldcard shipped keys that were always guessable and every single one of them looked like a perfectly good key for five years, until someone swept 594 BTC in twenty five minutes. The audit was not lazy. The failure mode is simply invisible to the method being used.
Crypto gaming built its entire trust model on this exact gap
Now apply the same lens to the thing you clicked on last night.
A crypto casino tells you it is provably fair. Underneath that claim is usually a badge in the footer, a dated RNG certificate from a testing lab, a Curaçao licence, and increasingly a line saying the platform “integrates Chainlink VRF” or “uses on-chain randomness”. Every one of those is a presence claim. The certificate says a random number generator was tested on a date. The integration line says a component exists somewhere in the stack.
None of it says the number that decided your spin came from there.
This is not a hypothetical failure mode. It is the cheapest possible one to build. A platform can deploy a genuine VRF consumer contract, request randomness on a schedule, emit events, point to them proudly, and still compute the outcome that pays you in a server process that never touches the returned word. The contract is real. The integration is real. The link between the randomness and your result is the part nobody checked, and it is the only part that matters.
Gaming is harder than the wallet case on two axes. Frequency, first: a hardware wallet generates a seed once, so there is a single moment to get right, whereas a game resolves thousands of outcomes a day and every one of them is a separate opportunity for the wrong path to run. Incentive, second: nobody at Coldcard profited from weak entropy, it was a mistake. In gaming, the identical defect is indistinguishable from a business model, and there is no forensic artefact left behind. A weak key eventually shows up as a theft on chain. A rigged coinflip shows up as an ordinary losing night.
What on-chain settlement actually changes
The fix is not a better auditor, a longer certificate or a more reputable RNG vendor. Coldcard already had all three. The fix is making invocation observable rather than asserted.
That is the structural property of running the game on chain. With Chainlink VRF, the coordinator verifies the cryptographic proof attached to the randomness before it will call your contract back, so the number arriving in the callback is not merely claimed to be random, it carries evidence. But the part relevant to this week’s news is the next step: the outcome is written inside that callback transaction, in deployed contract code you can read, and the whole sequence leaves a public record.
So the question “was the good RNG actually called” stops being a matter of professional judgment. On Satoshie you can pull the randomness request, pull the fulfilment transaction, open the verified contract, and see that the outcome is derived from the returned word in the same transaction that delivered it. For a coinflip that arithmetic is one modulo operation. For a raffle it is a hash of the VRF word against a prior blockhash, taken modulo the tickets minted. You are not trusting that the path ran. You are looking at the transaction where it ran.
The difference between transparency and evidence is who does the showing. A platform that publishes a verification page is showing you something. Querying the chain yourself, from a node of your choosing, with the operator unable to see that you ran the query or to block it, is evidence.
The honest caveat
On-chain does not automatically close the gap. If a game’s contracts are unverified, you cannot read the callback body and you are back to trust. If they sit behind an upgradeable proxy, the code you audited today can be swapped tomorrow, which is the same presence-versus-invocation problem wearing a helmet. And the front end you are clicking can always be lying about which contract it talks to.
The narrower and defensible claim is this: when contracts are verified, immutable and settle the outcome in the VRF callback itself, invocation becomes a public fact rather than an assertion by someone who was paid to look. That is a category change from the Coldcard situation, not an improvement on it.
Three questions worth asking
- Can you point at the transaction where randomness decided your last result? Not a dashboard, not a results feed. A transaction hash, on a public explorer.
- Is the outcome computed in the same transaction that delivered the randomness? If the number arrives on chain and the result is settled somewhere else, the integration is decoration.
- Is the contract verified and immutable? Unverified means you cannot check. Upgradeable means what you checked is not binding.
Five years, an open source codebase, air gapped hardware and a real audit were not enough to catch a random number generator that was present and never called. Crypto gaming has less scrutiny, more frequency and a direct financial motive to leave that gap exactly where it is. The industry’s answer has been to publish more badges. The only answer that survives the Coldcard test is architecture where the calling is on the record.
📷 Photo by Vishnu Mohanan on Unsplash
