Zcash has some of the best privacy cryptography in production. It has zero-knowledge shielded pools, Halo 2 with no trusted setup for Orchard, and a Rust node called Zebra. Its proof of work, Equihash, has been dominated by ASICs for years. If you want to mine Zcash on the desktop you already own, you can't do it in any meaningful way.
Monero went the other way. Since November 2019 it has used RandomX, a proof of work built so that the most efficient hardware looks like an ordinary CPU.
Zecnero (ticker ZMR) combines the two. It is a fork of Zebra, pinned at v6.3.0, with a short, fixed list of consensus changes. The biggest change is that Equihash is replaced by RandomX. This post covers what changed, what stayed, and the reasoning behind each choice.
Status, stated plainly: a public testnet has run since September 24, 2026. Mainnet has not launched. There is no market, no price and no sale of any kind. Testnet coins have no value.
What was kept#
The cryptography is kept completely. Sapling and Orchard keys, notes, commitments, nullifiers, note encryption, signatures and proofs are instantiated exactly as in Zcash. That includes the Zcash domain-separation strings. The Sapling parameters from Zcash's multi-party ceremony are reused unchanged. Orchard needs no parameters.
Transparent addresses and scripts work as they do in Bitcoin and Zcash. Everything the Zecnero specification doesn't change follows the Zcash protocol at NU6.
One practical consequence: the same spending key produces the same shielded addresses on Zcash and on Zecnero. If you use both networks, use a separate seed, account or coin type for each. Otherwise someone who watches both chains can link them.
What was removed#
- Sprout, Zcash's first shielded pool, along with its JoinSplits and BCTV14 proofs. A new chain has no Sprout funds to support, and keeping the code adds risk with no benefit.
- Transaction versions 1–4. Only v5 is valid.
- The Founders' Reward, funding streams and the dev fund lockbox. A single smaller founder stream replaces them (details below).
- The slow start. The full subsidy is paid from block 1.
The proof of work: RandomX-Zecnero#
RandomX runs randomly generated programs. Their instruction mix and memory behaviour are modelled on general-purpose processors, so a desktop CPU does the work well and a GPU adds little.
Zecnero uses the audited RandomX v1 reference configuration with exactly one change, the Argon2 salt:
| Salt | |
|---|---|
| Monero | "RandomX" \|\| 0x03 |
| Zecnero | "ZecneroRX" \|\| 0x01 |
A different salt produces an unrelated cache, dataset and hash function. As a result, Monero's hashrate, and any hardware or software that only implements Monero's configuration, can't be pointed at Zecnero. Every other parameter stays at its audited value.
Why not something else?
- New Equihash parameters would only delay ASICs.
- A GPU algorithm would hand the early chain to idle GPU farms.
- A brand-new algorithm hasn't been reviewed. It may contain shortcuts, and whoever first writes an optimized implementation gets a private advantage during launch.
A few more details from the spec:
- The RandomX key is the hash of an ancestor block. It rotates every 2,048 blocks (about 42.7 hours) and is fixed 64 blocks before first use.
- The hash is computed over the first 140 bytes of the header, which is every field before the (now empty) solution. The header is 141 bytes.
- Miners use fast mode, which needs a dataset of about 2,080 MiB. Validators use light mode, which needs a 256 MiB cache and costs milliseconds per hash.
- The block hash is kept separate from the proof-of-work hash.
The miner is xmrig-zecnero, an XMRig build that knows the rx/zecnero algorithm and the Zecnero header.
Difficulty: ASERT with a two-hour half-life#
A new, small chain sees sudden hashrate swings. Zcash's averaging window would leave blocks slow for a long time after a big miner leaves.
Zecnero uses aserti3-2d, the absolutely scheduled exponential algorithm from Bitcoin Cash, anchored at genesis. ASERT depends only on the anchor and the tip. It has no window to game, and it recovers within a few half-lives.
Bitcoin Cash uses a two-day half-life. Zecnero uses two hours, because its blocks come eight times more often (a 75 s target) and a small chain has to react within hours. The testnet is the first real data on whether 7,200 s is the right value. A study of that is on the roadmap.
Two rules follow from this choice:
- Tighter timestamps: at most 2,700 s past the median of the last 11 blocks, and at most 900 s into the future.
- A 20-block reorg limit. Nodes refuse to reorganise more than 20 blocks, about 25 minutes of chain. Renting hashpower is still possible, and a majority miner can still censor and reverse recent blocks. The limit caps how much history a reorg can undo.
Issuance and the founder stream#
- 6.25 ZMR per block from block 1
- The subsidy halves every 1,680,000 blocks (about four years at 75 s)
- Zero after 30 halvings, for a total of 20,999,993.5652 ZMR
- No tail emission. After that, miners are paid by fees alone.
The only allocation is a founder stream. Every block below the first halving pays 3% of its subsidy (0.1875 ZMR) to a published P2SH founder script. That comes to 314,999.8125 ZMR, which is 1.5% of all ZMR that will ever exist. The 3% and the 1.5% describe the same thing in two ways; don't add them. Nodes reject any block that leaves the payment out, so the stream is visible and fixed, and it stops permanently at the first halving.
There is no premine, presale, dev fund or treasury, and no block height is reserved for anyone. Before mainnet, the founder script and the founder's mining addresses will be published, so anyone can measure the founder's share of early blocks. The genesis block commits to a recent Bitcoin block, which proves it wasn't made before that block existed.
Network identity#
| Zecnero | Zcash | |
|---|---|---|
| P2P port | 8733 (testnet 18733) | 8233 |
| RPC port | 8732 (testnet 18732) | 8232 |
| Branch ID | 0x01524D5A ("ZMR" + 0x01) |
Zcash's own |
| Addresses | N1…, N3…, ns1…, nu1… |
t1…, t3…, zs1…, u1… |
An honest note on Orchard#
The node verifies Orchard proofs only under the corrected circuit that Zcash introduced at NU6.2, from height 1. The wallet's libraries already contain that circuit, but one line in their network-upgrade table still maps Zecnero's branch to the older revision. An Orchard proof built with them today would be invalid, and the node would refuse it. Nothing reaches the chain and no coins are at risk. For now the wallet refuses Orchard and unified addresses with a clear error. The fix ships with the next testnet network upgrade.
Try it#
The testnet is open. The one-command installer verifies the signed release, has you save a mining key, and starts mining on the testnet pool about a minute later:
# Linux, or Ubuntu under WSL 2
curl -fsSL https://downloads.zecnero.org/install-miner.sh | bash
# Windows PowerShell (sets up WSL if needed)
irm https://downloads.zecnero.org/install.ps1 | iex
Or run the miner directly against the pool:
xmrig-zecnero -o stratum.zecnero.org:3334 --tls -u YOUR_TESTNET_ADDRESS -a rx/zecnero
- Spec (PDF): https://zecnero.org/zecnero-protocol.pdf
- Source: https://gitlab.com/zecnero
- Explorer: https://explorer.zecnero.org
- Mining guide: https://zecnero.org/mine
Consensus review is especially welcome now, while changing consensus is still cheap. Security issues go privately to security@zecnero.org.
Zecnero is not affiliated with the Zcash Foundation, Electric Coin Co., the Monero Project or XMRig. Testnet coins have no value. Nothing here is investment advice.
Comments
No comments yet. Start the conversation.