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.
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.
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.
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.
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:
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
Vote types
Proposal status
CLI syntax & examples
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. $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 flags configuration section
Roles & Permissions documentation for more details. $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 flags configuration sectionGovernance
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