Coldcard: firmware history, signatures and review questions

I’ve decided to publish an "investigation" into Coldcard after all, inspired in part by @oomahq’s work.

There are too many details here that deserve a closer look: the firmware vulnerability itself, the "switck" identity, Peter D. Gray / @DocHex, the GPG signatures linking the accounts, the integration of "libngu", the development history, and the questions around how this code was reviewed and allowed to remain in production for years.

I’ll keep a strict line between what can actually be proven from code, Git history, signatures, patents and archived material, and what is still speculation. The confirmed facts are serious enough without inventing anything around them.

..........

First of all, credit to @oomahq for digging into this properly.

I went through the underlying material because this Coldcard story has now moved far beyond a simple “hardware wallet had a bug” headline, and some of what has surfaced deserves much more attention.

For anyone who has not followed the story from the beginning, here is what actually happened, you can skip the part if you know the story:

Coldcard is a Bitcoin hardware wallet made by Coinkite and for years had a strong reputation in the self-custody market.

The entire purpose of a device like this is to generate and protect cryptographic secrets in a way that makes them effectively impossible to predict.

In this case, however, a firmware change introduced in 2021 broke one of the most fundamental assumptions behind that security.

On 1 March 2021, Coldcard firmware received a large change titled “First pass w/ libNgU”. Seed generation was routed through "libngu", a cryptographic library hosted under the GitHub account "switck".

➡️ This is where the problem begins.

Coldcard's production configuration intentionally contained:

"MICROPY_HW_ENABLE_RNG = 0"

That was not supposed to mean “do not use hardware randomness”. Coldcard had its own separate hardware RNG implementation. But libngu checked the setting using "#ifndef", which only asks whether the macro exists, rather than whether its value is actually enabled.

Because the macro existed but was set to "0", the safety check passed....

Instead of reaching Coldcard's hardware true random number generator, libngu silently resolved to MicroPython's fallback "rng_get()" function.

And because hardware RNG was disabled in that MicroPython configuration, "rng_get()" was not hardware randomness at all.

It was Yasmarang, a deterministic software PRNG initialised from things including the MCU unique ID and timer state.

That distinction is catastrophic when the output is being used to create a Bitcoin seed....

The code itself even described the requested bytes as “best-quality high entropy TRNG bytes”.

In reality, on vulnerable Mk2/Mk3 firmware, the hardware TRNG was never being called. Wizardsardine's independent analysis describes the result plainly: the seed-generation path was effectively combining software PRNG output with software PRNG output rather than obtaining physical randomness from the STM32 hardware generator.

And this was not some bug that lasted 2 days.

It survived in production for more than 5 years.

Block's technical analysis currently identifies Mk2 and Mk3 firmware versions 4.0.0 through 4.1.9 as using the confirmed vulnerable path with no secure reseed.

Mk1 is outside this regression. Mk4 from production firmware 5.0.0 onward, all production Q firmware and all production Mk5 firmware retained the fallback problem, although those later devices also introduced entropy from a secure element.

The problem there is that the implementation ultimately preserved only 32 bits of securely differentiated state in the relevant reseed path. Once the remaining fallback state and call history are fixed, Block calculates at most "2^32" securely distinguishable output streams, averaging roughly "2^31" trials.

That is why I would be careful with simplified claims floating around that this was universally a “40-bit” or “72-bit” wallet problem.

The real technical picture depends on the Coldcard generation, firmware, UID information, timing and RNG call history. Block explicitly does not claim that every seed can simply be cracked remotely at some fixed cost.

What it does establish is much worse than a normal cryptographic implementation should ever permit: the intended source of cryptographic randomness was bypassed, and under the right conditions an attacker could reproduce or enumerate candidate seeds offline.

➡️ Then, at the end of July 2026, wallets started getting emptied...

The first major publicly identified wave occurred around 30 July.

Initially estimated that more than 1,000 BTC had been stolen across more than 1,000 wallets, with roughly $70M reportedly disappearing in about 41 minutes.

After additional suspected waves were identified, early estimates rose to nearly $89M.

Other later reporting has placed the losses even higher, but attribution is still evolving, so I would not pretend there is a final number yet.

The particularly brutal part is that installing new firmware does not make an old vulnerable seed secure.

Coinkite has now released emergency firmware fixes including 4.2.0 for Mk2/Mk3, 5.6.0 for Mk4/Mk5 and 1.5.0Q for Q, along with Edge releases.

But Coinkite itself explicitly states that updating the firmware does not repair a seed generated by affected firmware.

Those seeds have to be replaced and the funds migrated, subject to the documented exception for independently added dice entropy.

Now we get to the part of @oomahq's thread that makes this story substantially stranger.

Who exactly is "switck", the account behind libngu?

On 4 August 2026, James O'Beirne published a reproducible analysis of the Git history and GPG signatures. His result is extremely difficult to dismiss as coincidence.

He found 58 commits authored under the identity "Switck" that carry valid cryptographic signatures made using the personal GPG key of Peter D. Gray, aka "doc-hex", Coinkite's CTO.

The same key signs commits attributed directly to Peter D. Gray in the same repository. The identities appear interleaved in time. The "switck" GitHub account itself has no uploaded GPG key.

The key fingerprint published under Gray's identity is:

"A004 C9BC E217 ABE9 341C D81A A2DC D558 C2BE 5D7C"

Its UID identifies "Peter D. Gray (Personal) <peter@conalgo.com>".

Of the Switck-authored commits O'Beirne examined, 56 were signed using Gray's signing subkey and another 2 using the primary key itself.

He also documented 19 commits authored as Peter D. Gray signed by the same personal key.

The activity crosses the same periods: Switck commits in late 2020 and early 2021, Peter D. Gray commits in February and March 2021, with both identities appearing around the same development timeline.

There is more circumstantial evidence around the repository.

Coldcard production firmware directly depends on "switck/libngu". Gray's "doc-hex" account publicly interacted with and maintained that repository, opening issues, contributing fixes and submitting changes that the Switck account subsequently merged.

O'Beirne also points to a Switck merge commit signed with Gray's primary key whose commit message references a local SSH remote named "git-switck".

Could somebody else theoretically have possessed Peter Gray's private signing key?

Yes. Cryptography proves control of the private key, not a person's physical identity sitting behind a keyboard. But there is currently no public evidence supporting such a key-sharing scenario, while a large amount of evidence points in the opposite direction.

That matters because it changes the way the development history should be understood.

This was not simply Coinkite integrating some random external cryptographic library from an unrelated anonymous developer. The available cryptographic evidence strongly indicates that the pseudonymous author and Coinkite's own CTO were operating behind the same signing identity.

And that creates legitimate questions about review, accountability and how independently this code was actually being scrutinised.

➡️There is also an important historical detail.

Peter D. Gray was involved with Digital Multitools, a company specialising in KVM-over-IP and remote computer-control technology.

Patent records list Peter D. Gray and Brian J. Carrigan as inventors on remote-computer-control technology assigned to Digital Multitools, including the patent family that produced US8595324B2.

Digital Multitools itself says its systems have been deployed in data centres, medical environments and FAA air-traffic-control centres, including custom KVM systems for switching high-resolution radar displays.

Archived résumé material now being circulated also attributes development of a hardware USB keylogger to Gray.

That claim is worth investigating further, but I would distinguish it from the patent and company records above, which are directly verifiable. Dual-use security and remote-access work is not evidence of malicious activity by itself.

And that distinction is important because this is exactly where an investigation can either become valuable or turn into conspiracy garbage.

Does any of this prove that the Coldcard entropy failure was an intentional backdoor?

No.

Does it prove an intelligence operation, a deliberate theft mechanism or “spooks inside Bitcoin”?

No.

There is currently no public evidence establishing any of those things.

The technical failure is entirely compatible with an extraordinarily serious integration mistake: a preprocessor guard checked whether a variable existed rather than whether it was enabled, the wrong "rng_get()" symbol resolved successfully, MicroPython supplied its deterministic fallback, and nobody caught the resulting entropy failure for years.

That explanation is mundane compared with an intelligence conspiracy, but the consequences are anything but mundane.

What IS now worth asking is how a company selling one of Bitcoin's most trusted security devices allowed a cryptographic seed-generation path to bypass its hardware TRNG for more than 5 years, why testing did not detect it, how the relevant library was reviewed, why the library sat behind a pseudonymous account apparently controlled with the CTO's own cryptographic signing key, and whether the public perception of separation between those identities accurately reflected the actual development process.

➡️ Those are fair questions. They do not require inventing a conspiracy.

And this is why I think @oomahq deserves credit for pushing beyond the surface-level “Coldcard had an RNG bug” story.

The firmware failure itself is already established by Coinkite, Block and independent researchers. The Git history and GPG signatures add another layer that deserves scrutiny.

Investigate the evidence first. Follow the signatures, commits, timelines and code. If something darker is there, the evidence should be capable of showing it.

We do not need to manufacture the conclusion.

The facts are already disturbing enough.

@oomahq @DocHex The Coldcard disaster may end up being useful for one reason: it is finally forcing people to look at how fragile parts of this ecosystem still are.

After the hack, the Bitcoin Red Team started reviewing hundreds of open-source Bitcoin projects. Their preliminary numbers are… https://t.co/w2z0jg5eGB