Tag: Hard Fork

Nerva forked at block 4,320,000 on July 21, 2026, and the network is now running on CryptoNight-Adaptive v6. It went smoothly, and the numbers have already settled.

This was our first hard fork in over six years. The last one was February 6, 2020, at block 930,000. Six years and five months is a long time between forks, and getting a network this old through a Proof of Work change without drama is not a given. It happened because people prepared.

What the numbers look like now

If you glance at the explorer and panic, don’t. Here’s the before and after:

• Hashrate: ~400 – 800 kH/s before the fork, now stabilized between 25 and 40 kH/s
• Difficulty: 30M+ before, now around 2M+
• Block time: back to roughly 60 seconds, right on target

That’s over a 90% drop in the reported hashrate, which is almost exactly what we predicted before the fork. The number is smaller because each hash on the new algorithm does far more work. CNA v6 uses an 8 MB scratchpad, generates a fresh random program every block, and forces each memory access to depend on the previous one. Same hardware, same effort, far fewer hashes per second.

Comparing hashrate across two different algorithms is apples to oranges. A lower number here does not mean fewer miners or less security. We wrote a full explanation of this before the fork, and it holds up: Hashrate After Hard Fork 13: Why the Number Will Drop, and Why That’s Fine

Why it went smoothly

Hard forks go badly when nobody’s ready. This one had a two week runway, and the ecosystem used it.

Every centralized service integrated with Nerva upgraded to v0.3.0.0 before the fork: the exchanges (NonKyc, CexSwap, NoirTrade), the explorer and API, TipBot, NerVault, NervaQuest, and coinQuests. That meant no service downtime and nothing for their users to do.

Node adoption climbed steadily too, from 19% in the first two days after release to 69% by fork day. Most miners and node operators paid attention, and it showed.

What Hard Fork 13 actually changed

CryptoNight-Adaptive v6. The new Proof of Work keeps mining on ordinary CPUs and pushes back hard against ASICs, FPGAs, and GPUs. The larger scratchpad moves the working set out of CPU cache and into main memory, and the dependent access pattern stops fast chips from hiding memory latency. The practical result is that a high end machine can’t run away with the network the way it can elsewhere, and modest hardware stays competitive.

Privacy and consensus hardening. Transaction validation is stricter now, including a minimum output rule and tighter requirements on the outputs referenced by ring signatures.

Missed the upgrade?

If your node ran through the fork on an old version, it’s on the wrong chain, but it’s fixable.

1. Upgrade to v0.3.0.0: https://nerva.one/#downloads
2. Pop blocks back below the fork height with nervad --pop-blocks X, where X is your current height minus 4,320,000, plus about 10 for safety. In NervaOne, use Daemon Setup > Restart with Optional Command and enter --pop-blocks X.

Your node will resync onto the correct chain from there. Popping a few extra blocks does no harm.

What’s next

Work on Hard Fork 14 has already started. The plan includes CLSAG and Bulletproofs+ (smaller, faster transactions with the same privacy), a ring size increase for a larger anonymity set, and potentially CryptoNight-Adaptive v7 to even out per-core hashrate further across different CPUs. No fork heights are set, and nothing changes until they are.

The direction is the same as it’s always been: close the privacy gap with Monero while keeping what makes Nerva different, solo CPU mining with no pools and no central authority. 1 CPU = 1 Vote.

Thank you

This went well because the community made it go well. People developed, tested, reported issues, upgraded their nodes, and nudged the stragglers. Contributors wrote the code, reviewed it, and shipped it.

Nerva has always stood for one CPU, one vote. With HF13 live, reality moved a lot closer to that vision.

If you’re watching Nerva’s network hashrate around Hard Fork 13, brace yourself for a big drop. Right after the fork, net hashrate is going to fall sharply, we expect around a 90% drop, from 400 – 800 kH/s in the last few months to somewhere around 50 kH/s afterwards.

Before anyone panics: this is expected, it’s healthy, and it does not mean the network got weaker. Here’s exactly what’s happening and why.

The short version

Hashrate measures how many hashes the network computes per second. Hard Fork 13 replaces the mining algorithm with CryptoNight-Adaptive v6, and each hash on the new algorithm does far more work than a hash on the old one. So the same computers, working just as hard, produce far fewer hashes per second.

The number goes down because the unit changed, not because the network lost security or miners.

Why each hash is now so much heavier

Three things make a CNA v6 hash much more expensive to compute than the old algorithm:

1. A 4x larger scratchpad. The old algorithm used a 2 MB memory buffer per hash. CNA v6 uses 8 MB. Every single hash now has to work through four times as much memory.
2. A random program per block. Instead of one fixed calculation, each block runs a freshly generated program of hundreds of instructions, executed thousands of times. That’s a lot more computation packed into every hash.
3. Dependent memory access. The algorithm is built so each memory step depends on the result of the one before it. Your CPU can’t run ahead or do the work in parallel, it has to wait for each step, which deliberately slows each hash down.

Add those together and a single hash takes far longer than it used to. If each hash takes roughly ten times as long, the hashes-per-second number falls by about ninety percent. Same hardware, same effort, much heavier hash.

Comparing the two numbers is apples to oranges

This is the key thing to understand: you cannot compare hashrate across two different algorithms. It’s like comparing miles per hour to laps per hour. A lower number on a longer track doesn’t mean you slowed down.

500 kH/s on the old algorithm and roughly 50 kH/s on the new one represent a similar amount of real work being done by a similar set of machines. The headline number shrank because each hash now counts for a lot more.

What about network security?

A smaller hashrate number does not make Nerva easier to attack. Security comes from how expensive it is to out-compute honest miners on the same algorithm, and CNA v6 is more expensive and more resistant to specialized hardware than the old algorithm, not less.

In fact, the new algorithm strengthens security in ways the raw number doesn’t show. The large memory requirement and random program are specifically designed to shut out ASICs, FPGAs, and GPUs, keeping mining on general-purpose CPUs where it stays widely distributed. An attacker can’t just buy specialized machines to overpower the network. They’d have to out-CPU everyone else, on an algorithm built to keep any single machine from running away with it.

What miners will notice

Your personal hashrate number will drop too, and that’s completely normal. What matters is your share of the network, and everyone’s numbers drop together, so your slice, and your rewards, stay proportional.

A few other things to expect:

• Block times stay normal. Difficulty automatically readjusts to the lower hashrate, so blocks keep coming at about 60 seconds.
• Un-upgraded miners fall off the real chain until they update to v0.3.0.0.

Bottom line

When you see Nerva’s hashrate drop around 90% at Hard Fork 13, that’s the algorithm change doing exactly what it’s supposed to. The number is smaller because each hash is much bigger. The network is just as secure, more resistant to specialized hardware, and still mined by everyday CPUs the way Nerva is meant to be.

Nerva has always stood for one CPU, one vote. With HF13, reality just moved a lot closer to that vision.

If you haven’t upgraded yet, do it before the fork at block 4,320,000 so you don’t miss a beat: https://nerva.one/#downloads