Before proceeding please ensure that you are meeting the minimum system & software requirements to operate a node. As long as those requirements are met it should be possible to launch a validator and other types of KIRA nodes in a home environment and use off-the-shelf single-board computers such as a Raspberry PI. There are no slashing penalties for validators going offline or becoming temporarily inaccessible. Nodes that go offline for a prolonged period of time will become inactivate and removed from the consensus automatically by the state machine.

The network is designed to halt in the case where ≥ 1/3 of consensus nodes suddenly become unresponsive, however in the case of individual nodes leaving and entering the consensus randomly there should be no interruption to the network operation. As long as the number of validators does not fall below min_validators as defined in Network Properties, the chain will continue producing new blocks.

Sybil-resistance must be ensured to guarantee the security of the network, for that purpose you need to pass screening that will identify you as a unique individual since our testers are considered to be official KIRA Evangelists who are eligible for grants, bounties, can be granted validator seats and governance roles, receive UBI, participate in the private testers chat and more. On the mainnet, a dedicated governance body can decide which operators can be considered non-Sybil without need for KYC or other personal identification. There is no limit to the number of validators on either testnet or mainnet. To learn more about the Evangelist role or preview your application please see our whitelist page.

Using KIRA Manager (KM) is the quickest way to run a node, as it is a straightforward bash-shell script that can easily create a new personal network or join an existing one on your behalf. However, it is important to note that KM is only intended for internal testing and should not be used on the mainnet. For operating each aspect of the infrastructure manually on the mainnet, please refer to our public documentation page after you have become comfortable and familiar with the process. At present, KM can only be installed on Ubuntu. If you prefer to use a Mac, you will need to install VMware and virtualize the Ubuntu OS. On Windows, WSL2 is supported.

To join an existing network, you will require knowledge of the specific software version you need to run and the IP address of a trusted node operator within that network. You can find all of this information conveniently located in the "Active Testnets" section below, so there is no need to worry. Let us now examine some simple setup examples.

Once you have accepted the initial terms and conditions, you will be presented with the Launcher Menu, which enables you to configure your node, manage networking settings, download snapshots, and preview the hash of a genesis file. Within the Node Launcher Menu, you will need to specify the IP address of a trusted seed node or another validator. Your node will use this connection to synchronize with other nodes on the network and keep its copy of the blockchain up to date. You can request an IP address from any of the fellow validators in the testers chat, or use an address of a genesis validator that is listed in the corresponding testnet section below.

Every node has a connection limit and the official genesis validator may be targeted by the DOS/DDOS, and thus become non-operational or non-responsive to the new peers. If this happens, node operators will need to coordinate via the testers chat and share between each other IP or DNS addresses of their personal validator, seed or sentry nodes. Alternatively testers can utilize any endpoint of an active INTERX node at <IP>:11000/api/pub_p2p_list where <IP> is an IP of any public testnet node to discover more IP addresses.

As a validator, your most important role is to stay online, be an active participant in the testers community, and preserve the cryptographic secrets that your node will use to sign new blocks being proposed to the network. There can be many of those “cryptographic secrets” that you need to know about and archive, so we simplified the entire process into just a single set of bip39 mnemonic words that you need to write down. You can visit the Key Management page to learn more or utilize KM to generate it all for you automatically. If you choose to go with KM, please make sure to select option [M] View or Modify Mnemonic before leaving the “Node Launcher Menu” and follow up with [V] Display master mnemonic from keystore within the menu of the “Secrets Manager”.

If by mistake you forgot to write down your mnemonic words, you can always display them by typing the following command in your console window: tryGetVar MASTER_MNEMONIC "$KIRA_SECRETS/mnemonics.env". If your node fails or needs to be recovered, you can regenerate all the secrets by providing the master mnemonic to the KM within the “Node Launcher Menu”. Otherwise, your node will generate a new set of secrets every time you set up a new node on a fresh instance.

If you ever need to fully recover your validator node, including all its secrets and private keys, you can do so by importing the mnemonic that you previously wrote down. To access this option, simply select[M] Modify master mnemonic and DELETE all secrets from the main menu of the “Secrets Manager”. However, it is important to note that this process will destroy all auto-generated secrets and replace them with the ones derived from your master mnemonic. You should be very careful when using this option and ensure that you have a backup of your master mnemonic in a secure location. It is also crucial to never attempt to recover your validator or reuse your secrets on two machines simultaneously. Doing so will result in double signing of a block and lead to your node being jailed.

To join the validator set you will need to become an official KIRA tester first. Your initial goal will be to determine your validator public address, which you will need to submit as part of the application process to become whitelisted.

Once you have completed the installation process, you can easily find your validator address by typing kira into your terminal window to open KIRA Manager. From there, simply press the corresponding number on your keypad to designate your validator container (usually [0] by default). You will then be presented with a container manager that provides statistics about your node, including your Validator Address.

Once you have been whitelisted by the testnet support team, you will be presented with an explicit option to [J] Join Validator Set in the main menu of KIRA Manager. Upon executing this option, your node will begin to produce and sign proposed blocks. In addition to this, the main menu of KIRA Manager provides many other options such as configuring the firewall or creating snapshots.

Main highlight of all KIRA testnets is collaboration on performing automated on-chain upgrades. Our upgrade module is a blockchain application which allows validators to coordinate soft & hard forks as well as agree on the integrity and content of each new KIRA release. KIRA Manager will automatically detect upcoming changes, delete all containers, perform snapshots & genesis file exports then rebuild the environment and launch new release without your assistance. You can enable or disable automated upgrades from within your KM, by selecting option [U]. You will also be notified via the KM of the exact time of the upcoming upgrade. All upgrades are scheduled according to timestamps predefined in the upgrade proposals and NOT block-height based thus making it way more predictable to coordinate and apply changes regardless if you plan to use KM or a dedicated continuous deployment (CD) pipeline for your infrastructure.

It is mandatory for ALL validators to vote on upgrade proposals. If you skips the vote then the on-chain status after the upgrade will be changed to inactive and you will not be producing blocks while your validator leaderboard rank will significantly decrease.

If you do not wish to use KM and instead utilize your own dedicated continuous deployment (CD) tools, then you can acquire informations about upcoming upgrades from either the sekai CLI or the following two INTERX endpoints:

The “current” plan contains informations & resources regarding current release while the “next” plan contains informations & resources regarding upcoming release. You can also use resource references specified in the “current” plan endpoint of a trusted node while joining the the network for the very first time. If you choose not to use KM and new genesis file is required (hard fork), you can create it by first exporting genesis at the height where the network stopped (your node daemon should be shut down) and then passing it through a dedicated new-genesis-from-exported command.