THORChain Crypto Economic Model

2018-12-13 — 7 min read

We attempt to analyze the economics around the Rune token in order to determine the potential behaviour of actors who will participate in the network on launch.

Every living organism alive is motivated out of simple self-interest, including ourselves. Modern economic theory is built on this assumption:

Economics has assumed that each individual has stable and coherent preferences, and that she rationally maximizes those preferences. Given a set of options and probabilistic beliefs, a person is assumed to maximize the expected value of a utility function, U(x).

Mathew Rabin, Professor of Behavioural Economics at Harvard Business School, 1998.

Bitcoin is the first system that is based purely on the principles of self-interests, and the entire system grows stronger and more resilient as every actor attempts to maximise their gain; in what can be seen as a positive externality and an intrinsic forcing function. In Bitcoin there is only one rule: try to be as greedy as possible.

Compare this to legacy Keynesian economic theory which uses the heavy hand of regulation to constantly apply *negative* externalities and forcing functions to drive an economy. In Keynesian economies there are millions of rules stacked on top of each other. The antithesis of a free market.

The Rune Token

The RUNE token, is essential to the entire THORChain ecosystem and by extension our solution to decentralised exchange. It has many uses including rewarding users for providing liquidity to securing the network through bonded stakes, RUNE serves a cryptoeconomic function in providing incentives and deterrents for the protocol.

Here are some uses for RUNE:

Rune is bonded to Validators to earn block rewards.

Rune is circulating freely as a medium of exchange.

Rune is staked in liquidity pools to earn on liquidity fees.

Rune is not circulating at all.

Staking and Network Security

THORChain is a proof-of-stake network that relies on a number of validators bonding Rune collateral in order to become eligible to earn block rewards from the network. Since a BFT algorithm is used (Tendermint) that relies on synchronicity, the number of validators must be capped in order to reach finality in each round of block proposals.

Matching the Cosmos architecture, it is expected to have 100 validators on launch of the network, increasing over a number of years to a larger (but capped) number.

Tendermint requires full-nodes as Validators or block producers, and each Validator must have a weight on the network. The weight is determined by the stake they hold, so Tendermint can support Proof-of-Stake out of the box.

Staking

THORChain must not only achieve optimal network security (protection from byzantine actors) but it must also achieve ideal asset security to protect its cross-chain bridges that will be holding external assets.

By design, THORChain’s bridges are permissionless and opt-in to validators in order to protect the network from censorship.

The bridges are secured by validators that choose to maintain bridges to earn on exit fees. They form a compliant “quorum” of validators that are cycled through the multi-signatures protecting the bridge assets.

However, because of the opt-in nature of this responsibility external bridges do not have the security of the entire network. Thus, the bridging protocol uses economic incentives to ensure that the assets held on bridges are always safe.

Safety, as it relates to this, is determined by enforcing a net economic loss on the attacking actor, that far outweighs the potential reward. An example of asymmetric design, commonly used in computer architecture, to deter attacks before they happen.

Achieving ideal asset security is defined as ensuring that the value of stake bonded by the set of validators guarding a bridge is always twice as high than the value of the assets held on the bridge.

What are the incentives to do this?

The incentives to bond tokens with Validators are to earn block rewards that will be emitted as part of the token’s inflation schedule, as well as any transaction fees collected (including trading and exit fees).

THORChain’s proposes a design with a flat 2–5% emission to validators.

The incentives to stake Rune in liquidity pools are to earn on liquidity fees, which are proportional to volume across pools, transaction sizes and existing liquidity depth.

Staking is an inherent part of the protocol and provides liquidity to all assets. Due to the way that CLPs are created alongside the instantiation of digital assets on THORChain, there will always be some liquidity depth to assets. By adding incentivisation (liquidity fees), trading pairs will always be liquid, increasing the usefulness and value of the protocol.

When staking, a user can stake symmetrically or asymmetrically in the pool. Despite the method of staking, the user will always end up receiving assets on both sides of the pool.

The reasons for this are twofold:

By receiving assets on both sides of the pool the staker is hedged against any downside on one side and thus any fees earned presents a net gain in value to the staker.

Staking asymmetrically creates a price imbalance that is corrected by either arbitrage or market forces, and thus results in an accumulation of assets on the unbalanced side for the staker.

Relationship with Bridges

Since THORChain is a cross-chain protocol with bridges that hold assets, our network design is asymmetric towards asset security. We choose a safety threshold of 2 on all bridge assets, that is, there must be twice the amount of Rune securing a bridge than there is in the value of the asset.

Since the incentives for staking arise from economic activity, we attempt to form a position on what would likely be the level of staking participation. We assume that any actor who can stake can also bond, so we can suppose that they will position their assets between staking and bonding depending on the potential ROI available.

From real world analysis of liquidity networks and decentralised exchanges we determine the following numbers:

Secure Network Design

For a byzantine attacker to attack the network, they would need to accumulate 25% of the supply of Rune. Roughly 250m units.

To remove even 200m Rune from the pools, the attacker would need to place in 4 times the amount of paired assets. Since the pools are coupled mathematically, the price action on the asset would cause the value of Rune to increase by 25 times.

The bridges would increase in security by 25 times due to the rise in value of the stake holding the assets. The value of the block rewards and transaction fees paid to validators would increase in value 25 times.

This large multiple in incentives would attract further delegation from Rune holders, increasing the amount of Rune the attacker would need to acquire. This positive feedback loop would continue until the attacker cannot collect enough Rune from markets to conduct an attack.

To re-iterate a point made earlier, the Rune token is not only integral to the THORChain environment, but defensible and asymmetrically designed towards maintaining the security of assets and data. It has been designed this way as the native token of the THORChain solution to decentralised exchange and communication.