Zecnero: a fair-launch proof-of-work fork of Zcash

1Introduction

Zecnero bridges the transparent payment scheme of Bitcoin with shielded payment schemes secured by zero-knowledge proofs. All value belongs to one of three chain value pools: transparent, Sapling and Orchard. On Mainnet no transaction can add value to the Sapling pool, so all shielded value is in the Orchard pool. The testnet follows from its network upgrade NU2: from then no transaction can add value to the Sapling pool or take value from it, so Sapling notes not moved to Orchard before it can no longer be spent. Transparent value moves essentially as in Bitcoin, with the same privacy properties, but from network upgrade NU1 only a coinbase transaction may create a transparent output. Value in a shielded pool is carried by notes, each with a commitment revealed when it is created and a nullifier revealed when it is spent; without the right key, the two cannot feasibly be linked.

Blocks are produced by proof of work. A miner searches for a header whose RandomX-Zecnero hash, read as an integer, does not exceed a target; from NU2 that value is a commitment to a RandomX version 2 hash. The target is computed from the genesis time, the height of the chain and the timestamp of the previous block, so that blocks arrive on average every 75 seconds. Each block pays its miner a subsidy that halves every 1,680,000 blocks, together with the fees of the transactions it contains. During the first halving period each block also pays a fixed fraction of its subsidy to a published founder script.

This is a draft. The specification marks several values as undecided, and those must not be used on any public network.

2Notation

The specification writes byte sequences, integers and bit sequences with explicit types, and gives every integer constant a name in sans-serif, defined once in §5.2. All integers in Zecnero-specific encodings, including block and transaction fields, are unsigned and little-endian unless stated otherwise (§5.1). SHA256d means SHA-256 applied twice.

Block hashes are written in RPC byte order, which is the reverse of the raw output of SHA256d. Amounts are counted in nero: one ZMR is 10⁸ nero, and every currency constant in the document is in nero. Time constants are in seconds.

3Concepts

All value belongs to one of three chain value pools: transparent, Sapling and Orchard; on Mainnet every shielded note is an Orchard note, and so is every note the testnet creates from NU2. Transparent value moves as in Bitcoin; from NU1 only coinbase transactions create it. Shielded value is carried by notes; creating a note reveals its commitment, spending it reveals its nullifier, and without the owner’s key the two cannot feasibly be linked. Zero-knowledge proofs show a spend is valid without saying which earlier note it spends.

Sapling and Orchard keys, viewing keys and diversified addresses are derived as §3.1 describes, and §5.3 instantiates every scheme behind them exactly as Zcash does at NU6. Wallets should derive keys with ZIP 32 under the Zecnero coin type. One caution is specific to a fork: the same spending key produces the same shielded addresses on Zecnero and on Zcash, so a wallet should use a separate account or coin type for each network, or the two histories can be linked.

Each block creates a subsidy. Below the first halving it is split between the miner and the founder stream; after that the miner receives all of it, plus the fees. Mainnet carries ZMR; Testnet runs the same rules with a currency of no value, and may be reset at any time.

4Abstract Protocol

Zecnero inherits every abstract cryptographic scheme of the Sapling and Orchard protocols from Zcash unchanged: the note commitment trees, the pseudorandom functions that derive nullifiers and keys, note encryption, the spend-authorization and binding signatures, Groth16 for Sapling and Halo 2 for Orchard.

Two abstractions are new. The proof-of-work function takes a 32-byte key and a 140-byte input, and changes key on a schedule that depends on the chain. It must be hard (no shortcut below about 2²⁵⁶/(T+1) evaluations), progress-free (each attempt is independent, so a miner’s share of blocks matches its share of work), hardware-neutral (no cheaper per unit of energy or capital on specialised hardware than on a general-purpose processor), and cheap enough for every validator to check.

The difficulty adjustment function is absolutely scheduled: the target for the next block depends only on constants, the genesis block, and the height and timestamp of the tip, never on intermediate blocks.

5Concrete Protocol

5.4 RandomX-Zecnero

Proof of work is RandomX with one change from the reference configuration: the Argon2 salt is "ZecneroRX" || 0x01 instead of Monero’s "RandomX" || 0x03. A different salt produces an unrelated cache, dataset and hash function, so hardware and software that only implement Monero’s configuration cannot mine Zecnero. Every other parameter is the reference value and must not be changed.

RandomX-Zecnero has two versions with the same salt, key schedule, cache and dataset. rx/zecnero is RandomX program version 1. rx/zecnero2 is program version 2 as released in RandomX 2.0.1: programs of 384 instructions instead of 256, and the value compared with the target is BLAKE2b-256 of the 140-byte header input followed by the hash. The testnet uses rx/zecnero2 from its network upgrade NU2. Mainnet launches with one of the two, and the version is being finalized on the testnet. The 2019 audits of RandomX cover version 1; no audit of version 2 has been published.

The RandomX key for a block is the hash of an ancestor block, and it changes every 2,048 blocks (about 42.7 hours), fixed 64 blocks before first use. The hash is computed over the first 140 bytes of the header, every field before the solution. Mining uses fast mode, which needs a dataset of about 2,080 MiB per key; validation uses light mode, which needs a 256 MiB cache and costs milliseconds per hash.

5.5 Difficulty

The target follows aserti3-2d. From network upgrade NU1 the half-life is 3,600 seconds: every hour the chain is behind schedule doubles the target, and every hour ahead halves it. Mainnet has NU1 from block 1, so its schedule is anchored at genesis: the block at height h is scheduled at genesis time plus 75 × h seconds. The testnet uses a 7,200-second half-life anchored at genesis until its network upgrade. There the schedule is re-anchored at the block before the upgrade, with the target the old schedule gives the upgrade block, so difficulty carries on without a jump. There is no Testnet minimum-difficulty rule.

5.6 to 5.8 Header, timestamps, transactions

The header keeps the Zcash layout with an empty solution field, 141 bytes in all. A block’s timestamp must be above the median of the last 11 blocks and at most 2,700 seconds past it, and a node rejects one more than 900 seconds ahead of its clock; Zcash allows 90 minutes and 2 hours, which an exponential difficulty algorithm cannot afford. Only version 5 transactions are accepted. Blocks are at most 2,000,000 bytes.

5.9 Subsidy, founder stream and coinbase

The subsidy is 6.25 ZMR per block, halving every 1,680,000 blocks and reaching zero after 30 halvings, for a total of 20,999,993.5652 ZMR. There is no slow start. Below height 1,680,000 every coinbase must also pay at least ⌊subsidy × 3 / 100⌋, 0.1875 ZMR at the first subsidy, to the published founder script: 314,999.8125 ZMR in all, about 1.5% of total issuance. Coinbase outputs mature after 100 blocks.

5.11 to 5.14 Encodings, network and genesis

On the testnet before NU2, Sapling proofs use the parameters of Zcash’s Sapling ceremony unchanged; Mainnet has no Sapling Spend or Output, and the testnet none from NU2, so a Mainnet node verifies no Sapling proof, and Orchard needs no parameters. A Mainnet Sapling address is a valid encoding that no transaction can pay, as is a testnet one from NU2, and a Mainnet unified address carries an Orchard receiver only. The genesis coinbase names a recent Bitcoin block, mined no more than 24 hours before the genesis time, and pays nothing: its one output is OP_RETURN with value 0.

6Network Upgrades

Zecnero changes its rules by network upgrades in the ZIP 200 style: an activation height and a new consensus branch identifier. The rules at launch form the first upgrade, Genesis, with branch identifier 0x01524D5A (the bytes of “ZMR” and 0x01). It incorporates the Zcash upgrades Overwinter through NU6. The second, NU1, has branch identifier 0x02524D5A and protocol version 180100. From NU1 a transaction that is not a coinbase transaction must have no transparent outputs, coinbase outputs must be shielded before they are spent on Testnet as on Mainnet, and the difficulty half-life is 3,600 seconds. Mainnet has NU1 from block 1. The testnet runs Genesis from block 1 and activates NU1 at its network upgrade. The third, NU2, has branch identifier 0x03524D5A and protocol version 180200. From NU2 blocks are mined with rx/zecnero2, and on the testnet no transaction may have a Sapling Spend or Output; the difficulty carries on without a new anchor. The testnet activates NU2 at a height announced with its release, expected on Sunday, November 8, 2026. Whether Mainnet launches with NU1 or NU2 depends on the RandomX version being finalized on the testnet. Mainnet’s rule that no transaction has a Sapling Spend or Output is not part of an upgrade: it holds from block 1 and changes no branch identifier. On the testnet the same rule is part of NU2.

Changes Zcash makes after NU6 do not apply unless a later Zecnero upgrade adopts them, with one exception: two security fixes from Zcash NU6.2 apply from height 1. Orchard proofs must verify under the corrected circuit, never the unsound one Zcash used from NU5 until NU6.2, and the Orchard proof field must be exactly the size its number of actions requires. Zecnero never enables the temporary rule Zcash used to disable Orchard while that fix was prepared.

7Consensus Changes from Zcash

Removed

• The Sprout shielded protocol: JoinSplits, its tree and nullifier set, and BCTV14 proofs.
• Version 1 to 4 transactions from height 1.
• The Founders’ Reward, funding streams and the development fund lockbox.
• The slow start and the Blossom subsidy adjustment.
• Equihash, the Zcash difficulty algorithm and the Testnet minimum-difficulty rule.

Replaced

• Proof of work: RandomX-Zecnero over the 140-byte header prefix; from NU2, a commitment to a RandomX version 2 hash of it.
• Difficulty: aserti3-2d, with a 3,600-second half-life from NU1.
• Subsidy: 6.25 ZMR, halving every 1,680,000 blocks.
• Timestamp bounds, and the network identity: magic, ports, branch identifier, address encodings and genesis.
• The Orchard circuit and proof-size rule: the corrected NU6.2 versions, from height 1.

Added

• The founder stream.
• The genesis commitment to a recent Bitcoin block.
• The maximum reorganisation depth and checkpoint rules.
• From NU1, shielded-only payments: no transparent outputs outside coinbase.
• On Mainnet from block 1, and on the testnet from NU2: no Sapling Spend or Output descriptions.

For the same list in plain words, see Zecnero vs Zcash.

8Chain Selection

A node never switches to a chain that would disconnect more than 20 blocks from its current best chain, even one with more work. At 75 seconds a block that is 25 minutes; Zcash nodes allow 100. Each release also carries checkpoints on the Mainnet chain, and a node refuses any chain that conflicts with them.

These are rules of node behaviour, not of block validity. They protect synchronised nodes from an attacker who mines a longer chain in private and publishes it later. The cost is that a partition longer than 20 blocks does not heal on its own: operators have to choose a chain.

9Rationale

Proof of work. The goal is that the most efficient mining hardware looks like the hardware people already own. RandomX runs random programs modelled on general-purpose processors, has secured Monero since November 2019, and was audited four times before deployment. New Equihash parameters would only delay ASICs; GPU algorithms would hand the early chain to idle GPU farms; an unreviewed new algorithm may contain shortcuts, and whoever first writes an optimized implementation gains a private advantage during launch. A private salt separates Zecnero from Monero’s hardware and hashrate while leaving the audited design untouched. RandomX version 2, which no published audit covers, runs on the testnet from NU2 before the version Mainnet launches with is set.

Difficulty. A new chain sees sudden hashrate swings. ASERT depends only on the anchor and the tip, has no window to game, and recovers within a few half-lives. Its half-life is one hour from NU1 (the testnet started with two hours), not Bitcoin Cash’s two days, because blocks are eight times more frequent and a small chain must react within hours.

Issuance and founder allocation. About 21 million with a halving about every four years, then fees only; a tail emission was considered and not adopted. The founder stream is fixed in consensus and published before launch, paid by every block whoever mines it, and ends at the first halving. Sprout is removed: a new chain has no Sprout funds, and carrying the code adds risk for no benefit.

10Launch Procedure

1. A public Testnet runs for several weeks with independent miners before Mainnet parameters are fixed. It activates NU2 in that time, and the RandomX version Mainnet launches with is set after that run.
2. At least a week before launch, the genesis time, the source code, the founder script and its address, and the founder’s mining addresses are published.
3. Shortly before the genesis time, a recent Bitcoin block is chosen and the genesis block is built and mined.
4. At the genesis time, the node and miner, reproducible build hashes and the genesis hash are published together.
5. From then on anyone may mine. The founder mines with the published software from the published addresses and does not mine before the software is public: a commitment, bounded by the Bitcoin block in the genesis block.

11Security Considerations

• Majority attacks. Hashrate can be rented. The 20-block limit bounds reversals seen by running nodes; recipients of significant payments should wait at least 20 confirmations, and more when the value at stake is large. The protocol makes no stronger finality guarantee.
• Compromised machines. A proof of work efficient on general-purpose processors is also efficient on compromised computers and misused cloud accounts; the protocol cannot distinguish them from other miners.
• Specialised hardware. If hardware with a large RandomX-Zecnero advantage appears, the proof of work can be changed by network upgrade.
• Timestamp manipulation. The tight timestamp bounds limit how far a miner can lower difficulty for its own blocks.
• Trusted setup. Sapling relies on Zcash’s ceremony; Orchard has no such assumption. Mainnet has no Sapling transactions, and the testnet none from NU2, so this applies only to the testnet before NU2.
• One shielded pool. On Mainnet the Orchard pool holds all shielded value, so a soundness flaw in the Orchard circuit would affect the whole shielded supply, with no second pool to move to. The turnstile detects counterfeit value when it would leave the pool.
• Cross-network linkability, implementation risk, economics and regulation. Keys can link Zcash and Zecnero activity; a divergence between implementations can split the network; a miner’s expected share equals its hashrate share and nothing makes mining profitable; privacy assets face restrictions in several jurisdictions.

ADifficulty Algorithm

Appendix A gives a reference implementation of aserti3-2d in Rust, with a 512-bit integer for the final steps, and these worked examples. T₀ is the genesis target, 2²³⁶. The examples use NU1’s 3,600-second half-life: every hour behind schedule doubles the target, and every hour ahead halves it.

BIssuance Schedule

Subsidy per block and cumulative issuance at the end of each halving period. The first period is one block shorter, because height 0 is the genesis block. The PDF lists all 30 periods.