I’ve started a company. It’s called Nummyx. It’s based in Berlin, and it does one thing: offensive security for Bitcoin. Breaking things before attackers do. Audits of the software and hardware people trust with their coins: custody, exchanges, hardware wallets, sidechains, L2s. Under contract, paid for by clients.
Here’s why I think it needs to exist.
In August, attackers drained at least 1,366 BTC from users of a popular hardware wallet, COLDCARD, roughly $130 million at the time. The cause was a predictable fallback in the device’s random number generator. Block’s engineering team published the analysis, and Galaxy Research published the loss estimate.
Who was supposed to find that first?
Bitcoin has software engineers, cryptographers, and protocol engineers, but very few security researchers. Attacking software is a different skill from writing it. It’s not something you can usually combine in a single role. Doing both well takes more hours than anyone has.
I know a lot of good security people, and almost none of them work in Bitcoin. A few dislike it because of something they’ve read; the rest can earn more money elsewhere.
Bitcoin’s missing bit is a security company that’s native to Bitcoin.
That’s what I’m building.
What grants fund
Take Bitcoin Core. It’s open-source, shared infrastructure, free for anyone to use. No one owns it, so the work on it has always been paid for by whoever has the most to lose, and that now includes companies holding bitcoin on their balance sheets. That’s why grant programs exist.
A hardware wallet is a different thing. It’s a commercial product, aimed mostly at consumers. Whatever the software license says, the buyer expects a fully working product, and that includes the RNG. A business buyer might be able to fund a third-party audit, but not every business can afford one. An ordinary consumer can’t either, may know nothing about security, and shouldn’t have to. So it falls to the vendor to decide whether a third-party audit is worth paying for. If they skip it and their internal security processes are weak, the consequences can be catastrophic. Grant programs won’t fill that gap.
I suspected as much, but tried my luck anyway as a way to kick-start my company. In May, I applied to three grant programs with a proposal to audit the key generation pipeline in hardware wallets: how they source randomness and derive keys. I had worked on an embedded vulnerability research project before, and I couldn’t find any published research on hardware wallet security beyond physical seed extraction. Sourcing randomness is a well-known weak spot in embedded devices. I planned to cover both firmware and hardware, since plenty of vulnerabilities live at the boundary between them, and to review both source and binaries. Three security researchers I had worked with agreed to act as references.
The proposal named four popular devices, all attractive targets for attackers, COLDCARD among them. I want to be careful here. I’m not claiming I predicted anything. I had no idea about the RNG, and if I had, I would have reported it instead of writing a funding application. My claim is narrower: my only criterion for picking those four was that I couldn’t find a published third-party audit for three of them, or a comprehensive and transparent one for the fourth. That criterion pointed at the right device.
None of the three programs funded it. That was expected: each funds only a handful of projects a year, and mine fell outside their stated scope. I mention it because it’s the clearest evidence I have for the structural point. This work has no natural home in the grant model.
When vendors don’t pay for audits, it isn’t always about saving money at the customer’s expense. Sometimes they simply lack in-house security expertise. That’s where a Bitcoin-focused security company could make a difference: by reaching Bitcoin businesses that general security firms would otherwise miss.
AI
The response across Bitcoin this year has been to reach for AI. Red-teaming efforts got organized and funded, scanners got built, projects got swept. I’m glad that’s happening, and some of it will find real bugs.
What bothers me is who checks the model’s work.
A lot of the security work now being done in Bitcoin is done by people who had never played a CTF or written an exploit before these models came along. If that’s you, how do you know the model did a good job? It’ll hand you a PoC, and the PoC might even run. But how do you know it looked at the things worth looking at, instead of the things that were easy to reach?
Most of what these models do is drive tools you could have driven yourself: static analysis, fuzzing harnesses. So who’s reviewing the harnesses? A model can report coverage it never achieved, or quietly skip the paths that matter, and spotting that takes exactly the expertise the model was supposed to replace. And the model you validated last week can behave differently today, because the vendor changed something upstream and didn’t tell you.
Used like that, you’ll find shallow bugs, and bugs in code nobody had looked at before. Those are real and worth fixing. But a list of bugs found tells you nothing about the ones that weren’t.
Criminals have the same models. If your advantage is a tool your adversary can rent by the hour, your real advantage has to be somewhere else. I think it’s knowing what the tool didn’t do.
Why this can be a business
Ten years ago nobody holding bitcoin had a balance sheet that made paid adversarial research a sensible line item. That’s changed. Exchanges, custodians, ETF issuers, treasury companies, and mining operations now carry exposure in the billions, and one incident this year cost a single set of users $130 million.
That’s why I think this can work as a business. The money to do the work properly now exists, and it sits with the people carrying the risk. They have every reason to pay someone to attack their systems before somebody else does.
What Nummyx does
Security engagements are shaped around the client’s needs, whether that’s a single project or ongoing work. Either way, findings are written up, and a named person is responsible for them. The scope covers wherever an attacker would look: code, firmware, hardware, the services around them, and the supply chain. Attackers go for the weakest link, and it’s rarely the part that got audited.
Nummyx is Bitcoin only. Most security firms treat Bitcoin as one area among many, if they cover it at all. Keeping to one area allows going deeper.
I started the company with my own capital, and the plan is to grow through client work.
Because the focus is Bitcoin, work that improves one client’s security tends to improve everyone’s. Where findings can be published, with the client’s agreement, they will be.
What I’ve been working on
While the company was being incorporated and I couldn’t do anything commercial, I spent my time on Bitcoin Core and the tooling around it.
Niklas Gögge started work on Bedrock, a deterministic hypervisor, which is close to what I’ve spent years on. I fixed some crashes, got it running on older and cheaper server hardware, and experimented with scheduling strategies to see how many bugs it finds compared to TSan on the RaceBench workload.
When Core replaced libevent with a custom HTTP server, there was a fuzzing report attached, but the coverage numbers looked low to me. So I fuzzed it myself and found a memory leak. Later I also found a crash from a malformed PSBT in the MuSig2 code. Both went to the security list first.
Since then I’ve been reading as much of the Core source as I can and writing my own tooling. That’s the part that compounds, and there’s no shortcut for it.
Getting in touch
If you want to talk about a commercial security engagement, email me at hello@nummyx.com.
I’ll be at the Plan ₿ Forum in Lugano on October 23-24 if you’d rather talk in person.