On 21 August 2026 Coinkite shipped a Coldcard firmware update in the aftermath of the $130 million Bitcoin exploit, and buried in the release notes is one of the most interesting design decisions in crypto security this year: the device will no longer generate your seed on its own. You have to add your own randomness. Roll dice, mash a keypad, contribute something the hardware did not produce, and the final key is derived from both.
It is the right call for a hardware wallet. It is also, almost word for word, the argument crypto casinos have been making for a decade to explain why their games are fair. So it is worth being precise about what user-supplied entropy actually buys you, because the wallet version and the gambling version are not the same thing, and one of them is largely theatre.
TL;DR
- Coldcard’s new firmware requires the user to contribute entropy when generating a wallet seed, so a flawed device RNG cannot silently produce a guessable key on its own.
- Crypto casinos have offered a superficially identical feature for years via “client seeds”, and it is the weakest part of the hash-commitment model they call provably fair.
- Participation and verification are different guarantees. Contributing randomness limits who can predict the number. It says nothing about whether the number was applied to your bet, at the stated odds, with the stated payout.
- The Coldcard fix works because you generate a seed once, in your hand, and keep the output. A game runs thousands of outcomes a day on infrastructure the operator controls, and the operator profits when the process breaks.
- Chainlink VRF takes the opposite route: the player contributes nothing, and the proof is verified by the coordinator contract on-chain before the game’s callback can run. Satoshie’s honest limit is stated in full below.
What Coldcard actually fixed
We wrote about the underlying failure last month. Randomness is the only security primitive whose broken output is indistinguishable from its working output. A bad signature gets rejected. A bad decryption produces garbage. Weak entropy just returns an ordinary-looking number, and it keeps returning ordinary-looking numbers right up until somebody sweeps 594 BTC in twenty-five minutes.
The conclusion at the time was that “use a reputable open-source audited air-gapped device” is exactly what failed, so the fix cannot be a better device. Coinkite’s answer is to stop requiring the device to be the sole source. If the hardware RNG is compromised, backdoored or merely buggy, your dice rolls still push the result into a space no attacker can enumerate. The attacker now has to break both.
That works because of three properties specific to wallets. You do it once. You do it yourself, physically, on a device that is not talking to anyone. And you keep the artefact, so there is no counterparty who benefits from your key being weak.
The casino version of the same idea
Now hold that up against the standard “provably fair” implementation on a hash-commitment casino. The operator generates a server seed and publishes its hash before you play. You supply a client seed. Outcomes come from an HMAC over the server seed, your client seed and an incrementing nonce. At the end of the session the operator reveals the server seed and you can confirm it hashes to the commitment.
Structurally that is user-supplied entropy, and the maths is real. The commitment genuinely stops the operator from choosing a server seed after seeing your client seed. Within its scope, it works.
Its scope is the problem. That scheme proves one thing: a number was derived from inputs fixed in advance. It proves nothing about the layer where the money actually lives.
- It does not prove the number was applied to your bet. The mapping from hash output to win, loss, multiplier or payout runs in server code nobody has read.
- It does not prove the odds. House edge, RTP and maximum payout are configuration values in a database, changeable per user, per session, per hour.
- It does not prove you get paid. Your balance is a row. Solvency is not in scope for any hash commitment.
- Verification is retrospective and permissioned. You check the games you thought to check, after the fact, in a verifier the operator hosts, against a seed the operator chose to reveal. A check the operator can decline is not a check.
- It is selective by construction. Every one of those steps runs on a server that knows exactly who is asking.
So the player contributes entropy and comes away feeling like a participant. Participation is a feeling. Verification is a property. The casino model hands you the first and calls it the second, and it has been getting away with it since roughly 2014.
Why the wallet fix does not port to gaming
Take the three properties that make Coldcard’s approach sound and check them against a game. You do it once becomes thousands of outcomes a day, and nobody is rolling physical dice before every coinflip. You do it yourself on an air-gapped device becomes you type a string into a web form on the operator’s infrastructure. And the part with no interested counterparty becomes a business whose margin is the difference between the odds it states and the odds it runs.
That last one is the killer, and it is why gaming is a harder problem than custody rather than an easier one. When a wallet’s randomness fails, the artefact is on-chain forever and the forensics are unambiguous. When a game’s randomness fails, there is no artefact at all. A rigged draw and an unlucky draw produce the same screen. The failure mode is indistinguishable from the business model.
Where Satoshie lands, including the awkward bit
Satoshie does not ask players for entropy, and adding a client seed field would be a downgrade dressed as a feature. The design goes the other way. A draw requests randomness from Chainlink VRF; the VRF coordinator contract verifies the cryptographic proof on-chain before it is permitted to call back into our contract; the outcome is computed inside that callback, in deployed bytecode on Base that anyone can read at the verified address. Nobody at Satoshie sees the number before it lands, because the number does not exist until a proof for it has already been checked by a contract we do not control.
The honest limit: you are not a participant in that randomness. You did not contribute to it, and you are trusting that the Chainlink oracle set behaves as specified. That is a real assumption and we are not going to pretend otherwise. What you are not trusting is us, which is the assumption that has historically cost players money. The request seed is derived from the requesting contract, the subscription nonce and chain state, so the operator cannot grind it. A re-request is a new transaction with a new hash, visible to anyone watching. And the payout terms are fixed in deployed code, so changing them means deploying to a new address.
Coldcard’s fix asks you to distrust the device by taking part. VRF asks you to distrust the operator by making your participation unnecessary. Taking part does not scale past the first few hundred outcomes. A proof verified by a contract before the callback fires costs the player nothing and runs on every single draw, whether anyone is watching or not.
Three questions worth asking any platform
- My client seed changes the number. What, in code I can read, decides what the number means for my balance?
- Who verifies the proof, and does it happen before or after the outcome is applied?
- If I stop asking, does anything still get checked?
Hash commitments answer the first with a server, the second with “after, if you ask”, and the third with no. That is not a small gap. That is the whole thing.
📷 Photo by Lea Böhm (@alleslea) on Unsplash
