The core innovation of the Koinos blockchain framework is its ability to evolve; to rapidly adapt to the ever-changing needs of developers and their end-users. Practically any upgrade can be made to the blockchain without a hard fork because everything is done in upgradeable smart contracts.

What this means is that hard forks are no longer a bottleneck, governance is the bottleneck.

On Koinos-based blockchains, once an upgrade is approved by governance, it simply becomes part of the system. This obviously places a great deal of importance on the governance system which I am excited to announce … is officially complete! This update will be dedicated to explaining that system, but if you would prefer to view the governance story on github, you can find it here.

First Principles of Governance

Because Koinos is so upgradeable, we always want to start from the simplest design possible because the community can always make it more complicated through upgrades. Simple designs also tend to be the most generalizable which is important for composability, as you will see.

Let’s start by thinking about governance from first principles. In order for people to vote on upgrades, those upgrades first need to be proposed. In order for people to see those proposals and process the information contained within them, there must be a known “review period.” Then there must be a “vote period” during which they can actually cast their votes. At the end of that period, the proposal must pass or fail.

Implementation Details

Our challenge then was to implement those behaviors in a Koinos smart contract. To allow for those behaviors, the governance smart contract database allows for a proposal ID, vote start block, vote tally, and the authorization to perform a system call override; which is what ultimately allows for a system behavior to be modified without a hard fork.

The proposal ID is simply the merkle root of the operations contained within the proposal. The “vote start block” is the block when the voting period will begin and the “vote tally” is what keeps track of how many votes the proposal has received. Once a proposal has reached the necessary threshold of votes, “shall authorize” is set to “true” and the necessary privileges are granted and system call overrides made.

Because people are used to operating on weekly schedules, the “review period” for proposals will initially be set to 1 week, and to ensure that people (specifically those producing blocks) have enough time to cast their votes, they are given twice the length of time to do so (2 weeks). Each block, the producer will be able to vote for any proposals they support. An absence of a vote is considered a vote against a proposal. Once a vote is cast it cannot be changed. We expect mining pools to become an important tool in organizing for or against governance proposals.

A proposal should not be applied the instant voting concludes, it should be delayed for a certain period of time to prevent certain attacks. Therefore there is an additional “application delay” of 2 weeks.

Mitigating Abuse

It’s important that bad actors not be able to abuse the governance system by spamming proposals, but we also don’t want anyone to be able to profit off of the system. The simplest solution to that problem is to require users to burn some KOIN in order to submit a proposal. It is important to remember that the system should only ever be changed if doing so will add considerable value relative to any other solution, therefore it is reasonable to impose a monetary cost for proposing upgrades.

In order to ensure this fee can be calculated in a decentralized and autonomous manner, it is based on the total supply of KOIN. The total supply is simply divided by 1,000,000. So if the total supply of KOIN is 100,000,000, then the user must burn 100 KOIN in order for their proposal to be submitted. Since all actions on the blockchain must also pay a fee in Mana, the “resource credit limit” for submitting a proposal is 1/10th of the burn fee, or 10 Mana in the previous example.

Upgrading Governance

Since the governance system is itself a Koinos smart contract, these numbers can always be changed without a hard fork. In fact, this is what ultimately distinguishes Koinos as the only blockchain truly capable of evolution; governance can upgrade ITSELF!

Of course, as the most important component of the system, it should be much harder to change governance than any other part of the system. For that reason, a 75% supermajority vote is required for governance upgrades, while only a 60% majority is required for non-governance system upgrades (system call overrides and system contract promotions).

Composability & dApp Governance

One of the things we are always thinking about when we design any of the system contracts is composability; how will application developers use this smart contract in their own dApps? From the perspective of the system, the upgradeability of Koinos enables the blockchain to evolve, but this same capability accrues to the dApp developer as well. Koinos smart contracts are designed to be upgraded so dApp developers are no longer stuck with their past mistakes or forced to implement complicated and insecure “proxy” smart contracts to achieve upgradeability.

As with the Koinos system logic, the dApp’s governance will therefore be what determines when changes are made, as opposed to any system level limitations. The default condition for a smart contract is that the creator of the smart contract can upgrade it whenever they wish, but this obviously is not decentralized. While that might be acceptable for certain blockchain-based applications, enabling decentralized applications is of paramount importance, in which case they will need a decentralized governance system.

DApps will require their own system for enabling their token holders to propose and vote on upgrades that cannot be abused. Because all of the system logic on Koinos is implemented as smart contracts, dApp developers can simply copy the Koinos governance smart contract and add it to their dApp, instantly getting a robust governance system for free.

Over time, we expect dApp developers to modify the governance contract and experiment with features that could ultimately filter down to the Koinos governance contract, but that contract should always remain the simplest and most generalizable implementation of a governance contract on Koinos to maximize composability.

The World’s Simplest DAO

One way to think about the Koinos governance system is that it is the world’s simplest DAO. It is a smart contract that contains only the logic necessary to upgrade itself. The rest of the Koinos system then piggybacks off of this functionality to make a slightly more complicated DAO in the form of the Koinos system, and then a potentially infinite variety of DAOs in the form of Koinos dApps.

Developers, Developers, Developers

With the completion of the Governance contract, the only remaining smart contract work left is proof-of-burn, so now is the perfect time for developers to begin building their Koinos applications! If you or someone you know is considering building a blockchain-based app but needs help, don’t hesitate to send them to where they can book a free consultation with our team.

We’re here to help as many people as possible build insanely great applications and accelerate decentralization through accessibility!

Be Free!