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.

If the abstention counter reaches a value equal to or greater than max_abstention (defined in Network Properties), the Councilor's status changes to inactive. While in the inactive state, a Councilor cannot vote or create proposals, and their rank is reset to 0. However, abstention is not reset. To regain the ability to vote, a councilor in the inactive state must submit a MsgCouncilorActivate transaction, which resets the abstention to 0.

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.

Query the number of account that can create or vote at least one type of proposal.