Coinkite’s Coldcard wallet was supposed to be the paranoid option. It had two separate hardware random number generators, an air-gapped signing flow, and a five-year reputation as the device serious Bitcoin holders reached for. Then, starting July 30, 2026, attackers drained roughly 1,816 BTC (about $116 million at the time) from more than 5,200 addresses across four waves in under a week. The bug traced back to a single firmware commit from March 2021 that quietly swapped hardware entropy for a predictable software fallback. Nobody noticed for five and a half years.
If you hold Bitcoin in cold storage, that incident should change how you think about your setup, regardless of which device you use. A hardware wallet’s job is to generate a secret nobody can guess and never expose it. When the entropy source fails silently, “cold storage” stops meaning anything, even though every visible signal (the device screen, the passphrase prompt, the seed words) looks completely normal. This tutorial walks through how to audit your own cold storage for entropy weaknesses, regenerate a seed properly using multiple independent tools, and migrate funds without leaking your keys in the process. It applies to Coldcard, Trezor, Blockstream Jade, SeedSigner, Krux, and any other BIP-39 compatible signer.
Why cold storage entropy failures matter more than exchange hacks
Exchange hacks and cold storage failures look similar from the outside (coins move, someone loses money) but the failure mode is completely different. When an exchange gets hacked, the custodian’s infrastructure was the weak link, and there’s usually a company, an insurance policy, or a lawsuit to argue about afterward. Cold storage is supposed to remove that dependency entirely. You hold the key, you sign the transaction offline, and no third party can touch your coins. That model only works if the key itself was generated correctly in the first place.
The Coldcard case broke that assumption in the worst possible way. According to TRM Labs’ analysis of the incident, the vulnerability came from a 2021 change that routed seed generation through MicroPython’s Yasmarang pseudo-random number generator instead of the STM32 chip’s dedicated hardware TRNG, even though the hardware RNG was present and working the whole time. Independent write-ups of the bug, including one from researcher Steven Geller, describe it bluntly: the device had two hardware RNGs and used neither for its most important operation. Analysts at crypto.news traced the flaw to a specific build flag introduced on March 1, 2021, meaning any seed generated on firmware from that date through the July 31, 2026 hotfix could carry reduced entropy, regardless of how carefully the owner otherwise handled the device.
What makes this worse for cold storage specifically is the delay between cause and consequence. A user who generated a seed in 2021, wrote it on a steel plate, buried it in a safe, and never touched the device again had no way to know anything was wrong until on-chain forensics teams reconstructed the pattern in mid-2026. Firmware updates protect seeds generated going forward. They do nothing for a seed that already exists, because the weakness lives in the key itself, not in the software currently running on the device that holds it.
Prerequisites: hardware, software, and versions you’ll need
Before starting, gather the following. This tutorial assumes you already hold Bitcoin in a single-device cold wallet and want to audit it, then migrate to a hardened, multi-device setup.
- An existing hardware wallet with funds (Coldcard Mk2/Mk3/Mk4/Mk5/Q, Trezor Safe 3/5/7, or similar), updated to its latest published firmware
- A second, independent signing device from a different vendor for cross-verification (SeedSigner on a Raspberry Pi Zero 2 W, a Krux build on an M5StickV, or a Blockstream Jade)
- Sparrow Wallet, latest stable release, running on an offline or air-gapped computer for watching addresses and building transactions
- Two sets of six-sided dice (or one casino-grade set) for manual entropy generation
- A metal seed backup plate (steel capsule or similar) rated for fire and corrosion resistance, one per new seed
- A dedicated, freshly wiped microSD card if your signer uses SD-based PSBT transfer
- A notepad and pen for tracking dice rolls before they’re converted digitally — never type raw dice rolls into an internet-connected device
- Roughly 3 to 4 hours of uninterrupted time, ideally split across two sessions so you’re not rushing the migration step
None of this requires spending money on new hardware if you already own a second device. If you don’t, a basic SeedSigner build costs under $50 in parts and is fully open source, which is precisely the point: you want your entropy verified by hardware and firmware that has nothing in common with your primary wallet’s supply chain.
Step 1: Identify your device model and firmware history
Start by establishing exactly what hardware you have and when your current seed was generated, not just what firmware is currently installed. On a Coldcard, this information lives under Advanced/Tools then Version Info. Write down the exact model (Mk2, Mk3, Mk4, Mk5, or Q) and the firmware version shown. On a Trezor, check Settings then Device in Trezor Suite for the model and firmware string.
The critical detail people miss here: the firmware version displayed today tells you what’s installed now, not what was running when the seed was first generated. If you set the device up years ago and only updated firmware occasionally, your seed’s effective security depends on the firmware version active at setup time, which you may need to reconstruct from purchase dates, old screenshots, or update logs.
# On a Coldcard connected via USB with ckcc-protocol installed
pip install ckcc-protocol
ckcc version
# Output shows firmware version and build date, e.g.:
# COLDCARD Mk4 firmware v5.4.1 (2026-08-02)Step 2: Build a risk table for your specific device and window
Based on the disclosed advisory and independent hardware wallet analysis compiled by D-Central’s signing device reference, exposure varies significantly by model and firmware window. Use the table below to classify your own risk level before deciding whether a full migration is warranted.
| Device / firmware window | Estimated effective entropy | Recommended action |
|---|---|---|
| Coldcard Mk2/Mk3, firmware 4.0.1-5.0.3 | As low as ~40 bits | Migrate immediately, treat as compromised |
| Coldcard Mk4/Mk5/Q, seed generated before July 31, 2026 hotfix | ~72 bits | Migrate as a precaution; no confirmed on-chain exploitation in this cohort yet |
| Coldcard, any model, seed generated after July 31, 2026 patch | Full 128/256-bit (hardware TRNG restored) | No action needed if verified on patched firmware |
| Trezor, Ledger, Jade, seed generated via their own on-device RNG | Not affected by this specific bug | Still worth a manual entropy cross-check as general hygiene |
Effective entropy dropping from an expected 128 bits down to roughly 40 bits is not a small degradation. Each bit lost halves the search space an attacker needs to brute-force, so a drop of that magnitude turns a computationally infeasible attack into one that automated scanning tools can complete quickly, which lines up with how fast the July 2026 waves swept through thousands of addresses.
Step 3: Understand why “just update the firmware” isn’t enough
This is the single most misunderstood point in the entire incident, and it’s worth spending a full step on it. Coinkite’s hotfix, identified in commit ca724637 and shipped July 31, 2026, changes how the device generates entropy for any seed created from that point forward. It does not touch, re-derive, or in any way strengthen a seed that already exists on the device. The private key math is already fixed the moment the seed words were generated. Updating firmware afterward doesn’t reach backward in time to fix a value that was already computed.
Practically, this means: if you generated your seed anytime between March 2021 and July 31, 2026 on affected firmware, updating today changes nothing about your existing coins’ safety. Your only real remediation path is generating a brand-new seed on verified-good hardware and moving every satoshi to addresses derived from that new seed. Anything less is treating a symptom while leaving the underlying key intact.
A quick primer on BIP-39 entropy, so the numbers above make sense
The BIP-39 standard, maintained in the Bitcoin protocol’s own specification repository, defines how a wallet turns raw randomness into the 12 or 24 words you write down. Under the hood, a 12-word seed encodes 128 bits of entropy plus a 4-bit checksum, while a 24-word seed encodes 256 bits of entropy plus an 8-bit checksum. Every additional bit of entropy doubles the number of possible seeds an attacker would have to try, which is why the difference between 128 bits and 40 bits isn’t a modest downgrade, it’s the difference between “not crackable within the lifetime of the universe” and “crackable with a rented cloud GPU cluster in a reasonable timeframe.”
NIST’s SP 800-90B publication, which sets the federal standard for entropy source validation, is the reference most hardware wallet vendors point to when they claim their RNG is cryptographically sound. The Coldcard incident is a useful case study precisely because the hardware itself likely would have passed that kind of validation. The STM32 chip’s true random number generator was fine. The problem was a software routing decision that never reached it, which is a class of bug no entropy validation test on the chip alone would ever catch, since the test isn’t looking at how a separate firmware layer chooses to call it.
| Seed length | Entropy bits | Checksum bits | Total words |
|---|---|---|---|
| 12 words | 128 | 4 | 12 |
| 18 words | 192 | 6 | 18 |
| 24 words | 256 | 8 | 24 |
This table is worth keeping in mind while you work through the migration steps below, because it explains why security researchers keep emphasizing bit counts rather than just saying “the bug was bad.” A seed effectively reduced to 40 bits isn’t a slightly weaker version of a 128-bit seed, it’s a different security category entirely, closer to a short password than a cryptographic key.
Step 4: Generate entropy manually with dice as a verifiable baseline
The lesson security researchers keep repeating after this incident is that a single entropy source, no matter how well designed on paper, is a single point of failure. The fix isn’t to trust a different chip blindly; it’s to combine sources you can verify independently. Dice rolls are the simplest verifiable entropy source because you can watch the randomness happen with your own eyes, with no firmware in between.
For a 24-word BIP-39 seed you need 256 bits of entropy. Standard six-sided dice give you roughly 2.585 bits per roll, so you need at least 99 rolls to comfortably clear 256 bits, and most practitioners round up to 100 for a clean number. Record each roll on paper before touching any device.
# Example dice-roll log (do this on paper, not a computer)
# Roll 1-10: 4 2 6 1 3 5 6 2 4 1
# Roll 11-20: 3 6 2 5 1 4 3 2 6 5
# ... continue to 99-100 rolls total
#
# Convert using a base-6 to entropy tool ONLY on an air-gapped device,
# e.g. SeedSigner's "Dice" seed generation flow, or Krux's dice entropy tool.
# Never type raw dice values into any internet-connected computer or phone.Both SeedSigner and Krux include a built-in dice-entropy workflow that takes your rolls, mixes them with the device’s own camera-based or hardware entropy, and derives a BIP-39 mnemonic entirely offline. Using this combined approach means an attacker would need to compromise both your physical dice-rolling process and the device’s independent RNG simultaneously, which is a fundamentally different threat model than trusting one chip.
Step 5: Cross-verify the seed on a second, independent device
Once your new signer has generated a candidate seed, don’t just trust it and move on. Load the same 24 words onto a second device from a different manufacturer, running different firmware, ideally built on different silicon. If you generated the seed on SeedSigner (which runs on a Raspberry Pi Zero), verify it by importing on a Blockstream Jade or a patched Coldcard using the “restore from existing seed” flow. Confirm that both devices derive the exact same set of receive addresses for the same derivation path.
This step catches two distinct classes of problems: a firmware bug that mis-derives addresses from a correct seed, and a supply-chain compromise where a device silently substitutes a different seed than the one it displayed. Two independently sourced devices agreeing on the same addresses is meaningfully stronger evidence than a single device’s confirmation screen, precisely because a single device confirming its own output tells you nothing about whether that device is trustworthy in the first place.
Step 6: Set up watch-only wallets in Sparrow before moving any funds
With your new seed verified across two devices, set up a watch-only wallet in Sparrow Wallet using the extended public key (xpub or zpub) from your new signer. This lets you generate receive addresses and monitor incoming transactions from an internet-connected machine without ever exposing your private keys online.
# In Sparrow Wallet
File > New Wallet > "post-migration-cold-storage"
Keystore: choose your new hardware device or "Airgapped Hardware Wallet"
Import via: SD card / QR code (PSBT) depending on your signer
Script Type: Native Segwit (P2WPKH) unless you specifically need Taproot
Save wallet file, then verify the first 3 receive addresses
match what your hardware device displays on its own screenAlways compare the addresses shown in Sparrow against the addresses shown directly on your hardware device’s screen before sending anything meaningful. A compromised watch-only setup or a man-in-the-middle on the QR/SD transfer path could otherwise substitute a different address without you noticing.
Step 7: Build and sign the sweep transaction offline
Now build a transaction in Sparrow that sends the full balance from your old, potentially compromised wallet to the new watch-only wallet’s receive address. Sparrow will produce a PSBT (Partially Signed Bitcoin Transaction) file. Transfer this to your old hardware wallet using its air-gapped method (microSD or QR code, never USB if you can avoid it, to minimize attack surface).
# Sparrow: Send tab
Recipient: paste the new wallet's receive address
Amount: click "Max" to sweep the entire balance minus fees
Fee rate: check mempool.space for current sat/vB, aim for
next-block confirmation unless the network is congested
Create Unsigned Transaction > Save as PSBT to microSD
# On the OLD hardware wallet (air-gapped):
Load PSBT from microSD > verify recipient address on-screen
matches your NEW wallet exactly > Sign > Save signed PSBT back to SD
# Back in Sparrow:
Load signed PSBT from SD > Broadcast TransactionVerify the destination address on the old device’s own screen character by character before approving the signature. This is the last checkpoint before funds move, and it’s the one step in this entire process you should never rush.
Step 8: Confirm the transaction and wait for adequate depth
Once broadcast, track the transaction on a block explorer such as mempool.space using its transaction ID. For amounts under roughly $10,000 in value, one confirmation is generally considered sufficient for your own peace of mind, though most exchanges require three to six. For migrating a life-changing sum, waiting for 6 confirmations (roughly one hour under normal network conditions) before considering the funds fully settled is a reasonable, low-cost precaution.
Do not decommission or wipe the old device until you’ve confirmed the new wallet’s balance matches what you expect and you’ve independently verified you can see the funds from at least one other tool (a block explorer plus your watch-only Sparrow wallet, checked separately).
Step 9: Split the new seed with Shamir or a multisig setup
A single, freshly generated seed is a big improvement over a compromised one, but it’s still a single point of failure for theft, fire, or a bad backup decision. Once your funds are safely on the new seed, consider one of two hardening paths depending on the size of your holdings and your risk tolerance.
- Shamir Secret Sharing: splits your seed into N shares where any M of them reconstruct it (for example, 3-of-5), so no single share compromise or loss is fatal. Suited to holders who want a single wallet but distributed physical backups.
- Multisig with Sparrow: requires signatures from M of N separate hardware devices to move any funds at all, meaning an attacker (or a bug) affecting one device alone cannot drain the wallet. Suited to holders who want protection against a single device’s entropy or firmware failing again in the future, since the failure of one signer doesn’t compromise the whole wallet.
Multisig is the stronger structural defense against exactly the class of bug that caused the Coldcard incident, because even if one manufacturer’s RNG fails silently again, your funds remain safe as long as the other signers in your quorum used independent, unaffected hardware.
Step 10: Store the new backup using the 3-2-1 principle
Stamp or engrave your new seed words (or Shamir shares) onto metal backup plates rather than paper. Paper burns, fades, and degrades with humidity over the multi-year timeframes cold storage is meant for. Follow a 3-2-1 pattern: at least 3 total copies, stored on 2 different media types if practical, with at least 1 copy geographically separate from your primary residence (a bank safe deposit box, a trusted family member’s secure location, or a commercial vault service).
Label each backup with the derivation path and script type used (for example, “Native Segwit, m/84’/0’/0′”), but never label it with an amount or an obvious indication that it’s a cryptocurrency backup. A steel plate that just looks like scrap metal to an unaware observer is safer than one stamped “BITCOIN SEED.”
Step 11: Set a recurring audit calendar reminder
The Coldcard bug sat undetected for roughly five and a half years. That’s not because nobody was looking; it’s because entropy failures don’t produce symptoms. The device works perfectly in every visible way right up until someone with the right knowledge and enough patience empties your wallet. The only defense against this class of bug is periodic, deliberate re-verification, not one-time trust.
Set a recurring calendar reminder, at minimum annually, to check for vendor security advisories, confirm your firmware version against the manufacturer’s published changelog, and verify your watch-only wallet still matches your hardware device’s derived addresses. This is a five-minute task performed once a year, which is a trivial cost against a six-figure downside.
Step 12: Document your setup for anyone who might need it later
Write a plain-language recovery document, stored separately from your seed backups, that explains your setup structure without revealing any secret material: which devices you used, whether it’s multisig or single-sig, where the backup shares live, and what software (Sparrow, specific derivation paths) is needed to reconstruct access. This document is for your heirs or a trusted executor, not for day-to-day use, and it should never contain actual seed words, only the instructions needed to locate and use them.
Common pitfalls to avoid during migration
- Typing dice rolls into a phone or laptop. Any internet-connected device is a potential leak point. Keep entropy generation entirely within air-gapped hardware.
- Trusting a firmware update to fix an existing seed. As covered in Step 3, the fix only protects seeds generated after the patch, never seeds that already exist.
- Skipping the second-device cross-check. A single device confirming its own seed generation provides no independent evidence that generation was actually correct.
- Reusing the old seed’s derivation path assumptions on the new seed without checking. Always verify the new wallet’s script type (Segwit vs Taproot vs legacy) matches what you configured, or funds may appear “missing” when they’re actually just under a different derivation path.
- Moving funds in a single transaction without a test sweep first. For large balances, send a small test amount first, confirm receipt in the new wallet, then sweep the remainder.
- Wiping the old device before confirming the new setup fully works. Keep the old device intact and untouched (but offline) for at least a week after migration as a fallback.
- Storing all backup copies in one location. A single fire, flood, or theft event should never be able to destroy every copy of your recovery material.
- Labeling backups in a way that identifies them as crypto-related. This turns a random home invasion into a targeted one if discovered.
Expected output at each stage
Here’s what a clean run through this process looks like in terms of concrete outputs, so you can sanity-check your own progress against it.
| Stage | Expected output |
|---|---|
| Device audit (Step 1-2) | A written record of model, current firmware, and estimated seed-generation-time firmware |
| Dice entropy (Step 4) | 100 recorded rolls, converted into a 24-word BIP-39 mnemonic on an air-gapped device |
| Cross-verification (Step 5) | Identical first 5 receive addresses on two different hardware devices for the same derivation path |
| Sparrow watch-only setup (Step 6) | A wallet file showing a zero balance and a valid first receive address matching your hardware |
| Sweep transaction (Step 7-8) | A confirmed transaction ID on mempool.space, balance visible in the new watch-only wallet |
Troubleshooting common problems
- Sparrow shows a zero balance after import. Confirm you selected the correct script type (Native Segwit is m/84′, Nested Segwit is m/49′, Legacy is m/44′). A mismatched derivation path shows an empty wallet even though the funds exist elsewhere on the same seed.
- The two devices show different addresses for the same seed. Check that both are using the same derivation path and the same passphrase (an empty passphrase is still a passphrase, and a typo here creates an entirely different wallet).
- PSBT file won’t load on the old hardware wallet. Some older firmware versions cap PSBT file size or format. Update to the latest firmware for the old device specifically for this transfer step (this doesn’t fix the old seed, but it does let you actually move it out).
- microSD card not recognized by the signer. Reformat as FAT32, not exFAT. Most hardware wallet firmware only reads FAT32.
- Dice-to-entropy tool on SeedSigner rejects your roll count. You need a minimum of 50 rolls for 12 words or 99 rolls for 24 words; recount and make sure you didn’t skip a digit while transcribing from paper.
- Transaction stuck unconfirmed for hours. Check the fee rate you set against current mempool.space conditions; if it’s below the median, use Sparrow’s replace-by-fee (RBF) option if you enabled it when creating the transaction.
- Watch-only wallet balance doesn’t match the block explorer. Sparrow may need a manual rescan if you imported an xpub that already had transaction history; right-click the wallet and select rescan.
- Old device firmware update fails during the pre-sweep step. Try a wired USB connection instead of any wireless transfer method, and confirm the device has sufficient battery or is plugged in throughout the update.
Advanced tips for high-value cold storage
If you’re securing a meaningful amount of Bitcoin, a few additional practices are worth the extra setup time. First, consider geographic distribution for multisig co-signers, not just backup shares: keeping your three multisig devices in three physically separate locations means a single burglary, fire, or coercion event can’t compromise your spending quorum. Second, use a passphrase (the 25th word) in addition to your seed, stored separately from the seed itself; this creates plausible deniability and means a compromised seed backup alone still isn’t enough to move funds. Third, periodically test your recovery process on a small amount using a fresh, unused device to confirm your documentation actually works, rather than assuming it does until the day you desperately need it.
Finally, follow vendor security disclosures directly rather than relying on secondhand summaries. Manufacturers like Coinkite publish advisories on their own blog and GitHub repositories first, often before mainstream coverage catches up, and subscribing to those channels is the fastest way to learn about the next entropy or firmware issue before it becomes a headline.
Complete working setup: a hardened 2-of-3 cold storage reference
Putting the full process together, here’s what a complete, hardened cold storage setup looks like once you’ve finished the migration described above.
| Component | Role |
|---|---|
| Signer 1: patched Coldcard (post-July 31, 2026 firmware) | Primary daily-use signer, kept at home in a safe |
| Signer 2: Blockstream Jade | Secondary signer, stored at a separate location (family member or safe deposit box) |
| Signer 3: SeedSigner (Raspberry Pi Zero build) | Tertiary signer with independently generated dice-based seed, stored offsite |
| Sparrow Wallet, 2-of-3 multisig | Coordinates the watch-only wallet and transaction building across all three signers |
| Metal backup plates, one per signer’s seed | 3-2-1 storage pattern across at least two physical locations |
# Sparrow multisig setup summary
File > New Wallet > "hardened-cold-storage"
Policy Type: Multi Signature
Total Signers: 3, Threshold Required: 2
Add Keystore 1: Coldcard (import via SD card / xpub)
Add Keystore 2: Blockstream Jade (import via QR)
Add Keystore 3: SeedSigner (import via QR)
Apply > verify addresses across all 3 devices before fundingWith this structure, losing or having one device compromised (through theft, an entropy bug, or physical damage) doesn’t cost you your Bitcoin. You’d still need a second signer to authorize any spend, and you have a documented recovery path to rebuild a lost signer using your remaining two.
Time and cost to expect
People planning this migration usually want to know two things upfront: how long will it actually take, and what does it cost if I don’t already own a second signing device. Neither answer is complicated, but both are easy to underestimate if you try to rush through the verification steps.
| Task | Typical time | Typical cost |
|---|---|---|
| Device audit and firmware history check | 15-30 minutes | $0 |
| Dice entropy generation (99-100 rolls) | 20-30 minutes | $0 if you already own dice |
| Second signing device (if you need one) | 1-3 days shipping | $0-$50 for a SeedSigner build, $70-$150 for a Blockstream Jade |
| Cross-verification across two devices | 15-20 minutes | $0 |
| Sparrow watch-only setup and address verification | 20-30 minutes | $0, Sparrow is free and open source |
| Sweep transaction, sign, broadcast, and confirm | 30-60 minutes plus confirmation wait | Network transaction fee only, typically a few dollars |
| Metal backup plates (per seed) | Same day if on hand | $15-$60 per plate depending on material |
Realistically, budget one focused afternoon if you already own a second device, or spread it across a week if you need to order hardware first and want to wait for shipping rather than rush the cross-verification step. The single biggest time sink people underestimate is the dice-entropy roll count: 99 rolls sounds trivial until you’re actually doing it by hand, so don’t schedule this step for the last ten minutes before you need to leave the house.
Frequently asked questions
Do I need to migrate if I use a Trezor or Ledger instead of a Coldcard?
The specific RNG bug described here was disclosed in Coldcard firmware. It doesn’t mean other vendors are affected by this exact flaw. That said, the broader lesson, that a single, unverified entropy source is a risk regardless of brand, applies to every hardware wallet, so a periodic cross-check against a second device is worthwhile no matter what you use.
How do I know exactly when my seed was generated if I don’t remember?
Check your purchase receipt or order confirmation email for a rough date, then compare against your device’s firmware update history if you kept any records. If you genuinely can’t determine the window, treat the seed as potentially affected and migrate as a precaution rather than guessing.
Can I reuse my old seed words on the new, patched firmware instead of generating a fresh seed?
No. If the seed itself was generated with weak entropy, reimporting those same words onto patched firmware doesn’t add entropy after the fact. The private key math was already fixed at generation time. You need an entirely new seed.
Is dice-based entropy actually more secure than a hardware RNG?
Not inherently more secure on its own, but combining dice entropy with a device’s internal RNG is stronger than trusting either source alone, because an attacker would need to defeat both independently. That combined approach is exactly what SeedSigner and Krux implement in their dice-entropy workflows.
How many confirmations should I wait for before considering a migration transaction final?
One confirmation is a reasonable baseline for smaller amounts. For migrating substantial holdings, waiting for 6 confirmations (roughly an hour under normal network load) is a low-cost way to be confident the transaction won’t be reorganized out of the chain.
Is multisig overkill for a smaller cold storage balance?
For very small amounts, a well-verified single-sig setup with dice entropy and a proper metal backup is reasonable. Multisig adds setup complexity that only pays off once the value at risk justifies the extra operational overhead of coordinating multiple devices.
What’s the fastest way to check if a hardware wallet vendor has an active security advisory?
Go directly to the vendor’s own security or blog page and their GitHub repository’s security advisories tab. Third-party summaries are useful for context but the vendor’s own disclosure is always the authoritative source for affected firmware ranges and remediation steps.
Should I be worried about entropy bugs in software wallets too, not just hardware wallets?
Yes, in principle any wallet software that generates its own seed depends on getting randomness right. Hardware wallets are generally preferred specifically because a dedicated hardware RNG chip is easier to audit than a general-purpose operating system’s entropy pool, but that assumption only holds if the firmware actually uses the hardware RNG correctly, which is precisely what failed in this case.
For further reading, see TRM Labs’ full incident analysis, the Forbes coverage of affected users, the D-Central Bitcoin signing devices reference, Steven Geller’s technical breakdown of the RNG failure, and the official BIP-39 specification for the mnemonic standard referenced throughout this guide.
