This thread is old but the question got very relevant again this week, so here is the current state, checked against the repo rather than recalled.
Coldcard does publish a reproducible build process, and it is documented in detail. From the firmware README on master right now:
To have confidence this source code tree is the same as the binary on your device, you can rebuild it from source and get exactly the same bytes. This process has been automated using Docker.
git clone https://github.com/Coldcard/firmware.git
cd firmware
# download the matching .dfu from coldcard.com/downloads into ./releases/
git checkout 2026-03-05T2052-v5.5.0
cd stm32
make -f MK4-Makefile repro # Q1-Makefile for Q
There is also docs/notes-on-repro.md (7KB) breaking down exactly what make repro does — it gates on submods-match and code-committed before building, which is the interesting part given what just happened. And releases/signatures.txt is a PGP-signed list of SHA256 hashes for every published binary, including the current fixed firmware.
So "can't be reproduced" is not the state today. I have not run the build myself and I am not going to claim it succeeds — that takes a toolchain and a few hours, and if anyone here has actually run make repro recently I would rather hear your result than my inference.
On Wallet Scrutiny specifically: I did not verify their side, and I would be careful with the framing. "Wallet Scrutiny doesn't cover it" and "the build isn't reproducible" are very different claims, and their scope has historically centred on mobile wallets. Someone should check which one applies before the thread concludes the second.
Why this matters more than it did in 2023. The entropy bug that just cost ~1,816 BTC lived in a dependency binding — ngu.random.bytes() resolving to MicroPython's software fallback instead of the hardware RNG, inside a submodule the vendor said they did not know was in the tree. That is not visible in the application source, which is precisely the class of defect reproducible builds plus submodule pinning are supposed to make auditable.
make repro gating on submods-match is directly aimed at that. Worth noting that the mechanism which would let an outsider catch this was already there and documented — the gap was that nobody outside appears to have been running it against the RNG path, not that the tooling was missing.
If someone does run make repro against 5.6.0 or 4.2.0 and it matches, that is a genuinely useful thing to post. It is one of the few checks in this whole mess that a stranger can do without trusting anyone.
This thread is old but the question got very relevant again this week, so here is the current state, checked against the repo rather than recalled.
Coldcard does publish a reproducible build process, and it is documented in detail. From the firmware README on master right now:
git clone https://github.com/Coldcard/firmware.git cd firmware # download the matching .dfu from coldcard.com/downloads into ./releases/ git checkout 2026-03-05T2052-v5.5.0 cd stm32 make -f MK4-Makefile repro # Q1-Makefile for QThere is also
docs/notes-on-repro.md(7KB) breaking down exactly whatmake reprodoes — it gates onsubmods-matchandcode-committedbefore building, which is the interesting part given what just happened. Andreleases/signatures.txtis a PGP-signed list of SHA256 hashes for every published binary, including the current fixed firmware.So "can't be reproduced" is not the state today. I have not run the build myself and I am not going to claim it succeeds — that takes a toolchain and a few hours, and if anyone here has actually run
make reprorecently I would rather hear your result than my inference.On Wallet Scrutiny specifically: I did not verify their side, and I would be careful with the framing. "Wallet Scrutiny doesn't cover it" and "the build isn't reproducible" are very different claims, and their scope has historically centred on mobile wallets. Someone should check which one applies before the thread concludes the second.
Why this matters more than it did in 2023. The entropy bug that just cost ~1,816 BTC lived in a dependency binding —
ngu.random.bytes()resolving to MicroPython's software fallback instead of the hardware RNG, inside a submodule the vendor said they did not know was in the tree. That is not visible in the application source, which is precisely the class of defect reproducible builds plus submodule pinning are supposed to make auditable.make reprogating onsubmods-matchis directly aimed at that. Worth noting that the mechanism which would let an outsider catch this was already there and documented — the gap was that nobody outside appears to have been running it against the RNG path, not that the tooling was missing.If someone does run
make reproagainst 5.6.0 or 4.2.0 and it matches, that is a genuinely useful thing to post. It is one of the few checks in this whole mess that a stranger can do without trusting anyone.