Reference · Bitcoin seed generation

Dice to seed

Bitcoin wallets that generate seeds from dice rolls all use the same recipe. This documents it, verifies it against every implementation, and looks honestly at what imperfect dice actually cost.

First published

2026-08-03

Scope

Dice → BIP-39

Method

Source-read

Status

Living document

The short version

1

recipe, shared across the ecosystem

0

mismatches over 4,000 sequences run against Coldcard

2.4×

bias before a 24-word seed drops to 128 bits

11

bits a realistically bad die costs, 245 remain

1Why dice at all

Every Bitcoin wallet has to produce a seed from somewhere, and almost all of them use the device's own random number generator. You are then trusting that generator, and there is nothing in its output you can inspect to tell whether it did its job. A sound generator and a broken one produce results that look exactly alike.

Dice are for when you would rather not take that on trust. The rolls are the only input, so the seed is a pure function of something you watched happen, reproducible elsewhere to confirm the device did what it should.

A seed the device chose, you can only trust. A seed you rolled yourself, you can verify.

2How it works

50 rolls makes a 12-word seed. 99 rolls makes a 24-word seed. Every implementation listed below does exactly this. A formal specification with test vectors is at the end.

Why 50 and 99 rolls

A die has six faces, so N rolls produce 6^N possible sequences. The only question is whether that is as many as there are possible seeds.

50 rolls comfortably exceeds what a 12-word seed needs. 99 rolls lands at 255.9 bits against 256, a 100th roll would push past what a 256-bit seed can hold.

3Who implements it

Each was read from source at a pinned commit, not from documentation.

If the wallet you are looking for is not in this table, start with the addendum. Keystone, BlueWallet, BitBox02, Blockstream Jade and Foundation Passport all offer something for hand-rolled seeds, but not this recipe.

One caveat, and it matters: iancoleman.io reproduces the recipe in its Hex and Base 10 modes. Its Dice mode uses a different approach and gives a different seed.

Many implementations, many languages, one recipe, with no specification, but a reference implementation several of these projects deliberately matched.

This is not blind convergence, and presenting it as such would be misleading. iancoleman.io functions as the de-facto reference: seedtool-cli's source carries the comment “Compatibility with iancoleman.io/bip39”, SeedSigner's docstring cites iancoleman and Seed Tool as its model, and Seed Tool is code-derived from iancoleman. At least three deliberately targeted it. Krux and Kern share an author, and both Gordian tools come from Blockchain Commons, so treat each of those as one lineage.

The recipe has also left Bitcoin. LumenSigner, a SeedSigner fork for Stellar, carries the function across essentially unchanged. That is worth knowing for what it says about how a convention spreads: by being copied, not by being specified.

Roll once, verify anywhere. The same rolls give the same seed on any of these, so checking your wallet against one is a real cross-implementation test, not the same code twice.

4Does dice quality matter?

The honest measure is min-entropy, conservative, assuming an attacker knows your die's exact bias and always guesses the most likely sequences first. Every figure below already assumes that worst case.

■ 24-word (99 rolls)   ■ 12-word (50 rolls)

A perfectly fair die 255.9 / 128.0 bits

One face 8% more often than it should 244.9 / 123.7 bits

20% more often, visibly odd 229.9 / 116.1 bits

50% more often, obviously defective 198.0 / 100.0 bits

110% more often, grossly loaded 149.9 / 75.7 bits

Half of all rolls, a trick die 99.0 / 50.0 bits

For a 24-word seed to fall even to 128 bits, one face would have to come up 40.8% of the time, about two and a half times its fair share. Not a slightly warped die; one you would notice in an evening of board games.

The ten-dice-in-a-box method

A common recommendation is to put ten dice of any quality in a box, shake, and read them left to right. It helps, for a reason worth understanding: after a shake, which physical die lands in which position is itself random, so each reading is drawn from the average of the pool's ten distributions, and averaging independent biases pulls that mixture toward uniform.

The bigger win is speed: ten shakes instead of 99 rolls. Tedium is a real risk: bored people start placing dice by hand. One caveat: shake hard, or faces repeat between readings.

What to actually do

1. Don't test your dice. The arithmetic above shows it cannot pay off.
2. If you're worried, choose 24 words. The extra 49 rolls buy enormous headroom.
3. The ten-dice box method is a good one, mostly for speed, with a real if modest bias-averaging bonus. Mixed handful, vigorous shake.
4. Just roll normally. Toss it so it tumbles, let it settle. Casinos make dice hit a studded back wall because they face professionals deliberately controlling throws for money, you have no reason to cheat yourself.

5Why not roll more than 99?

Advice to roll 120 or 150 times circulates, on the theory that extra rolls buy margin against an imperfect die.

With a fair die there is a ceiling. A 24-word seed is 256 bits, and 99 fair rolls already deliver 255.9 of them. Roll 150 times and you feed 388 bits into a hash that can only emit 256, the surplus is discarded.

With a biased die, extra rolls do restore what bias costs, this is worth stating plainly rather than pretending otherwise:

So the argument against rolling more is not that it does nothing. It is that the thing it buys back is not worth buying: 245 bits against a 100-bit floor. More rolls also means more tedium, and tedium produces the rushed throws that are a far bigger risk than any manufacturing tolerance.

99 is not a floor to exceed for safety; it is the number that fills the seed.

6Guarding against bad rolls

None of the above addresses a different problem: someone who types the same digit fifty times, or an obvious pattern. Implementations differ on whether they try to catch this.

Why the obvious guard doesn't work

Both common approaches, a face-frequency limit and a Shannon-entropy score, measure which faces appeared. Neither sees what order they appeared in.

Both scoring approaches share the same gap, they measure which faces appeared, not in what order.

Krux is the exception, and only partly: alongside its Shannon meter it runs a derivative-based check that flags arithmetic progressions, so it catches the row below that the scores alone do not. A face-frequency limit or an entropy score, on its own, does not.

Rolling 1-2-3-4-5-6 repeatedly gives every face its exact fair share, so it scores essentially maximum while being entirely predictable. A compression check sees it, because repetition compresses whether or not the distribution looks uniform.

And it can't detect a biased die anyway

With only 50 or 99 samples the estimate is far too noisy. At a threshold tuned to falsely warn 1 honest user in 1,000, at 99 rolls a Shannon score catches a die favoring one face 50% more often just 3.9% of the time. A related subtlety: a fair die does not score 2.585.

Coldcard's fixed 30% threshold shows the same tension from the other side: it falsely warns 3.4% of honest users at 50 rolls, against 0.33% at 99.

This is the detection paradox again, and it resolves itself: these checks miss exactly the biases that don't matter. A roll-quality guard should catch patterned input, not judge your dice. Compression does that better than either approach, with fewer false alarms.

7What you still have to trust

Dice very nearly remove trust from seed generation. Not entirely: no seed produced on a device somebody else built can be perfectly trustless. But what is left over is a narrow and specific residue, not the broad act of faith that “trusting your hardware wallet” usually describes. Once you have tested the device's arithmetic often enough to satisfy yourself, and checked its answer, essentially nothing about the seed itself still rests on the manufacturer's word. How many runs count as enough is a real question, and it is taken up below.

This section is about the residue, and it is deliberately unflattering about it.

The claim a dice seed makes

When a device shows you 24 words after 99 rolls, it is asserting exactly one thing:

These words are the BIP-39 encoding of SHA-256 over the 99 digits you just entered.

That assertion is falsifiable. There is one correct answer, it does not depend on anything the device knows, and anyone holding the rolls can compute it. If the device produces anything else, it is caught.

Testing the device costs you nothing

The useful consequence is that you can check the device as often as you like, with rolls that protect nothing. Type in fifty arbitrary digits, read the words off the screen, and compute the same thing somewhere else. Then do it again with different digits. The input is throwaway, so this can be done on any computer, connected, carelessly, as many times as your patience allows.

Each pass rules out a little more. A device that returns the expected answer run after run, for inputs it had no way to anticipate, is behaving as a deterministic function of what you typed and nothing else. Enough passes and this device implements the recipe faithfully stops being something you assume about the manufacturer and becomes something you measured yourself.

After enough test runs the device is not something you trust. It is a tool you have checked, running the same arithmetic any other tool runs.

This is the part people miss about dice. The value is not only that one seed can be verified. It is that the device's behavior can be verified, repeatedly and for free, without a single real seed ever leaving the room.

What testing settles, and what it leaves open

Two checks that get confused

These sound alike, prove very different things, and only one of them is a good idea.

Verifying means trusting the checker instead

Comparing the device against a second implementation replaces one trusted program with another. That is only progress if the second one is independent and smaller, so it is worth being deliberate about:

• Independent is not the same as different. As §3 notes, several of these implementations deliberately targeted iancoleman.io, and some share authors. Two programs from one lineage agreeing tells you less than it appears to.
• Check the convention before you trust a mismatch. Test a Keystone against the recipe in this document and not one of the 24 words will match, and nothing is wrong. That device uses the other convention. A mismatch means investigate, not panic.
• The recipe is three lines. Hash a string, truncate, encode. A checker you wrote yourself is a checker you do not have to trust.
• An AI will write you one in seconds, and this is the cheapest route to a genuinely independent implementation, because one produced on demand shares no lineage with anything in §3. Ask for BIP-39 built from the specification rather than from a library. What you want back is source code you run yourself, not an answer. The prompt in §8 asks for exactly this.
• Disagreement is the informative outcome. Two checkers agreeing is weak evidence when they share code. Two disagreeing always means something is wrong, and finding out which is cheap.

The counter-argument, stated fairly

Not everyone thinks the trade is worth it. Foundation, who make Passport, ship the final-word feature but advise against dice, and their then-head of strategy argued publicly in 2024 that they had heard of zero compromised seeds caused by hardware-wallet RNG failures, against repeated cases of users losing funds to botched dice procedures, one of them having used fewer than ten rolls.

The half about botched procedure stands, and it is the real objection: dice move the risk onto the human, and humans skip steps. The other half was an argument from absence of evidence, and the evidence arrived. On 1 August 2026 Wizardsardine disclosed that Coldcard had shipped a broken entropy path since 2021, across the Mk2, Mk3, Mk4, Mk5 and Q. The defect has been fully verified, wallets were drained at scale, and most of the funds that were exposed are already gone. Coinkite issued emergency firmware on 31 July, which fixes generation from that point on and repairs nothing already generated.

The bottom line

Generating a seed on any device normally requires trusting it on two counts: that it produced a good secret, and that it kept it. Dice plus verification eliminate the first and leave the second untouched.

Verification proves the device did the right thing. It cannot prove the device did nothing else.

What is left is narrow. Not did this device make a good secret? but did it keep the one I made? That is a single, well-understood question, and it is the one an air-gapped signing device is built to answer: no wireless hardware, no persistent storage, nothing to carry a secret out on. Turning the broad question into that narrow one is the whole benefit on offer, and it is a large benefit. It is simply not the same as zero.

8Verify it yourself

By hand, no programming, about ten minutes

1. Take the published 99-roll example:
   655152231316521321611331544441236164664431121534415633526456254462245546236542364246312613322234612
2. Go to iancoleman.io/bip39, ideally a downloaded offline copy.
3. Tick Show entropy details.
4. Set the entropy type to Hex, not Dice.
5. Paste the digits and set Mnemonic Length to 24 Words.
6. You should get: eyebrow obvious such suggest poet seven breeze blame virtual frown dynamic donor harsh pigeon express broccoli easy apology scatter force recipe shadow claim radio

With your own AI assistant

The goal is a checker you can run, not an answer from a chatbot. Ask it for code, run that code locally, and keep dice rolls out of the conversation entirely. Everything the model needs is in this page already.

Step 1 is not optional. An unvalidated checker is not a second opinion, it is a second guess. Requiring the official vectors first is what makes the rest of the answer worth anything, and it catches the common failure of a model applying the 6-to-0 remap on its own initiative.

Do not let it answer step 4 with a keyword search. Searching firmware for “dice” case-insensitively drowns in the word indices; searching with word boundaries misses vendors whose dice support lives in a published PDF rather than in code. Require it to read the seed-creation path, the release notes, and the vendor's own documentation, and to say which of the four categories in §3 applies.

Tell it explicitly not to evaluate the result by testing whether the output looks random. Hashing anything produces output that passes randomness tests, so such tests cannot detect a weak seed.

What ships with this page

The backing material sits in the repository beside this document, so none of it has to be taken on description alone. Only verify_constructions.py is standard library only; the rest need pip install mnemonic embit==0.8.0 in a virtual environment.

9Reference: the construction

There is no BIP for this. What follows is not a proposal for one. It is a description of what the implementations in §3 already do, written down so it can be checked against them.

INPUT   rolls : string of ASCII digits '1'-'6'
                len(rolls) == 50  ->  12-word seed
                len(rolls) == 99  ->  24-word seed

STEP 1  entropy = SHA256(rolls.encode('ascii'))          # 32 bytes
STEP 2  if 12-word:  entropy = entropy[0:16]             # 128 bits
STEP 3  mnemonic = bip39_encode(entropy)                 # BIP-39, English
                                                         # indices are 0-based: 'abandon' == 0

NOT     no 6 -> 0 remap; the digit 6 is hashed as the character '6'
        no base-6 or numeric conversion of the roll string
        no bit-packing or bias-correction encoding
        no separators, padding, or trailing newline in the input

Test vectors

A correct implementation reproduces both. If yours does not, the most likely cause is a 6→0 remap or a numeric conversion applied before hashing.

10Known analyses

Published analyses of these implementations that we are aware of.

• Coldcard, Dice roll firmware trace, 2026. An independent dynamic trace of the 24-word dice path on Mk4/Mk5 firmware v5.6.0 (commit 3238f6fd, which is the emergency release of 31 July 2026), run on the headless simulator, logging every write into the hash accumulator and confirming no RNG is touched. Includes a deterministic-build proof tying that commit to Coinkite's published signed firmware. By Portland.HODL.
  Scope: does not exercise the 12-word path; Mk4/Mk5 only, not the Q line; one roll pattern; simulator rather than hardware.
• SeedSigner, Dice entropy: AI analysis and full release history, 2026. Reproduces the published vectors against independent implementations, traces the shipped function dynamically, and tracks the construction across every release since 2020.
  Scope: dice path only; produced by the that project's own lead developer using AI tooling.

We reproduced the trace's figures independently before listing it.

11Addendum: other dice methods

Everything above concerns one construction. This addendum covers the rest of the landscape, for readers checking a specific wallet rather than the recipe itself.

Dice, but a different recipe

These take your rolls and do the arithmetic themselves, but not this arithmetic. Each is internally consistent and none is broken. They simply produce a different wallet from the same rolls, so they cannot be used to check each other.

The most common divergence is a single character. A competing convention rewrites every 6 to a 0 before hashing, so the six faces read as 0 to 5 rather than 1 to 6. That one substitution is not a subtle difference in the result: run the 99-roll example from §2 through both conventions and the two 24-word phrases have no words in common at all. They agree only if you roll no 6 in the entire sequence, which at 99 rolls happens about once in 69 million.

Dice with a paper table

A third group does no dice arithmetic at all, and still deserves to be called dice support. The method is old and needs no firmware: roll dice, look each word up in a printed table, write it down. Anything that accepts a typed recovery phrase can then receive the result.

What makes it practical is the last word. A BIP-39 phrase ends in a checksum, so most word combinations are invalid, and finding a legal final word by hand means testing candidates one at a time. These tools compute it for you, which is the whole reason the feature exists.

A printed table is the usual way to reach the first 23 words, but it is not the only one, and the group is not only hardware. A desktop wallet can offer the same calculation against words you arrived at however you like, which is what puts Sparrow here rather than in the list below.

BitBox02's table is the clearest published example of the method. Five dice give 10 bits: you reroll any die showing 5 or 6 until it shows 1 to 4, which makes each die worth exactly 2 bits. A coin flip supplies the eleventh. Twenty-three words later you have 253 bits, and the device supplies the last word.

Jade's published method is not a six-sided one at all. It calls for two 16-sided dice and one 8-sided die, thrown together once per word and read off a lookup table as (D1−1)×128 + (D2−1)×8 + (D3−1). That covers 16×16×8 = 2048 exactly, so there is no rerolling and no coin flip, and each throw yields a whole word rather than a partial one. It arrives where BitBox02's method arrives, by different hardware and different arithmetic. The two are not variants of one scheme, and a transcript from one means nothing to the other.

No dice

These generate seeds from their own random number generator, and offer nothing for dice beyond the ordinary ability to type in a phrase you produced elsewhere:

Trezor · Ledger · KeepKey · OneKey · Bitkey · Tangem · Cypherock · NGRAVE · Ellipal · SafePal · D’CENT · Satochip · Prokey · SecuX · Arculus · Ballet · Passport Prime · Portal · Frostsnap · Electrum · Nunchuk · Liana · Wasabi · Blockstream Green · Bitcoin Core