Proposals are a governance process in which selected members of the KIRA Network can modify behaviour of the blockchain application and collectively make various off-chain decisions.
There exist two types of network actors who can take part in voting on governance proposals:
Validators - users who claimed a validator seat and their nodes actively produce new blocks
Councilors - users who are not validators but claimed a councilor seat thus acknowledged responsibility of governing the network
Validators & Councilors together form a governance set. Being part of the governance set does NOT automatically allow for voting on every possible proposal type. Every governance member requires a specific permission assigned in order to have rights to vote on a specific type of proposal. When it comes to creating new proposals, the same rule applies - account is required to have a specific permission enabling it to submit a specific proposals. Permissions can be applied individually to accounts or via roles. More about roles & permissions can be found here.
All governance set member are non-sibil, that means they are identifiable individuals and can NOT be the same person owning multiple kira accounts with different or same governance permissions.
Non-sybil status of governance members is ensured by the governance set itself, this can be called a governance curated governance set. Although governance members do NOT have to be public or KYC'd they must be recognizable as individuals. There are many ways through which governance can ensure that new governance members are indeed individuals, for example by hosting a meeting in person or by having a group call / online meeting.
Voting power of all governance members is always equal. Opposing to governance models where tokens define weight of the individuals vote, in KIRA regardless of the wealth status or token holdings all governance member share the exact same weight of vote. This is done to ensure that stolen tokens or accounts can NOT be used to circumvent expected network operation or otherwise sway governance votes. It is highly important in the case where centralized custodians such as exchanges hold large token positions of their users and thus are able to influence the operation of other networks.
Thanks to roles & permissions model KIRA governance is almost infinitely scalable, allowing for creation of multiple governance sub-councils that can be codependent through checks and balances or any other governance system. By efficient separation of responsibilities between many users KIRA governance is able to simultaneously manage various on-chain parameters, staking interest rates and more.
Voting Rules
Proposals can be passed, rejected or vetoed by governance members with relevant voting permission and in accordance to the following rules:
Only those network actors who are validators or councilors can vote on proposals (Governance actors).
Governance actor can only vote on the specific proposal if he/she has assigned a specific permissions that allow this specific actor to vote on that specific proposal or if said actor has a role containing said permission
Governance actor can only vote on a proposal using only one of four distinct vote types: yes (1), abstain (2) , no (3) or veto (4)
Network actors with different roles (or permissions) might have ability to cast only certain vote types (e.g. validators might be able to cast veto but other governance members not)
Proposal is passed only if MORE then 1/2 (>50%) of all votes were yes votes and quorum of MORE than 1/3 (>33%) of all actors with permissions to vote on a specific proposal voted on said proposal
Proposal is rejected if votes of type different then yes sum to MORE or EQUAL to 1/2 (>=50%) of all votes
Proposal is rejected if MORE or EQUAL to 1/2 (>=50%) of actors who posses veto privileges vote veto (minority with veto power can reject a proposal)
Proposal can't pass, be rejected or vetoed before its expiration time passes. Proposal can't be enacted (take effect) sooner then after the enactment time passes.
During enactment time no votes can be casted. And proposal takes effect only after enactment period ends
NOTE: The minimum quorum percentage is configurable via network properties and can be changed by governance. The recommended safe default is 33%
Vote Types (ref.)
Proposal Status Codes (ref.)
NOTE: Enactment time is used to ensure that network participants have time to analyze result of successful proposal and act accordingly without being surprised by the suddenly swayed vote.
Available Proposal Types
Governance Module (ref.)
Upgrade Module (ref.)
Slashing Module (ref.)
Staking Module (ref.)
Tokens Module (ref.)
NOTE: Proposals can be raised using via CLI sekaid tx customgov proposals command. The --help flag can be used to discover further options. To raise a certain proposal a dedicated permission is required. For example to submit SetProposalDurationsProposalType message a PermCreateSetProposalDurationProposal (31) permission must be assigned to the account creating said proposal. For example to vote on the SetProposalDurationsProposalType a PermVoteSetProposalDurationProposal (32) is needed.
Commands Examples
Proposals Duration Change
# CLI
sekaid tx customgov proposal set-proposal-durations-proposal "$PROPOSALS" "$DURATIONS" \
--title="Update proposals duration " --description="Set durations of '[$PROPOSALS]' to '[$DURATIONS]' seconds" && \
--from=$ACCOUNT --keyring-backend=test --home=$SEKAID_HOME --chain-id=testing --fees=1000ukex --yes
# KM
# e.g.: setProposalsDurations <account> <comma-separated-proposals> <comma-separated-durations-in-seconds>
setProposalsDurations validator "UpsertDataRegistry,SetNetworkProperty" "300,360"
Bash
Query Proposals
# CLI
sekaid query customgov proposals --limit=1000000000 --output=json --home=$SEKAID_HOME | jq
# KM
showProposals
Bash
Vote On Proposal
# CLI
sekaid tx customgov proposal vote $PROPOSAL_ID $VOTE_TYPE --from=$ACCOUNT --chain-id=$NETWORK_NAME \
--keyring-backend=test --fees=100ukex --yes --log_format=json --broadcast-mode=async --output=json
# KM
voteYes 668 validator
voteNo 668 validator
Bash
Query Proposals Durations
# CLI
sekaid query customgov all-proposal-durations --output=json --home=$SEKAID_HOME | jq
# KM
showProposalsDurations
Bash