Skip to main content

Proposals & governance structure

Overview​

Proposals form the backbone of the governance process within the KIRA Network, empowering selected network members to collectively influence the blockchain application's conduct and make myriad of off-chain decisions.

Proposing & Voting Rights​

Two types of network participants are empowered to vote on governance proposals:

  • Consensus nodes: These are individuals who occupy a validator seat and operate nodes that actively generate new blocks.
  • Councilors: These are non-validator individuals who, having secured a councilor seat, shoulder the responsibility of network governance.

Together, consensus nodes and councilors constitute the governance set. Inclusion in the governance set doesn't inherently grant the ability to vote on every proposal type. Each governance member necessitates a specific permission to vote on a certain type of proposal. The same principle holds for the creation of new proposals—a specific permission enabling the submission of certain proposals is essential. Permissions can be granted on an individual basis or via roles. This model facilitates an almost infinitely scalable governance system. It allows for the creation of multiple governance sub-councils that can maintain a codependent relationship through checks and balances or any other governance system. This efficient division of responsibilities enables KIRA governance to manage various on-chain parameters, staking interest rates, and more, concurrently. More details on this can be found in the Roles & Permissions section.

Permissioned Governance Set With Equitable Vote Distribution​

KIRA's governance structure aims to promotes a non-sybil community—i.e identifiable individuals who cannot own multiple KIRA accounts with the same or different governance permissions. This non-sybil status is curated by the governance set itself, hence termed “permissionned” or “governance curated” governance set. While members do not need to disclose their identity or undergo KYC procedures, they must be identifiable individual entities. This is primarily achieved through KIRA’s Identity Registrar, which enables all KIRA users to claim and validate various type of information on-chain. Additionally, the governance has various ways to ensure that new members are genuine individuals—like conducting in-person meetings or group calls.

The voting power among governance members is uniformly distributed. Contrary to governance models where token holdings determine voting weight, KIRA provides equal voting weight to all governance members irrespective of their wealth or token ownership. This mitigates the risk of stolen tokens or accounts being used to manipulate network operations or sway governance votes. This becomes crucial in scenarios where centralized custodians, like exchanges holding large token positions of users, can impact other network operations.

Decision-making Process​

The KIRA Network's decision-making process is orchestrated through the mechanism of proposals. These can be accepted, vetoed, or dismissed by governance members, provided they have the appropriate voting permission.

This process is guided by the following principles:

  • Voting Eligibility: Only those network participants who are validators or councilors (collectively known as Councilors) are eligible to vote on proposals.
  • Voting Permission: Councilors can vote on a specific proposal only if they have been granted the respective permission that allows them to do so or if they possess a role that encompasses said permission.
  • Vote Casting: Governance actors have the option to cast one of four distinct vote types: yes (1), abstain (2), no (3), or veto (4).
  • Proposal Timeline: A proposal cannot be accepted, vetoed, or dismissed until its voting_end_time time has elapsed. Furthermore, a proposal cannot take effect until the enactment_end_time has elapsed. No votes can be cast during the enactment period, and a proposal only comes into effect after this period ends.
note

The enactment time allows participants to analyze successful proposal results and act accordingly, avoiding unexpected shifts in voting outcomes.

  • Quorum Requirement: A proposal necessitates a minimum number of votes, or a quorum, to be considered valid. The quorum is essential for ensuring adequate participation and representation in the decision-making process. Failing to meet the quorum results in the proposal being marked as QuorumNotReached.
note

The default proposal minimum quorum percentage is 33% and is configurable by governance via the vote_quorum network property.

The outcome of a proposal is determined based on the following rules:

OutcomeCondition
PassedIf quorum is reached and more than 121\over 2 (>50%) of all votes are yes votes.
RejectedIf quorum is reached and votes of a type other than yes sum to more than or equal to 121\over 2 (>=50%) of all votes.
RejectedWithVetoIf more than or equal to veto_threshold (default 33.4%) votes are veto votes, the proposal is rejected (a minority of members can reject a proposal).
QuorumNotReachedThe quorum was not reach before voting_end_time.

Network Properties​

Two fundamental network properties establish the baseline for proposal duration and enactment timeframes: minimum_proposal_end_time and proposal_enactment_time.

  • The minimum_proposal_end_time sets the lower limit for all proposals durations, also known as voting_end_time which can be adjusted by the governance for individual proposal types.
  • The proposal_enactment_time creates a consistent rule that applies to all proposals. It sets each proposal's enactment_end_time by adding the proposal_enactment_time to that proposal's voting_end_time.

There are two additional properties to consider:

  • The min_proposal_end_blocks sets the minimum number of blocks during which the proposals remain active, which prevails over minimum_proposal_end_time. This is used to prevent edge cases where minimum_proposal_end_time is set to a value shorter than a single block time, thus making it impossible to vote in time.
  • The min_proposal_enactment_blocks defines the minimum number of blocks that must pass after a proposal has passed for the proposal to take effect. It prevails over proposal_enactment_time for the same reason explained above.

Parameters​

Proposal Types​

Existing governance proposals types are listed here.

Proposal​

NAMETYPEEXAMPLEDESCRIPTION
proposal_iduint641The unique identifier of the proposal.
titlestringsome titleThe title of the proposal.
descriptionstringsome descriptionThe description of the proposal.
contentgoogle.protobuf.AnyThe content of the proposal.
submit_timegoogle.protobuf.Timestamp1677781730The timestamp when the proposal was submitted.
voting_end_timegoogle.protobuf.Timestamp1678386530The timestamp indicating the end of the voting period for the proposal.
enactment_end_timegoogle.protobuf.Timestamp1678991330The timestamp indicating the end of the enactment period for the proposal.

Vote Types​

VOTE OPTIONDESCRIPTION
VOTE_OPTION_YES (1)Councilor agrees with the proposal and wants it to pass successfully.
VOTE_OPTION_ABSTAIN (2)Councilor has no strong opinion on the proposal, but wants to signify that they took note of it.
VOTE_OPTION_NO (3)Councilor disagrees with the proposal and wants to prevent it from passing successfully.
VOTE_OPTION_NO_WITH_VETO (4)Councilor strongly disagrees with a proposal and wants to prevent it from passing successfully bypassing the majority vote percentage requirements for approval due to concerns highly impacting network operations or safety.

Proposal Statuses​

STATUSDESCRIPTION
VOTE_RESULT_UNKNOWN (0)Result of the proposal is not yet known/defined
VOTE_RESULT_PASSED (1)Proposal reached quorum, passed successfully, was enacted and took effect
VOTE_RESULT_REJECTED (2)Proposal reached quorum but did NOT pass by lacking a minimum of >50% VOTE_OPTION_YES (1) votes
VOTE_RESULT_REJECTED_WITH_VETO (3)Proposal reached quorum but did NOT pass due to rejection of >50% VOTE_OPTION_NO_WITH_VETO (4) votes
VOTE_PENDING (4)Proposal is not finalized yet and is still awaiting votes
VOTE_RESULT_QUORUM_NOT_REACHED (5)Proposal failed to reach quorum and thus was rejected
VOTE_RESULT_ENACTMENT (6)Proposal was successful but is awaiting enactment time to be passed and thus enforced
VOTE_RESULT_PASSED_WITH_EXEC_FAIL (7)Execution of the proposal logic failed with an unforeseen exception and no changes were made

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.