Staging Quantum from QUBITCOIN: A Memory-Safe Rewrite of Bitcoin Core

On July 23, nine of the largest names in institutional Bitcoin (BlackRock, Coinbase, Strategy, Fidelity Digital Assets, Galaxy, ARK Invest, Block, Blockstream, and Anchorage Digital) launched the Bitcoin Security Consortium, pledging a combined $15 million over three years to fund the network's long-term security, with much of the attention on preparing for a future era of quantum computing.

It is a genuinely good thing. Money flowing to the people who secure Bitcoin is money well spent, and it is overdue that the largest holders of the asset put resources behind the code they depend on.

But read the fine print. The consortium "does not develop or direct Bitcoin's protocol, takes no position on specific protocol changes, and does not speak for Bitcoin or its developers." Each member directs its own pledge; the coordination runs through Brink, the non-profit that has funded Bitcoin Core contributors since 2020. In other words: the fund pays developers, and those developers work, overwhelmingly, on a single codebase.

That is the part worth sitting with. You can pour fifteen million dollars into Bitcoin's security and still leave its single greatest structural risk untouched, because that risk isn't a lack of funding. It's a lack of diversity.

Bitcoin runs on a monoculture

Almost every economically meaningful node on the Bitcoin network runs one implementation: Bitcoin Core, written in C++. It is a remarkable piece of software, maintained by some of the most careful engineers in the industry. It is also a single point of failure.

When one codebase defines consensus for the entire network, its bugs are the network's bugs. A validation flaw, a denial-of-service vector, a memory-corruption exploit: any of them, in that one implementation, is not a local incident. It is a systemic one. The network has lived this before: consensus-critical bugs have been found and quietly patched in Core, and each time, the whole ecosystem's safety rested on a single team catching a single mistake.

Every other piece of critical infrastructure learned this lesson long ago. The internet does not run on one TLS library. It does not run on one operating system, one web server, one DNS resolver. Diversity is not an inconvenience there; it is the security property. A flaw in one implementation is contained because the others don't share it.

Bitcoin, the settlement layer for a multi-trillion-dollar asset that BlackRock now sells to retail, does not have that property. A grant program doesn't give it one. A second implementation does.

Memory safety is not optional anymore

There is a second reason the codebase itself matters, and it is not philosophical.

C++ is memory-unsafe. Buffer overflows, use-after-free, out-of-bounds reads (the entire category of vulnerabilities that has produced the majority of critical CVEs in systems software for thirty years) is possible in every line of it, no matter how careful the author. This is not a knock on Bitcoin Core's engineers; it is a property of the language. Microsoft and Google have both reported that roughly 70% of their serious security vulnerabilities are memory-safety bugs. The US government's own cybersecurity agencies now formally urge new critical systems to be written in memory-safe languages.

Bitcoin is the most critical financial system there is. Rewriting its node in a memory-safe language isn't a stylistic preference: it removes, at compile time, the single largest class of exploits that can take a node down or worse.

qubitcoin: the same rules, a safer codebase

This is why SUBFROST is open-sourcing qubitcoin.

qubitcoin is a 1:1 Rust port of Bitcoin Core with full consensus compatibility. Not a new set of rules: the same rules, validated by a different, memory-safe engine. It carries custom types throughout, mapped deliberately to the C++ reference (uint256, CAmount, the script interpreter, the serialization formats) so that its behavior matches Core's to the byte, block for block. It is a complete node: validation and chainstate management, a Tokio-based P2P stack, the JSON-RPC surface, a descriptor wallet, RocksDB and flat-file storage, plus an in-process WASM indexer runtime that speaks the metashrew standard, so tools like esplora, alkanes, and BRC-20 run against it out of the box.

The objection to alternative implementations is well known and worth taking seriously: two implementations that disagree about consensus can split the chain. That risk is real, and it is exactly why fidelity, not novelty, is the entire design goal here. qubitcoin does not try to be clever about the rules. It tries to be identical, and then proves it: differential testing against Core, fuzzing across the consensus surface, exact reproduction of the reference behavior. A faithful second implementation doesn't fragment the network. It hardens it, the same way a second audit hardens a contract, by having independent code arrive at the same answer.

Bitcoin, refactored into parts you can build on

A rewrite is only worth doing if it leaves you with something better to build on, and here the Rust matters as much as the memory safety.

Bitcoin Core is a monolith: a program you run, not a library you import. qubitcoin is the opposite. Every layer of Bitcoin is its own crate: the primitives (uint256, amounts, txids, block hashes), the serialization, the script interpreter, the consensus rules, the P2P protocol, the storage engine. Each is an independent, up-to-date module any modern Rust project can depend on directly. Need Bitcoin's exact script verification in your own tool? Import the crate. You don't shell out to a node or reimplement it from a spec.

This is a property the whole SUBFROST software suite is built on, and qubitcoin is no exception: the entire thing compiles to WASM, and is otherwise fully cross-platform. That one fact unlocks everything below.

A Bitcoin node in the browser, and in your test suite

Because qubitcoin builds to WASM, a developer building on Bitcoin for the first time can run a Bitcoin node in the browser. No installing bitcoind, no syncing a chain, no standing up a regtest or testnet backend just to click through a manual test: the real validation engine, with the real rules, runs client-side.

More important still: you can test Bitcoin technology entirely inside cargo test, the ordinary Rust test suite, against the real rules of a Bitcoin regtest instance. Your software gets exercised the way any Rust library does: fast, deterministic, in CI, with no real funds and no external infrastructure. Anyone who has fought a flaky integration test against a live regtest node knows the size of that difference: a stateful, out-of-process dependency becomes a value you construct and assert on in memory.

And the P2P crates are a full implementation of the Bitcoin wire protocol, not a demo. SUBFROST already runs them out-of-band to track live mempool state for explorer.subfrost.io. The networking stack is real enough to sit on the public network today.

Expressive views, layered on the chain

qubitcoin also supports secondary indexes built on the primary L1 data. They're opt-in (the node does its job without them), but when you want a richer view, you layer asynchronous indexing on top of the initial block download instead of bolting a separate service onto the side.

This isn't new code with new bugs; it inherits years of research and development from metashrew. Indexers run in a sandboxed VM, fed by a change-data-capture pipeline modeled precisely to Bitcoin, so arbitrary transforms of the chaindata stay both expressive and safe. They are fault-tolerant by design: they follow reorgs gracefully rather than corrupting the way naive indexers do.

What you build on that ranges from views that read on-chain metaprotocols like Alkanes or Runes, to plain indexed by-address activity in the style of a mempool.space, all as opt-in modules over the same validated chainstate, with no trusted third party in the loop.

Parity you can verify, speed you inherit

Fidelity to Bitcoin Core is a claim, so we earned it the hard way. Part of building qubitcoin was rigorous forensics: packet-sniffing the live bitcoind software and establishing 1:1 parity with its network activity, message for message, so a qubitcoin node is indistinguishable from Core on the wire.

A rewrite also doesn't have to surrender the decade of tuning that went into the reference, so we ported it. Every optimization Bitcoin Core has accumulated, at the database layer and down the stack, is carried over and remodeled in Rust on a more modern RocksDB. You inherit ten years of C++ performance work without ten years of C++ memory bugs.

Built by a team that works in the code

None of this works if it comes from outsiders guessing at Bitcoin's internals.

SUBFROST is an independent team, and qubitcoin comes from people who work closely with the Bitcoin Core software itself: reading it, building against it, and tracking it commit by commit. A port that matters has to be written by people who can tell the difference between an implementation detail and a consensus rule. That kind of fidelity isn't a claim you can make from the outside; it's earned by knowing the reference software cold.

The upgrade you can't buy

The Bitcoin Security Consortium is right that the network's security deserves serious money, and right to raise the alarm early on quantum. When the network eventually migrates to post-quantum signatures (through a scheme like BIP-360, on the network's own timeline), that migration will be a deep change to the most sensitive code in the system. You want that change to land in a codebase where a mistake is a compile error, not a memory-corruption exploit. A clean, memory-safe implementation isn't opposed to the quantum effort; it's the foundation that makes surviving it more likely.

But the improvement that a fund can't buy is the one that was always missing: a second, independent, memory-safe implementation of the Bitcoin standard. Not to compete with Bitcoin. To complete it. The best way to improve a protocol is to give it another way to be correct.

That's what open-sourcing qubitcoin is for.

Explore the code

• qubitcoin: the 1:1 Rust port of Bitcoin Core
• metashrew: the secondary-index framework qubitcoin's indexers build on

---

qubitcoin is a consensus-compatible research and infrastructure project; it is not a fork of Bitcoin and proposes no changes to Bitcoin's rules. Nothing here is financial advice.