Governance

THORChain governance is deliberately minimal. It decides which chains and assets are listed, and when the protocol gets upgraded.

THORChain aims to have as little governance baked into the system as possible. This is done so that nodes don't communicate or learn who one another are. This is important for security because it makes sure that nodes don't act together to take control.

THORChain governance decides—

  • which assets are listed/delisted

  • which chains are listed/delisted

  • when the protocol gets upgraded

  • the economic limit – how many nodes can participate

Asset Listing/Delisting

Users signal which assets they want on the network. To signal they want the network to support a new asset, users make a staking transaction into the network. This transaction is the same as when staking in a pool.

The user's funds get added to a "bootstrapping pool". This is a normal asset pool except swapping is disabled on it. Every few days the networks looks at all the bootstrapping pools and lists the one with the highest value.

Assets are delisted when all liquidity providers have taken their assets out of it.

The process is repeated to re-list an asset.

Chain Listing/Delisting

When the community wants to support a new chain

  1. community developers write software to connect it

  2. code gets tested and validated by core developers

  3. if accepted, it gets added to THORNode software

  4. nodes upgrade their software as they are cycled off and back onto the network

  5. when 67% of nodes are running the new software, the new chain is connected

To delist, nodes stop watching a chain. When 67% are no longer watching, it gets removed. A process begins and the assets of that chain are returned to their owners.

Protocol Upgrades

The protocol is made up of 3 main pieces, run by the nodes—

  • application logic – runs the blockchain

  • schema – stores key values of vaults

  • network software – keeps the TSS protocol key generation and signing

Upgrading node software happens when nodes are cycled off the network. Application logic and schema have versions. When the node wants to enter the system they need to say which versions they're running. The network may select them if they're running software that's more up to date than 67% of the active nodes.

When upgrading the network software, nodes agree on a certain block number in the future when the upgrade will happen. When the network reaches that point the whole chain stops running. Then there's a genesis import to a new network.

Economic Limit

There are only so many nodes who can participate on the network. This is because there's a minimum bond amount and a fixed supply of Rune. If the fixed supply can't keep the number of nodes down then the number of nodes that can join can also be reduced through governance.