COINKITE Blog

COLDCARD Firmware Update 5.6.2 & 1.5.2Q: Verifiable Seed Mixing; Continued Security Review; and EDGE 6.6.1X/6.6.1QX

Fri, 04 Sep 2026 03:30:00 -1200

COLDCARD firmware 5.6.2 for Mk4/Mk5 and 1.5.2Q for Q restore visibility into the device-generated input used during seed creation and add a standalone tool for independently checking dice-roll or coin-flip mixing.

The release also includes changes from our continuing review of transaction validation, USB communications, Virtual Disk handling, firmware upgrades, temporary wallets, Delta Mode, and other security boundaries.

Given the volume of security reports coming to us and appearing across Bitcoin hardware and software projects, our recommendation for the next while is simple: treat every applicable COLDCARD firmware release as a critical update and upgrade promptly.

We strongly recommend that all COLDCARD Mk4, Mk5, and Q users install 5.6.2 for Mk4/Mk5 or 1.5.2Q for Q from our official firmware downloads page.

We are grateful to @drk1wi, @hitechhayekian, @Amiga500, Huzaifa Jawaid, “FreeZ Agent,” “Rety,” @KirillCherikov, @instagibbs, Karma-X, Shiny (@bigshiny0), Mike Rahel (@itooshatonamask), Mars (@Marsmensch), and PortlandHODL for reporting issues, contributing code, reproducing edge cases, sharing ideas, and independently reviewing the remediation. We also thank @danilotg and @spaceainot for post-incident implementation, testing, release, tooling, and disclosure-policy work. Each finding still has to be reproduced and evaluated within its actual scope, but this scrutiny is making COLDCARD stronger.

Thank you for the many messages of support since the fixes shipped. COLDCARDs are in stock, and we’re working to keep up with the increased demand. We appreciate your patience while we get orders out. Development continues: we’ll keep improving the product and releasing new firmware.

We’ll keep publishing concrete, inspectable changes as this work proceeds.

View and Verify Seed Mixing

Every newly generated master seed, Temporary Seed, and generated CCC Key C still requires one user-sourced entropy method:

at least 65 key presses with unpredictable timing;
at least 50 rolls of a physical six-sided die; or
at least 128 physical coin flips.

The standard workflow combines that input with fresh device entropy from the STM32 TRNG, SE1, and SE2.

The new View TRNG Words menu item displays 24 BIP-39 words encoding the full 256-bit device-generated input before the user’s key presses, dice rolls, or coin flips are mixed in. All 256 bits participate in the calculation, including when creating a 12-word wallet. On Q, the 24-word grid begins on a fresh screen so the words remain together.

This restores visibility that existed in the earlier dice-roll workflow but was inadvertently absent from firmware 5.6.1 and 1.5.1Q.

The firmware source now also includes the public-domain, dependency-free verify_seed_mix.py tool. It can independently recompute a final 12- or 24-word seed from the displayed TRNG words and the complete dice-roll or coin-flip sequence. It does not support key-mashing input. This complements rolls.py, first published in October 2020, which performs the corresponding offline calculation for 24-word seeds created through the separate Dice Rolls Only workflow. rolls12.py covers the 12-word variant.

Keep every part of this process secret. Anyone who obtains the resulting seed—or both the displayed TRNG words and your complete dice-roll or coin-flip sequence—can recreate the wallet and steal its funds. Notes, photographs, clipboard contents, terminal history, logs, and backups may retain this information. Run the verification tool only on an offline computer you trust. The safest approach is to use one complete seed-generation run only to prove the math, never fund that wallet, then discard it and start again. Generate new TRNG words and use fresh, unrecorded rolls or flips for your actual master seed.

Explore the interactive, source-linked SeedFlow map by @scgbckbone to trace the complete seed-generation process and inspect the firmware behind each step.

USB Communications

USB ncry v3 adds authenticated encryption with direction-separated keys and replay protection.
The unused USB CDC/VCP serial interface has been removed from normal operation and keyboard-emulation mode.

Transaction Validation and UTXO Handling

COLDCARD warns when a transaction’s block-height nLockTime is more than ten years beyond the Bitcoin height known to the firmware.
The UTXO cache now retains up to 128 entries across restarts.
Cancelled PSBTs no longer commit claimed input amounts to the UTXO cache. Amounts are committed only after signing and only for inputs COLDCARD actually signed.
Single-signature SegWit change amounts are cached during finalization so understated input amounts can be detected instead of silently trusted.
Duplicate singleton keys in PSBT maps are rejected.
BIP-322 Proof of Reserves rejects foreign inputs, including inputs disguised with forged key-path metadata or partial signatures.
P2SH-P2WSH inputs with missing or incorrect redeem scripts are rejected instead of proceeding with an unknown fee.
PSBTv2 transactions with out-of-range transaction versions are rejected, matching the PSBTv0 parser.
On Mk4/Mk5, BIP-322 message signing with WIF Store keys requires an unrestricted HSM message-signing policy.

Firmware and Virtual Disk Boundaries

Signing stops if a Virtual Disk firmware import overwrites the reviewed PSBT. Thanks to Huzaifa Jawaid.
A pending firmware upgrade is cancelled if its staged image is overwritten before approval. Thanks to Huzaifa Jawaid.
Cyclic FAT chains in Virtual Disk imports are rejected instead of causing the device to hang.
Virtual Disk files with FAT metadata inconsistent with their declared size are rejected. This fixes an integer underflow in psram_copy_file and psram_mmap_file that could permit out-of-bounds PSRAM writes, reads, or mappings from a compromised USB host.
Firmware images extending beyond the world-checksum-covered flash region are rejected.

Wallet-State and Policy Boundaries

With an empty master wallet and an active Temporary Seed, imports and backup restores remain temporary instead of becoming master-wallet changes.
Change Main PIN is hidden while a Temporary Seed or BIP-39 passphrase wallet is active.
In Delta Mode, attempting to view or activate a duress-wallet secret from the Trick PINs menu wipes the seed instead of revealing it.
Non-ASCII BIP-39 passphrases are rejected at USB, saved-passphrase, note, and password entry points instead of deriving wallets incompatible with BIP-39-normalizing software.
Single-Signer Spending Policy now provides a block-height reset from the Last Violation screen after a policy bypass, matching CCC behavior.

Simulator Fix

The COLDCARD simulator no longer crashes during Bless Firmware because of a desynchronized LED pipe, and it now records its firmware-greenlight state correctly.

This is a developer-tooling fix and does not change the security behavior of a physical COLDCARD. Thanks to @hitechhayekian for the report and fix.

Important Seed Reminder

Installing this update does not make an existing vulnerable seed safe.

If your seed may have been generated on affected firmware from 2021 through July 2026, create a completely new seed using fixed firmware and move your funds by following our seed-generation advisory.

The July 31 firmware corrected the seed-generation failure for new seeds. The August 20 release added required user-sourced entropy and further hardening. This release adds verification and additional security work, but it does not change the migration guidance for seeds already generated on affected firmware.

Upgrading alone is not sufficient.

Our team remains heads down reviewing security reports and helping affected users upgrade, create new seeds, and complete their migrations. Support and other contact channels are handling unusually high volumes, so responses may take longer than usual.

Verified guidance remains available on the Security Status page.

How to Update

Download firmware only from the official COLDCARD downloads page.
Follow our instructions to verify the SHA-256 hash and PGP signature.
Install it using the MicroSD upgrade procedure.
After restarting, select Advanced > Upgrade > Show Version.
Confirm that the device reports 5.6.2 on Mk4/Mk5 or 1.5.2Q on Q.
If the July seed advisory applies to you, complete the separate seed migration. Upgrading alone is not sufficient.

The complete standard-release list is available in the firmware changelog.

Security reports can be submitted privately to security@coinkite.com under our responsible-disclosure policy. Customers who need assistance should contact our support team.

EDGE 6.6.1X and 6.6.1QX — August 31, 2026

We also released EDGE 6.6.1X for Mk4 and 6.6.1QX for Q.

EDGE is a separate preview track. It has not been qualified and tested to the same standard as normal releases and is recommended only for developers and early adopters doing experimental work.

These builds are synchronized with the standard release lines through 5.6.1 and 1.5.1Q. Their shared changes include:

Reject cyclic FAT chains during Virtual Disk imports instead of hanging.
Abort a pending firmware upgrade if its staged image is overwritten before approval. Thanks to Huzaifa Jawaid.
Detect and abort signing if a Virtual Disk firmware import overwrites the reviewed PSBT. Thanks to Huzaifa Jawaid.
Allow uncompressed WIF keys in WIF Store.
Speed up multisig address generation and PSBT-input verification.
Use predictable sequential filenames when PSBTs are repeatedly processed through MicroSD or Virtual Disk.
Prevent USB hosts from enrolling, deleting, listing, or exporting Multisig or Miniscript wallet configurations while Spending Policy mode is active.
Compact repeated transaction warnings, relative timelocks, and unusual change-path summaries. Individual details remain available in the transaction explorer.
Generate distinct MuSig2 nonces for different aggregate-key derivations of the same participant set.
Harden MuSig2 session handling for foreign MuSig2 inputs and differing witness UTXO data.
Preserve incomplete MuSig2 sessions while waiting for cosigner public nonces.
Prevent PSBT corruption when the same MuSig2 participant performs multiple signing rounds through Key Teleport.
Track remaining multisig and Tapscript signers separately for each PSBT input.
Limit MuSig2 participant lists to 32.
Generate unique names for multisig wallets created from PSBTs with identical M-of-N parameters.
Correctly identify consolidations containing zero-value OP_RETURN outputs without misclassifying other zero-value external outputs.
Prevent duplicate WIF Store keys and multisig wallets after restart.
Require HSM policies to explicitly allow a path before signing BIP-322 messages with WIF Store keys.
Reject foreign inputs in BIP-322 Proof of Reserves transactions.
Prevent PSBT uploads from being mistaken for partial firmware uploads.
Reject BIP-388 wallet-policy imports with non-ASCII or non-printable names.
Reject duplicate singleton keys in PSBT maps.
Restore View TRNG Words for the complete 256-bit device-generated input before user entropy is mixed.
Fix the Bless Firmware simulator crash. Thanks to @hitechhayekian.
Fix invalid signatures on transactions containing both SegWit v0 and Taproot inputs.
Hide Change Main PIN while a Temporary Seed or BIP-39 passphrase wallet is active.
Keep imports and backup restores temporary when the master wallet is empty and a Temporary Seed is active.
Do not misidentify future-version SegWit outputs as Taproot change.
Reject unsupported Taproot leaf versions during PSBT signing. Only Tapscript 0xc0 is supported.
Serialize future even TapLeaf versions correctly.
Report the correct transaction ID when finalized MuSig transactions contain scriptSigs.
Remove the unused USB CDC/VCP serial interface from normal operation and keyboard emulation.

See the complete tagged EDGE changelog and verify the firmware through the official downloads page before installing.

COLDCARD + Sparrow: Air-Gapped from First Address to First Signature

Mon, 24 Aug 2026 00:03:59 -1200

Sparrow and COLDCARD should have different jobs.

Sparrow runs on the computer, watches the blockchain, tracks wallet history, chooses coins, creates transactions, and broadcasts. In this workflow, COLDCARD holds the signing key, interprets the proposed transaction on its own screen, and signs after physical approval.

The air-gapped workflow connects those jobs without a live data cable:

export public wallet data from COLDCARD;
import it into Sparrow as watch-only;
verify a receive address on both devices;
let Sparrow build a PSBT;
move it to COLDCARD by Q QR or Mk5 MicroSD;
return the signature to Sparrow and broadcast.

With official COLDCARD firmware, the standard wallet export contains public wallet data and does not include the seed or private keys. This limits the computer’s role, but it does not make the computer, transfer medium, or signing device risk-free.

Versions current at publication

Menus and buttons change. At publication, the current releases were:

COLDCARD Q standard firmware 1.5.1Q;
COLDCARD Mk5 standard firmware 5.6.1;
Sparrow Wallet 2.5.3.

Check the COLDCARD Security Status page, install and verify the current signed COLDCARD firmware, and check Sparrow releases before starting. Download Sparrow only from sparrowwallet.com or its linked official repository, and verify the download according to Sparrow’s instructions.

This article covers a standard single-signature wallet. Multisig uses the same PSBT concept but requires the complete policy and enough cosigners to meet the threshold.

What this workflow changes—and what it does not

QR and MicroSD signing avoid a live data connection between COLDCARD and the computer. They do not make either device trusted, verify firmware for you, protect an exposed backup, or prevent every attack. This article describes the intended workflow, not a guarantee against every software, firmware, supply-chain, backup, or operator failure. Install only signed firmware from the official download page, keep the device under your control, and approve a transaction only after its recipient, amount, fee, change, and warnings match your intent on the COLDCARD screen.

If the wallet seed was created on firmware covered by the July 2026 advisory, updating the device alone does not repair it. Follow the affected-seed migration guide before relying on this setup for that wallet.

Prepare COLDCARD first

Complete the current Q or Mk5 setup:

inspect the tamper-evident bag;
set the PIN and learn the anti-phishing-word check;
install and verify current signed firmware before creating a seed;
generate or import the intended seed;
make and test the required backups;
record the expected extended fingerprint.

Current standard firmware combines fresh device entropy with one required user method for every new seed: at least 65 key presses with unpredictable timing, 50 private rolls of a fair physical six-sided die, or 128 private physical coin flips. Dice Rolls Only remains a separate advanced workflow.

Before funding a wallet with an amount whose loss would be materially harmful to you, apply a strong, unique BIP-39 passphrase after verifying the base-seed backup. Back up the passphrase exactly and separately, record the passphrase wallet’s fingerprint, and test the complete recovery path before depositing funds. Additional complexity can create recovery risk; use multisig only with a documented and tested policy.

Never type the seed words or BIP-39 passphrase into Sparrow for this watch-only workflow. Do not provide Coinkite support with them, your PIN, backup password, private keys, or dice-roll sequence.

If the wallet uses a BIP-39 passphrase, apply it on COLDCARD before exporting to Sparrow.

Under official firmware, the export describes the wallet that is active at that moment. The base seed and each passphrase have different keys, fingerprints, addresses, and balances. Sparrow needs a separate watch-only wallet for each.

Confirm the active fingerprint at:

Advanced/Tools > View Identity

Do not proceed if it is not the one recorded for this wallet.

Export the Sparrow wallet from COLDCARD

On Q or Mk5 open:

Advanced/Tools > Export Wallet > Sparrow

Read the export notice and use account 0 for a standard first wallet. Use another account only if your wallet plan already specifies it.

MicroSD export

Insert a FAT-formatted MicroSD card.
Choose MicroSD as the export method.
COLDCARD writes a coldcard-….json file to the card’s root.
Eject the card and insert it into the computer.

Q QR export

Choose Show QR.
Q displays the export as animated BBQr when needed.
Keep the code ready for Sparrow’s Scan option.

With official firmware, the Sparrow export contains the extended public key, derivation path, address type, and related public wallet data. It does not include the seed or private keys.

“Public key” does not mean “publish it.” An extended public key or descriptor can reveal present and future wallet addresses, balances, and transaction relationships. Handle the export as private financial metadata.

Import as an air-gapped hardware wallet

In Sparrow:

choose File > New Wallet;
give the wallet a recognizable name;
select Airgapped Hardware Wallet;
find COLDCARD in the hardware-wallet list;
choose Import File for MicroSD or Scan for Q QR;
load the JSON file or scan the complete BBQr sequence;
inspect the populated keystore and wallet settings;
click Apply.

Sparrow saves a watch-only wallet and begins synchronizing its addresses.

The computer can now generate receive addresses and build spends. A correctly created watch-only wallet cannot produce the COLDCARD signature. If Sparrow can spend without the device in this arrangement, stop and determine what private material was imported.

Verify the first receive address

This is the setup step that turns “the import seemed to work” into a concrete check.

In Sparrow:

open Receive;
select the first receive address at index 0;
keep the complete address visible.

On COLDCARD:

open Address Explorer from the main wallet menu;
choose the matching address type;
select receive index 0;
compare every character with Sparrow.

If they differ, do not receive bitcoin. Common causes are the wrong passphrase state, address type, account number, derivation, or export file. Correct the cause and re-export rather than trying to make one screen resemble the other.

After a match, receive a small practice amount. Label it in Sparrow and wait until it is available to spend.

Q path: sign the first PSBT over QR

Q performs the entire round trip through the two screens.

Build in Sparrow

Open Send.
Enter the destination, amount, and fee rate.
Click Create Transaction.
Review the proposed inputs, outputs, and fee.
Click Finalize Transaction for Signing.
Click Show QR.

Sparrow displays a single QR for a small PSBT or animated BBQr for a larger one.

Review and sign on Q

Press Q’s QR key to start the camera.
Hold Q in front of Sparrow’s code until every frame is captured.
Read the transaction on Q.
Compare the complete recipient address, amount, network fee, and change with your intended payment.
Stop on any unexpected warning.
Press ENTER only when the on-device transaction is correct.

Q signs and displays the result as QR or BBQr.

Return to Sparrow

Click Scan QR in Sparrow.
Present Q’s screen to the computer’s webcam until the signed result loads.
Review the complete transaction again.
Click Broadcast Transaction.

If scanning fails, do not take a photograph and send it through a random service. Improve the light, steady the devices, retry the BBQr sequence, or use MicroSD as the fallback.

Mk5 path: sign the first PSBT with MicroSD

Mk5 has no camera for inbound QR, so MicroSD is the standard round trip.

Build and save in Sparrow

Open Send.
Enter the destination, amount, and fee rate.
Click Create Transaction.
Review and click Finalize Transaction for Signing.
Click Save PSBT.
Save the .psbt file in the root of the MicroSD card.
Eject the card cleanly.

Review and sign on Mk5

Insert the card into Mk5.
Select Ready To Sign.
Choose the intended PSBT if more than one is listed.
Compare the recipient, amount, fee, and change on the Mk5 screen.
Stop on an unfamiliar warning or wrong-wallet fingerprint.
Press ✔ only after the details match your intent.

Mk5 writes [original]-signed.psbt and, for supported complete transactions, a ready-to-broadcast .txn file to the card.

Return to Sparrow

Move the MicroSD card back to the computer.
In Sparrow select Load PSBT.
Open the signed PSBT or .txn.
Review the result.
Click Broadcast Transaction.

The card is a transport medium, not a trusted display. Malware may alter files on it. Base approval on what Mk5 parsed and showed, not on the file name or the computer screen.

What Sparrow learns

This workflow removes the live data connection between COLDCARD and the computer. It does not make the watch-only wallet anonymous or make the coordinator, transfer medium, or signer automatically trustworthy.

Sparrow knows the wallet descriptor and can derive its addresses. It sees the transactions it discovers and the labels you add. If it connects to a public Electrum server, that server may observe the addresses and transactions being queried together.

For better privacy, connect Sparrow to your own Bitcoin node, ideally over Tor. That changes who receives the wallet queries. It does not erase information already disclosed to a public server, exchange, block explorer, or reused address.

Keep Sparrow’s wallet file, COLDCARD export, and labels out of general cloud storage unless that disclosure is intentional.

Troubleshooting by symptom

Addresses do not match

Check the passphrase state, active XFP, account number, address type, and whether Sparrow imported the correct file. Re-export only after the intended wallet is active.

COLDCARD reports wrong XFP

The PSBT was prepared for another wallet. Open the Sparrow wallet created from this COLDCARD and passphrase context, or activate the expected wallet on COLDCARD. Do not override the mismatch.

COLDCARD warns about change

Inspect the change address and derivation. If you cannot explain why COLDCARD does not recognize it, cancel and rebuild the transaction.

Sparrow cannot see the signed file

Eject and reinsert the MicroSD card, then load [original]-signed.psbt or the .txn file. Do not accidentally reload the unsigned original.

The repeatable routine

The routine is short once the setup is correct:

Receive: Sparrow address → verify on COLDCARD → receive.

Spend with Q: Sparrow PSBT QR → Q review and signature → Sparrow scan → broadcast.

Spend with Mk5: Sparrow PSBT on MicroSD → Mk5 review and signature → Sparrow load → broadcast.

Sparrow may remain online, and the transfer medium should be treated as untrusted. In the intended workflow, the signing key remains on COLDCARD. Authorize the payment only after the on-device transaction details match your intent.

Use the current COLDCARD and Sparrow setup, Q QR signing, and MicroSD signing guides for current screens and troubleshooting. Check the Security Status page for current firmware and migration guidance.

Get COLDCARD Q or Mk5

COLDCARD Security Update: Seed Generation, Transaction Integrity, and Data Isolation

Thu, 20 Aug 2026 00:00:00 -1200

Three weeks ago, we disclosed a firmware bug that caused weakened seed generation. Attackers regenerated the corresponding private keys offline and stole funds. The COLDCARD devices themselves were not hacked, remotely accessed, or taken over. This release reflects three weeks of sustained review since our July 31 hotfix — including AI-assisted review by Kimi and other frontier models — not just the RNG path, but the whole system.

This update covers what we found, what we fixed, and what customers need to do.

Immediately, we strongly recommend that all COLDCARD Mk4, Mk5, and Q users upgrade to firmware 5.6.1 for Mk4/Mk5 and 1.5.1Q for Q from our official firmware downloads page.

We are grateful to the security researchers who went above and beyond over the past weeks, reporting issues, reproducing edge cases, and reviewing our fixes. Their work put this firmware under intense, sustained scrutiny and made this release stronger.

Law enforcement authorities continue investigating the thefts and are working to identify those responsible. We remain available to assist, and authorities are keeping us informed of material developments.

We’ll keep publishing concrete, inspectable changes as this work proceeds, and we remain committed to supporting every customer working through their migration until it’s done.

What This Release Includes

This release includes improvements unrelated to the original RNG issue, including policy changes to seed generation, transaction review, USB data handling, firmware-update validation, Delta Mode hardening, and wallet backups.

We’re publishing the major security and correctness changes here, including changes unrelated to the original bug.

Important seed reminder: Installing this update does not make an existing vulnerable seed safe. If your seed may have been generated on affected firmware from 2021 through July 2026, create a new seed using fixed firmware and move your funds by following our seed-generation advisory.

The July 31 firmware corrected the seed-generation failure for new seeds. This release gives affected customers a more thoroughly reviewed foundation to generate replacement seeds and complete their migration. It does not change the migration guidance for seeds already generated on affected firmware.

Our team remains heads down helping affected users complete their migrations. Support and other contact channels are handling unusually high volumes, so responses may take longer than usual. We appreciate your patience and will continue publishing verified guidance on the Security Status page.

Seed Generation and Defense in Depth

Every newly generated seed now requires one user-sourced entropy method: at least 65 key presses with unpredictable timing, 50 rolls of a physical six-sided die, or 128 physical coin flips. The same requirement applies to generated Temporary Seeds and generated CCC Key C. The standard workflow combines that input with fresh device entropy from all sources available to us: SE1, SE2, and TRNG. The backup PRNG generator now uses SHA-256 Hash_DRBG instead of Yasmarang.

At boot, it is initialized from the STM32 TRNG and reseeded with a full 256-bit digest from SE1 and SE2; its output is also mixed with fresh STM32 TRNG words. For each new seed, firmware combines 32 bytes from the generator, 32 fresh bytes from SE1, and 8 fresh bytes from SE2, then applies double SHA-256 before mixing the required user input with versioned method and purpose identifiers.

Explore the interactive seed-generation flow.

Dice Rolls Only remains a separate advanced option: it excludes all hardware-generated randomness and requires 50 rolls for 12 words or 99 rolls for 24 words. Keep every input and any final hash shown by the device private.

Seed-entry handling was also tightened: holding a key no longer counts as repeated dice rolls.

For a wallet intended to hold a meaningful balance, we recommend the standard Dice Rolls option executed honestly with genuine rolls, a strong and unique BIP-39 passphrase, and, where appropriate, a carefully designed multisig setup suited to your threat model.

These protections do not make an already vulnerable seed safe and do not replace moving funds to a newly generated seed.

Active-Wallet Display and Backup Behavior

When a BIP-39 passphrase wallet is active, View Seed Words now shows the effective extended private key instead of the parent seed words.
Backup System, Clone Coldcard, and Key Teleport’s Full COLDCARD Backup now capture the wallet currently in effect, including a Temporary Seed or passphrase wallet, and warn before export.
For a passphrase wallet, the backup contains the effective XPRV. It does not contain the parent seed words or the passphrase. Review the backup documentation before relying on a new backup, and retain the recovery material needed for your intended wallet structure.

Transaction Approval and Signing

COLDCARD now re-verifies a staged PSBT immediately before signing. If a connected host changes the transaction after it was reviewed on the device, signing stops and COLDCARD displays Transaction modified. This fixes a theoretical vulnerability if your computer’s USB port was compromised and COLDCARD is connected during the signing process.
SIGHASH_SINGLE and SIGHASH_SINGLE|ANYONECANPAY are now blocked by default because later transaction outputs can remain modifiable. Advanced users who require these modes can set Sighash Checks to Warn.

USB Data and Firmware-Update Boundaries

USB downloads are now limited to the most recent result produced by the device, require an encrypted session, and are invalidated by new uploads, transactions, or sessions.
Additional bounds checks reject integer wraparound and out-of-range access at the firmware call boundary. The SE1 check value now uses a nonce range separate from encrypted secret data.

Delta Mode Hardening

Delta Mode now blocks Seed Vault access through Seed XOR, Key Teleport, CCC Key C import, and BIP-85.
Listing saved BIP-39 passphrases in Delta Mode no longer exposes seed-derived wallet details.
Seed-derived message signatures are no longer valid when using a Delta Mode PIN.

Integrated TRNG Self-Test

We made the hardware TRNG path itself more robust against some internal error states and compilation errors:

Firmware now checks hardware RNG seed-error state, output readiness, and zero-word conditions. It retries a bounded number of times and stops on obvious faults. After clearing a recoverable seed-error condition, firmware discards the next 12 hardware words as required by the STM32 recovery procedure before using new output.
At boot, firmware checks that the exact rng_get() function used by the running build enters the intended hardware RNG read path. If that check fails, the device stops before normal operation.

These controls verify specific source and failure boundaries. Passing the boot-time check confirms that the running build’s rng_get() call reached the intended hardware-read path during the self-test. It does not independently prove the quality of every output or every entropy source, and it should not be read as a claim that finite testing can prove arbitrary randomness.

Compatibility and Correctness

BIP-322 message signing rejects unsupported text before approval, including non-ASCII text and ambiguous whitespace cases.
WIF Store no longer creates duplicate entries after restart.
Short PSBT uploads are no longer mistaken for firmware. Multisig enrollment rejects duplicate or device-owned keys. Clone restore now confirms the seed fingerprint. Backup restore is capped, PSRAM is cleared on seed wipe, and multisig names must be unique.
On Q, BBQr rejects malformed or oversized imports, and BIP-21 fields are sanitized. Locally entered passphrases must be scrolled before reveal.
Send Password remains available as an explicitly approved emulated-keyboard action when the general USB data protocol is disabled.

Thanks to External Contributors

“FreeZ Agent” reported the staged-PSBT issue, “Rety” reported the Seed XOR issue, and Peter Todd shared ideas on inter-key timing entropy.

New COLDCARD Security Status Page

We’ve launched a new public COLDCARD Security Status page. This is the place to check the current fixed-release matrix, migration guidance, independent-validation evidence and its stated limits, and verified incident updates. It also provides machine-readable status, and we’ll keep it updated as verified information changes.

Our Security & Transparency hub connects that live status page with the advisory, disclosure history, firmware-verification resources, private reporting instructions, and related public records.

How to Update

Download firmware only from the official COLDCARD downloads page.
Follow our instructions to verify the SHA-256 hash and PGP signature.
Install it using the MicroSD upgrade procedure.
After restart, select Advanced > Upgrade > Show Version and confirm that your device reports 5.6.1 on Mk4/Mk5 or 1.5.1Q on Q.
If the July seed advisory applies to you, complete the separate seed migration. Upgrading alone is not sufficient.

Full technical notes, affected-version information, source links, and researcher acknowledgements are available in our firmware release notes.

Security reports can be submitted privately to security@coinkite.com under our responsible-disclosure policy. The firmware repository now also publishes private reporting guidance in SECURITY.md. Customers who need assistance should contact our support team.

Update on Customer Data Retention

Fri, 07 Aug 2026 00:54:54 -1200

We want to inform our customers of a change to our data-handling practices in connection with the security incident disclosed on July 30, 2026.

As many of you know, our standard practice has been to automatically blank customer records after 120 days, retaining only email addresses and country of residence. We have also offered customers the option to request accelerated blanking at any time after delivery.

Due to legal obligations arising from the security incident, including the preservation of records that may be relevant to ongoing and anticipated legal proceedings, we have temporarily suspended our automated data-blanking process. This means that customer records that would otherwise have been blanked under our standard schedule will be retained until further notice.

However, if you would like us to apply our existing retention policies to your data, we will exempt them from this protocol. Please confirm that you do not want us to preserve your data by using our support form.

We understand that this is a departure from our published practices and that our customers value the privacy protections we have committed to. We want to be transparent about why this change has been made. We are required by law to preserve records that may be relevant to legal proceedings. This obligation applies regardless of our internal data-retention policies and overrides our standard deletion schedule.

During this period, all retained customer data will be stored securely and access will be restricted to authorized personnel. Retained data will not be used for any purpose other than compliance with legal obligations. We will resume our standard data-blanking practices as soon as we are legally permitted to do so.

If you have questions about this change, please use our support form.

Adding to the Public Record on Our Ongoing Investigation

Tue, 04 Aug 2026 08:02:40 -1200

What Happened, in Simple Terms

There was no intentional weak-entropy fallback. It is important to be precise about what happened.

Yasmarang was MicroPython’s built-in general-purpose PRNG, introduced upstream in May 2018. It did not become part of COLDCARD’s seed-generation path until the libNgU migration in March 2021. Most language runtimes include a non-cryptographic PRNG for general-purpose tasks. Its presence was not itself unusual.

COLDCARD was designed to rely exclusively on its hardware TRNG for seed generation, with no software fallback. Setting MICROPY_HW_ENABLE_RNG=0 was intended to disable the software path. A build and link integration error meant that setting did not have the intended effect, and libNgU’s rng_get() symbol resolved to MicroPython’s default Yasmarang implementation instead.

The hardware TRNG did not fail and trigger a weaker fallback at runtime. This was inherited platform behavior activated by a link-time error, not an intentional seed-generation design decision or shortcut. This distinction does not change the risk or migration guidance for affected seeds.

The COLDCARD devices themselves were not hacked, remotely accessed, or taken over. A firmware bug in affected releases caused weakened seed generation. Attackers exploited those weak seeds offline by regenerating the corresponding private keys and stealing funds.

We understand there is real anger at this moment. Users have suffered real losses, and for those impacted, no public statement is enough.

We continue to support affected customers directly and urge others to reach out to any other users they are aware of who may be affected. Urgently: if your seed was generated with our affected firmware, without at least 50 independent, private dice rolls, and your funds aren’t protected by a strong, unique BIP-39 passphrase, move those funds to a new wallet now.

We also believe this vulnerability is a warning for every company building Bitcoin hardware and software, not only us—and we’re publishing this now, while the details are still fresh, because other companies need time to check their own code to prevent potential further loss.

To support that effort, we’ve published a new resource: coinkite.com/historical-disclosures, a page that records all known public security research, coordinated disclosures, professional reviews, internal findings, and security advisories affecting COLDCARD devices.

We’re publishing it because researchers, journalists, and security teams doing their own review need a definitive record to work from. We’ll keep this updated as the investigation continues.

Where This Bug Lived

As independent researchers have publicly corroborated, this firmware bug appears to have lived at a boundary between two unrelated submodules, not in the parent code, and not in the cryptographic or Bitcoin-specific logic that are the subject of most internal and third-party reviews.

Because the flag check looked correct, the bug silently went unnoticed, and its potential impact grew with every release.

We believe it’s important for the broader ecosystem to understand how this bug arose, and why it evaded detection, so they can avoid similar consequences.

What AI-Assisted Review Did, and Didn’t, Catch

We know there are questions about our own use of AI in code review. We’ll cover this fully in our post-mortem, but given the active investigation right now, here’s what we can say immediately.

We’ve run AI-assisted review against our critical codebases, including in the weeks before the exploit. It did not catch this vulnerability. Since the incident, we’ve also tested our code against frontier models, including Kimi K3, Claude Fable, and Codex 5.6. None of them caught it.

It’s a reason for us, and anyone else relying on AI tools, to be specific about what they currently catch and what they might not.

What We’re Asking Other Teams to Do

We remain committed to sharing what we learn as our own review process continues. If your team relies on AI review of security-critical code, we recommend you test it specifically against build and submodule boundaries.

As a result of these new and powerful AI models, we believe many Bitcoin projects, including those that rely on open-source code, require immediate review.

We’re addressing what we can, we’re supporting the people directly affected, and publishing everything we know.

Update, Sunday.

Sun, 02 Aug 2026 11:00:19 -1200

The last three days have been some of the hardest in this company’s history, and for a lot of the people reading this, they’ve been something much worse. Money that took years to save, gone. Trust that took years to build, broken. That impact is real, and for some, the damage is permanent. Some are asking hard questions about our company. We are, too.

Our work won’t stop in the weeks ahead. It is just beginning.

Since Friday, our team has been reaching out and working directly with customers, helping move funds that were still safe to move, walking through recovery options together, and staying reachable for anyone who wrote in not knowing where they stood. We acknowledge that others in the community did the same, selflessly, and without compensation. We thank them sincerely.

We’ve also been in direct contact with the wider hardware wallet and self-custody community, including other builders, researchers, and people who’ve thought hard about this kind of failure. All have graciously offered whatever resources they could spare. We are still engaged in this outreach and are committing to work with the broader industry going forward.

If you have an affected device, please do not dispose of it. It may become essential if funds are recovered. Our legal team will coordinate as warranted with law enforcement across multiple jurisdictions to support efforts in identifying those responsible.

We destroyed our remaining COLDCARD inventory manufactured with the vulnerable firmware, and shipment was halted when the vulnerability was confirmed. SATSCARD, OPENDIME, and TAPSIGNER are not affected by this issue.

Our patched firmware prevents this issue from affecting any new seed generated going forward. It does not repair or restore security to a seed that was already generated on vulnerable firmware. A new seed must be created, and funds moved to it to be secure.

If you need a device sooner than we can provide one, or want an alternative while you decide next steps, Bitkey, Ledger, Trezor, Jade, and BitBox are reputable options. For collaborative custody, AnchorWatch, Casa, Unchained, Nunchuk, and Liana are worthy of consideration.

We continue to read everything—the replies, the texts, the emails. Some of it we owe direct answers to. We’ll follow up on that specifically and soon.

There are real lessons here for us as a company. We owe the community better, and we’re beginning to understand the many ways in which our best efforts and designs could have allowed for this to happen. We’ll show that in our technical postmortem, as soon as it is possible to do so.

For now, please continue to refer to the COLDCARD Security Advisory for the best available information. Please continue to reach out to friends, family, and loved ones who may be affected. Time is of the essence. The threat remains real and ongoing.

Technical Deep Dive into the Entropy Issue

Thu, 30 Jul 2026 00:00:00 -1200

What Happened, in Simple Terms

There was no intentional weak-entropy fallback. It is important to be precise about what happened.

Updated August 1, 2026 at 2:35 p.m. EDT: Funds controlled by seeds generated on affected firmware are at risk if the seed was created without at least 50 independent, private dice rolls and the funded wallet is not protected by a strong, unique BIP-39 passphrase.

Fixed firmware is now available for every affected model and release track, including Edge firmware versions 6.6.0X for Mk4/Mk5 and 6.6.0QX for Q.

What You Should Do

The passphrase must be strong, unique, secret, and separate from the seed backup. A short, common, patterned, quoted, reused, exposed, or uncertain passphrase does not qualify; treat those funds as at risk. Even when a strong passphrase reduces the immediate exposure, it does not repair an affected seed. Unless the independent dice-entropy exception applies, replace the seed and migrate as soon as practical.

If your seed was generated on a Mk2 or Mk3 running firmware 4.0.1 through 4.1.9 without at least 50 independent, private dice rolls:

Update the Mk2 or Mk3 to firmware version 4.2.0 or later before generating a replacement seed.
Generate a completely new seed on the updated COLDCARD.
Record and verify the new backup, wallet fingerprint, and a receive address.
Send a small test transaction before moving the remaining funds.
Keep the old backup until the migration is complete and confirmed.

Follow the dedicated Mk2/Mk3 Security Advisory and migration instructions. Proceed calmly and verify every step.

If you added at least 50 fair, independent, private dice rolls when originally creating the seed, read the dice guidance in the advisory before migrating. We do not consider that seed at risk from this RNG issue alone.

If your seed was generated on affected Mk4, Mk5, or Q firmware without at least 50 independent, private dice rolls:

Upgrade to the fixed firmware for the release track you use before generating any new seed:
- Standard: version 5.6.0 or later for Mk4/Mk5, or version 1.5.0Q or later for Q
- Edge: version 6.6.0X or later for Mk4/Mk5, or version 6.6.0QX or later for Q
Generate a completely new seed on the updated COLDCARD.
The fixed firmware’s device-generated seed is sufficient. Dice rolls are optional and are not required to address this issue. A BIP-39 passphrase is a separate wallet-security choice.
Back up the new seed and any passphrase carefully. Store the passphrase separately from the seed words.
Power-cycle the COLDCARD and verify the wallet fingerprint and a receive address.
Send a small test transaction before moving the remaining funds.

Updating the firmware does not repair a seed that was generated by affected firmware. A new seed must be generated and the funds migrated to the new wallet.

Standard and Edge are separate release tracks. If you use Edge, install the fixed Edge release for your model. Do not assume an older Edge 6.x release is fixed merely because its version number is higher than the standard release.

A passphrase creates a different wallet. Every passphrase—including one containing a typo—produces a valid wallet, so verify the wallet fingerprint before depositing funds. Losing the passphrase means losing access to that wallet.

Read the COLDCARD passphrase instructions and dice-roll instructions before using either option.

TAPSIGNER, OPENDIME, and SATSCARD are not affected because they use different codebases.

Summary

A complex and subtle series of bugs prevented the hardware RNG from contributing randomness in certain versions of the firmware. We were unaware of the bug until today. Changes introduced for Mk4 added entropy from SE1 and SE2, which partially reduced the impact on later models but did not restore the intended 128-bit security target.

The COLDCARD source code has always been open and publicly available, so we have to assume that someone used AI to review previous versions of our firmware and stumbled upon this issue. A few weeks ago, we used one of the best available AI models to review our code for security issues, and it did not find this bug or anything serious.

Both attackers and defenders have the same AI tools, but today it did not help us, and only helped the bad guys.

For funded wallets with neither the independent dice entropy nor a strong, unique BIP-39 passphrase described above, the reduced search space is a direct security risk, not a theoretical possibility.

Technical Background

In 2021, we moved COLDCARD’s elliptic-curve operations to Bitcoin Core’s libsecp256k1, using the same implementation trusted by Bitcoin Core instead of maintaining a separate EC stack. That required adding libNgU, an embedded MicroPython library that exposes libsecp256k1 and other Bitcoin primitives.

The cryptographic choice was sound. The integration was not. During that migration, wallet seed generation moved from ckcc.rng_bytes() to ngu.random.bytes(). That path resolved rng_get() to MicroPython’s software fallback instead of COLDCARD’s hardware RNG implementation.

The bulk of randomness on the COLDCARD was coming from a PRNG that I didn’t know was actually in the source code base (it is from a submodule, Micropython). At the same time the carefully crafted TRNG code I wrote was being used, but just by chance, and only for less important things.

On Mk2 and Mk3, the active PRNG was seeded primarily from device and timing state. Under our current attack assumptions, we estimate the effective search space at about 40 bits. This is a preliminary estimate and may change as analysis continues.

During Mk4 development, we also mixed values from the TRNGs in SE1 and SE2 into the PRNG state as a backup to a backup. This additional entropy materially improves the situation for Mk4, Q and Mk5. Under the same current assumptions, we estimate the effective search space at about 72 bits.

Although Mk4, Q and Mk5 had additional secure-element entropy mixed into the PRNG state, they continued to draw most subsequent random values from the same MicroPython PRNG:

micropython/ports/stm32/rng.c

That file either builds PRNG code, or uses the STM32 hardware TRNG. Looking quickly at it, you’d think we got the TRNG version of get_rng() but in fact, I explicitly set MICROPY_HW_ENABLE_RNG to zero, thinking we didn’t need either version, but that’s not what it does. Because that code provided a PRNG with the same function signature as the desired code, the build completed without identifying the wrong implementation.

The MicroPython fallback was introduced upstream in May 2018. It did not enter COLDCARD wallet seed generation until the libNgU migration in March 2021. The affected Mk2 and Mk3 firmware range is 4.0.1 through 4.1.9. Version 4.2.0 corrects new seed generation. The eight-year figure therefore describes the age of the upstream fallback code, not the duration of affected COLDCARD seed generation.

Existing review confirmed that the intended TRNG implementation was present in the firmware binary, but did not verify which rng_get() implementation the wallet seed-generation path actually reached across the two submodules. No changes are needed in the COLDCARD firmware itself, just which code comes along for the ride.

Why Existing Review Did Not Catch It

Both RNG implementations had the same function signature, and the intended board-specific TRNG code was present in the binary. Existing review verified that code but did not verify end-to-end symbol resolution and call reachability from wallet seed generation.

The relevant preprocessor guard is visible in this section of code:

random.c:22-31

The guard used #ifndef, which tests whether MICROPY_HW_ENABLE_RNG is defined, rather than whether its value is nonzero. We defined that macro as zero, so the #error did not stop the build.

The hotfix now explicitly excludes MicroPython’s fallback PRNG object and adds a build-time RNG symbol check. The build fails unless the board-specific object defines the global rng_get() symbol and the upstream fallback object defines no symbols.

Next Steps

We have released emergency hotfixes for every affected model and release track:

These hotfixes correct entropy generation. Updating does not repair seeds that were generated by earlier affected firmware; those seeds must still be replaced unless the independent dice-entropy exception applies.

At this point, many researchers and competitors have studied this bug and published their own analysis:

Download the latest firmware

Coldcard Security Advisory

Thu, 30 Jul 2026 00:00:00 -1200

Fixed firmware is now available for every affected model and release track:

Mk2/Mk3: version 4.2.0 or later
Mk4/Mk5 standard: version 5.6.0 or later
Q standard: version 1.5.0Q or later
Mk4/Mk5 Edge: version 6.6.0X or later
Q Edge: version 6.6.0QX or later

Do not generate a new seed on any of these models until the update is installed.

Funds controlled by a seed generated on Mk2 or Mk3 version 4.0.1 (March 2021) through 4.1.9 inclusive are at risk if the seed was created without at least 50 fair, independent, private dice rolls and the funded wallet is not protected by a strong, unique BIP-39 passphrase.

Seeds generated on Mk4, Q and Mk5 before the fixed firmware releases are also affected, with about 72 bits of entropy rather than the expected 128 bits.

Updating the firmware does not change or repair an existing seed. If your seed was generated before the fixed firmware version for your model, follow the migration guidance below unless the independent dice-entropy exception applies to you. A strong passphrase reduces the immediate exposure, but it does not repair the affected seed; passphrase users should also migrate as soon as practical.

TAPSIGNER, OPENDIME and SATSCARD are not affected by this bug as they are different codebases

The issue is present on Mk2 and Mk3 firmware versions 4.0.1 through 4.1.9 inclusive. It also affects seeds generated on Mk4 and Mk5 before standard version 5.6.0 or Edge version 6.6.0X, and on Q before standard version 1.5.0Q or Edge version 6.6.0QX. The impact on Mk4, Mk5 and Q is not as severe but is still serious.

If You Added Dice When Creating the Seed

This issue affects the device-generated entropy. It does not remove independent entropy that you supplied with dice.

On affected firmware, COLDCARD hashed the device-generated seed together with every dice roll entered through Add Dice Rolls:

50 to 98 independent, private rolls: the dice input alone contributed at least 128 bits of entropy.
99 or more independent, private rolls: the dice input contributed approximately 256 bits of entropy.
Fewer than 50 rolls, or you do not remember: follow the migration guidance in this advisory.

If you entered at least 50 fair and independent rolls, and the rolls were not recorded or exposed, we do not consider the resulting seed at risk from this RNG issue alone.

This applies to the final seed words shown after the dice were added. If you are uncertain which words you used, how many rolls you entered, or whether the rolls were private, migrate to a new seed.

If You Used a Passphrase

If the affected seed was used with a strong, unique BIP-39 passphrase, that passphrase adds an independent barrier. The reduced seed entropy alone is not enough to reach funds in that passphrase wallet; an attacker must also discover the passphrase.

A short, common, patterned, quoted, or reused passphrase may be guessable. If that describes your passphrase, or you are uncertain about its strength, treat the funds as at risk and migrate immediately.

This means a BIP-39 passphrase, not the COLDCARD PIN. Even with a strong passphrase, migrate to a newly generated seed as soon as practical. Continue to protect the passphrase and do not enter it into a website or an untrusted device.

If the Mk2 or Mk3 Is Your Only Device

Firmware 4.2.0 allows the Mk2 and Mk3 to generate a replacement seed correctly. You do not need a newer COLDCARD to complete the migration. Updating does not repair the affected seed already stored on the device.

Using one Mk2 or Mk3 for both wallets requires carefully switching between the old and new seeds. If a second device with fixed firmware is available, use it instead. If the Mk2 or Mk3 is your only device:

Verify the written backup and wallet fingerprint of the affected seed.
Install firmware 4.2.0 or later and confirm the version on the device.
On an empty Mk2 or Mk3, generate a new seed. Record and verify its backup, wallet fingerprint, and a receive address.
Restore the affected seed and send a small test transaction to the verified address.
Restore the new seed and confirm that its fingerprint matches and the test funds arrived.
Restore the affected seed and move the remaining funds.
Restore the new seed and confirm the migration. Keep the old backup until the complete balance has arrived and is confirmed.

The fixed firmware’s device-generated seed is sufficient. Dice rolls are optional and are not required to address this issue. A BIP-39 passphrase is a separate wallet-security choice; if used, back it up exactly and separately from the seed words.

Optional Dice-Only Seed on Mk2 or Mk3

After updating to version 4.2.0, users who are confident in their ability to perform and verify a dice-only migration can create a replacement seed without using the device’s random-number generator. This is optional; the normal New Wallet flow is corrected in version 4.2.0.

On an empty Mk2 or Mk3 running 4.2.0, select Import Existing > Dice Rolls and enter at least 99 independent rolls of a fair six-sided die. This dedicated dice-only path hashes the roll sequence directly; it does not use the device’s generator.

This is an advanced procedure. A one-device migration requires safely alternating between the old and new seeds. Before erasing either seed from the device, verify its written backup and XFP. Verify a receive address for the dice-generated wallet, restore and verify the original wallet, and send a small test transaction before moving the remainder. Keep the original backup until the entire migration is confirmed.

The dice-roll sequence is secret key material. Never photograph it, save it digitally, or enter it into a networked computer. Read the COLDCARD dice-roll method before attempting this option.

Migrate Carefully

When migrating to a new key, calm and care should be applied. Rushing a wallet migration can create a more immediate risk than the issue you are trying to address.

Seeds generated on Mk2 or Mk3 versions 4.0.1 through 4.1.9; Mk4 and Mk5 before standard version 5.6.0 or Edge version 6.6.0X; or Q before standard version 1.5.0Q or Edge version 6.6.0QX are affected unless the independent dice-entropy exception applies. Before generating a replacement seed, update Mk2 or Mk3 to version 4.2.0 or later; Mk4 and Mk5 to standard version 5.6.0 or later, or Edge version 6.6.0X or later; or Q to standard version 1.5.0Q or later, or Edge version 6.6.0QX or later:

Confirm the fixed firmware version is installed.
Generate a new seed on the updated COLDCARD.
Record and verify its backup before depositing funds.
Verify a new receive address on the COLDCARD screen.
Send a small test transaction and confirm that the new wallet works.
Only then move the remaining funds.
Keep the old backup until the migration is complete and confirmed.

We are continuing to investigate. More details will follow.

One COLDCARD, Many Wallets: Better Backups with BIP-85

Wed, 29 Jul 2026 01:00:00 -1200

Every new wallet creates another seed phrase to record, hide, duplicate, and eventually recover. BIP-85 gives COLDCARD users another option: derive a different seed for each compatible wallet from one protected parent, without entering the parent seed into any of them.

Restore the same parent on a COLDCARD, select the same output type and index, and you get the same child again. A compromised child does not reveal its parent or siblings through BIP-85. A compromised parent can recreate every child.

That asymmetry is what makes BIP-85 useful—and what makes the parent backup so important.

Separate wallets without seed reuse

BIP-85 derives deterministic entropy from the active seed on your COLDCARD. COLDCARD can format that entropy as:

12, 18, or 24 BIP-39 words;
a WIF private key;
a BIP-32 XPRV;
32 or 64 bytes of hexadecimal data;
a deterministic password.

For another hardware or software wallet, the usual output is a new BIP-39 seed phrase. Each application type and index produces a different result.

This is not seed reuse. Wallet A receives child 0. Wallet B receives child 1. Each gets different seed words, keys, addresses, balances, and transaction history. Neither destination receives the COLDCARD parent seed.

The parent remains the common recovery root. Its seed words or encrypted backup can recreate the children, provided you also preserved the information that selected each one.

What this fixes

Backup quality tends to fall as wallet count rises.

The main savings wallet may have a tested steel backup in two locations. A later mobile wallet gets words on a card. A test wallet lands in a notebook. Six months later, nobody remembers which phrase belongs to which application.

BIP-85 replaces some of those unrelated secret backups with one carefully protected root plus a recovery map. That map should record:

the parent wallet or passphrase context;
the BIP-85 output type and word count;
the index;
the destination wallet and network;
any account, derivation, descriptor, or application data needed by that wallet.

The index is not a password. It tells COLDCARD which deterministic child to reproduce. Losing it does not expose the child, but it can turn recovery into a search.

This model is useful for a mobile spending wallet, another hardware wallet with a different interface, or a temporary wallet used for a specific job. The child can do that job without becoming another independent seed-generation and backup project.

Create a BIP-85 child on COLDCARD

Before starting, decide which COLDCARD seed will be the parent. If a BIP-39 passphrase or Temporary Seed is active, it becomes part of the parent context. You will need that exact context to reproduce the child.

For a simpler recovery plan, derive the child from the normal parent before entering a passphrase or loading a Temporary Seed.

COLDCARD Mk5.

On COLDCARD Mk4 or Mk5, open Advanced/Tools > Derive Seed B85.
On COLDCARD Q, open Advanced/Tools > Derive Seeds (BIP-85).
Read the warning, then choose the output format accepted by the destination wallet.
Enter a unique index from 0 to 9999.
Record the output type, word count, index, and intended wallet in your recovery map.
Display or export the child, then import it with the destination wallet’s official recovery workflow.

COLDCARD can move the result by MicroSD, Virtual Disk, NFC, QR, or USB keyboard emulation. Every export contains a live secret. Choose the narrowest path supported by the destination.

For another hardware wallet, prefer entering the words on that device when it supports on-device entry. Do not type seed words into a website. Do not leave an exported copy on an ordinary computer or MicroSD card unless that copy is part of a deliberate backup plan.

See BIP-85 in practice

These Coinkite walkthroughs show how to derive a dedicated child seed from COLDCARD and restore it on a mobile wallet or a Ledger. Only the child seed moves to the destination; the COLDCARD parent remains separate.

Mobile wallet

Ledger

Test the recovery path, not just the seed

A seed phrase can be correct while the recovery plan is incomplete.

Use a disposable wallet or resettable spare for the first test. Do not erase an existing funded wallet unless its independent backup has already been tested.

Import the BIP-85 child into the destination wallet.
Record its first receive address.
Remove the child from the test destination.
Recreate it on COLDCARD from the recorded parent context, format, and index.
Restore it again and confirm the same receive address appears.
Send and spend a small amount before using the wallet for meaningful funds.

The test checks more than the words. It checks whether your recovery notes identify the correct parent, passphrase state, output type, index, destination, and wallet settings.

Some wallets need metadata that a seed phrase does not restore. Multisig wallets need the complete wallet policy or descriptor. Account-based applications may need the correct account or derivation information. Follow the destination wallet’s documentation and preserve anything it says is required.

What BIP-85 does not protect

The destination wallet does not inherit COLDCARD’s secure elements, firmware, trusted display, or signing controls.

If you load a child into a phone, it becomes a hot-wallet secret. Malware, screen recording, cloud backup, or somebody with access to the unlocked phone may expose it. BIP-85 limits that failure to the child; it does not make the phone cold.

The reverse risk sits at the parent. Anyone who obtains the parent seed, any required passphrase, and the recovery map can recreate all of its children. Protect the parent for the total value and importance below it, not only for the balance visible on the parent wallet.

This shared root also means BIP-85 children are not independent multisig cosigners. Do not derive two or three members of the same multisig quorum from one parent. A single parent compromise would recreate the quorum and defeat the reason for multisig.

Privacy remains separate as well. The children are not cryptographically linked on-chain merely because they share a BIP-85 parent, but address reuse, transaction behavior, exchange records, and destination-wallet telemetry can still connect them.

Do not build one failure domain for everything

One parent can produce many children. That does not mean one parent should produce every secret you own.

Keep long-term savings separate from routine spending when the consequence of a shared-root compromise would be too large. A dedicated COLDCARD seed can serve as the BIP-85 root for spending wallets and experiments while a separate savings seed remains outside that tree.

The same rule applies to deterministic passwords, XPRVs, and WIF keys. Convenience is not a reason to put unrelated, high-consequence secrets under one root.

Choose the boundary first. Then use BIP-85 to make backups inside that boundary more orderly.

One root, a written map, and tested children

BIP-85 is a practical answer to wallet sprawl:

keep the parent seed on COLDCARD;
give each compatible wallet a different child;
record the parent context, format, index, and destination;
treat every exported child as a live secret;
test recovery before funding;
keep multisig cosigners and unrelated high-value secrets independent.

Read the full COLDCARD BIP-85 guide for every output and export option. The BIP-85 specification defines the derivation and test vectors.

Get COLDCARD Q or Mk5

arca Reservations Are Open

Wed, 22 Jul 2026 00:00:00 -1200

Reservations are open for arca, the physical digital safe built for secrets you cannot afford to lose—our personal data haven. A $99 USD partial prepayment per unit reserves a place in the limited first batch, currently targeting January 2027.

The tentative early-bird price is $669 USD for one arca, $539 USD each for two, and $499 USD each for three or more.

Reserve arca

Founder’s Edition Hardware

arca comes from the same Coinkite shop that built COLDCARD, OPENDIME, TAPSIGNER, SATSCARD, and our other physical custody tools.

The Founder’s Edition hardware includes:

a Rockchip RK3328 host running FreeBSD;
an Arm Cortex-M33 security controller with TrustZone;
ATECC608C and DS28C36BQ+T secure elements;
a secure real-time clock, motion sensor, and active tamper-detect circuit;
two USB power inputs, Power Over Ethernet, and an internal UPS;
planned reproducible deterministic builds and decoy PIN paths.

Founder's Edition rear panel.

These parts provide defence in depth. The FreeBSD host handles higher-level services. The Cortex-M33 security controller and two different secure elements put sensitive operations behind separate boundaries. The secure clock, motion sensor, tamper circuit, independent power inputs, PoE, and internal UPS add physical-state and availability controls. No single chip or feature is the whole security argument.

Passwords can be stored inside arca, but they are not its primary authentication model. Access uses physical 2FA tokens and one-time codes instead of a reusable password.

Recovery should not depend on one phone, one building, or one person

The authenticator app was on the dead phone. The seed backup is in one building. The registrar login depends on one inbox. Production credentials exist in one employee’s notes. The emergency procedure is “ask Alice.”

None of this requires a sophisticated attacker. Normal life is enough:

The phone is gone. You know the account password, but the authenticator, passkey recovery, or code needed to enroll a new phone lived on the old one.
Everything is in one building. The seed plate, emergency USB, printed codes, and recovery instructions are all “offline” in the same home or office. A fire, flood, evacuation, seizure, or long trip makes every copy unavailable at once.
One employee is the recovery plan. The registrar, cloud root account, signing process, and production credentials depend on a founder or administrator who left, is unreachable, or no longer remembers the full procedure.
The pieces exist, but the recovery path does not. The password is in a manager, one code is in email, another is on paper, and the final step lives in someone’s memory. Nobody has tested whether the pieces still work together.
Family must solve it under stress. They know important assets and accounts exist, but not which instructions are current, who should receive what, or how to start without exposing everything.

These are small secrets with large consequences. The usual fixes pull in opposite directions. Make more copies in screenshots, email, chat, and cloud drives, and sensitive material becomes easier to leak. Keep only one careful offline copy, and one dead device, inaccessible building, or unavailable person can lock everyone out.

A password manager is useful for daily logins. A NAS is useful for files. Paper and steel are useful static backups. A hardware wallet is useful for signing. Each solves part of the problem, but the recovery path can still depend on the same phone, inbox, cloud account, building, or person.

arca is built to turn that scavenger hunt into a custody plan. It gives critical secrets and their recovery context a dedicated physical home. The current design uses isolated tenants for family, business, partner, and hosted contexts. Policy controls and Swarm mirroring are in development so selected people can recover the right context and two or more arcas can keep encrypted copies in different trusted locations.

arca does not replace those tools. For everyday use, it protects daily backups, passwords, business access, files, and signing material on dedicated hardware. For continuity, it keeps the recovery layer underneath them: seed words, recovery codes, business keys, runbooks, inheritance notes, important encrypted files, and the instructions someone will need when the normal path is gone. A third path under development will give authorized agents narrow, policy-controlled access without handing them every secret. For Bitcoin and crypto users, that can include wallet recovery material, exchange recovery codes, signing policies, and continuity instructions.

More than encrypted storage

One arca can work as a standalone physical safe for digital secrets. The larger design includes several services inside the same hardware custody boundary:

a widely adopted password-manager server, likely Bitwarden and/or KeePassXC, for personal and team credentials;
an embedded COLDCARD signing emulator for remote multisig co-signing or a dedicated single-signature wallet;
CK Bunker-style HSM functions in development, so approved systems can request signing or cryptographic operations without receiving the raw key;
isolated spaces for family, work, company, partner, and hosted contexts;
controlled access for people, services, and authorized agents.

This is pre-production hardware and software. Some of this works in the alpha; some remains in design or prototyping. The final interfaces and feature scope may change before release.

A password manager helps with daily logins. A NAS stores files. An HSM performs narrow key operations. arca overlaps with all three, but it is broader than recovery alone: everyday backups and signing, personal and business continuity, and controlled access for authorized agents.

One arca is a safe. More than one is a Swarm.

One arca still means one device in one physical location. Two or more are designed to mirror an isolated encrypted tenant across places you choose.

A second arca covers loss of the first device or building. A third location lets one arca be offline for maintenance, travel, or an outage without leaving only one recovery copy. The locations can be a home, office, family property, company site, or another city or jurisdiction that fits your threat model.

You do not need to own every arca in the Swarm. The design lets a trusted friend host your isolated encrypted tenant on their arca without receiving access to its contents. You can host theirs in return. Think reciprocal safes, not a shared folder, login, or vault.

That is why the quantity pricing matters. Buying more than one is not about keeping a spare beside the first box. It is about removing one device, one building, and one local event as the only recovery path.

Business continuity without the shared-secret mess

Businesses accumulate secrets that quietly become infrastructure: production credentials, API keys, signing keys, vendor accounts, recovery codes, treasury material, and emergency runbooks.

arca is built to separate those contexts by team, company, partner, or project. Policy controls and CK Bunker-style HSM interfaces are in development so selected secrets can be available without copying them into chat, email, or every employee’s password manager. An approved system can request an operation without receiving the raw key.

Multiple arcas are designed to keep encrypted recovery contexts in different offices or trusted locations. If a founder, administrator, finance lead, or other key person leaves or becomes unavailable, the company should have a documented path back that does not depend on reconstructing one person’s private ritual.

Inheritance and the dead-man switch

Families have the same continuity problem under worse conditions. A survivor should not have to reverse-engineer the owner’s digital life while dealing with an emergency.

arca is built so selected secrets, documents, and instructions can have a controlled recovery path for chosen people. A planned dead-man switch can make selected material recoverable after defined inactivity or release conditions.

The useful version is not “miss one check-in and dump the whole vault.” Different people may need different instructions. A business context should remain separate from a family context. Sensitive releases need authentication, limits, and records.

The policy and release mechanics are still in development. arca will not determine whether someone has died, and it does not replace legal estate planning.

Reservation details

arca tentative pricing and reservation prepayments
Quantity	Tentative price	Due today
1	$669 USD	$99 USD
2	$539 USDper unit	$198 USD$99 per unit
3 or more	$499 USDper unit · best unit price	$99 USDper unit

The first batch is very limited and is currently targeting January 2027. Pricing and timing remain tentative while we finish the product.

If your recovery plan still depends on one phone, one building, one cloud account, or one person remembering everything, reserve arca.

Learn more about the product, Swarm backups, Founder’s Edition hardware, and how it compares with adjacent tools at arcasafes.com.