Coinkite Publishes Full Custom COLDCARD Firmware Build Guide

Anyone can now build, sign, and run their own COLDCARD firmware. The dev key is already in the repo.

Key takeaways

• Coinkite published a full build-and-run guide on September 23, 2026, enabling anyone to compile custom COLDCARD firmware and install it using the development signing key (key zero) already included in the public GitHub repository.
• The bootloader enforces a permanent warning and forced delay on every boot for non-factory firmware, so a custom build can never silently impersonate official firmware.
• The guide arrives seven weeks after COLDCARD's entropy-bug disclosure. It lowers the barrier to independent firmware review but does not change the MIT + Commons Clause license that restricts commercial use and, critics argue, dampens incentives for adversarial auditing.

Coinkite published a step-by-step guide on September 23 explaining how anyone can clone the COLDCARD firmware repository, build a custom image, sign it with the development signing key already in the repo, and install it on a dedicated development device, no request to Coinkite required. It is the first official, full-walkthrough treatment of a capability that has existed quietly in the codebase, and it formalizes a build loop that previously required developers to piece together documentation on their own.

The guide was verified against firmware commit 948dc108.

What the Build Loop Actually Looks Like

The source blog post lays out the full path: clone the repo recursively, create a branch, run the simulator to validate changes, build a DFU image using either stm32/MK-Makefile (Mk4/Mk5) or stm32/Q1-Makefile (Q), sign with key zero using the signit tool, verify the SHA-256, and load via MicroSD onto a dedicated development unit.

Key zero is the development signing private key. It is intentionally not secret, it lives in the public repo and lets anyone sign a firmware build for installation without Coinkite's involvement. Factory firmware uses separate production signing keys that are not public. The bootloader distinguishes them and flags non-factory firmware on every single boot with a warning and a forced delay. That distinction matters: a custom build cannot quietly pass as official firmware. You always know what you're running.

According to the source article, most COLDCARD application code is Python under shared/. Users can replace the Python application, native modules, and even the embedded MicroPython interpreter. The bootloader is the one thing they cannot touch, it runs first, checks the image, and cannot be changed after the device leaves the factory.

Coinkite is explicit about one boundary: do not run custom firmware on a device that holds real bitcoin. Custom firmware can read secrets after login, alter what the screen displays, sign the wrong transaction, or leak data. Reinstalling official firmware cannot un-expose a seed. A dedicated blank development unit, PIN set, no seed, is the only acceptable testbed.

The Unresolved Tension

This guide is a genuine improvement in operational sovereignty for technically competent Bitcoiners. The ability to read every line of firmware before running it, build it yourself, and install it without asking permission from the manufacturer is meaningful. The bootloader's visible warning on dev firmware is a feature: it is cryptographic, user-visible proof that you are not running factory firmware.

The context around this release, however, deserves clear-eyed attention. The guide lands seven weeks after the worst security event in COLDCARD's history, an entropy bug in firmware affecting seed generation since March 2021. Fixed firmware (5.6.0+ for Mk4/Mk5, 1.5.0Q+ for Q) shipped July 31. TFTC's prior coverage tied that incident directly to the firmware's license structure: MIT + Commons Clause. The Commons Clause FAQ explicitly states that MIT + Commons Clause is "not open source." Commercial use restrictions remain. Coinkite has not changed the license alongside this guide.

That distinction cuts to the core of what this announcement actually delivers. Lowering the friction to run your own build is not the same as creating the economic incentives for adversarial review that a true open-source license would generate. Whether the entropy bug was surfaced internally or externally remains publicly ambiguous from Coinkite's advisory. If the next major vulnerability is also found outside the community of developers building and auditing the firmware under this new publicized workflow, the "removes vendor trust" claim fails in practice. A build guide does not automatically produce a community of security researchers willing to put in the work, license terms, compensation structures, and commercial incentives do.

The thesis: this guide is the most concrete step Coinkite has taken toward removing the vendor-trust bottleneck at the firmware layer. The trigger that breaks it: the next serious vulnerability surfaces from inside Coinkite, not from an independent developer using this workflow.

What to Watch

The license question is the live variable. If Coinkite moves to a genuinely open-source license, the commercial incentive for external adversarial auditing follows. Until then, this guide lowers the floor on self-custody for developers who want full firmware visibility, without changing the structural conditions that left a critical entropy bug undiscovered by outside eyes. The hardware-wallet industry as a whole, Trezor, Bitkey (Block), Foundation Devices, Jade, and others, is now implicitly being benchmarked against this level of build transparency. Whether any of them meet it, and whether Coinkite goes further on the license, is what actually resolves the open question.

Sources

• Coinkite build-and-run guide
• COLDCARD firmware GitHub repository
• COLDCARD firmware downloads