Councilors & governance ranking

A KIRA account is considered a Councilor if it has at least one whitelisted Permission or Role that allows the creation of proposals or voting. Accounts with no Permissions/Roles or blacklisted Permissions/Roles are not considered Councilors. It is essential to note that having permissions or a role does not automatically imply being a councilor. Councilors are governance members who can collude to raise proposals or vote on said proposals. Sudo users (users with sudo permissions such as 2 or 3) are not considered councilors in this context.

Before any governance member can execute their right to create proposals or vote, they must first "claim" their Councilor Seat, similar to how consensus nodes claim their Validator Seat. This action acknowledges the network Code of Conduct and allows registering a KIRA user in the governance registrar. When submitting a MsgClaimCouncilor transaction using the claim-councilor-seat CLI, the user must supply the following information, which will be persisted in the Identity Registrar:

Councilors have statuses that implies their ability to perform their role in creating proposals and voting.

The Councilor ranking system is used to apply changes to statuses and collect statistics that can be utilized by the governance to determine which network actors fulfill their assigned roles. Note that the ranking of Councilors and Consensus nodes is totally independent and has separate logic. The ranking system is based on proposal creation and proposal votes counters. If the Councilor participates in voting or creates a proposal, their rank increases by 1 and the abstention counter is set to 0. If the Councilor fails to vote, their rank is decreased by abstention_rank_decrease_amount (defined in Network Properties), and abstention is increased by 1.

When the abstention counter equals or surpasses the max_abstention value (set in Network Properties), a Councilor becomes inactive. In this status, they can't vote or initiate proposals, and their rank drops to 0. However, their abstention count remains. To resume voting, an inactive councilor must send a MsgCouncilorActivate transaction, resetting their abstention count to zero.

To prevent the status from becoming inactive while being absent for prolonged periods of time, Councilors can submit a MsgCouncilorPause transaction, which changes their status to paused. In the paused state, the abstention counter does not change, and the rank is not automatically reset, but the Councilor cannot vote or create proposals. To exit the paused status, a Councilor must submit a MsgCouncilorUnpause transaction, but the abstention is not reset as a result.

The rank is reset to 0 if the Councilor's status changes to jailed. In the jailed status, a Councilor cannot vote and create proposals unless the Validator is unjailed by the governance, in which case the Councilor's status changes to inactive.

It may be useful for the governance to have the ability to reset all ranks and abstention counters of all governance members simultaneously (e.g., incentivized games, etc.). For this purpose, the governance module has a dedicated proposal and corresponding voting permission.

Claim a councilor seat using the claim-seat command.

Signal to the network that you will not be present for a prolonged period of time using the pause command.

Signal to the network that you wish to regain voting ability after planned absence using the unpause command.

Signal to the network that Councilor wishes to regain voting ability using the activate command.

Query all councilors, waiting or not, including their corresponding statuses, ranks & abstention counters.

Query all governance members that are not councilors.

Query the governance registry. The registry can be queried by either address or moniker.

Retrieve the count of accounts that can create a proposal (proposers) and the count of accounts that can vote on at least one type of proposal (voters).