Generating a wallet from dice rolls

What you will end up with

A twelve-word recovery phrase whose randomness came from dice you rolled and watched, converted into words by two programs that were written by different people and agreed, and restored into a watch-only wallet before it holds anything.

The reason to bother is narrow and worth stating plainly. Every other way of making a seed asks you to trust a random number generator you cannot inspect: a chip inside a signing device, or an operating system's entropy pool. Those are almost certainly fine. But "almost certainly fine" is a claim you are taking on someone else's word, and dice are the one source of randomness you can watch with your own eyes and count. Coldcard rebuilt its own entropy handling in 2026 for exactly this reason: the change was about what a user can check, not about the chip getting better.

This guide is not for everyone. If you are moving a modest amount off an exchange for the first time, a reputable signing device's own generator is a reasonable thing to trust, and this procedure adds several new ways to lose the money. Read what self-custody actually costs you first and come back when the amount justifies the care.

Before you start

• Dice. Either a sixteen-sided die marked 0-9 and A-F, sold as a hex die or a d16, or ordinary six-sided dice. Both work; the roll counts differ, and the next section says why.
• Paper and a pen. Not a phone, not a notes app, not a photograph.
• A way to convert rolls into words, offline. Either a signing device that does it on the device, such as SeedSigner 0.8.7 or a Coldcard, or a computer with its network turned off.
• A second, independent implementation for the check. If the first conversion happens on a device, the second happens on a computer, and the other way around. Two runs of the same program prove nothing.
• A flat surface with a lip, so a die that rolls off the table does not become a roll you have to guess at.

Checked in August 2026 against the BIP-39 specification, the Ian Coleman BIP39 tool at release 0.5.6, python-mnemonic, Sparrow 2.5.3 and SeedSigner 0.8.7. Where a number below comes from a project's documentation rather than from the specification, the link goes to that documentation.

The arithmetic, because it decides how many times you roll

A sixteen-sided die has sixteen equally likely outcomes, so one roll carries log2(16) = 4 bits. Each roll is exactly one hexadecimal character.

• 32 rolls give 128 bits, written as 32 hexadecimal characters, which BIP-39 turns into a twelve-word phrase.
• 64 rolls give 256 bits, written as 64 hexadecimal characters, which becomes a twenty-four-word phrase.

The word count comes out of the arithmetic rather than being chosen: BIP-39 appends a checksum of one bit per 32 bits of entropy, so 128 bits plus a 4-bit checksum is 132 bits, and 132 divided by 11 bits per word is twelve words.

Twelve words is not a weaker wallet in any sense that matters to a person. 128 bits is the security level of the elliptic curve the keys sit on, so a 256-bit seed does not buy you a stronger key, it buys you a longer thing to write down and mistranscribe.

A six-sided die carries log2(6) = 2.58 bits per roll, which is why the counts are awkward. Coldcard requires 50 rolls for twelve words and 99 for twenty-four, and hashes the roll string with SHA-256 rather than reading it as digits, because the digits 1 to 6 are not a uniform four-bit value and treating them as one would throw away entropy.

The tradeoff you are accepting

You are removing the manufacturer from your threat model and putting yourself in it. Every one of these is a real way people have lost coins:

• A transcription error in 32 hexadecimal characters produces a valid-looking phrase for a wallet that is not yours and cannot be recovered.
• A biased or loaded die silently reduces entropy, and you will not notice.
• A computer you believed was offline and was not, or that wrote the phrase into a swap file, a shell history or a browser cache.
• A "clever" roll pattern. If you re-roll a result because it "looks wrong", or stop early because the digits seem random enough, you have replaced randomness with your own judgement, which is the one thing being avoided here.

The failure mode of the ordinary path, trusting a device's generator, is that the generator is backdoored. The failure mode of this path is that you made a mistake. Across the population of people who have tried both, the second has cost far more money than the first.

Steps

Do this in one sitting, with the door shut and nobody filming.

1. Turn off networking on the machine you will use for the conversion, or use a signing device and skip to step 8.
2. Open your conversion tool from a local copy. Download the Ian Coleman BIP39 release, verify the file against the release's published hash, then open the single HTML file from disk with no network available.
3. Draw a grid of 32 numbered boxes on your paper. Numbering them is what stops you from losing count.
4. Roll the die once. Write the character it shows in box 1.
5. Repeat until all 32 boxes are filled, in order, writing each result before rolling again. If a die lands cocked or off the table, that roll did not happen; roll it again. Discarding an ambiguous roll is fine. Discarding a result you dislike is not.
6. Read the 32 characters back off the paper, aloud, and count them. There must be exactly
8. Type them into the tool's entropy field with the type set to Hex [0-9A-F]. Confirm the tool reports 128 bits before you look at the words.
9. On a signing device instead: choose the dice-roll seed option, enter 50 six-sided rolls for twelve words, and let the device do the conversion on-device.
10. Write the resulting words down, in order, numbered, on paper. Write them from the screen once, then close the tool.
11. Power the machine off. If it was a live system booted from removable media, that is the point at which the entropy stops existing anywhere but on your paper.

Verify it worked

Do all four of these before the wallet receives a single satoshi.

1. Convert the same rolls again with a different implementation. On a second offline machine, run python-mnemonic or a signing device against the same 32 characters, read off your paper rather than copied from the first tool. The twelve words must be identical. If they are not, one of the two entries has a typo, and you find it rather than guessing which output to keep.
2. Restore the phrase, do not create a wallet from it. In Sparrow 2.5.3, create a watch-only wallet by importing the phrase, and note the first receive address.
3. Check the same address appears from the other implementation, on the same derivation path. Two tools deriving the same first address from the same words is the strongest single check available to you without spending anything.
4. Send a small amount and spend it back out. Not just receive: receive, then construct and broadcast a spend from the restored wallet to an address you control elsewhere. Receiving proves the address was right. Spending proves you hold the key.

Only after step 4 does the wallet get the rest.

If something goes wrong

The tool says the phrase is invalid. That is the checksum doing its job: one of the words is wrong or out of order. BIP-39 words are unique in their first four letters, so compare four letters at a time rather than whole words.

The two implementations produce different words. Do not pick one. Re-enter the 32 characters in both, slowly. Hexadecimal transcription errors cluster around 0 and D, 8 and B, and 5 and S, which is not a hex digit at all and is usually a misread 5.

The first receive address does not match between tools. This is almost always the derivation path rather than the seed. Sparrow defaults to native segwit, m/84'/0'/0'; a tool set to m/44'/0'/0' will give a completely different and equally correct address from the same words.

You lost count of the rolls. Start over. A phrase built from 29 rolls you padded to 32 is a phrase with 116 bits of entropy that you believe has 128.

You typed the phrase into anything connected. Treat that seed as burned. Generate a new one and move the funds. There is no way to un-see a seed phrase, and the coins do not know that the exposure was accidental.

Correction, 20 August 2026. An earlier version of this post said that 32 rolls of a hex die produce a 64-character hexadecimal private key. They produce a 32-character, 128-bit value; 64 characters would need 64 rolls. That version also described the result as a raw private key rather than as BIP-39 entropy, which is not how any current wallet expects a dice-generated seed to be handled. Both have been corrected above.