COINKITE Blog

Understanding the COLDCARD Mk5 and Q Security Model

Mon, 26 Oct 2026 00:00:00 -1200

COLDCARD Mk5 and Q look very different, but they use the same core security architecture: two secure elements from different vendors, an STM32 microcontroller, locally verified firmware, a clear case, and no required companion app.

This is the current version of our original Mk4 security-model explainer, which remains online. The original was written by guest author Tristan Borges Solari. This edition keeps the useful parts and updates the setup, hardware, firmware, and seed-generation details for Mk5 and Q.

Before You Set Up a Wallet

Inspect the device, set the PIN, then stop at the main menu. Check the current security status, install the current standard firmware, and verify the signed download before you generate or import a seed.

Firmware changes the device. It does not change an existing seed. If the security status says a seed requires migration, follow the migration guidance; an upgrade alone is not a migration.

Start with What You Can Inspect

Each COLDCARD ships in a tamper-evident bag with a unique number. Before setup, check the bag for damage and confirm that the number on the bag, the tear-off tab inside, and the number shown by the COLDCARD all match.

The clear case is another deliberate check. You can see the board, the chips, and the exposed traces instead of trusting a sealed black box. Neither a bag nor a clear case is magic. Together they make interception and physical changes harder to hide.

If the packaging looks wrong, the numbers do not match, or the board looks altered, stop. Do not enter a PIN or seed.

Authenticity Without a Required App

Every authenticity system has tradeoffs. A remote attestation service can be convenient, but it also creates another central service and a valuable key for attackers to target. COLDCARD keeps its core checks local: inspect the clear case, match the bag number, verify the signed firmware, and check the GENUINE/CAUTION LEDs.

At startup, the bootloader checks the firmware and flash contents. The red CAUTION LED is on while verification runs. The green GENUINE LED turns on after the expected firmware state is confirmed. The LEDs are connected to the secure-element path; ordinary firmware cannot simply draw a green light on the screen and call itself genuine.

If the red light remains on, do not enter your PIN. A red light can also appear after a firmware change until the PIN holder reviews and blesses it. Follow the firmware instructions rather than guessing why it changed.

This design still has trust boundaries. Coinkite signs standard firmware, and you must obtain the verification key through a channel you trust. The firmware source, signed release manifest, reproducible-build process, and on-device indicator make that boundary inspectable instead of hiding it behind an app.

The PIN Is More Than a Lock Screen

The main PIN has a prefix and suffix. After the prefix, COLDCARD shows two anti-phishing words derived from secrets unique to that device. Record those words during setup and check them before entering the suffix in the future.

A replacement device should not produce the same words for the same prefix. That makes the words a useful warning against an evil-maid or look-alike-device attack. They are a check only if you remember to check them.

PIN attempts are rate-limited and finite. Mk5 and Q also support Trick PINs that can open a duress wallet, wipe the seed, start a countdown, or brick the device. These are advanced controls. Test any Trick PIN with a disposable setup before depending on it.

Two Secure Elements and One MCU

Mk5 and Q use three chips from three vendors in the secret-protection path:

SE1: a Microchip ATECC608-family secure element;
SE2: a Maxim DS28C36B secure element; and
MCU: an STMicroelectronics STM32L4S5 microcontroller.

COLDCARD Q and Mk5 share the same dual-secure-element design.

SE1 stores the seed material in encrypted form, but SE1 does not hold the full key needed to decrypt it. The decryption path combines secrets held by the MCU and SE2 and requires the correct PIN. Pairing secrets and authenticated communications protect the short electrical links between the chips.

The design goal is straightforward: compromising one chip should not be enough to recover the wallet secret. An attacker targeting the stored seed must get through the MCU, both secure elements, and the PIN path rather than depending on one component.

The secure elements do not implement Bitcoin transaction signing. Bitcoin operations run on the MCU using the same libsecp256k1 cryptographic library used by Bitcoin Core. The secure elements protect secrets and enforce parts of the access-control path; the public firmware implements the Bitcoin logic.

The secure elements remain visible through the Mk5 case.

The detailed key relationships, pairing operations, ECDH exchanges, wipe keys, and storage slots are documented in the public dual-secure-element design and security-model document.

Current Seed Generation Uses Device and User Entropy

Current standard firmware does not ask you to trust one random-number source. For each new seed, COLDCARD combines fresh input from the STM32 hardware TRNG, SE1, and SE2. It then requires one physical user-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.

You cannot skip this step. Dice rolls are our recommended standard method.

Current firmware can also display the full device-generated input as 24 BIP-39 words before dice or coin input is mixed in. The public verify_seed_mix.py tool can recompute the result offline for dice rolls or coin flips. It does not support key-mashing input.

Verification exposes wallet secrets. Anyone who obtains the displayed device words together with your complete dice or coin sequence can recreate the wallet. The safest way to test the math is with a disposable run that will never hold funds, then start over with new device words and fresh, unrecorded rolls or flips for the actual wallet.

Read the Master Seed guide for the current workflow and the verification guide before using the advanced checks.

The Firmware Is Part of the Security Model

COLDCARD firmware is developed in public. You can inspect the source, build it, and compare builds with a signed release. The bootloader verifies firmware before normal use, and the GENUINE/CAUTION system reports the approved flash state locally.

That does not make software bug-free. It makes changes reviewable and gives users several independent checks: source, release history, signed hashes, reproducible builds, and the device’s own boot verification.

Keep the firmware current. Verify the release manifest and file hash yourself. Do not rely on a version number copied from an old article, video, or social post.

Signing Without Handing the Keys to an App

The wallet software on your computer or phone prepares a PSBT. COLDCARD parses it and shows the transaction details for review. If you approve it, COLDCARD signs on the device and returns the signed transaction.

Mk5 supports MicroSD, NFC, USB-C, and Virtual Disk workflows. Q adds a camera, QR signing, two MicroSD slots, a larger screen, and a full keyboard. Neither model requires a COLDCARD account or a particular companion wallet.

The channel is not the final security decision. A MicroSD card, QR code, NFC, or USB link can carry hostile data. The important boundary is that COLDCARD parses the request, shows what it intends to sign, and waits for your approval. Read the screen. Verify destination addresses and amounts before signing.

What Still Depends on You

No hardware design can fix a bad recovery plan. You still need to:

keep the device on current, verified firmware;
protect the seed backup from theft and loss;
use a strong, unique BIP-39 passphrase for a wallet whose loss would be materially harmful, back it up separately, and test recovery;
verify receive addresses and transaction details on the COLDCARD screen; and
consider multisig when its extra recovery and operating complexity fits the amount and threat model.

The point of the Mk5 and Q security model is not that any one chip, bag, light, or workflow is perfect. The point is that the layers fail differently and can be checked in different ways.

Get COLDCARD Q or Mk5

Technical References

COLDCARD Firmware 5.6.3 & 1.5.3Q: Codex32 and Shamir Backups

Thu, 01 Oct 2026 00:50:00 -1200

COLDCARD firmware 5.6.3 for Mk4/Mk5 and 1.5.3Q for Q let you split the wallet already on your device into Codex32 Shamir shares. No funds move, and the wallet does not change.

Codex32 is the main feature. The release also adds optional Seed Vault names for temporary seeds, PSBTv2 locktime support, and several signing and parsing fixes.

Codex32, defined by BIP-93, is a checksummed format for wallet secrets. It includes a Shamir secret-sharing scheme for manual backup and recovery.

A normal seed backup is all-or-nothing. Shamir sharing lets you make several shares and choose how many are needed for recovery. With a 2-of-3 set, any two shares recover the wallet and one share does not reveal its secret.

COLDCARD supports sets of two through nine shares, with a threshold from two through the total. You can:

generate a 128- or 256-bit Codex32 wallet
import a complete Codex32 secret
split the active wallet with Shamir Split
restore a wallet with Shamir Recover
derive another share for an existing set
calculate the checksum for a supported Codex32 header and payload

On a blank COLDCARD, generation, import, recovery, derivation, and checksum calculation are available from the new Codex32 menu. To split the active wallet, select:

Advanced/Tools > Danger Zone > Seed Functions > Shamir Split

The new Codex32 menu on COLDCARD Q.

Calculate Checksum completes a Codex32 secret or share from its header and payload without importing a wallet. Mk4 and Mk5 shorten the menu label to Calc Checksum. The calculation uses exactly what you enter; it cannot find or repair an error already present in the text.

COLDCARD picks an encoding from the active wallet. MS1 holds raw BIP-32 master-seed bytes. CW1 holds the entropy behind English BIP-39 seed words. CX1 holds extended private-key material, including an active passphrase wallet. CW1 and CX1 are COLDCARD extensions, so recovery software must support them explicitly.

Passphrases change what gets backed up. Splitting the original words wallet creates CW1 shares. Recovery returns the words, and you apply the passphrase again. Splitting while the passphrase wallet is active creates CX1 shares. Those shares recover that wallet directly; they do not contain the original words or passphrase.

COLDCARD does not keep a share set after a split. Record and compare every share before leaving the split screen. Splitting again creates a different set, so shares from separate splits cannot be mixed.

QR codes, NFC exports, and text files contain shares in plaintext. Keep fewer than the threshold in any one place. Before relying on the set, recover from the exact copies you plan to store and reproduce a known receive address. A matching fingerprint alone is not a complete recovery test.

A 2-of-5 share set ready to record and store separately.

The full Codex32 guide covers saved recovery sessions, passphrase examples, backup limits, and recovery testing. Source and review history are in Coldcard/firmware PR #819.

Seed Vault Names for Temporary Seeds

Temporary seeds normally appear at the top of the home menu as a fingerprint in square brackets. A new master-seed setting can replace that fingerprint with the matching Seed Vault label.

On Q, select:

Settings > Buried Settings > Temporary Seed Names > Use Names

On Mk4 and Mk5, the shorter menu label is used:

Settings > Buried Settings > Tmp Seed Names > Use Names

If the active temporary seed matches a Seed Vault entry named Travel, for example, the home menu shows [Travel]. COLDCARD falls back to [XFP] when the setting is disabled, no matching vault entry exists, or the label is too wide to fit. Master-seed fingerprints continue to use angle brackets.

PSBTv2 Locktime and Parsing

PSBTv2 can put required block-height or timestamp locktimes on individual inputs. COLDCARD now derives the transaction-level locktime from those per-input requirements according to BIP-370.

When several inputs specify compatible requirements, the transaction uses the required maximum. A per-input requirement takes precedence over the global fallback locktime. If height-only and time-only requirements cannot be satisfied by one transaction locktime, COLDCARD rejects the PSBT instead of signing an inconsistent transaction.

The parser also rejects more malformed PSBTv2 files before signing:

singleton global, input, and output fields carrying unexpected key data;
non-canonical global input or output counts with trailing bytes; and
PSBTv2 files that omit the required explicit global version.

Fixes and Hardening

COLDCARD now warns before installing firmware signed by an external contributor or downgrading from the currently installed version.
On Q, Ready To Sign and the Key Teleport retry screen now accept only the expected QR types. Scanning seed words or an extended private key there no longer risks replacing the master seed.
Message-signing input supplied through NFC, QR, or a MicroSD .json file no longer crashes the device when the JSON contains a number, string, list, or null. COLDCARD treats it as a plain-text request instead. Thanks to @Amiga500 for the report and fix.
After a failed signing attempt, COLDCARD clears the old output-verification state before checking outputs again.
In Delta Mode, the device wipes before reading duress-wallet slot data.

How to Update

Download COLDCARD Firmware

Download firmware only from the official COLDCARD downloads page.
Follow the 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.3 on Mk4/Mk5 or 1.5.3Q on Q.

The complete source changes are available in the public COLDCARD firmware repository, including Codex32 source documentation, the 5.6.3 and 1.5.3Q release changelog, and the individual pull requests for temporary-seed names, message signing, PSBTv2 locktimes, and PSBTv2 parser hardening.

Need a COLDCARD for a tested recovery plan? Enjoy 10% off with on-chain Bitcoin. Use code CKBTC at checkout.

Get COLDCARD Q or Mk5

Codex32 and Shamir Backups on COLDCARD

Wed, 30 Sep 2026 00:00:00 -1200

Your seed backup has a problem that more copies cannot fix.

One copy is a single point of failure: lose it, lose the coins. Make a second copy and that is fixed, at the cost of doubling the number of places somebody can find the whole secret. Three copies, three places. Redundancy and secrecy pull against each other, and every copy you make buys one by spending the other.

Shamir Secret Sharing breaks that trade. Split the backup into several shares and set how many are needed to rebuild it. Fewer than that number reveal nothing about the secret.

COLDCARD can now split the BIP-39 seed words you already use into Shamir shares. Same wallet, same addresses, no coins moved. It ships in firmware 5.6.3 (Mk4/Mk5) and 1.5.3Q (Q).

Get COLDCARD Q or Mk5

Threshold Beats More Copies

Backup plan	Survives losing	Compromised by
1 copy	nothing	1 find
3 copies	2	1 find
2-of-3 shares	1	2 finds
3-of-5 shares	2	3 finds

Three copies in three places is three chances for one burglary — or one curious relative — to walk off with everything. A 3-of-5 split survives two destroyed shares and still defeats whoever reaches two of the five — so one share can sit with a lawyer, one in a deposit box, one at home, and no single visit is enough.

COLDCARD makes 2 to 9 shares, with any threshold from 2 up to the total. Unlike Seed XOR, which needs every part, you choose the redundancy. Pick the smallest arrangement you can actually store, explain to your heirs, and test.

BIP-93, Natively

BIP-93, authored by Andrew Poelstra, Leon Olsson Curr, and Pearlwort Sneed, defines Codex32: an encoding for wallet secrets with a strong checksum and Shamir sharing built in, designed so a checksum can be verified — and shares recombined — with pen, paper, and printed tables.

On a COLDCARD with a PIN and no wallet, the new Codex32 menu covers the lifecycle: Generate a new MS1 secret, Import Codex32, Shamir Recover from a threshold of shares, Derive Shares, and Calculate Checksum.

Derive Shares is the one people underestimate. Lose a share from a 2-of-3 and any two survivors reproduce exactly that missing share. The set stays valid and the shares already sitting in other locations do not have to be replaced.

The Part That Usually Costs You an On-Chain Move

Standard Codex32 (MS1) starts with its own wallet secret format. SLIP-39 can technically convert an existing BIP-39 wallet through Trezor’s command-line tool, but Trezor Suite does not support it and Trezor recommends creating a new wallet and moving the funds instead. For most existing BIP-39 users, that means paying transaction fees, rebuilding their wallet setup, and potentially linking addresses on-chain — a cost in money, effort, and privacy just to improve a backup.

So we extended Codex32. COLDCARD can split an existing BIP-39 seed directly into Codex32 shares—without creating a new wallet or moving coins. The checksummed strings can be recorded on paper or steel. The format is chosen from whatever wallet is already active:

Active wallet	Format	A threshold of shares restores
BIP-39 seed words	`CW1`	Your original 12, 18, or 24 words
Extended private key, including an active passphrase wallet	`CX1`	The chain code and private key
BIP-32 master seed	`MS1`	The master seed bytes — standard BIP-93

CW1 encodes the entropy behind your English BIP-39 words. Each share is 48 characters for a 12-word wallet, 61 for an 18-word wallet, or 74 for a 24-word wallet, displayed in numbered groups of four for copying. Recover a threshold of them and you get those same words back, usable with SeedQR, Seed XOR, passphrases, and every other word-based feature.

Share A of a split 12-word wallet: 48 characters, starting CW1.

Nothing moves on-chain. Your existing words, XPRV, and encrypted .7z backup all stay valid. You are adding a recovery path, not replacing one.

CX1 covers the case BIP-39 words cannot: split while a BIP-39 passphrase wallet is active and the shares carry that wallet’s derived keys. Recovery restores it without asking for the passphrase. It does not restore the words or the passphrase — that is the feature, and also the limit.

The honest caveat, which the device puts on screen before you start: CW1 and CX1 are ours, not BIP-93. Recovery needs COLDCARD, or software that explicitly supports the prefix — MS1 support alone is not enough. If you want a standards-only backup, use MS1.

COLDCARD tells you which format it will use, and what recovery will need, before you commit.

How a Split Works

With the wallet you want to back up active:

Advanced/Tools > Danger Zone > Seed Functions > Shamir Split

(step by step, with screenshots)

Choose the number of shares, choose the threshold, confirm the format notice, and the set appears. Each share can be written down from numbered four-character groups, or exported by QR, NFC, MicroSD, or Virtual Disk.

A 2-of-5 set. Any two of these five rebuild the wallet.

QR, NFC, MicroSD, and Virtual Disk exports contain plaintext shares. Keep fewer than the recovery threshold in any one place. Before relying on the backup, recover from the copies you will store and confirm both the expected wallet fingerprint and a known receive address. A valid checksum confirms a well-formed share; it does not prove that the share recovers the intended wallet.

Shamir shares protect your backup; they do not turn your wallet into multisig.

Shamir shares rebuild one secret. Multisig uses separate signing keys.

See the Codex32 guide for storage precautions and recovery instructions.

Where to Read the Details

Codex32 and Shamir Secret Sharing arrive in Mk4/Mk5 v5.6.3 and Q v1.5.3Q.

Every workflow, format, file rule, and troubleshooting case: COLDCARD Codex32 & Shamir guide
The specification: BIP-93

Split your backup. Keep your wallet.

Artwork from the Codex32 booklet, illustrated by Micaela Paez under the MIT License.

Enjoy 10% off when you pay with Bitcoin at checkout.

Shop COLDCARD Q and Mk5

Build and Run Your Own COLDCARD Firmware

Wed, 23 Sep 2026 00:33:43 -1200

COLDCARD will run firmware you build yourself. The source tree includes the development signing private key (key zero), so you can change the code, test it, build a DFU file, and install it without asking Coinkite to sign it.

The bootloader makes the difference obvious. Development firmware gets a warning and forced delay on every boot. It cannot quietly pass as factory firmware.

This guide covers the practical loop: make a branch, run the simulator, build for Mk4/Mk5 or Q, verify the result, and load it onto a dedicated development unit.

Use a blank COLDCARD reserved for development. Do not experiment on a device that controls real funds or contains a real seed. Custom firmware can read secrets after login, change what the screen shows, sign the wrong transaction, or leak data through files and signatures. Reinstalling official firmware cannot make an exposed seed private again.

This article was checked against firmware master at 948dc108.

What You Can Change

Most COLDCARD application code is Python under shared/. Code used by both product families is selected in shared/manifest.py; model-specific modules are selected in shared/manifest_mk4.py and shared/manifest_q1.py.

You can replace the Python application, native modules, and even the embedded MicroPython interpreter. The bootloader is outside that image and runs first. It checks the image before handing over control and cannot be changed after the COLDCARD leaves the factory.

Mk4 and Mk5 use the same firmware target. Q has its own target. The current build files are:

stm32/MK-Makefile for Mk4 and Mk5
stm32/Q1-Makefile for Q

Start with a display string, menu, export, parser, or simulator fix. Do not make boot or login code your first experiment. A crash or other issue that prevents firmware upgrade will effectively brick your test unit, since there is no other way to change or correct the firmware.

Prepare a Development Unit

Use a COLDCARD that will never hold real secrets. Set a main PIN, because firmware installation requires it, but stop before creating a master seed. If you need a wallet for testing, use a disposable seed on testnet or regtest.

Before changing anything, also download the current official DFU from the COLDCARD firmware page and verify its hash and signature using the upgrade instructions. That gives you a known file to return to if your build is able to reach the upgrade menu.

Get a COLDCARD for Development

Clone the Source

The repository uses submodules. Clone it recursively, and keep it in a path without spaces.

git clone --recursive https://github.com/Coldcard/firmware.git
cd firmware
git switch -c my-feature
git rev-parse HEAD

python3 -m venv ENV
source ENV/bin/activate
pip install -U pip setuptools
pip install -r requirements.txt
pip install --editable ./cli

Keep the commit ID from git rev-parse HEAD with your test notes. When a result matters, “master” is not a useful version number.

The compiler and desktop packages differ between macOS and Linux. Install the current prerequisites from the firmware README rather than copying an old toolchain list from a post or forum reply.

Run the Simulator First

Follow the README’s complete setup for your operating system before building the simulator. Current Apple Clang and Ubuntu 24.04 require different MPY_CFLAGS workarounds, and Ubuntu also requires pysdl2-dll. Use the current values from the firmware README, set MPY_CFLAGS as shown there, and pass it through each compiler step:

make -C external/micropython/mpy-cross CFLAGS_EXTRA="$MPY_CFLAGS"
cd unix
make setup CFLAGS_EXTRA="$MPY_CFLAGS"
make ngu-setup
make CFLAGS_EXTRA="$MPY_CFLAGS"
./simulator.py --eff

--eff starts with disposable simulator settings. For the Q interface, use:

./simulator.py --eff --q1

Make the smallest change that proves your idea. Restart the simulator, reproduce the old behavior, and then show the new behavior. Add a focused pytest case when the change can regress. The test suite accepts --sim for simulator tests and --dev for real development hardware; some hardware tests are destructive, so read the testing notes before using --dev.

If the change is intended for everyone, add a short item to releases/Next-ChangeLog.md.

Build Development Firmware

From the repository root, build Mk4/Mk5 firmware with:

cd stm32
make clean
make -f MK-Makefile setup
make -f MK-Makefile firmware-signed.dfu
mv firmware-signed.dfu my-feature-mk.dfu
signit check my-feature-mk.dfu
shasum -a 256 my-feature-mk.dfu

For Q, use the Q build file and give the result a different name:

make clean
make -f Q1-Makefile setup
make -f Q1-Makefile firmware-signed.dfu
mv firmware-signed.dfu my-feature-q.dfu
signit check my-feature-q.dfu
shasum -a 256 my-feature-q.dfu

On Linux, use sha256sum instead of shasum -a 256.

Both targets write the shared files firmware-signed.bin and firmware-signed.dfu. Removing both before each model build (via make clean) prevents Make from packaging a cached binary for the other model.

The normal firmware-signed.dfu target signs with key zero, whose private key is included in the source tree and is not secret. signit check prints the target hardware, version, key number, digest, and signature result. Read that output to check it is signed and verifies.

Shop COLDCARD Q and Mk5

Install It on the Development Unit

Copy your model’s DFU file to a MicroSD card.
Unlock the development COLDCARD.
Select Advanced/Tools > Upgrade Firmware > From MicroSD.
Choose the DFU, confirm the model and version, and let the write finish.
On reboot, confirm that the development-firmware warning and delay appear.

USB upload with ckcc upgrade and Virtual Disk installation are also supported, but MicroSD makes the file being tested easy to keep with its source commit and SHA-256 hash.

There is no way to suppress the boot-up warning, except by getting your change into the master (or edge) firmware image that Coinkite builds. We do actually accept pull requests, and some of our features have come from outside contributors like yourself!

Keep a Useful Test Record

For each build, keep:

the Git commit and a clean diff;
the target model;
the DFU SHA-256 hash;
the signit check output;
the simulator and hardware tests run; and
the expected warning, screen, file, or signing result.

If someone else cannot reproduce the result from that record, the experiment is not ready to distribute.

What Good Contributions Look Like

Useful firmware work is usually smaller than people expect. PR #729 fixed a simulator crash with a short root-cause explanation and a three-line code change. PR #808 fixed a malformed-JSON crash and added a regression test. PR #766 added View TRNG Words with the corresponding UX tests and changelog entry.

There are also independent experiments. The unaudited privkeyio/cc-firmware fork changes transaction signature-hash behavior and documents the development-key boot warning. TibaneLabs/catcard is a clean-room Rust firmware project targeting COLDCARD hardware; its own README warns users not to put funds on it. These are examples to inspect, not firmware recommendations or endorsements.

A fork is appropriate for a personal experiment or a deliberately different product. A generally useful fix or feature should usually become a focused pull request against the current COLDCARD tree.

Returning to Official Firmware

If the device still reaches the upgrade menu, install any official DFU using the usual upgrade commands. Confirm the factory-firmware boot state afterward.

Do not restore a seed that was present while unknown or third-party firmware was running. Keep development hardware out of production, even after reinstalling official firmware. The inexpensive part is another device. The expensive part is wondering what an experiment may have exposed.

The complete source and current build instructions are in the COLDCARD firmware repository. Developer access, warning behavior, and recovery limits are documented in docs/dev-access.md.

Keep experiments on empty hardware. If the change should benefit everyone, send the tested patch upstream.

Need a dedicated unit for development? Enjoy 10% off when you pay with Bitcoin at checkout.

Get COLDCARD Q or Mk5

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.