The ultimate goal of Klaymore Governance System to make the DAO the true and only owner of the Klaymore Protocol. This is not limited to fine tunings on some predefined set of parameters or mere opinion polls. Rather, the DAO will be the final decision maker of any kind of governance decision, including updates on the core protocol. In other words, from deciding protocol fee policy to adding/removing GC nodes to the Stakehouse platform or contract updates for new features, all of the decision-making will be voted on-chain and be self-enforced by smart contracts.

Who gets to vote?

All HOUSE stakers will be able to vote pro rata to their stakes. Yet, this is the initial setting of the governance and can be changed by the on-chain governance itself.

Category 1: Self-enforcing Votes

Self-enforcing Vote is the ultimate goal of the DAO governance. This kind of vote contains its own execution transaction when proposed on-chain. This transaction is activated automatically as the agenda gets passed. This is why this is called a ‘self-enforcing’ vote. There are two sub-categories of the self-enforcing vote.

1-a) Arbitrary Agenda Vote

When passed, this category can execute any arbitrary transaction with the protocol’s highest-level authority. As the word ‘arbitrary’ implies, this means this kind of vote can execute ‘anything’ from protocol parameter adjustments to updates on the core logic of the protocol. Simply put, it is like the DAO getting the administrator authority.

Because of its high degree of freedom based on high authority, this kind of vote must be discussed and reviewed thoroughly over enough period of time. It can even change the governance mechanism itself. So if a malicious proposal gets passed without the community’s thorough review, it could lead to a catastrophic disaster for the protocol. As we all understand, with great power comes great responsibility.

1-b) Parameter Adjustment Vote

This category is also self-executed. However, the authority of this vote is limited to the adjustment of some predefined set of protocol parameters. Technically, this is a subset of 1-a so it might look redundant. However, this allows the community to make decisions on some important parameters that might need to be adjusted frequently and has rather small potential side effects more efficiently. This may include, for example, the reward distribution policy parameters or staking fee rate parameter.

Category 2: Non-self-enforcing Votes (a.k.a. Opinion Polls)

Category 2 is the non-self-enforcing vote. This is for gathering opinions of the Klaymore community. If a proposal in this category contains an on-chain execution gets passed, there should be a follow-up governance process that can enforce it. For example, under the final version of the DAO governance system, one should create a transaction that implements the content of the Category 2 proposal and post a separate Category 1 proposal that contains it.

Voting Rules


A vote meets its quorum requirement to be considered valid. For example, if there are 100,000,000 total participable votes (i.e., the number of all staked HOUSE) and the quorum requirement is 5%, at least 5,000,000 votes must be done for the proposal to meet the quorum. (The number of Total Participable Votes of a certain proposal is counted at the last voting transaction of it)

Categories of Vote Results

The result of any voting is either ‘Passed’ or ‘Rejected.’ When the quorum requirement is met and the option with the most votes - among ‘general options’ - gets more votes than the ‘Against All’ option, the proposal is considered ‘Passed’ with the option selected. Conversely, if the quorum is not met or the ‘Against All’ option gets more votes than any of the general options, the proposal is considered ‘Rejected.' Rarely, if two general options get the same number of votes, the result is considered invalid hence rejecting the proposal.

Special Options: ‘Abstain’ and ‘Against All’

All voting has two special options - ‘Abstain’ and ‘Against All.’ Both are counted in ‘total participation.’ However, voting on ‘Abstain’ has no effect on the result besides the quorum condition. Voting on ‘Abstain’ might mean you’re supporting the vote's validity but do not have a preference on a specific option. ‘Against All’ means rejecting all of the given general options. For example, if the general option with the most votes gets 10,000 votes and ‘Against All’ gets 15,000, the proposal gets rejected.

Governance Roadmap

v0 - Jul 2022

Governance v0 includes Category 2 votes only. Although this category does not technically enforce itself but the core team will do their best to enforce the decisions made by the community.

v0.9 - Q3 2022

Governance v0.9 includes Category 2-b as well. At this point, adjustments on some protocol policy parameters can be voted and executed on-chain. Since this is a self-enforcing category, the core team does not have to execute each decision manually. At launch, it might include decisions on protocol fee rate and HOUSE reward distribution parameters.

v1.0 - Q4 2022

Governance v1.0 is the ultimate model that includes Category 1-a. From this point, all of the governance is under the DAO’s control, and the core team does not hold any special authority. The core team will continue contributing to the protocol as a member of the DAO. In other words, anyone can propose a Category 1 vote containing a protocol update proposal, which, when passed, is enforced by itself regardless of the core team’s opinion on it. Conversely, even core team will not be able to apply any updates on the protocol if it does not pass the DAO voting process.

Last updated