Kadena — On-chain voting for miners — Toward decentralization

What is a hard fork?

A hard fork is a mechanism that allows blockchains to evolve and implement new features. In short, a hard fork is a change to the chain’s rule set: the rules that determine whether a block is valid or not.

At some point in time, a new rule set replaces the old, and every block made after that must conform to the new rules.

It’s known as a “hard fork”, because any nodes that don’t recognize the upgrade will branch off into their own “fork” afterwards.

Changes requiring hard forks include:

• Adding new chains to chainweb
• User-visible bug fixes and new features in Pact
• Tokenomics changes

The current state

The team includes an “expiry date” with each node version release, to make sure that all “old nodes” turn themselves off before the next hard fork takes place. Miners can technically remove this expiry date from the code themselves, but hard forking changes are usually desirable to the community, so miners keep their nodes updated to avoid being stuck on a fork that the community isn’t interested in.

Almost all versions released include a new hard fork.

What’s coming next?

The node version 3.01 is the last version to include an expiry date (January 7th 2026).

The node’s version 3.1 includes a new mechanism: the on-chain miner fork voting system, similar to that of Bitcoin.

After Jan 7th 2026, miners — and node operators — will be able to freely decide whether they want the network to hard fork. Once 66% of miner hashrate comes from upgraded node software for a 5 day voting period, the chain will effectively fork automatically.

With this mechanism, miners are no longer dependent on periodic releases to keep their nodes running; they just decide whether to upgrade the network.

**Most readers can jump to the conclusion.** We now go into some detail about the fork voting mechanism.

How It Works — A Simplified View

What I will present here is not 100% technically accurate; it is intentionally simplified to make the concepts easier to understand, without altering their meaning.

Let’s assume: we have two set of rules:

• Red (old rules)
• And blue (new rules)

The time is divided into Fork Epochs (5 days each). Each fork Epoch is composed of two distinct periods:

• Voting period (119 hours = 14280 blocks)
• Counting period (1 hour = 120 blocks)

The diagram below represents a single Fork Epoch. Only 3 chains (out of 20) are shown for clarity.

Voting period

At the beginning of the Epoch, Red rules are in force, and will remain so at least until the end of that Epoch.

During the voting period, each miner sets a flag on every block it mines, indicating its preference for the rules to be applied in the next Fork Epoch.

In the above example: one miner wants to keep the old rules, and two are mining blocks with Blue flags, signalling their support for the new rules.

Counting period

There is, however, a challenge. Kadena is multi-chain. Voting happens per chain, but what we want is:

• cross-chain (X-Chain) consensus, and
• a fork that occurs simultaneously on all chains.

This is the purpose of the short counting period.

During this phase, chains exchange their voting data, then aggregate, normalize, and average their flag counters. By the end of the counting period, all chains share a consistent view of the global vote.

First block of the new Epoch

At this point, we have a clear picture of:

• what miners want, and
• which miners have actually upgraded their nodes.

Two outcomes are possible:

• Case 1: We have more than 66% of votes for the Fork (new Blue rules), asin the example above => Miners reached a 2/3 consensus. And Blue rules come into force immediately at first block of new Epoch. Miners still enforcing Red rules become incompatible with the network and are effectively excluded
• Case 2: We have less than 66% of votes for the Fork, the vote didn’t reached the required threshold => We keep the old Red rules, and a new voting period starts again … and again … until a 66% consensus is eventually reached.

Conclusion

With this update:

• The expiry date feature (sometimes called by critics the “kill switch”) is completely removed.
• Hard forking process is smoother, requiring two thirds of hashpower to participate for a few days at minimum. There is less risk of dramatic drops to hashrate.
• Hard forks are no longer scheduled by the team, but by miners, who choose their own timeline. Miners — especially solo miners — take on a new responsibility and can block decisions that would go against their own interests or harm the network’s resilience.

This is a major step toward real decentralization.

Miners, and node operators: don’t forget to upgrade your node to version 3.1 before midnight UTC, January 6!