//
Proposals & governance structure
Search
Duplicate
Try Notion
Proposals & governance structure
Concept
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 off-chain decisions.
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, validators 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—identifiable individuals who cannot own multiple KIRA accounts with the same or different governance permissions. This non-sybil status is preserved 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.
📌
The enactment time allows participants to analyze successful proposal results and act accordingly, avoiding unexpected shifts in voting outcomes.
The outcome of a proposal is determined based on the following rules:
Outcome
Condition
Passed
More than 121\over 2 (>50%) of all votes are yes votes, and more than 131\over 3 (>33%) of all actors with permission to vote on a specific proposal have cast their vote.
Rejected
Votes of a type other than yes sum to more than or equal to 121\over 2 (>=50%) of all votes.
Rejected (veto)
More than or equal to 121\over 2 (>=50%) of actors who possess veto privileges vote veto (minority with veto power can reject a proposal).
📌
The default proposal minimum quorum percentage is 33% and is configurable by governance via Network Properties.
Proposal duration
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 but cannot fall below the value defined by the minimum_proposal_end_time.
The proposal_enactment_time forms a uniform rule across all proposals. It extends the proposal's duration by adding to the voting_end_time, determining the proposal’s enactment_end_time.
Parameters
Proposal types
Existing governance proposals types are listed here, or in the following page with their correspond permissions and CLI descriptions
Proposal parameters
NAME
TYPE
EXAMPLE
DESCRIPTION
proposal_id
uint64
1
The unique identifier of the proposal.
title
string
some title
The title of the proposal.
description
string
some description
The description of the proposal.
content
google.protobuf.Any
The content of the proposal.
submit_time
google.protobuf.Timestamp
1677781730
The timestamp when the proposal was submitted.
voting_end_time
google.protobuf.Timestamp
1678386530
The timestamp indicating the end of the voting period for the proposal.
enactment_end_time
google.protobuf.Timestamp
1678991330
The timestamp indicating the end of the enactment period for the proposal.
min_voting_end_block_height
int64
17500
voting_end_time corresponding minimum block height at which the voting period for the proposal ends.
min_enactment_end_block_height
int64
17500
enactment_end_time corresponding minimum block height at which the enactment period for the proposal ends.
Vote types
VOTE OPTION
DESCRIPTION
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 status
STATUS
DESCRIPTION
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% yes (1) votes
VOTE_RESULT_REJECTED_WITH_VETO (3)
Proposal reached quorum but did NOT pass due to rejection of >50% 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
Governance
Table
Filter
Sort
Subcommand Path
CLI
DESCRIPTION
PERMISSIONS (VOTE/CREATION/SUDO)
set-proposal-durations-proposal
Proposes to set the voting_end_time of specific proposal types
31
32
Transactions
N/A
Queries
sekaid query customgov
proposals
proposal
vote
votes
voters
all-proposal-durations
proposal-duration
Query Proposals
Query all paginated proposals that match optional filters using the proposals command.
Flags
$VOTER_ADDRESS: (Optional) Filter by proposals voted on by this voter.
Bash
Copy
sekaid query customgov gov proposals --voter=$VOTER_ADDRESS \ $FLAGS_QR | jq
Query Proposal
Query details for a proposal using the proposal command.
Args
$PROPOSAL_ID: The unique identifier of the proposal.
Bash
Copy
sekaid query customgov proposal $PROPOSAL_ID \ $FLAGS_QR | jq
Query Vote
Query details for a single vote on a proposal using the vote command.
Args
$PROPOSAL_ID: The unique identifier of the proposal.
$VOTER_ADDRESS: The address of the voter.
Bash
Copy
sekaid query customgov vote $PROPOSAL_ID $VOTER_ADDRESS \ $FLAGS_QR | jq
Query Votes
Query vote details for a single proposal using the votes command.
Args
$PROPOSAL_ID: The unique identifier of the proposal.
Bash
Copy
sekaid query customgov votes $PROPOSAL_ID \ $FLAGS_QR | jq
Query Whitelisted Proposal Voters
Query voters for a single proposal using the voters command.
Args
$PROPOSAL_ID: The unique identifier of the proposal.
Bash
Copy
sekaid query customgov voters $PROPOSAL_ID \ $FLAGS_QR | jq
Query All Proposal Durations
Query all proposal durations using the all-proposal-durations command.
Bash
Copy
sekaid query customgov all-proposal-durations \ $FLAGS_QR | jq
Query Proposal Duration
Query a proposal duration using the proposal-duration command.
Args
$PROPOSAL_TYPE: The type of the proposal.
Bash
Copy
sekaid query customgov gov proposal-duration $PROPOSAL_TYPE \ $FLAGS_QR | jq
Table