Every Monero node on the network today runs the same software: monerod, a 250,000-line C++ codebase maintained by the same team since 2014. A consensus bug or a memory-safety vulnerability would affect 100% of the network at once. Cuprate is the antidote — an independent Monero node implementation written from scratch in Rust, with a modular crate-based architecture, full Tor support, and an async tower::Service design that lets it be embedded as a library rather than just run as a daemon. Still experimental as of v0.0.7 "Molybdenite" — but it's the most serious second implementation Monero has ever had.
Bitcoin learned this lesson the hard way: a network running a single implementation is a network one bug away from a chain split or worse. Bitcoin Core's dominance has long been a debated risk. Ethereum split its implementation across Geth, Erigon, Nethermind, Besu, Reth — partly to avoid exactly that. Monero today is where Bitcoin was: monoculture. Every monerod shares the same bugs, the same parser, the same database engine, the same potential CVEs.
If monerod has an edge case where two valid blocks are interpreted differently by different builds, the entire network forks. With one implementation, there's no "second opinion" to detect this before it ships.
monerod is C++. Buffer overflows, use-after-frees, signed-overflow UB — all classic remote attack surfaces. A bad incoming P2P message has historically been able to crash or worse. Rust eliminates entire classes of these by construction.
The monerod codebase is large, organic, and concentrated in a small group of maintainers. A clean-room rewrite in a modern language with a modular design is much easier to onboard new contributors into.
Cuprate's lead developer hinto-janai has explicitly drawn the analogy. Reth (Rust Ethereum) and Erigon proved that a clean-room alternative client can not only catch up to the reference implementation but often surpass it in performance and clarity. Cuprate is trying to do for Monero what Reth did for Ethereum — and it's borrowing many of the same architectural patterns (Tower services, modular crates, async-first design).
The two implementations target the same protocol but make very different engineering choices. monerod is the product of a decade of incremental evolution from the original Bytecoin/CryptoNote codebase; Cuprate is a 2023-onwards clean-room rewrite that gets to pick modern defaults from day one.
torsocks or proxyCuprate isn't really "a program." It's a library of crates from which the cuprated binary is assembled. This is the deepest architectural break from monerod. Each crate is independently versioned, independently tested, independently usable by third-party Rust code (a wallet, a block explorer, a research tool) — and the daemon is just one consumer of them.
Connection handling, handshake state machine, network zone abstraction. Implements the Levin protocol from the P2P schema.
Peer set management, address book, sync logic. Built on cuprate_p2p_core. What cuprated actually uses to gossip.
Pure implementation of the Levin binary protocol that the previous P2P schema described. Codec only — no networking opinions.
Strongly-typed Monero P2P message definitions. Replaces monerod's verbose epee glue with Rust enums and derive macros.
Dandelion++ stem-then-fluff propagation. Built as a Tower middleware so it composes cleanly with the rest of the P2P stack.
Pluggable transport. Arti integration for Tor onion services, plus the standard clearnet TCP. Network zones are first-class.
Abstract database traits. Defines what a Monero storage backend must do; the concrete backend is pluggable (currently heed/LMDB).
The actual blockchain tables: blocks, transactions, outputs, key images. Implements the schema monerod's blockchain.db uses, but typed.
The transaction pool. Holds pending txs, runs admission rules, evicts stale entries. Asynchronous from day one.
Hard-coded block hashes up to a recent height. New nodes can skip full validation of ancient history and trust the binary's bundled checkpoints — drastically faster initial sync.
The heart of Cuprate's correctness story. Validates block headers, transactions, ring signatures, fee rules, hard fork rules. Independent reimplementation of monerod's validation logic.
Per-hard-fork rule definitions. Monero has had many forks (v1 → v16+), each with different rules; this crate encodes them all.
Pure-Rust CryptoNight implementation for validating pre-RandomX blocks. (RandomX itself uses tevador's reference library via FFI — see RandomX schema.)
Built on axum. Routes /get_block, /json_rpc, /send_raw_transaction etc. to handler services.
Strongly-typed request/response definitions for every monerod RPC endpoint. Lets other Rust projects type-check their RPC calls.
JSON-RPC 2.0 framing layer. Generic — could be used for non-Monero projects.
ZeroMQ message definitions for the pub/sub feed (block notifications, txpool notifications). Matches monerod's existing ZMQ contract.
The kitchen-sink crate. Block, Transaction, Output, HardFork enum, RingCt variants, chain identifiers. The vocabulary all other crates share.
Pure-Rust implementation of monerod's "epee" binary format. The wire format that everything in the Monero ecosystem speaks.
Cross-cutting helpers: time, paths, encoding, math. The "everything-else" crate.
Block pruning logic for nodes that don't want to keep the entire history. Monero pruning preserves enough of each block to validate but discards old ring members.
The actual daemon. Wires all the above crates together with a Tokio runtime, config loading, signal handling, RPC server, P2P server. ~5% of total LoC.
The point isn't just that this is cleaner code. It's that any of these crates can be used by other Rust projects. Want to build a block explorer? Pull in cuprate_blockchain and cuprate_types. Want to write a P2P scanner that connects to Monero peers and logs traffic? Use cuprate_p2p_core directly. monerod offers no such factoring.
Cuprate's biggest architectural innovation is its use of the Tower crate's Service trait — the same pattern Tokio uses for HTTP, Linkerd uses for service meshes, and Zcash's zebrad pioneered for blockchains. Every Cuprate subsystem (database, network, mempool, consensus) is a Tower service: an async function from a request to a response. They compose like Lego.
poll_ready means a service can say "I'm overloaded, wait." This propagates up — a slow database means the P2P layer stops reading from peers, preventing memory blowup. monerod has had to hand-engineer this in many places.
Want to add rate limiting to RPC? Wrap the RPC service in RateLimitLayer. Want to add tracing? Wrap in TraceLayer. New behaviors are middleware crates that drop in.
Mock services are trivial — just implement Service with a closure. The consensus crate can be tested without a real database; the P2P crate can be tested without a real consensus. monerod's tightly-coupled module structure makes equivalent testing far harder.
As of release 0.0.7 "Molybdenite" (late 2025), Cuprate is a real-but-experimental node. It can sync the Monero chain, validate consensus rules, gossip on the P2P network, and serve a useful subset of RPC. It cannot yet mine or fully replace monerod for an exchange. The roadmap is open and CCS-funded.
| Capability | Status | Notes |
|---|---|---|
| Block validation | ✓ Working | cuprate_consensus validates the chain through all hard forks back to genesis. |
| P2P networking | ✓ Working | Levin handshake, peer discovery, block/tx propagation, Dandelion++. |
| Tor support | ✓ Working | Built-in via Arti as of v0.0.6 (Aug 2025). No external torsocks needed. |
| Initial sync | ✓ Working | Fast-sync to height ~3.45M using bundled checkpoints; full validation thereafter. |
| RPC (read) | ~ Partial | get_block, get_block_count, get_height, get_block_headers_range available. Many more pending. |
| RPC (write) | ~ Partial | submit_block and send_raw_transaction enabled in v0.0.5. More endpoints landing per release. |
| Transaction pool | ✓ Working | Pool manager added in v0.0.6 with relay rules and persistence. |
| Block reorganization | ✓ Working | Including recovery from failed reorgs (v0.0.3). |
| Mining (template assembly) | ○ Not yet | No get_block_template RPC, so no pool/solo mining yet. |
| Wallet protocol | ○ Not yet | cuprate-wallet exists as a placeholder; no scanner/builder yet. |
| Pruning | ○ Crate exists | cuprate_pruning has the logic; integration into cuprated still in progress. |
Cuprate is community-built and funded through Monero's Community Crowdfunding System (CCS). Core contributors over the project's life: SyntheticBird45 (original founder), hinto-janai (current lead, RPC + binary), Boog900 (consensus, P2P), Asurar0, dimalinux, jomuel, kayabaNerve (also leads FCMP++ — see that schema). Multiple have had multiple full-time CCS-funded development periods. The Monero Research Lab and reference monerod developers have been broadly supportive.
From a single contributor's hobby project to a serious second-implementation candidate.