Dice to seed

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, its RNG. You are then trusting that RNG and there is nothing in its output you can inspect to tell whether it did its job (see: the 2026 Coldcard incident, §20).

Dice are one answer 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.

You have to trust a seed a device creates for you. You can verify a seed you rolled yourself.

Convenience against verifiability

These methods trade against each other rather than ranking cleanly. Three dimensions separate them: what you have to obtain before you start, what you have to do once you have it, and how much of the result you can check afterward.

  no cost   minor cost   a real cost   the method's weak point

The vertical brackets on the left indicate where the work happens. Hashed dice sit in neither group: the rolls happen in the real world but the device plays an integral role.

• Device RNG. The process can be audited, often in real depth, but the input, the noise the generator sampled, can't be observed. A device with a broken generator hands you a seed that looks like a sound one, but is not.
• Camera image. The live preview is your verification that real camera data is arriving. But the frame never leaves the device, so nothing can be rechecked afterward.
• Dice, hashed. The rolls go straight into the device, so there are no lookups and no arithmetic to get wrong: you write down what you rolled and type it in. The result reproduces anywhere, though a machine does all of the conversion rather than just the last word.
• Coin flips. Eleven flips yield eleven bits, which specify one word exactly, with no rerolling. But bits are not words, so reaching the word takes one of three routes: search a worksheet for 10100101101, manually convert binary to decimal, or type all 256 flips into a device.
• Dice worksheet. Six faces do not divide into eleven bits, so the worksheets branch and reroll. In a common D6 one, the first roll picks a half of the chart by odd or even, then five more are read as 1 to 4, with every 5 or 6 thrown again. That yields one word, and you need twenty-three.
• Word picking. Cutting out 2048 slips is the whole cost.

No route here is machine-free. A BIP-39 phrase ends in a checksum word, so that word gets computed however you reached the other twenty-three (§12). The last column is what each method leaves you to verify.

Which column matters most is yours to decide, and reasonable people land in different rows. But one row never drops below easy.

Dice is a reasonable compromise that holds up well enough in all three columns. The dice are ones you already own, the procedure adds nothing to the rolling beyond typing the digits in, and the result reproduces anywhere from what you wrote down. Every other method on this chart offsets its strengths with a drawback somewhere: a costly setup, an awkward procedure, or a result nobody can check.

2Does dice quality matter?

Not enough to change anything you do. A biased die does cost you bits, so the only question is how many.

Every figure below is a worst case rather than an estimate. A real die does better.

How unfair is a cheap die, really?

Not much has been published on this. These two studies are the most substantial we found.

Two studies, four decades apart, measuring different things, both landing near 1.4%. This page works from 2%, which deliberately exaggerates both. §17 has the links and the caveats.

Any bias large enough to matter is large enough to notice casually. The one that has actually been measured took a machine and 315,672 rolls to pin down.

3Why not roll more?

Extra rolls are not necessary. Advice to roll 120 or 150 times circulates on the theory that they buy margin against an imperfect die. They would, but §2 leaves no such die to guard against: a real one costs almost nothing, and one skewed far enough to matter would be so obviously bad you would not have used it in the first place.

There is a ceiling. A seed holds a fixed number of bits, 128 for a 12-word phrase and 256 for a 24-word one. 99 rolls already deliver 255.9 of that 256. Roll 150 times and the surplus has nowhere to go.

A seed rolled to the count its wallet asks for is complete. Nobody who rolled that way has anything to fix.

The roll count is not a floor to exceed for safety. It is the number that fills the seed.

4What to actually do

1. Use the dice you have. Buying better dice does not buy a better seed.
2. Testing your dice is almost certainly a waste of your time. The imperfections of cheap dice are too small to matter (§2).
3. Choosing 12 or 24 words has a bigger impact on your backup strategy than on your security. A 24-word phrase is twice as much to write down and stamp into metal.
4. Every roll needs a thorough tumble. The one thing here measured to matter.
5. Use the dice-in-a-box method. Faster and it tumbles better.

How you throw matters more than what you throw

A die remembers where it started. Kapitaniak and colleagues found that the face which starts at the bottom is the one most likely to finish there, and that how much depends almost entirely on bouncing (§17).

Their conclusion is worth quoting: “It is not enough for a die which is fair by symmetry to be fair by dynamics.”

So make sure every roll gets a real tumble, several bounces before it settles, whether that comes from your hand or from a box. It is the one thing here that can genuinely weaken a seed, and the easiest to get right.

This is where casino practice stops being a useful guide. A craps table makes dice hit a studded back wall to stop a player from exploiting this determinism for money. You are not trying to stop yourself from cheating. You only need the dice to bounce, which is a much easier thing to arrange.

The dice-in-a-box method

Put a handful of dice in a box, shake, and read them left to right. Use a box with enough room for the dice to tumble properly and shake it long enough that they do.

If that handful happens to be a mix of different dice, so much the better: different flaws partly cancel each other (§17). The gain is far too small to go shopping for, so just use whatever you happen to have, even if they all come from the same set.

5Don’t trust, verify: the seed it shows you

Dice nearly remove trust from seed generation. Not entirely, but what is left is narrow and specific rather than the broad act of faith that “trusting your hardware wallet” usually describes.

The claim a dice seed makes

When a device turns your rolls into a phrase, it is asserting exactly one thing: that these words are what its published method produces from those digits. For the hashed construction of §8 that reads:

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

Every construction in this catalog substitutes its own formula, and none of them leaves anything for the device to choose, so the method and the rolls fix the answer between them.

That assertion is falsifiable: one correct answer, computable by anyone holding the rolls, depending on nothing the device knows. A device that shows you anything else either has a bug or is deliberately trying to deceive you. Either way, it is caught the moment you check.

Testing the device costs you nothing

The useful consequence is that you can check the device as often as you like, with test rolls. Nothing is at stake in a test set, so it can be done on any computer, connected, carelessly, as many times as your patience allows.

Roll a test set for real, exactly as you would one you meant to keep. Digits you made up instead of rolling are not a rehearsal of anything. They can trip the pattern guards in §14, so the run never exercises the path your real seed will take, and typing numbers you did not roll is not a habit to build. What makes a test run free is that the seed is disposable, not that the process is.

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 working from what you typed and nothing else.

A device could answer honestly through every test and then lie on the run that matters, but it would have to guess which run that is, and nothing in your rolls tells it.

After enough test runs the device is not something you trust. It is a tool you have checked, doing exactly what its method says it should.

What to check with

Two browser tools cover most of what is in this catalog: iancoleman.io and Seed Tool from bitcoiner.guide. Either one will turn a set of test rolls into words you can hold up against your device, and §15 walks through it click by click. For most people that is the whole job.

An AI can also write you a checker from scratch, sharing no lineage with either tool. §15 has a prompt to copy.

Not everyone thinks this trade is worth making. §20 sets out the strongest objection to dice and the 2026 disclosure that tested it.

6Don’t trust, verify: the code it runs

Checking the arithmetic establishes that the device turned your rolls into the right words. It says nothing about whether the machine kept a copy of them, or whether the firmware on it is the firmware the vendor published. Those are separate questions, and they are not answered by trust either.

Reading the source tells you what the published code does. Three further steps connect that code to the device in your hand, and none of them asks you to take anyone’s word for it:

• Reproducible builds let anyone compile the published source and get byte for byte the same firmware image the vendor ships, so the binary cannot contain anything the source does not.
• Signed releases let you confirm that the image you downloaded is the one the project published, rather than something substituted on the way to you.
• A secure bootloader, on devices that have one, refuses to run firmware that is not signed, so someone with brief physical access cannot leave modified firmware behind.

Each is a subject in its own right and this page does not try to teach any of them. What matters here is that they exist, and that using them is not someone else's job.

“Open source” is not the same as “reviewed.” The entropy defect in §20 sat in published code from 2021 until 2026 before anyone caught it. Public code protects you only when somebody actually reads it, and that has meant waiting for a specialist with the time to look.

That is the part that has changed. An AI will read a firmware repository alongside you and answer questions about what it does, which puts a real look at the code within reach of someone who could not have managed it alone. You need no permission and no expertise to point one at your wallet's dice routine and ask what it touches.

7The methods and who uses which

These methods are not interchangeable. Two implementations agree only when they use the same method.

Click any column heading for how that method works.

● yes, read from source ◐ yes, with the limit in the note · no ? not established here

1. Five dice per word, each rerolled until it shows 1 to 4, plus one coin flip for the eleventh bit. The device offers the 8 valid final words.
2. A 17-page guide: two 16-sided dice and one 8-sided, thrown together, one whole word per throw.
3. Typing a phrase in, the last word is offered only as checksum-valid choices.
4. A separate option hashes rolls on top of a seed the device generated.
5. The device picks the final word with its own RNG instead of showing you the valid ones.
6. Documents the final-word feature and names dice, but advises against dice and publishes no table.
7. Requires 100 rolls for 24 words, not 99, while its own documentation still says 99.
8. D20 rolls are joined with dashes before hashing, so a D20 transcript reproduces only on Krux.
9. Its Calc Final Word tool takes the last word's spare bits from coin flips, a BIP-39 word you pick, or zeros. Not from a dice table. A coin-flip routine for a whole seed exists in the code but no menu reaches it, so the chart records dice only.
10. Autosuggests every checksum-valid last word; ships a Border Wallets grid, not a dice table.
11. You set any word's 11 bits by hand and the checksum is repaired; words you do not set stay device RNG.
12. 99 rolls and 24 words only, with no 50-roll path.
13. The mode labeled “Coldcard” applies the rewrite. Coldcard does not.
14. Any shortfall below the target length is filled from the phone's RNG after a dialog.
15. Truncates to 16 bytes unconditionally, so dice give 12 words however many times you roll.
16. Enforces no roll count at all and will derive a seed from five rolls.
17. Base 10 mode. Hex mode takes a digest you computed elsewhere.
18. Dice mode, hashed when a word count is fixed and unhashed in its default raw sub-mode.
19. Hashed mode by default; its “raw” mode packs the rolls into bits instead.
20. Demands exactly 50 or 99 rolls, the same counts as the hashed method, then never hashes them.

One column the chart does not carry: whether an implementation looks at the rolls you typed and tries to judge them. Most do not, and the few that try disagree about how. §14 is what each one checks and what the check is worth.

The chart records what each implementation does with your rolls, read from source. It is not an audit of the software and appearing in it is not a recommendation. §18 sets out what was established and what was not.

8Hash the rolls as typed

50 rolls makes a 12-word seed. 99 rolls makes a 24-word seed. The rolls are hashed as text, exactly as you wrote them down, and the resulting hash is the seed's entropy.

Check this method yourself: ten minutes, no programming, with the published test vectors.

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.

A correct implementation reproduces the published vectors in §15. If yours does not, the most likely cause is that it implements §9, §10, or §11 instead.

Coldcard also offers a separate mode that hashes your rolls on top of a seed the device generated. Nothing from that mode reproduces anywhere, because the starting value was never shown to you. It is a real trade rather than a mistake, protecting you if your dice turn out to be terrible, at the cost of the one property that made dice worth using.

9Rewrite every 6 to a 0, then hash

The same shape as the hashed method of §8, over a different alphabet. Every 6 is rewritten to a 0 before hashing, so the six faces read as 0 to 5 rather than 1 to 6. Everything after that is identical: one SHA-256, truncate, encode.

Check this method yourself: the same tool as §8 with one setting changed and that setting decides which method you get.

One substitution, and it is not a subtle difference in the result. Run the 99-roll example from §8 through both 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.

10Pack the rolls into bits, never hash

This method never hashes anything. Each face contributes bits directly and the packed bits are the seed entropy.

Check this method yourself: only against itself, because the implementations do not agree with each other.

Because six is not a power of two, the encoding is variable-length: four of the faces carry two bits each and the remaining two carry one, which is what keeps the result unbiased. A six-sided die therefore averages about 1.67 bits rather than the 2.585 an ideal encoder would extract, so filling a 24-word seed's 256 bits takes roughly 154 rolls. Needing more rolls than a hashed method is a property of this encoding, not a sign that your dice are worse.

No two of the three produce the same seed from the same rolls, which is worth stating plainly. iancoleman rewrites every 6 to a 0 before packing and the other two do not; BlueWallet and Seed Tool share a face-to-bits table but differ in what they do with a roll count that under- or overshoots. There is no shared convention here to check against, which §15 sets out as the one method where cross-checking cannot help.

11Read the rolls as a base-6 number

The oldest and most literal reading: the roll string is one long number written in base 6, so the digits are parsed as an integer and written back out as bytes. No hash anywhere.

Check this method yourself: the conversion is checkable with a pencil on a short sequence.

It is internally consistent and it is not broken. It is also the method most likely to look correct from outside while producing something else entirely.

SeedSigner itself used this method until February 2022, along with the 6-to-0 rewrite, which is why old rolls do not reproduce old seeds on a current release. The release history in the companion analysis gives the formula for each era. §15 has the steps for checking the conversion.

12BIP-39 wordlist worksheets

A whole group of implementations 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.

Check this method yourself: the lookup table is the only thing that can be wrong and checking it needs nothing but the wordlist.

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 implementations 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. Coin flips do the same job eleven bits at a time and a desktop wallet can offer the same calculation against words you arrived at however you like, which is what puts Sparrow here.

Two different things are worth separating and the chart gives them separate columns. One is whether a device will finish a phrase you built yourself. The other is whether its vendor publishes the worksheet that makes the dice route practical, which is a statement about what the vendor recommends rather than about what the device can do.

Only BitBox02 and Jade do both. The rest of this group has the capability without the worksheet, which means the method works there but you supply the table.

BitBox02's table is the clearest published example of the method. It calls for five ordinary dice and a coin, rerolling any die that shows a 5 or a 6. 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, with no rerolling and no coin flip needed. 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.

Worth noticing: the final 3 bits of a 24-word seed come from a human choosing among 8 candidates, not from the dice. Negligible against 253, but the dice do not supply everything.

Both Passports hand those 3 bits to the device's RNG instead, so the last word is not yours at all. That is the difference between their half marks in the chart and BitBox02's full one.

Worksheets no vendor publishes

The table is the hard part of this method and it does not have to come from a wallet vendor. Several people have published their own. These were surveyed on 2026-08-15 and anyone can publish another, so read this as the ones found rather than the ones that exist.

Every one of them addresses all 2048 words evenly, which is the property that matters and the one worth checking. Each construction was verified against the wordlist for this page; the survey records the pinned sources, the file hashes, and how far each table was checked. §15 gives the steps for checking a table yourself, which is worth doing before trusting any of them.

Drawing the words instead

Take the dice out of this method and it still works. Draw the words themselves from a complete physical set, one at a time, and the device completes the phrase exactly as it does from a worksheet. What changes is the selector, not the method.

SeedPicker is the case where both are present at once: you draw a paper ticket and roll a die, the pair addressing one word between them.

That technique has its own reference: Drawing BIP-39 words, covering what makes a draw fair, what goes wrong with the set itself, and the sets available. It is a work in progress.

13Wallets that offer nothing for dice

These generate seeds from their own RNG 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 · Portal · Frostsnap · Electrum · Nunchuk³ · Liana · Wasabi · Blockstream Green · Bitcoin Core⁴

1. Trezor mixes its internal RNG into seed generation unconditionally, so even a custom host tool feeding it dice bytes cannot produce a seed derived from the rolls alone.
2. Ledger is the weakest entry here. Its onboarding firmware is closed source, so this rests on first-party documentation rather than a source read.
3. Nunchuk's iOS app is closed source too and is inferred from the shared core rather than read.
4. Bitcoin Core is a structural no rather than a policy one. It does not implement BIP-39 at all, so there is no seed for dice to feed.

14Detecting bad rolls

Whichever construction an implementation uses, it faces a separate problem: someone who types the same digit fifty times, or an obvious pattern, rather than rolling. Implementations differ on whether they try to catch that at all, and the differences do not follow the method they use.

Roll-count enforcement is the guard that has actually mattered. One roll leaves six candidate seeds and two leaves 36, and wallets sitting in a space that small get found and emptied.

This is not hypothetical. In October 2023 Crypto Guide went looking for exactly those wallets, searching the chain for seeds built from low dice-roll counts, reported that funds had already been taken from them, and demonstrated the same thing still being possible on a Coldcard Mk4 running the firmware current at the time. (A separate and older problem than the 2026 RNG failure in §20.)

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.

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.

Krux is the partial exception: alongside its Shannon meter it runs a derivative-based check that flags arithmetic progressions, so it catches that row where the scores alone do not.

And it can't detect a biased die anyway

With only 50 or 99 samples the estimate is far too noisy. Tuned to warn 1 honest user in 1,000, a Shannon score at 99 rolls catches a die favoring one face 50% more often just 4.9% of the time. Coldcard's fixed 30% limit shows the same tension from the other side, falsely warning 3.4% of honest users at 50 rolls. §17 has the thresholds and the arithmetic.

It resolves itself, because these checks miss exactly the biases that do not matter: a bias small enough to hide in 99 rolls is far too small to cost a seed anything (§2). A roll-quality guard should catch patterned input, not judge your dice. Compression does that better than either approach, with fewer false alarms.

15Check it yourself

What you can check depends on which method your wallet uses, and each method's own section links into its walkthrough here. The worksheet route of §12 needs nothing but the wordlist. Anything ending in a hash needs a machine, and what matters is that the machine is not the device you are checking.

The hashed method, against the published vectors

Ten minutes, no programming. This reproduces §8.

1. Take the published 99-roll example:
   655152231316521321611331544441236164664431121534415633526456254462245546236542364246312613322234612
2. Go to iancoleman.io/bip39. The hosted page is fine here; when to download it instead.
3. Tick Show entropy details.
4. Set the entropy type to Hex, not Dice. Dice selects a different construction, the one in §15's walkthrough.
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

Test vectors

The construction, written down

There is no BIP for this. What follows is not a proposal for one. It is a description of what the nine implementations 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

The 6-to-0 remap and the one setting that decides it

Ten minutes, no programming. This reproduces §9, the construction Keystone uses and the one behind AirGap Vault's “Coldcard” mode.

1. Take the published 99-roll example:
   655152231316521321611331544441236164664431121534415633526456254462245546236542364246312613322234612
2. Go to iancoleman.io/bip39. The hosted page is fine here; when to download it instead.
3. Tick Show entropy details and set the entropy type to Dice.
4. Paste the digits and set Mnemonic Length to 24 Words. This is the step that decides which method you are testing. iancoleman's Dice mode hashes only when a word count is fixed; left on its default it packs the bits instead, which is §10.
5. You should get: police guard reject concert debate curtain width great miss uncover lift kitten observe soap fun dog always spirit camera ten grant rate across engage

If the phrase comes out different, check the word count before anything else. Leaving Mnemonic Length unset is the common failure here: the tool switches to packing bits without saying so, and returns a perfectly valid phrase built by a different method.

This checks the construction rather than any particular device. A Keystone will not accept the vector at all, because it enforces 100 rolls for 24 words rather than 99.

Bit-packing and base-6, where checking runs out

§10 cannot be cross-checked at all. The three implementations map faces to different bit strings and one rewrites a 6 first, so there is no shared answer to compare against. The most you can establish is that an implementation reproduces itself: enter the same rolls twice and confirm the phrase comes back the same.

§11 is checkable in principle and tedious in practice. Reading 99 digits as one base-6 integer and writing it back out as bytes is machine work. Do it once on a short sequence with a pencil, because the point worth seeing is what is absent: no hash appears anywhere in the conversion.

A worksheet's lookup table, before you use it

The worksheet method needs no arithmetic, which leaves the table itself as the only thing that can be wrong. What you are looking for is a cell holding a real BIP-39 word that belongs at a different index, since nothing downstream would question it. The capitalization artifacts found in three of the five worksheets in §12 are harmless by comparison.

1. Get the canonical English wordlist. Its sha256, newline-terminated, is 2f5eed53a4727b4bf8880d8f3f199efc90e58503646d9ff8eff3a2ed3b24dbda.
2. Check that the table has 2048 entries and that each index carries the word the list carries at that position. Off-by-one is the failure to expect, since some tables number from 1 and the specification numbers from 0.
3. Look for TRUE, FALSE, and capitalized month names. Harmless in themselves, but they are what a spreadsheet does to true, false, march and october, so one of them tells you the table was never compared against the wordlist.
4. Confirm the scheme addresses every word evenly: the outcomes have to be a multiple of 2048, with any surplus sent back to a reroll rather than folded into a word.

The two vendor constructions, written down

Both reach all 2048 words exactly, by different arithmetic.

BitBox02   5 dice, each rerolled until it shows 1-4   -> 2 bits per die = 10 bits
           1 coin flip                                 ->  1 bit
           11 bits per word; 23 words = 253 bits; the device supplies word 24

Jade       2 x D16 + 1 x D8, thrown together once per word
           index = (D1-1)*128 + (D2-1)*8 + (D3-1)
           16 x 16 x 8 = 2048 exactly: no rerolling, no coin flip

A table that fails any of these was never compared against the wordlist by whoever published it. The survey records how far each one was checked here.

The web tools and when to download them

Two of the implementations in §7 are browser tools and the walkthroughs in this section reach for one of them. Each ships a signed standalone build alongside the hosted page. iancoleman's releases carry bip39-standalone.html beside signature.txt.asc, and Seed Tool's carry index.html beside signature.txt.

No real rolls ever go into any of these tools. They exist for one purpose: to establish that a device turns rolls into the seed the published method says it should. The rolls you use to create a seed you intend to keep are entered on that device and nowhere else, as §5 sets out.

The hosted pages are fine for that. A test run uses rolls you are discarding and vectors that are already public, so there is nothing for a server to learn.

Downloading the signed build is an optional extra. A hosted page can serve different code on every visit and can serve it to you alone, so in principle a checker could be changed under you and made to agree with a device that is wrong. A file you have checked against its signature is the same code every time you open it. That is a precaution against a narrow attack rather than a prerequisite for checking anything.

With your own AI assistant

The goal is a checker you can run, not an answer from a chatbot. Copy the prompt below as it stands, run the program it gives you on your own machine, and keep your rolls out of the conversation.

I want a small Python program I can run offline that turns dice rolls into a
BIP-39 recovery phrase, so I can check what my hardware wallet produced.

Start by reading this page:
https://kdmukai-bot.github.io/seedsigner-ai-analysis/dice/standard.html

Wallets do not agree on how to turn rolls into a seed. Section 7 charts which
implementation uses which method, and sections 8 to 12 describe each method.

1. Ask me which wallet or tool I am using.
2. Look it up in that chart and tell me which method it uses before you write
   any code. If it is the bit-packing method, stop and say so: no two
   implementations of that one agree, so there is nothing to check against.
3. Implement BIP-39 from the specification. Do not import a wallet library.
4. Prove the encoding is right by reproducing the official BIP-39 test
   vectors, and show me that before going further.
5. Implement my wallet's method exactly as that page describes it, then
   reproduce the published test vector for it from section 15.

Do not judge the result by testing whether the output looks random. Hashing
always produces output that passes randomness tests, so that proves nothing.

Step 4 is not optional. A model that cannot encode a known entropy value correctly cannot tell you anything about your rolls, and a wrong one will be fluent and confident about it.

Step 2 is what stops it guessing. Making the model name your wallet's method before it writes any code heads off the common failure, which is applying the 6-to-0 remap unprompted: iancoleman's Dice mode is well represented in training data and looks like the obvious reading of “dice entropy”. The other failure is reaching for a wallet library rather than the specification, which quietly reintroduces the shared lineage you were trying to escape.

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.

16Known analyses

Published analyses of these implementations that we are aware of. Where one reports figures, they were reproduced independently before it was listed.

• 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.
• Coldcard, The technical autopsy of an entropy failure, 2026. Wizardsardine's teardown of the RNG defect behind the §20 disclosure. Section 10, “What about dice rolls?” is the part that bears on this page: an instrumented run on Coinkite's desktop simulator recording every write into the hash accumulator, which opens on the empty-string digest and takes the rolls alone, making the seed the BIP-39 encoding of SHA-256 over the roll string and nothing else. It also finds that the mixed mode reached with key 4 disables both the distribution check of §14 and the minimum roll count. By Loïc Morel. That document carries no internal anchors, so scroll to the heading.
  Scope: the dice path is one section of a wider RNG analysis; by the party that disclosed the defect, who competes with the vendor.
• 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 that project's own lead developer using AI tooling.

17The dice-fairness measurements

The figures in §2 are other people's measurements, converted into seed bits here. This section is the detail behind them: what was measured, by whom, how thin the evidence is, what the conversion assumes, and where the thresholds they are judged against come from.

Labby 2009, the per-face figures

Zacariah Labby, “Weldon's Dice, Automated”, CHANCE 22(4), 2009. An apparatus of solenoids, a webcam, and pip-counting software repeated Weldon's 1894 experiment: 26,306 throws of 12 dice, 315,672 individual rolls. The dice are described in the paper as “inexpensive, standard white plastic dice with hollowed-out pips and a drop of black paint inside each pip.”

• Worst face 0.1688, which is 1.28% above 1/6. That is the measurement. §2 deliberately works from 2% instead, the pessimistic end, because one experiment on twelve dice does not justify quoting a measured constant.
• The bias is significant: chi-square 25.0 against the fair hypothesis over 315,672 rolls, p = 0.00014.
• The probabilities are pooled across the twelve dice, so they characterize the set, not any individual die. No per-die face distribution is published and an individual die may deviate further. This is the single largest caveat on the §2 figures.
• Pearson's explanation was refuted, not confirmed. The usual story is that drilled pips leave the six-face lighter, which predicts face probabilities following a linear -5, -3, -1, 1, 3, 5 trend. Fitting that pattern gives p = 0.00005 against it. Labby then measured the dice with a micrometer and found the 1–6 axis consistently about 0.2% shorter than the 2–5 and 3–4 axes. The dice are not quite cubes, and the 1 and 6 faces are correspondingly larger.
• Faces 5 and 6 do not both exceed 1/6, so the classic “fives and sixes come up more” summary does not survive per-face analysis, even though the joint 5-or-6 probability is slightly high.

Weldon 1894, the experiment being repeated

W. F. R. Weldon reported 26,306 throws of 12 dice to Francis Galton in a letter dated 2 February 1894, recording only whether each die showed a five or six. Karl Pearson used the data in the 1900 paper that introduced the chi-square goodness-of-fit test.

• Observed probability of a five or six: 0.3377, against a fair 0.3333. Labby's automated repeat gave 0.3343 on the same measure.
• Labby calculates that detecting a departure of Weldon's size requires at least 100,073 throws (8,340 throws of 12 dice) at 90% power and 5% significance.
• Weldon's dice were probably wood, ivory, or bone with carved pips, so they are evidence about nineteenth-century dice, not about the plastic dice in the shops today.

Iversen and Longcor 1971, the odd-even study

Iversen, Longcor, Mosteller, Gilbert, and Youtz, “Bias and runs in dice throwing and recording”, Psychometrika 36(1), 1971. Willard Longcor threw 219 dice, one block of 20,000 throws each, 4,380,000 throws, recording only whether the up-face was odd or even.

The dice are described but the brands are not named. The paper calls them A, B, C, and X:

The precision dice are described as having “sharp edges meeting at 90° angles” with pips “either lightly painted or constructed from extremely thin disks, the whole object being polished beautifully,” shipped in plastic cases in foam-cut slots, and costing about $1.25 a pair at the time. Brand X is the five-and-dime-store die with drilled pips and a drop of paint in each hole.

• Brand X came up even 0.5072 of the time, which the paper puts at about 16 standard deviations from fair. Note that every one of its 58 blocks of 20,000 throws had more than 10,000 even faces, so all 58 individual dice leaned the same way. That is the strongest evidence on this page that the defect is a property of cheap dice generally rather than of one unlucky batch.
• Spread evenly over the three even faces, that is 1.44% above 1/6 per face, which is the figure §2 quotes and is the direct comparison to Labby's 1.28%.
• The precision dice showed no bias. Of brand B the paper says the result is “remarkably close to zero” and the summary reads: “Except for the nonprecision dice (p ≈ 0.5072), the bias was small.”
• Detection power, in their words: “we cannot expect a good chance of detecting bias in single dice unless the bias is of the order of 0.01 or 0.02.” With 20,000 throws per die. That is the same point §2 makes, from the other end: a bias small enough to need a machine to find is small enough to ignore.

Two studies, two different physical causes

The papers disagree about why cheap dice are biased, which is worth knowing before citing either as the explanation.

Iversen attributes brand X's bias to pip weight: the even faces carry 2+4+6 = 12 pips against the odd faces' 1+3+5 = 9, so drilling them out leaves the even faces lighter and they land up more often. Labby tested exactly that prediction on his dice and rejected it, then found a dimensional cause instead, the 1–6 axis being 0.2% short.

Both can be true of different dice and the two studies are blind to each other's defect. Iversen's paper says so itself: a bias where “the probabilities of opposite sides are equally inflated and other opposites equally deflated, as they might be if the die were a rectangular parallelepiped instead of a cube” would not be detected by odd-even recording. A short 1–6 axis raises faces 1 and 6 together, one odd and one even, so it cancels in exactly that way.

What survives both is the magnitude. Two experiments, two mechanisms, two eras, both landing near 1.4%.

Why the hobby literature sounds more alarming

Most modern dice-fairness testing is about twenty-sided dice and it does report widespread failure. Campbell and Miller at Western Kentucky University, whose 2024 abstract opens “Dice are cursed or blessed; that is, they roll low or high, but they are never fair,” report that roughly one plastic-mold die in four tests fair over 3,000 rolls.

Two things to hold onto before importing that conclusion here. A twenty-sided die has far smaller faces and far more of them, which the same authors note makes it more susceptible to manufacturing imperfection than a d6. And failing a fairness test is a statement about detectability at a given roll count, not about effect size: it says the bias is big enough to see, not that it is big enough to matter to a seed.

Sourced from the published abstracts rather than the full papers, which were not retrievable. The related finding that a die's chi-square correlates with the spread of its measured diameters is consistent with Labby's micrometer result, and is worth checking properly if this section is ever revised.

The salt-water float test

The usual alternative to rolling, and the one the hobby recommends: dissolve salt into warm water until a die floats, then spin it repeatedly and watch whether the same face keeps surfacing. It is a real test, and it is far quicker than the roll counts in the conversion. It also answers a narrower question than it appears to.

• What it finds is an offset center of mass. That is the mechanism Iversen proposes: the even faces carry 12 drilled pips against the odd faces' 9, so the die is lighter on one side.
• What it cannot find is the defect actually measured. Labby's dice were biased by a 1–6 axis about 0.2% short, and a die of uniform density floats with no preferred face however far off square it is. The float test is blind to it, in the same way Iversen's odd-even recording was blind to it.
• Its sensitivity is not calibrated. We are not aware of a study relating what a die does in salt water to a measured per-face distribution, so a die that fails cannot be converted into a number of bits, which is what any of this would have to produce to matter.

None of that changes the advice, because the advice never depended on bias being hard to find. A die whose bias needs salt water to reveal is a die whose bias costs a seed nothing.

The dice-in-a-box simulation

The claim in §4 that a mixed handful beats a matched set is ours, not a measurement, and it is computed by dice_tendice_box.py. Each of 4,000 trials draws ten dice whose per-face weights are perturbed by a gaussian of a given severity; a pool of n reads the first n of those ten, so the columns compare the same dice rather than independent redraws. Min-entropy in bits per roll, against 2.585 for a perfect die.

• The tiers are labeled by what they produce, not by an adjective. Each label is the mean excess of the worst face over 1/6 across the generated dice, so the top row is comparable with Labby's measured dice: gaussian severities of 0.015, 0.05, 0.10, and 0.20 give 1.9, 6.3, 12.5, and 25.2 percent respectively, quoted rounded. Earlier drafts used qualitative tiers whose mildest grade was already three times worse than anything ever measured.
• The model treats each reading as an independent draw from the averaged distribution. A shake reads each die exactly once, so a real block of n is slightly more predictable than this implies. Negligible for mild bias, more material for badly skewed dice.
• The pooling gain is small where it matters. At the measured end, ten dice buy 0.019 bits a roll over a single die, about two bits across a 24-word seed. The case for the box is speed and starting-orientation scrambling, not bias correction.
• The same script simulates the degenerate case: ten identical dice sharing one defect, where the gain is exactly zero at every pool size.

The throwing-dynamics figures

M. Kapitaniak, J. Strzalko, J. Grabski and T. Kapitaniak, “The three-dimensional dynamics of the die throw”, Chaos 22(4), 047504, 2012. A three-dimensional model of a die bouncing on a table with dissipation, compared against high-speed camera observation.

The figures quoted in §4 are from their basin-of-attraction analysis for a cubic die, where they define the average probability that the die lands on the face which was lowest at the start:

• Landing on a soft table without bouncing: 0.548.
• Thrown from the hand or a cup, with initial angular velocity 20 to 40 rad/s (their characterization of a vigorous throw) and 4 to 5 bounces: 0.199. The paper calls this “closer but still significantly different” from fair.
• At much higher spin the figure moves past fair in the other direction (0.121 at 300 rad/s), which is a curiosity rather than something to act on.

These are model results checked against experiment, not a throw-count measurement, which is a weaker kind of evidence than the dice-fairness counts. The direction of the effect, that insufficient bouncing preserves the starting orientation, is the robust part.

Why §4 does not convert this into seed bits. The probability is conditional on the starting orientation. If that orientation is itself uniformly random, the marginal distribution over faces stays uniform and no entropy is lost. The loss appears only through correlation: if the way you handle the die between throws makes each starting position a function of the previous result, the rolls stop being independent, and it is the independence rather than the per-roll distribution that the seed arithmetic assumes. We are not aware of a published measurement of how strong that correlation is for real human rolling and that is the honest gap here.

Converting a distribution into seed bits

This part is ours and it is the part to attack. dice_bias_analysis.py carries the measured distribution as a literal and prints every figure quoted in §2.

h    = -log2(max p_face)                 # min-entropy per roll, the worst case
bits = min(seed_size, num_rolls * h)     # SHA-256 treated as an ideal extractor

measured worst face 0.1688  ->  h = 2.566 bits/roll
  24-word: min(256, 99 * 2.566) = 254.1   ->  costs 1.9 bits
  12-word: min(128, 50 * 2.566) = 128.0   ->  costs nothing, 50 rolls carry 128.3

2% rounded up, used in §2  ->  h = 2.556 bits/roll
  24-word: min(256, 99 * 2.556) = 253.1   ->  costs 2.9 bits
  12-word: min(128, 50 * 2.556) = 127.8   ->  costs 0.2 bits
fair face   0.16667         ->  h = 2.585 bits/roll
  24-word: 255.9    12-word: 128.0

• The extractor assumption. Treating SHA-256 as ideal is standard practice and the margins here are far too large for the difference to matter, but it is an assumption rather than a proof.
• Rolls needed to detect a bias, at 95% confidence and 80% power, from the same script: 241,700 for the measured 1.3% bias, 6,509 for the hypothetical 8% row, 1,129 at 20%, 212 at 50%. Labby's 315,672 rolls exceed the first of those, which is why his result reaches significance.

Robustness to the estimate being wrong

Every row below is the same conversion applied to a worse die. This is the table that makes the thin evidence base tolerable: the answer does not turn on getting the estimate right.

Where the chart's lines are actually crossed. Against a fair share of 16.7%, a 24-word seed does not fall to 128 bits until one face lands 40.8% of the time, and does not reach the 112-bit floor until 45.7%. A 12-word seed, carrying half as much, reaches that floor at 21.2%. All four are printed by dice_bias_analysis.py.

What would change this. A modern per-face study across many brands and many individual dice. We are not aware of one and its absence is the honest gap in §2. If you know of one or run one, the conversion is three lines and the ladder can be re-anchored immediately.

The two thresholds on the chart

The chart in §2 draws two lines. Neither is ours.

112 bits, the dashed line. NIST SP 800-57 Part 1 Rev. 5, Table 4: a security strength below 112 bits is disallowed for applying cryptographic protection, 112 is acceptable through 2030, and the accompanying text sets the expectation at “at least 128 bits in 2031.” Earlier drafts of this page used a 100-bit “practical floor” instead, which was invented rather than cited.

128 bits, the solid line. It is where NIST arrives in 2031, and it is also the point past which a Bitcoin key stops getting stronger. Pieter Wuille, on the recurring 12-or-24-words question, first the claim:

“cryptographically speaking, there is no benefit to private keys having more than 128 bits of entropy, as long as there is no pattern in them (e.g. don't use just 128 bit numbers as private keys, that's broken, but using the hash of 128 bit numbers appears to be just fine). The reason for suggesting more is just defense in depth.”

Then the reason:

“24 words = 256 bits, 12 words = 128 bits. But finding a private key given the public key already costs only 2¹²⁸ operations (using e.g. Pollard's rho algorithm, not using brute force of course). So if an attacker can just attack the private keys that come out directly, there is no reason to try to find the seed.”

• The no-pattern condition is satisfied here. BIP-39 stretches the phrase into a seed by hashing and BIP-32 derives keys from that, so a 12-word phrase is never a small number used directly as a private key, which is the case the first comment calls broken. Every construction in this catalog ends in a BIP-39 phrase, so every one of them inherits that.
• The 2¹²⁸ bound assumes the public key is known. That holds for any output already spent from, and for taproot outputs, where the key is the output. Where a public key has never been revealed, the cheapest attack on a 12-word wallet is still its 128-bit seed, while 24 words pushes an attacker onto the 160-bit address hash instead. That gap is the concrete content of “defense in depth.”
• None of it argues for rolling past the count your wallet asks for. The count is what fills the seed either way, which is §3. The choice this bears on is 12 words against 24, made before any dice are thrown.

What a 50- or 99-roll guard can detect

The guards in §14 score the rolls the user just typed, which is a sample of 50 or 99. That is far too small a sample to characterize a die, and both common guard designs inherit the problem. Computed by dice_shannon_scoring.py and dice_coldcard_crosscheck.py, both seeded, so they reproduce exactly.

A fair die does not score 2.585. A Shannon estimate over a short sample runs low, by about (K−1)/(2N ln 2), so a threshold has to sit below the fair-die average by enough to clear its spread as well:

• What that threshold then catches, at a false-warning rate of about 1 honest user in 1,000: a die favoring one face 50% more often, 4.9% of the time at 99 rolls and 1.2% at 50. A die 110% over goes to 64.2% and 19.0%. The bias has to be gross before a short sample sees it at all.
• Coldcard's fixed 30% face limit is the same trade from the other side. Its false-warning rate on a genuinely fair die is 3.44% at 50 rolls and 0.34% at 99, exact from the multinomial rather than simulated, and it catches a 50%-biased die 13.8% of the time. A fixed percentage behaves differently at the two roll counts because the sample changes, not because the dice do.
• Neither sees order. A repeating 1-2-3-4-5-6 sequence scores 2.584 on Shannon and puts no face over 17.2%, so it passes both. zlib compresses it to 0.172 bytes a roll against 0.606 for a sampled fair sequence, which is why §14 ends on compression. The patterned rows are exact; each script draws its own fair sequence for the last row, so that one moves with the seed.
• The roll counts needed to establish a bias of a given size are in Converting a distribution into seed bits: 241,700 rolls for the measured 1.3%, 212 for a die 50% over. A guard scoring 99 rolls is three orders of magnitude short of the first.

18Where each row was read

Each was read from source at a pinned commit, not from documentation, except where the method is a document: the worksheet procedures are first-party PDFs and help articles, cited as such.

The full reading, including the wallets that turned out to offer nothing and the traps that produce wrong answers in both directions, is in evidence/wallet-dice-survey.md beside this document.

19Surveying a wallet that is not here

This section is written for whoever adds the next row, which in practice is often a model. Pointing one at this section and at the chart in §7 is the fastest way to get a wallet classified correctly and the method is short enough to be worth reading yourself if you want to know how much a row is worth.

A row has to answer seven questions, one per column: which of the four constructions the implementation applies to your rolls, whether it will complete a phrase you built by hand, whether its vendor publishes the worksheet that method needs, and whether anything the device generated is blended in.

The two traps

Both of these produced wrong answers in the survey behind this document and each was caught only after the wrong answer had been written down.

Searching firmware for dice arithmetic, finding none, and concluding “no dice support” misclassifies BitBox02, Jade, and Passport. All three ship a feature built for hand-made seeds and two of the three publish dice instructions themselves. Their firmware contains no dice arithmetic because the arithmetic is the user's job. The feature is a lookup table in a PDF plus a checksum solver in the device.

Reading the seed-generation path, finding a call to the system RNG, and stopping there misclassifies Sparrow. Its last-word calculator sits on the seed-entry path, not the generation path, and its own documentation describes neither of the two features that put it in the chart. The affordance is not always where the entropy is and it is not always written down.

Why grep alone answers wrongly in both directions

• Case-insensitive dice drowns in false positives. The substring dominates inside indices, which appears in the hundreds in several of these repositories. BIP-39's own English wordlist contains the word dice. Italian, Spanish and Portuguese localization files carry codice, and índice, and Spanish que dice means “which says.”
• Word-boundary matching then produces the false negative that caused the revision. A vendor whose dice support is a published PDF plus a checksum solver leaves no dice string in the firmware at all.
• Nearby features look like the answer and are not. A user-entropy text box that becomes a card's chain code, a memorability grid shuffled by machine RNG, a marketing line describing a hardware RNG as a dice machine, and a vendor-branded fork of a web tool are all in the survey as near misses.

The only method that gets both directions right is to read the seed-creation path, the release notes, and the vendor's own documentation. Any one of the three alone will be wrong about some wallet in the chart.

What a new row has to carry

1. A pinned tag or commit and the specific lines that do the arithmetic. Not a branch, so the line numbers stay true.
2. Which column or columns, with the one-line reason. More than one is common and a mode name usually belongs in the reason.
3. The limits: enforced roll counts, available word lengths, and whether extra rolls are accepted. These are where implementations of the same construction stop being interchangeable.
4. What you roll, since not every method is six-sided.
5. What could not be established, stated as such. The chart carries a mark for that and an honest blank is worth more than a guess.

Two negative findings in §13 show the standard being applied to itself: Ledger's onboarding firmware is closed source and Nunchuk's iOS app is closed, so both entries rest on documentation rather than a source read, and both say so.

20The case against dice, and what happened to it

Not everyone thinks the trade is worth it. Foundation, who make Passport, ship the final-word feature but advise against dice. Their then-head of strategy argued publicly in 2024, in a personal post on a third-party forum rather than as company policy, 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 and wallets were drained at scale. Coinkite issued emergency firmware on 31 July, which fixes generation from that point on and repairs nothing already generated.

The procedural half of that objection is undiminished and the specific failure it describes is one the better implementations already prevent, by refusing to proceed below the required roll count.

21Corrections

Substantive changes made after publication are recorded here, with what changed and why. Revisions made while drafting are not corrections and are not listed.

• 2026-08-18, Passport Prime was listed as offering nothing for dice, and should not have been. KeyOS v1.3.1, released 2026-08-07, added a final-word helper wired into seed entry in the onboarding and Seed Vault apps, so Prime will complete a hand-built phrase. The crate did not exist at v1.3.0, the release this page was surveyed against, so the claim was true when it was read and had been false for nine days when it was published. Prime leaves §13, and the §13 count drops from 25 wallets to 24. It does not get a row of its own: Prime is a separate codebase reaching the same behavior as Passport Core, right down to taking the last word's spare bits from the device's RNG, so it is covered by the existing Foundation Passport entry in §7 and §12, the way Jade and Coldcard rows cover their hardware variants. §18 carries both pins, since two codebases were read. The differences between the two are real but do not change what a reader does, and are recorded in the survey instead.
• 2026-08-20, SeedSigner was recorded as taking coin flips, and does not. generate_mnemonic_from_coin_flips exists in helpers/mnemonic_generation.py at 0.8.7 and implements the hashed construction over a binary alphabet, but it has no caller anywhere in the source or the tests, so no menu reaches it. The live coin-flip affordance is the Calc Final Word tool, which uses coin flips for the last word's spare bits through a different function. The §7 row now reads dice only, and its note records the unreachable routine. The chart was reporting a capability the code has and the product does not.
• 2026-08-20, a comparison of the hand methods added to §1. A chart rating six ways of producing a seed across setup, procedure, and what each leaves you to verify, with a short justification for every rating and a closing case for dice as a reasonable compromise across the three. Two existing lines changed with it: the opening now calls dice one answer to an untrustworthy RNG rather than the answer, since the chart carries four hand methods; and a line saying verification generally needs a computer was cut, being true of the hashed methods but not of the worksheet or word-picking routes.
• 2026-08-21, the §1 chart now marks where each method runs. A rail beside the chart brackets the first two methods as running on the device and the last three as running by hand, with hashed dice left between the brackets: the rolls happen in the world and the device finishes the job. The grouping was implicit in the row order and is now stated. The cells were tightened in the same edit, and two of the changes are more than wording: the device RNG row now names the input, the noise the generator sampled, as what cannot be verified, where it previously said the output; and the hand methods' last-column cells name the final word rather than the checksum.