Governing THORChain

How THORChain Enables Equitable On-Chain Governance and Participation

THORChain

Published in

THORChain

6 min readOct 15, 2018

Implementing changes to cryptocurrency blockchains always had its own share of problems.

Bitcoin and Ethereum have been using a form of governance that can be considered off-chain, where a core group is responsible for coordinating and achieving consensus between stakeholders. This type of centralised governance is slow to implement changes to the protocol, and inevitably leads to stalemates and forking, as it becomes impossible to agree on bigger changes to the protocol.

Ethereum has substantially more decentralisation and some on-chain features like gas limit voting, but is still inefficient and requires hard forking to implement new features.

Both of these communities demonstrate a need to incorporate governance directly into the protocol.

Towards a Decentralised Future

By contrast, on-chain governance has two important qualities that solve the biggest problems of its counterpart:

1. It is much more decentralised

In on-chain protocols, all changes to the protocol are submitted on-chain instead of relying on off-chain coordination. This is done by submitting code proposals through new blocks, after which stakeholders vote on implementation of those proposals through nodes. Not all nodes have equal voting power, and that voting power is usually represented by the number of coins that are staked within a node. Since this process relies on collective decision-making by the entire community, it is much more representative of a democratic process than a centralised voting environment.

2. It enables fast and easy integration of changes to the protocol

As a direct result of decentralisation, proposing a change and reaching a consensus among stakeholders is much faster than in an off-chain protocol. Implementation of changes is further improved if the on-chain protocol includes a testnet, which enables drastic code changes to be properly tested by voters before being implemented on the mainnet. All of this ensures that project’s roadmap and future deadlines are much easier to follow through.

The biggest criticism of on-chain governance lies in two things: there aren’t enough incentives and penalties for voters to actually vote and secondly- nodes with greater number of staked coins have too much voting power so minorities are not represented, which in turn destroys the idea of decentralisation and takes us back to square one.

Fortunately, Thorchain’s governance model is designed to address both of these problems.

The Æsir Protocol

Due to the scope and vision of the THORChain ecosystem, a form of on-chain governance called the Æsir protocol will be used that is similar in nature to projects such as Tezos and Dfinity.

The word Æsir comes from old norse, as Æsir were members of the principal pantheon in Norse cosmology. They were the gods that discussed everything and made all the decisions.

With the Æsir protocol, the goal is to make everyone an Æsir within the governance model.

To accomplish this, all three entities that govern Thorchain’s ecosystem need to be economically empowered: Validators, Standby Validators, and Delegators.

Validators are the ones who propose blocks and commit them to the network. In order to do this, Validators must stake their runes to participate in block production, and are then required to have sufficient stake to be in the top 100 Validators, which we then call a Validator Set.

A Validator Set is responsible for producing all the blocks, securing the network and reaching consensus between the top 100 validators in case of a change proposal. In turn for running and securing the network, each Validator gets compensated from block rewards evenly, regardless of the stake they hold.

So if the top 100 highest staked Validators are responsible for proposing and accepting all the changes to the protocol, how is this different from an off-chain centralised environment where only the most vested shareholders have all the power?

This is where Delegators come in. A Delegator is essentially any token holder that wishes to stake their assets with a Validator in order to earn part of the Validator’s reward. This increases the total stake of that Validator and helps them to stay within the top 100, while it gives an opportunity for everyone else to help in securing the network, earning a part of the block rewards and also enables them to propose changes through the staking pool of that Validator.

Since each Validator gets compensated from the block rewards evenly regardless of their stake, it becomes advantageous for Delegators to stake with the lower-ranking Validators to earn bigger rewards. This creates a sort of equilibrium within the governance model so no Validator is far behind the others in regards to their total stake. This results in high churn in the Validator Set; where it is easy to get kicked out, but easy to enter if meeting the minimum conditions. This makes the protocol resilient, secure and decentralised.

Lastly, we have the Standby Validators. As their name suggests, Standby Validators are Validators that are not in the top 100, but are rewarded through minority block rewards to essentially be on standby. If one of the top 100 Validators drops out of the Validator Set, the next Standby Validator can be quickly nominated to replace them.

Economically incentivised two-layer governance

To further empower all governance entities, a two layer governance model is planned that consists of Voting inside of Staking Pools and Signalling for Validators. This process is fully connected as Delegators vote on proposals(or they propose a change themselves) inside of a Staking Pool, and then that Validator “signals” the final result to other Validators to see if that change is to actually be accepted.

Voting inside of a Staking Pool

As previously mentioned, to share block rewards and vote on protocol changes, Delegators must stake RUNE to be part of that Validator’s Staking Pool, after which they can also propose changes to the protocol.

If a proportion of voters fails to vote on a proposal, then their Validator will submit votes on behalf of them. This mechanism serves as a hybrid between direct and representative democracy, but ensures that the voter turnout is always 100% of the staked tokens within the pool.

To empower minorities that are voting inside the pool and prevent plutocracies, a process called Quadratic Voting will be implemented. Each member that stakes with a Validator can cast votes quadratically proportional to their stake, where each vote is a single whole unit, and increases with the number of subsequent votes. That means that 1 vote costs 1 token, 2 votes cost 4 tokens (2^2), 3 votes cost 9 tokens (3^2), etc. This policy prevents plutocracies as casting many votes by a single voter quickly becomes very expensive, while it empowers minorities as their votes become representative and meaningful.

To sway votes, Delegators can also re-delegate at any time and change Validators they are staked to. If they do this however, they will likely be bound to that new pool for the duration of the vote.

Signaling between Validators

At every single block a Validator is able to read all current proposals as well as nominate their own proposals.

For the vote to pass inside of a Staking Pool and to be signaled to other Validators, a 51% threshold is needed. However, when signaling between Validators, a 67% consensus is needed for the change to take effect and be implemented to the mainnet.

It is important for each Validator to vote on every proposal that is made as not signaling on a proposed change will result in their stake being slashed and redistributed to other Validators.

After a signal to other Validators is made, a grace period for voting can be specified depending on the severity of the proposed change. For sweeping architectural changes that need formal verification, Validators can test the implemented changes on the official Testnet before implementing changes to the Mainnet. The TestNet basically runs as a fork of the Mainnet, and if the new changes are satisfactory and running without issues, the TestNet can be decommissioned and merged with the Mainnet.

Conclusion

“The blockchain that is built today will never be the best blockchain”

The main idea behind on-chain governance is that blockchains should always improve, integrate, and add more technology without causing contentious hard forks all the time and making the process needlessly complicated.

The Æsir on-chain governance model proposes a solution which makes all entities within the model empowered while enforcing voter participation and making each of those votes meaningful.

These considerations are especially important for a project like Thorchain where security parameters are changed frequently and structural changes are implemented on the fly.

Like true Æsir of norse mythology, everyone is able to make their voice heard and be rewarded for participation, which in turn makes the whole ecosystem more effective and relevant.