How to Use Dice With a Trezor, a Ledger, or Any Other Wallet

The most common reaction to the Coldcard entropy bug has been “great, but I own a Trezor and it has no dice mode, so this isn’t for me.” That is the wrong conclusion, and it’s the fault of every dice guide including my own two. Your wallet does not need to support dice.

Correction, 5 August 2026. This post originally claimed Krux produces a different seed from the same dice, and showed a worked example of it. That was wrong on both counts.

Krux stopped dash-separating D6 rolls in v22.08.0, on 10 August 2022, specifically for consistency with Coldcard and SeedSigner. My source was a forum thread from 15 July 2022, fixed under a month later. I quoted the complaint and missed the fix.

Thanks to @matijaoe, who cross-checked it on real hardware and told me. The section below is rewritten, and I have reproduced Krux’s own test vector rather than taking anyone’s word for it this time.

---

🔑 Your wallet does not need a dice mode

Rolling dice produces a number. That number gets turned into 12 or 24 English words. Those words are your wallet.

The middle step, number into words, is BIP-39: a public standard that every serious wallet implements identically. It is arithmetic. It does not care what hardware it runs on.

So the job splits cleanly in two, and only the first half involves dice:

1. Generate the words from your dice, on any device or tool you trust.
2. Import those words into whatever wallet you actually want to use, via its normal “recover wallet” flow.

A Trezor cannot take your dice rolls. It can absolutely take the words those rolls produced. Same for a Ledger, a Passport, a BitBox, or a phone wallet.

Your hardware wallet doesn’t need to support dice. It needs to support importing a seed phrase. They all do, because that’s the same feature that lets you restore a backup.

There’s an irony here worth naming. Right now the best tools for the dice half of this job are Coldcard and SeedSigner. If you’ve sworn off Coldcard after the bug, a SeedSigner will do the same work for about $50. The device that generates your seed and the device that holds it do not have to be the same device.

🧰 Where to actually generate the words

Ranked by how much I’d trust them, and be honest with yourself about the tradeoff: an “offline laptop” is a general purpose computer with a hard drive, a USB stack, firmware, and a history of being online. That is a much bigger attack surface than a device built to do one thing.

Where	Why it’s good	Watch out for
SeedSigner	Dice are the only entropy source. No persistent storage, so it forgets everything on power off. Reproducible builds since v0.7.0. ~$50 of parts.	You have to build it. Pi Zero supply is annoying.
Coldcard / Keystone	Purpose built, dice mode is verifiable, both publish how to check the result.	If you don’t want to keep using it, generate, write the words down, then wipe it.
Tails, no hard drive	Amnesiac by design, leaves nothing behind. Run Coldcard’s rolls.py or an offline copy of iancoleman.	You’re trusting a laptop’s firmware and the USB stick you booted from.
Your daily laptop, “offline”	It’s what you have.	Genuinely the weakest option. Wi-Fi off is not the same as air gapped. Do this only for small amounts, if at all.

Whatever you pick, the output is the same: 12 or 24 words on a piece of paper, which you then type into your Trezor or Ledger.

🔁 The “two devices” check, and when it lies

There’s popular advice going around, and it is nearly right:

“Yeah simple just enter 100 dice roles in an exact sequence twice in two different devices. WHY DOESN’T EVERYONE DO THIS?!” @BitPaine, ~7K views

The instinct is excellent. Two independent implementations agreeing is exactly the kind of check that would have caught the Coldcard bug. And the good news, which I got wrong the first time I published this, is that the D6 tools do all agree.

Tool	How it turns dice into a seed	Matches Coldcard?
Coldcard, SeedSigner, Keystone, iancoleman (word count mode)	SHA256 over the digits, no separators	Yes
Krux (D6)	SHA256 over the digits, no separators	Yes, since v22.08.0
Krux (D20)	SHA256 over the rolls, dash separated	Not applicable, no other tool takes D20
BitBox02, Blockstream Jade	Printed diceware table: roll 5 dice, look up a word, repeat. Device computes the final checksum word	Not comparable
Trezor, Ledger, OneKey	No dice input at all	Import the words instead

Krux’s D20 mode keeps the dashes on purpose, and the reason is neat: without a separator, 1-17 and 11-7 both flatten to 117 and collide. A separator is genuinely required once faces reach double digits. For D6 it isn’t, so Krux dropped it.¹

So the two device check works, and the thing most likely to break it is not your tools. It’s your typing. Here are the same 99 rolls hashed as written, and then hashed after being written down in tidy space separated groups:

rolls: 655152231316521321611331544441236164664431121534415633526456254462245546236542364246312613322234612

as typed, no separators:     eyebrow obvious such suggest poet seven breeze blame virtual ...
same rolls, typed with spaces: fox snake scene riot sister jewel gather alarm lawn remind ...

Same dice. Different wallets. Nothing is broken, and no device did anything wrong. A space is a character, and it goes into the hash like any other.

I checked this rather than taking anyone’s word for it, having already been burned doing the opposite. Coldcard’s rolls.py reproduces SeedSigner’s published test vector exactly.² For Krux I reproduced the project’s own unit test: test_new_12w_from_d6 asserts the mnemonic diet glad hat rural panther lawsuit act drop gallery urge where fit, and hashing 50 D6 rolls of 1 as the bare string 111...1 gives exactly that, while the dash-joined version does not.¹ The BitBox and Jade rows are from vendor documentation.³

“Not comparable” means different, not worse. BitBox02 and Jade skip the two device check because they never need it: you pick the words off a printed table yourself, so the device has nothing to be checked on except one checksum word. That is arguably the strongest of these designs, since it’s the only one where verification needs no second tool and no computer. I make the full case in Verifying without a computer, including how to use BitBox’s free lookup table with a wallet you already own.

Foundation Passport is genuinely unclear. Its own community guide says there is no way to add your own entropy yet, while several reviews describe it mixing dice into device randomness. Those can’t both be true. If your Passport does mix dice with the chip’s output, that is perfectly safe but not reproducible, so the two device check is impossible by design. Ask Foundation before relying on either behaviour.

That last point generalises into the only question you actually need to ask:

Are my dice the only input, or are they mixed with the device’s own randomness? Dice only means the result is reproducible and you can check it. Mixed means it’s still safe, but nobody, including you, can ever recompute it.

✅ The two checks people keep conflating

The tweet above blurs two different verifications. Separating them is what answers “but what do I check against?” for a Ledger.

	What it proves	What it needs
Check 1: dice to words	your rolls were converted correctly	two tools from the same family in the table above
Check 2: words to address	the wallet is really using your seed	any two BIP-39 wallets, using the same derivation path

Check 1 is the one that needs matching algorithms. Do it entirely offline, before any hardware wallet is involved.

Check 2 works between literally any two BIP-39 wallets, because deriving addresses from words is standardised in a way that dice handling never was. This is the check that covers you on a Trezor or a Ledger, and it’s the one most people skip.

Concretely, for a Ledger:

1. Generate your words offline from dice. Verify with a second tool from the same family (Check 1).
2. On the same offline machine, derive the first receiving address at m/84'/0'/0'/0/0.
3. Write that address down. It should start with bc1.
4. Import the words into the Ledger.
5. In Ledger Live, look at your first receive address.
6. It must match the address from step 3, character for character.

If it matches, the Ledger is using your seed. You have not verified Ledger’s firmware, and you can’t, but you’ve confirmed the one thing that matters here: your dice, not its chip, produced this wallet.

📥 Importing into a Trezor

Trezor has no dice input. There’s a long standing feature request and it isn’t implemented.

What Trezor does have is an entropy check: the device commits to its own randomness before seeing 32 bytes from your computer, then proves it used both. It’s a genuinely good design and it defends against exactly the counterfeit-device problem. It just isn’t something you can drive with dice.

To import your own words:

• Model One: hold both buttons on boot, choose Recover wallet, pick 12/18/24 words. Standard recovery types words in Suite; advanced recovery uses the on-device 9-key layout so nothing sensitive touches the computer.
• Model T / Safe 3 / Safe 5: Recover wallet from seed, choose the word count, then tap the words on the device screen.

Prefer the on-device entry method where you have the choice. It keeps the words off your keyboard.

📥 Importing into a Ledger

Also no dice input.

On first setup, choose Restore from recovery phrase instead of “Set up as new device”. Set a PIN, choose 12 or 24 words, then type the first few letters of each word and select it from the device’s suggestions.

One thing to be aware of that has nothing to do with dice:

Ledger Recover applies to seeds you imported too. The firmware can extract seed material from the secure element, split it, and escrow it with third parties, unlocked by identity verification. That includes the beautiful dice seed you just generated. If your reason for rolling dice is minimising who you have to trust, understand that this capability exists on the device regardless of how the seed got there.

🚧 Four ways this goes wrong

Derivation paths. The same words produce completely different addresses depending on the path. m/84'/0'/0'/0/0 gives bc1... (native SegWit), m/49'/... gives 3..., m/44'/... gives 1.... Import a seed into a wallet defaulting to a different path and you’ll see a zero balance and panic. Your coins are not gone, they’re on addresses the wallet isn’t looking at. Always compare addresses using the same path.

Electrum seeds are not BIP-39. Electrum uses the same wordlist with a different checksum scheme. An Electrum seed will not import into a Trezor or Ledger. If you generate somewhere unusual, confirm it produced a genuine BIP-39 phrase.

Passphrases. If you add a BIP-39 passphrase (the “25th word”), it is part of the wallet. Same seed plus different passphrase equals a different wallet with no error message. Whatever you used at setup, you need at restore.

Untested backups. Restore the words onto a second wallet, or wipe and re-restore, and confirm you get the same first address before funding. Then send a small amount and confirm it arrives. A backup you have never restored is a hypothesis, not a backup.

The short version

Roll 100 dice. Turn them into words on something you trust, ideally a device that does nothing else. Verify those words in a second tool from the same family. Type them into your Trezor or Ledger. Confirm the first address matches what you computed offline. Then fund it.

Your wallet never needed to know about the dice.

---

New to this? Start with Rolling Dice for Your Bitcoin Wallet: The Simple Guide. Want the entropy maths, the bug that caused all this, and the source code? How to Safely Roll Dice for Your Bitcoin Seed.

1. Krux CHANGELOG v22.08.0, 10 Aug 2022: “we also introduced a change to how the D6 roll string is built, no longer including ‘-‘ between rolls prior to hashing to have consistency with ColdCard and SeedSigner”, while keeping the separator for D20 to avoid 1-17 and 11-7 colliding. The current source is one line, src/krux/pages/new_mnemonic/dice_rolls.py: entropy = "".join(self.rolls) if self.num_sides < 10 else "-".join(self.rolls). I confirmed the behaviour by reproducing the project’s own D6 test vector. The older discussion #138 from July 2022 describes the pre-fix behaviour and is what I originally, wrongly, relied on. ↩︎ ↩︎²

2. The 99 roll vector is SeedSigner’s own, from docs/dice_verification.md. I ran it through Coldcard’s rolls.py and got SeedSigner’s published mnemonic back, word for word. SeedSigner separately documents matching iancoleman and bitcoiner.guide/seed. Keystone documents the same SHA256 construction. ↩︎

3. BitBox02 diceware how-to and lookup table: five dice and a coin select each word from the printed 2048 word table, you enter 23 words and the device offers valid 24th words. Jade’s dice guide works the same way, entering the first 11 or 23 words. ↩︎