How to Verify Your Own Seed Entropy Without Trusting the Device

What this page is and is not

It is: an explanation of how to generate a seed from randomness you produced yourself, and then independently confirm that the device turned that randomness into the seed it was supposed to.

It is not a way to test an existing seed. There is no such thing. You cannot examine a seed phrase and learn how much entropy is behind it — that is a mathematical impossibility, not a gap in the tools. Anything claiming to check whether your existing seed is weak is either confused or stealing from you. Never enter an existing seed into anything, ever, for any reason.

What you can do is control and verify the process next time. If you want the underlying arithmetic first — what a “bit” of entropy actually counts, and why 128 is the floor rather than a target — start with what entropy actually is, and why 128 bits matters.

The property that makes verification possible

A device’s own random number generator is, by nature, unverifiable. It produces a number, you cannot reproduce it, and you have no way to distinguish real randomness from a broken generator’s output. That is not paranoia; it is the exact failure mode that ran undetected in Coldcard firmware for five years and four months.

Physical dice flip the problem around. You produced the randomness, so you know it is real, and you kept the input, so the whole computation becomes reproducible. Feed the same rolls into three independent implementations written by different people in different languages, and if all three produce the same twenty-four words, the device did its job correctly. That is a genuine verification rather than an act of faith.

The exchange is not free. You have taken the vendor out of the trust model and put yourself in it. Everything in the “ways this goes wrong” section below is a consequence of that trade.

The three trust models your device offers

Coldcard’s own documentation frames this well, and the framing generalises:

Method	Who supplies the randomness	Reproducible?	Main risk
Device generator only	The device	No	You are trusting hardware and firmware you cannot audit. Coldcard’s docs call this the method that “involves the most trust”.
Device generator + dice	Both, mixed	No	Coldcard calls this “the middle ground”. Their docs note you “cannot produce worse entropy than using the COLDCARD’s TRNGs only method” — but because the device contributes, the result cannot be reproduced or checked.
Dice only	You	Yes	Fully verifiable — and every mistake is now yours. Coldcard’s own warning: “if warnings are not heeded, it is possible to generate seeds that will be stolen immediately.”

Read that last warning carefully, because it is the honest counterweight to this entire page. Dice-only removes the vendor from your trust model and installs you in their place. If you are careful and methodical, that is a genuine upgrade. If you are not, it is worse than trusting the vendor.

Coldcard: Dice Only, and checking the math yourself

Coldcard supports dice-only seed generation and documents how to verify it, which is to its credit and worth stating even in a week when the device is under scrutiny.

The path on the device is New Seed Words > Advanced, then 12 Word Dice Roll or 24 Word Dice Roll. The firmware enforces a minimum of 50 rolls for 12 words and 99 rolls for 24.

The computation is deliberately simple so that it can be checked. From Coldcard’s documentation: “The seed value is calculated as SHA256 over the rolls, when expressed as an ASCII string.” That is the entire transformation — your rolls typed as digits, hashed once, and the resulting 256-bit value encoded as BIP-39 words. A useful detail for confirming you are in the right mode: before any rolls are entered, the displayed state is SHA-256 of the empty string, which always reads e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. If your device shows that at the start, the calculation is what the docs say it is.

Coinkite publishes two small Python programs — rolls.py for 24-word seeds and rolls12.py for 12 — that take a roll sequence and print the resulting words, so you can confirm the device off-device. Their instructions and their environment recommendation are in the Verifying Dice Roll Math documentation.

SeedSigner: user-supplied entropy by design

What it does well for this specific problem

SeedSigner is an open-source, air-gapped, stateless signing device built by an independent project from off-the-shelf parts. Relevant to the subject of this page: it has no device randomness source to fail. All entropy is supplied by the user — dice, or the pixel data from a camera image. There is no hardware generator in the design, which means there is no hardware generator that can silently substitute a weak one.

Roll counts match the convention: 50 rolls for a 12-word seed, 99 rolls for 24, under Tools > New Seed. The project publishes a dice verification guide that walks through confirming the same roll sequence produces the same fingerprint, the same extended public key and the same addresses across SeedSigner, Sparrow Wallet, iancoleman.io/bip39 and bitcoiner.guide/seed. For anyone comfortable with Python there is also a command-line tool, tools/mnemonic.py, which runs SeedSigner’s own conversion code outside the device and additionally accepts coin flips — 128 for a 12-word seed, 256 for 24.

Credit where it belongs: this documentation was written by the SeedSigner project, it is thorough, and it is free. Nothing on this page is our invention.

What it does not do, stated plainly

SeedSigner is not a safer device in general. It is a device with a different risk profile, and honesty requires the other half:

• It runs a full Linux system on a Raspberry Pi — a far larger attack surface than a bare-metal firmware device.
• The Pi has no secure boot and no mechanism to confirm the installed software came from a trusted source. A user can install a rogue image and the hardware will not object.
• The camera-entropy path places more trust in SeedSigner’s own code than the dice path does — which is the same category of trust that failed at Coinkite. If you are choosing SeedSigner specifically because you want verifiable entropy, use dice, not the camera.
• Broadcom’s CPU and GPU firmware on the Pi is proprietary.
• We could not locate any formal third-party security audit of SeedSigner. That is not evidence of a problem; it is an absence of evidence, and you should weigh it as such.
• The project has not published a tagged release since v0.8.7 on 2024-07-08 — over two years. The development branch and the OS repository are actively maintained, but the project is release-stalled and it would be misleading to describe it as fast-moving.

Background on both devices in our glossary: SeedSigner · Coldcard.

The airgapped verification environment

This section is short and non-negotiable, because getting it wrong turns a security improvement into an immediate loss.

Any computer you use to check real dice rolls must be treated as if you were handling the seed itself — because you are. The roll sequence is the seed, in a different encoding. A keylogger, a clipboard monitor or a browser extension that sees your rolls has your wallet.

Coldcard’s documentation recommends: “a computer running Tails — The Amnesic Incognito Live System, preferable without any network connection and no hard drives.” SeedSigner’s guidance is the same in different words: “Never input seed phrases that you intend to use to store real funds onto an internet-connected computer!!!”, and where real seeds are involved, use an airgapped ephemeral system such as Tails and abandon it afterwards.

Concretely: boot from removable media, no network cable, Wi-Fi off, tools downloaded and their signatures checked beforehand on a different machine, and nothing written to persistent storage. Power off when done. Do not do this on your daily-driver laptop “just this once”.

Practise on throwaway rolls first

The single highest-value habit here, and the one people skip.

Before you generate anything real, run the entire procedure with a roll sequence you have decided in advance is disposable. Generate it on the device, check it in the offline tools, confirm the words match, confirm the fingerprint and addresses match. You are not testing your randomness — you are testing your process: that you can drive the menus, that your tooling works offline, that you understand what a match looks like.

Then throw those rolls away, do the real one, and never put a satoshi near the practice seed.

Eight ways a dice seed goes wrong

Dice remove one failure mode and introduce several. All of these are avoidable; none of them are hypothetical.

1. Biased dice. Ordinary pipped dice have their spots drilled out, so the six-face loses more material than the one-face and the die is very slightly weighted. It is a small bias, but the whole exercise is about not accepting small unquantified compromises. Casino-style dice with flush, filled pips are the reason precision dice exist. A cheap die from a board game is better than a broken generator and worse than a good die.
2. Rolling badly. A die that slides on a soft surface, spins without tumbling, or is dropped from two centimetres is not producing an independent fair outcome. Roll properly, on a hard surface, with a real tumble, every time — including roll 97 when you are bored.
3. Transcription error. Ninety-nine digits recorded by hand. One wrong digit produces a completely different, perfectly valid wallet. This is not a security failure but it is a very effective way to lose money — you will have backed up a seed that is not the one holding your coins. The reproducibility check catches this, which is a large part of why the check is worth doing.
4. Keeping the roll record. If you write the sequence down and keep it, that paper is your seed. Not a hint toward it — it, exactly. Coinkite’s condition for dice mitigating the 2026 flaw explicitly includes that the rolls stayed private. Either destroy the record completely or protect it identically to the seed backup. Never both half-heartedly.
5. Verifying on the wrong machine. Covered above and worth repeating: real rolls typed into a networked computer, or into a website while online, means the seed is gone. The convenience of “I’ll just check it quickly in the browser” has cost people everything.
6. Too few rolls. 50 for 128 bits, 99 for 256. Devices enforce these, but if you are doing the math by hand, forty rolls is 103 bits, not 128, and the shortfall is real.
7. Substituting something that is not a fair die. A phone dice app, a website roller, a twenty-sided die used as if it were six-sided, “random” numbers you thought up. None of these are what the math assumes. Physical, fair, six-sided.
8. Assuming dice fix everything else. Perfect entropy does not protect you from a malicious device that shows you one seed and stores another, from a bad backup, or from an address swapped on a compromised screen. This is why the verification step is the point, not the dice. The dice make verification possible; the verification is what actually gives you the assurance.

Choosing between the three models

There is no universally correct answer, and anyone who tells you otherwise is selling something.

• Dice-only gives you the strongest assurance available and demands the most from you. It fits people who will actually do the offline verification and are methodical about the eight items above.
• Device + dice is the pragmatic middle. Coldcard’s docs are correct that mixing cannot make the result worse than the device alone. It is a reasonable default for most people. You give up reproducibility, so you cannot check the result — but you also cannot be sunk by your own procedural error.
• Device-only is the least work and the most trust. It is what almost everyone does. The 2026 Coldcard incident is a precise, expensive illustration of the risk that carries — and it remains true that vastly more Bitcoin has been lost to bad backups and lost keys than to broken generators.

Whichever you pick, the backup is still the thing that determines whether you keep your coins in ten years: Setting Up an Unbreakable Bitcoin Recovery Seed · Steel Seed Backup. And if one vendor’s mistake being fatal is what worries you, the structural answer is multisig across different manufacturers rather than a better single device.

Sources

• Coldcard, Master Seed documentation (the three methods) — coldcard.com/docs/master-seed
• Coldcard, Verifying Dice Roll Math (SHA-256 over rolls; rolls.py / rolls12.py; Tails recommendation) — coldcard.com/docs/verifying-dice-roll-math
• Coinkite advisory (the 50-roll mitigation condition) — blog.coinkite.com
• SeedSigner dice verification guide — github.com/SeedSigner/seedsigner
• SeedSigner project site and hardware documentation — seedsigner.com
• SeedSigner releases (v0.8.7, 2024-07-08 — most recent tagged release) — github.com/SeedSigner/seedsigner/releases
• WalletScrutiny on SeedSigner — walletscrutiny.com
• Tails — tails.net