Skip to main content

Jailing & Slashing Procedures

Automatic Jailing and Threshold Slashing​

note

Consensus nodes going offline are not punished as explained in the Consensus Nodes Ranking & Status Management.

In KIRA, there are two potential punishments for consensus nodes - slashing of stakes and jailing. Slashing is never an automatic consequence, while jailing is an automatic punishment that only triggers for the fault of double-signing. 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 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" chain, a.k.a 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:

  • Launching the node before it is fully synced
  • Application or hardware faults
  • Misconfiguration
  • Accidentally deploying two nodes with the same key

For this reason, KIRA does not automatically slash nodes for double-signing. Instead, they are automatically jailed and their fate is decided by governance later on, which may choose to permanently remove them from the consensus node set and slash them in cases of coordinated attacks. This process 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 facilitated by KIRA's Multistaking module, which decouples voting power from staked amounts, preventing any single consensus node from having outsized influence on 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.

Slashing and Governance Dispute Procedures​

note

Slashing a staking pool is a permanent operation. Once a slashing proposal, it is no longer possible to add deposits to it, and the node is permanently excluded from the consensus set.

In KIRA, slashing is governed, meaning that the decision to slash is never automatic 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.

Unjailing Process​

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 sekaid tx customstaking 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.

Slashing Proposals and Outcomes​

Governance members with the appropriate permissions (57) can raise a slashing proposal (proposal-slash-validator) to permanently remove a consensus node from the active set, either due to malicious behavior, lack of resources causing consensus issues, or any other reason deemed valid by governance. However, if a coordinated attack is detected, (i.e. max_jailed_percentage is reached within slashing_period), the network will automatically raise slashing proposals for each incriminated node.

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:

  1. If a consensus node is not currently jailed when a slashing proposal is raised against it, the proposal outcomes are:
    • If the proposal does not reach quorum, no further action is taken.
    • If the proposal reaches quorum and slashing is approved, the node is permanently evicted from the consensus set and its staking pool is slashed.
    • If the proposal reaches quorum but slashing is not approved, the node is permanently evicted but not slashed.
  2. If a consensus node is already jailed when a slashing proposal is raised, it can only request to be unjailed by raising an unjailing proposal if:
    • The slashing proposal does not reach quorum, or
    • The slashing proposal reaches quorum but the governance votes not to slash

In cases where the slashing proposal reaches quorum and slashing is approved, the jailed node cannot request unjailing and its staking pool will be slashed.

Governance Proposal Hierarchy​

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.

Slashing Amount​

note

Jailed nodes being slashed as well as any of the others colluders listed in the proposal cannot vote on any proposal as their status is jailed and not active.

If a slashing proposal is raised, 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.

Examples:

  • If the max_slashing_percentage is set to 0.1 and the slashing votes are: 0, 0, 0, 0, 0, 0.5, 1, 0.5, 0.25, 0.25, 0.25, 0.75, 0.01, 0, 0.25 then the median is 0.25 but the final slashing 10%.
  • If the max_slashing_percentage is set to 0.5 and the slashing votes are: 0, 0, 0, 0.01, 0.01, 0.03, 0.03, 1, 0.04, 0.05, 0.07, 0.08, 1, 0.1 then the median is 0.35 and the final slashing is 3.5%.
  • If the max_slashing_percentage is set to 0.25 and the slashing votes are: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.5, 0.5, 0.01, 0, 0, 1, then the median is 0 and no slashing takes place.

Slashing Mechanism​

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 systems like Uniswap. 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.

Parameters​

CLI Syntax & Examples​

note

Each CLI command and proposal process in KIRA requires specific permissions. These permissions must be added to the account's whitelist or obtained as sudo permissions for direct changes. Refer to the Roles & Permissions documentation for more details.

note

$SIGNER represents the transaction signer's account name or address. For instructions on setting common flags as environment variables, such as $FLAGS_TX and $FLAGS_QR, see the CLI Guide page.

Transactions​

There is no transactions other than the governance proposals for this sub-module.

Building the future of trustless computing by enabling scalable solutions for resource-intensive applications
2024 KIRA Network, All rights reserved.
Ecosystem
HomeToken & EconomicsBuild on KIRARun a node
Resources
GithubCareersBlogContact us
Community
XTelegramDiscord
2024 KIRA Network, All rights reserved.