# October 2025: Snake8 Hard Fork

## Summary

The upcoming SNAKE8 hard fork implements a randomized block producer algorithm, and enforces a minimum selection frequency, thus replacing the current system where validators receive an equal number of blocks.

This algorithm is designed to enhance competition among Chiliz Chain validators, and to incentivize contribution to the ecosystem. This is a change from the current logic which brings no advantage to validators who really go the extra mile to contribute to the ecosystem.

With the SNAKE8 hard fork, blocks are distributed based on the amount of CHZ staked on a validator node by delegators. This will give a higher probability of mining the next block to validators who attract more delegators, thus giving them the opportunity to accumulate more rewards.

## Details on the new block production algorithm

The new randomized Proof of Stake algorithm with enforced minimum selection frequency operates as follows:

* The probability of a validator node being selected to produce a block is directly proportional to the amount of governance tokens (CHZ) staked on it.
* To ensure all active validators have a chance to produce blocks, no validator node's selection frequency will fall below 1/(2\*N), where N is the total number of validator nodes.

The sum of all validator selection frequencies will always equal 100%.

## Algorithm Overview

The algorithm ensures the fair and proportional distribution of block production opportunities through an iterative adjustment process:

1. Calculate Initial Frequencies: \
   An initial frequency `fi` is computed for each node `i` based on its staked tokens `Si` relative to the total staked tokens `Stotal`.

<figure><img src="https://3400301555-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4L7rBH2rmyoBTn93MSdx%2Fuploads%2FPJjCBeSIPxeg9Ce2Vxov%2Fimage.png?alt=media&#x26;token=90101e48-2a32-45c2-a09f-8eb59a64cc6c" alt=""><figcaption></figcaption></figure>

2. Enforce Minimum Frequency: \
   An initial frequency `fi` is computed for each node `i` based on its staked tokens `Si` relative to the total staked tokens `Stotal` (`fi = Si / Stotal`).

<figure><img src="https://3400301555-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4L7rBH2rmyoBTn93MSdx%2Fuploads%2FxBcwbOyskLPtIDJLfyvf%2Fimage.png?alt=media&#x26;token=f6bfdb08-c4d8-461c-9284-b79f29380374" alt=""><figcaption></figcaption></figure>

3. Adjust Remaining Frequencies: \
   To maintain a total sum of 100% for all frequencies, the frequencies of nodes that are above the minimum threshold are proportionally reduced. This reduction compensates for the increases made in the previous step.

<figure><img src="https://3400301555-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4L7rBH2rmyoBTn93MSdx%2Fuploads%2FjXteWv1RvgbA1kdx17FD%2Funknown.png?alt=media&#x26;token=013ad28b-ebe5-484d-a0d9-4951b93ff0b7" alt=""><figcaption></figcaption></figure>

4. Iterative Adjustment: \
   If, after the proportional reductions, any node's frequency inadvertently falls below the minimum, the adjustment process is repeated iteratively. This ensures that all nodes consistently meet the minimum frequency requirement while the total frequency remains 100%.

<figure><img src="https://3400301555-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4L7rBH2rmyoBTn93MSdx%2Fuploads%2Fd4xAtqPDwyxuNC07Zayv%2Funknown.png?alt=media&#x26;token=4bbe35d4-221e-4186-a88b-b2f6937e3b5a" alt=""><figcaption></figcaption></figure>

## Example

This example scenario demonstrates how the validator reward logic adjusts node frequencies based on staked tokens, minimum frequency, and proportional adjustments.

For this example, we’ll use:

* 4 validator nodes (N=4),&#x20;
* each with a given number of staked tokens (respectively 80, 65, 10, and 3).

This scenario results in this table:

| Node        | Initial Frequencies | After Enforcing Minimum | After Proportional Adjustment |
| ----------- | ------------------- | ----------------------- | ----------------------------- |
| 1           | 0.506329            | 0.506329                | 0.413                         |
| 2           | 0.411392            | 0.411392                | 0.336                         |
| 3           | 0.063291            | 0.125                   | 0.125                         |
| 4           | 0.018987            | 0.125                   | 0.125                         |
| <p><br></p> | Total = 1           | Total = 1.16            | Total = 1                     |

Notes:

* Minimum Frequency (`fmin`): 0.125.
* Due to rounding errors, the total might slightly deviate from 1.&#x20;
* After Enforcing Minimum, Nodes 3 and 4 were adjusted up to `fmin`.
* After Proportional Adjustment, Nodes 1 and 2 were reduced to compensate for Nodes 3 and 4's increases, while ensuring they remain above `fmin`.

## Actions Required from Validators

All Chiliz Chain validators will be required to upgrade their nodes to the latest SNAKE8 compatible version. Failure to upgrade will result in your validator node being unable to participate in block production and consensus, leading to a loss of rewards.

Further details for the SNAKE8 hard fork will be communicated well in advance across our official channels.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.chiliz.com/chiliz-chain-changelog/governance-proposals-and-decisions/october-2025-snake8-hard-fork.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.