In KIRA, double-signing is the only penalized fault for consensus nodes. Consensus nodes going offline will not be punished and/or slashed as explained in the Consensus nodes ranks & statuses. Double-signing occurs when a consensus node proposes or participates in the production of two different blocks at the same block height, creating or attempting to create a fork in the blockchain. A fork in the blockchain is when there are two or more valid chain histories that could be followed, and it's not immediately clear which one should be considered the "correct" or "canonical" chain. Forks can disrupt network observers, such as light nodes, who do not have the resources to fully validate transactions and therefore rely on a single chain for their own operations. If a light node is unable to determine which fork is the canonical chain, it may be vulnerable to attacks where the same funds are spent multiple times, once on each fork.

However, double-signing does not necessarily mean that a consensus node is acting maliciously and in this case slashing doesn’t actually add any security to the network. There can be various reasons for unintentional misbehavior, such as:

For this reason, KIRA does not automatically punish nodes for double-signing. Instead, they are automatically jailed and their fate is decided by governance later on, which may choose to unjail them, permanently remove them from the consensus node set, and/or slash them in cases of coordinated attacks. This protects delegators' staked funds and minimizes the risk of accidental loss, which is important when staking valuable assets such as Bitcoin, digital fiat, or commodities. This is possible because the consensus node set is governance-permissioned and voting power is not based on the stake backing them. This means that malicious consensus nodes can be permanently removed by other consensus nodes without being able to influence governance decisions.

To detect coordinated attacks, KIRA utilizes the concept of threshold slashing. An automatic slashing proposal only occurs if a certain number of consensus nodes double-sign within a specific time frame, with the threshold being less than 1/3 of all consensus nodes. The threshold slashing parameters, slashing_period (3600 seconds by default) and max_jailed_percentage (25 by default, i.e 25% of all active consensus nodes), are network properties that can be adjusted by governance.

In KIRA, slashing is governed, meaning that the decision to slash and the amount to be slashed is determined by the governance and evaluated on a case-by-case basis to prevent cases where software bugs could result in the loss of delegator assets. KIRA's governance-permissioned nature reduces the difficulty and risk of running a node, making it accessible to anyone, even those with little experience, rather than requiring expensive cloud provider setups.

If a consensus node is caught double-signing, it will be automatically jailed by the network and its status will be changed to jailed. This does not necessarily mean that the node will be slashed, as double-signing is not automatically considered malicious. While a node is jailed, it (or any governance member with proposal creation permission 20) can request to be unjailed through a governance proposal using proposal unjail-validator. This request must be made within a certain time frame, defined by the unjail_max_time network property (600 seconds by default). If the request is not made or accepted within this time frame, the node will become permanently jailed. The process of unjailing a node is a judgment proposal, meaning that all governance members voting permissions 21 and consensus nodes with active status, can vote on whether or not the node should be unjailed.

While it is jailed, a node cannot propose blocks, doesn’t accumulate rewards, cannot receive any new delegations and cannot vote on any proposals. Meanwhile other nodes can wait to see if there is evidence of double-signing collusion with other potential malicious nodes or other suspicious activity during that time window.

If a slashing decision is being considered, all governance members with proposal creation permission 57 can rise a slashing proposal using proposal-slash-validator to slash and permanently remove the node from the active consensus node set. However, if max_jailed_percentage is reached, a slashing proposal for each incriminated consensus node is automatically rised by the network.

While a slashing proposal is ongoing, the consensus node under investigation can submit counter-evidence, or "refutation," using the refute-slashing-proposal method by providing an URL or CID to an IPFS resource. Once the counter-evidence is submitted, it cannot be updated again. If a governance proposal results in a slashing event, the consensus node can no longer be unjailed and its staking pool is slashed and becomes inoperative. Users can only undelegate their existing stake in this case.

A slashing proposal can have one of the following outcome:

Slashing proposals take precedence over unjailing proposals. If a slashing proposal is raised for a given consensus node, any active unjailing proposals related to this node are cancelled, and no new unjailing proposals can be raised until the slashing proposal is finalized. This hierarchical relationship ensures that no unjailing action can be finalized before a slashing action, which prevents malicious consensus nodes from starting to produce blocks and receive new delegations before a potential slashing event. This helps to prevent difficult-to-handle situations where malicious nodes are able to gain an advantage before being punished for their actions or having to slash new, innocent delegators.

If a slashing proposal is rised, all governance members with voting permission 58 and consensus nodes with the active status, can vote by providing a slashing percentage as an input. This input is limited by the maximum slashing percentage max_slashing_percentage, which is a configurable parameter in the network properties. This percentage can range from 0% to 100%, with a default value of 0.5%. This limit is meant to provide delegators to have a quantifiable manner of measuring their potential risks when staking. The exact percentage of slashing for a given proposal is determined by taking the median of all votes inputs. For the slashing to occur, more than 50% of all governance members participating in the proposal process must vote with a non-zero slash.

If a governance proposal results in a slashing event, the decided percentage will be taken off all staked tokens within the staking pool. The derivative tokens representing each one of these staked tokens will also lose their 1-to-1 peg. For example, if consensus node V1 is being slashed by 5%, then unstaking 2 of any tokens XYZ would only return 1.9 XYZ, similar to the concept of impermanent loss in automated market maker (AMM) systems. KIRA's slashing mechanism uses a ceiling function to avoid transferring 0 amounts and to accommodate singular units and non-fungible tokens. A specific mechanism for non-fungible tokens will be implemented in a future update. The slashed tokens, including KIRA's native token KEX, are transferred to a governance-controlled community spending pool where a decision can be made regarding their final fate, such as giving them away to the community or refunding them in the case of unfair slashing. The information about the slashing, including the percentage and the result of the governance proposal, is recorded in the staking pool and can be queried for reference.