Following the Kalima consensus, each validator must validate all blocks and they all must be validated in respect with their time of arrival. The same reward is given to all validators for all block validations. Validators are in charge of producing correct validation hash in time.

In return for their validation work, they receive rewards:

  • 1 KLX is emitted every block for each master nodes

  • 0,1 KLX is emitted every block for each validation node

Should they not comply with the consensus algorithm (incorrect hash, or delayed validation), they will face a penalty by seeing their right to validate transactions taken away temporarily.

Becoming a validator requires some technical skills in security, hardware requirements, as well as trust and support from the community, in the form of stake.



There are 2 different valisation nodes you can opt for:

Validation Nodes

  • Validation nodes oversee controlling transactions integrity. Simple validation nodes don't have to store the ledger. Validation Nodes validate and timestamp transactions.
  • Validation nodes are in charge of producing correct validation hash in time to control the hash produced by Leader node.
  • Validation nodes ensure  integrity of all transactions.

Master Nodes

  • Master Nodes are special validation nodes. They are the main validation nodes of the consensus; they are in charge to elect the Leader Node.
  • Master Nodes must store a full copy of the ledger to ensure traceability, integrity, and immutability of all transactions.
  • Master nodes store blockchain data and they publish them to the client's node after validation.
  • Master nodes are the only ones with administration nodes authorized to access all the data contained within the blockchain, including authorization data.
  • Each Kalima Blockchain governance can install as many master nodes as required with a minimum of five of them.
  • Each master node can have simple validation nodes in charge to control hash integrity with a limit of 9.




In Kalima Blockchain, validation nodes and master nodes  of the MaincChain channels are operated on validation pools.  Read the document “validation pools” for more details .

For PrivaChains nodes, it’s different,  PrivaChain governance can choose to delegate its validation and master nodes to Validation Pools or to delegate to independent Master nodes and validation nodes.

In the case where the PrivaChain governance delegate validation to independent Master nodes and validation nodes, the Privachain governance define the setup costs that must be paid in a contractual base with Master nodes and Validation nodes managers.


Running a Validator on Kalima

This guide will instruct you how to set up a validator node on the Kalima network.

Simple validation nodes differ from Master nodes since they are not required to store ledger data nor to elect node.

  1. Check the hardware recommendations below

  2. If the KLX reserve is met validators will be chosen by the network itself. This election ensures a sufficient level of rewards for the validators elected

  3. Every validation node  will be subject to a security Bounty to make sure that they have a sufficient level of security for their infrastructure.


Halving effect on validator rewards

As previously mentioned, KLX validator rewards are subject to a halving effect, which is a key mechanism within the Kalima ecosystem.

KLX validation rewards will be divided by 2 after every halving, which occurs every time 16 billion KLX tokens are emitted (or after 1.6 billion transactions), up until the hard cap of 480 billion KLX in circulation KLX is reached. Note that the initial supply of KLX is 160 billion tokens.

At the time of the KLX launch, the reward per validated block will be of 10 KLX. The first halving will take place after the emission of 16 billion KLX tokens, whereby the reward per bloc will be divided by 2 and become 5 KLX per bloc.



For validators, there are two scenarios for misconduct on the network:

  • They have failed to validate a block in time due to their local network malfunction
    • The validator will see his right to validate taken away for 5 epochs (10 days)
    • Their right to stake will be taken away for 14 epochs (28 days)

  • They have purposefully wrongfully signed a block
    • The validator will see his right to validate taken away for 14 epochs, and indefinitely if conducted again.
    • Their right to stake will be taken away for 14 epochs
  • In case of frequent failures DAO can decide definitive exclusion of a validation pool.



Minimum KLX requirements for PrivaChain nodes

To deploy a PrivaChain on the Kalima blockchain, the PrivaChain holder must create a set of Master Nodes and Validation nodes. The creation requires a payment to the Kalima foundation from the PrivaChain holder. This payment corresponds to the cost of setting-up the PrivaChain and the deployment of the nodes to ensure best performance on the chain, each project having full independence and high degree of customization.

The cost of a PrivaChain will then depend on the number of nodes PrivaChain want to have on their network.

  • The cost for a Master node is: 8.000.000 KLX

  • The cost for a Validation node is:  2.000.000 KLX

A Privachain can choose to delegate its validation and master nodes to Validation Pools or to delegate to independent Master nodes and validation nodes.


Hardware Recommendations

  1. CPU :

    • 6 cores / 12 threads, or more 2.8GHz, or faster
    • AVX2 instruction support (to use official release binaries, self-compile otherwise)
    • Support for AVX512f and/or SHA-NI instructions is helpful
  2. GPU :
    • Not strictly necessary at this time
  3. RAM :
    • 16 GB, or more
  • Disk
    • NVME SSD, or better
  • Accounts:
    • 100GB, or larger
    • High TBW (Total Bytes Written) suggested
  • Ledger:
    • 500GB or larger.
    • High TBW suggested
  • OS:
    • (Optional) 500GB or larger.
    • High TBW suggested

Testing has shown better performance with the ledger on its own disk. Due to high IOPS it is not recommended to store Accounts and ledger on the same disk.


Validation Nodes on Cloud Platforms

Validators can run a voting and non-voting machine on a cloud computing platform or on premise. Client nodes can take advantage of small memory footprint of Kalima and its capacity to run in small devices, IoT gateways or smaller. Also note that egress internet traffic usage may turn out to be high.



Running validator for live clusters (including mainnet-beta) inside Docker is not recommended. This is due to concerns of general Docker's containerization overhead and resultant performance degradation unless specially configured.



Prebuilt validators binaries are available for x86_64 CPUs (Ubuntu 20.04 recommended).



Internet service for validators should be at least 300Mbit/s symmetric, commercial. 1GBit/s preferred.