Abstract

THORChain aims to make it possible to trade digital assets—

• without a central organizing company
• at fair market prices
• in a way that is resistant to attack

The network is made of anonymous people running nodes. Nodes are computers running THORChain software. These nodes are regularly kicked off the network. This is done to make sure that—

• trading is always available
• no individuals get control over the entire network
• the system can improve over time

Together, nodes create addresses to hold assets like BTC and ETH. Nodes watch these addresses. When assets are sent into these addresses, nodes record these events on the THORChain blockchain.

When assets are coming into the network, all nodes must be involved. On the other hand, when assets are going out, much smaller groups of nodes are used. This is more efficient and quicker. This smaller group of nodes decides together whether or not to approve a transaction out of the network.

Many processes on the network are mediated by its token, RUNE. To secure itself, the network aims to have 67% of RUNE bonded by nodes and 33% staked by liquidity providers.

In general, THORChain is designed to have as little formal governance as possible. Important decisions like which assets to list are made by liquidity providers staking capital.

Introduction

There are a lot of cryptoassets now. But it's never been possible to exchange them all in a decentralized way. Instead, you need to use centralized exchanges. Centralized exchanges are companies which need to take hold of your assets in order for you to exchange them.

So far there hasn't been a way to do this in a way that is native to crypto. That is where no individual entity is taking control of your assets.

A network like this would allow anybody to contribute to its security and available assets. As more people get involved, the network would become more secure.

A network which solves this problem should be—

• able to connect to any chain
• able to connect to as many chains as there is demand for
• available for anyone to use and contribute to
• strong, always staying online and not falling under the control of a small group of individuals

Overview

THORChain is managed by a large group of nodes.

To participate in the network, nodes need to put up money. This bond makes sure that nodes have skin in the game. They are only selected if they've put up enough money.

Nodes watch for transactions into the network from external networks like Bitcoin and Ethereum. Then the nodes follow a process to come to confirm what transactions took place. Once they've come to agreement, they can take further action.

Nodes are also involved with approving assets to be sent out of the network. Small groups of nodes come to agreement using a process called the threshold signature scheme (TSS). This process makes sure that all nodes agree on when to send assets and how much to send.

Nodes

Bonding

Anyone can apply to become a node. They send RUNE into THORChain's primary vault. This is known as bonding. If they bond enough RUNE and are picked at random, they enter a competition. If they are successful in the competition they become an active node.

Nodes are regularly cycled. This means that every few days, a random set of nodes are kicked off the network. At the same time several new nodes are brought into the network through the process described in the previous paragraph.

This makes sure the service – exchanging assets – is always available to users. And it stops a few people from getting full control of the network.

Servicing the Network

Nodes cannot participate in governing the network. That is, they cannot change the rules of the system. What's more, they cannot decide which transactions can be made or which assets are supported. To make sure of this, nodes are kept anonymous on the network. There is no way for a node to talk to another node or to know who is running another node.

Nodes can be punished for—

• not properly recording transactions they see on connected chains
• not committing blocks
• disrupting the approval process for outgoing transactions

Nodes earn rewards every block and can claim them when they leave the network.

Leaving

All nodes are kicked off the network eventually. But they can request to leave at any time and that process takes a few hours.

When nodes leave they get back their initial bond and the rewards they've earned. Once nodes have left they can rejoin at any point by bonding again.

In order to rejoin the network nodes need to rebuild the node software. This encourages them to be running up to date software. It makes sure that the network upgrades itself over time and that it adapts quickly.

Chain Connections

One-Way State Pegs

THORChain connects to networks like Bitcoin through "one-way state pegs". This means that no assets are pegged as you see in other comparable projects. Only the state of transactions on the external network are synced into THORChain. Specifically, the system keeps track of—

• how much of the asset was moved
• associated information, like the ID of the transaction
• address of the sender
• address of the person receiving the asset

Note that only only information about transactions involving THORChain are synced. Not every transaction on the external network.

To make this possible code needs to be written for each connected network.

Witness Transactions

When a node sees a transaction on a connected network it records this in what is known as a "witness transaction". A witness transaction is basically a message from a node saying "this is what I saw happen". So it might be "I saw somebody send 1 BTC into THORChain". Nodes are all sending witness transactions into the system all the time.

Witness transactions have a standard structure no matter which network they came from. A Bitcoin transaction looks different to a Binance Chain transaction, but in THORChain they'll look the same.

Transaction Consensus

As all these witness transactions come in, the network needs to process them and decide which are correct. Nodes may make mistakes or disagree about what is happening in the external networks.

In order to reach agreement about a transaction ID, the network looks at all the witness transactions which relate to it. When the network sees 67% of nodes agree on a transaction it's approved and considered correct.

Nodes are punished if they miss witness transactions. They're also punished if they get a transaction wrong. For example if more than 67% of nodes say the transaction was for 1 BTC, but you say it was for 1.5 BTC, you'll be punished.

When nodes make mistakes they have "slash points" marked against their names. When nodes leave the network, they lose rewards based on the number of slash points they've got.

Network Variability

Blockchains can be messy. Sometimes they'll record a set of transactions but will change them further down the road. This can happen because of double-spending, chain re-orgs, network forks etc.

THORChain needs to resolve this because it needs an accurate record of what's going on on those chains. So to combat this, nodes keep their own copy of transactions on each external chain. This allows the network to stay in sync with external chains despite them updating themselves.

Liquidity Model

Continuous Liquidity Pools (CLPs)

THORChain keeps pools of assets. Pools contain an external asset and RUNE. This means that all external assets are linked via RUNE. This makes it possible for the network to know the price of any external asset. And it makes it possible for users to move directly from one external asset to another. For example from bitcoins to ether, or binance coin to monero.

It's helpful to think of pools as being in one container, but in reality pools are spread across lots of different addresses. They are "virtual". This is important for security. The system keeps track of all the different addresses which enables a user to consider a pool as a single entity.

This design, known as CLP, allows liquidity to be tied to security. As more value is pooled on the network, the value of RUNE grows. It also allows THORChain to subsidise the cost of moving external assets out of pools.

Providing Liquidity

Liquidity Providers make special transactions to deposit assets into THORChain vaults. The network tracks how much you put in and what proportion of the pool you own.

Here's a formula to work out how much of a pool you own—

• Pool Ownership = ((R + A) * (r * A + R * a))/(4 * R * A)
  • where—
    • r = Native Asset Staked
    • R = Native Asset Balance
    • a = Pooled Asset Staked
    • A = Pooled Asset Balance

Liquidity Providers make another special transaction to remove their assets from the pool. They get back the initial assets they put in and the fees earned whilst providing liquidity.

Exchanging Assets

In order to exchange assets, users make a transaction into the network. The transaction says

• which asset they want
• where they want to receive that asset
• what price they want to buy the asset at

The asset exchange uses this formula—

• y = (x * Y * X) / (x + X)^2
  • where—
    • x = input
    • X = Input Asset Balance
    • y = output
    • Y = Output Asset Balance

This is based on the constant product automatic market maker formula. The same formula Uniswap uses. But this CLP formula also has a slip-based fee.

Fees

Users are charged fees when they trade assets and when they take external assets out of the pool.

The trading fee is based on how much your trade causes the price between two assets to fall. This makes sure that the fee goes up and down with demand. It also encourages buyers and sellers to take into account the effect of the speed of the trade on price. If you try to push a trade through quickly, you will pay more.

There is also a network fee. This is charged when you take assets out of a pool. The fee is used to pay for gas costs on external networks. The fee is based on the external network's average cost of gas.

Vault Manager

Vault Management

THORChain manages several vaults. These hold assets for—

• the liquidity pools
• node bonds
• reserves

Vaults are non-custodial – all outgoing transactions are handled by the system and are only ever initiated by the assets' owner. Individual nodes never hold the key to withdraw funds.

Vaults are mentioned by the threshold signature scheme (TSS). TSS requires 67% of nodes to approve funds to leave a vault.

Every time nodes are cycled – which happens every few days – the vaults are recreated and assets are moved between them.

Each connected chain has one primary vault to keep incoming assets and multiple secondary vaults for sending assets out.

Each node is involved with every primary vault and some secondary vaults.

Receiving and Remitting Assets

To send assets into a THORChain pool, liquidity providers first need to get the current primary vault address for that connected chain. They ask multiple different nodes for this information. This avoids someone sending a fake address – a "spoofing attack".

When the assets have been sent, the nodes see them enter the primary vault address. They create witness transactions and send them into the network.

When assets need to be sent out – to return a bond, for a withdrawal, for an exchange – the network picks a secondary vault to do it. Approving this is quite quick because there aren't so many nodes involved.

If the nodes taking care of the secondary vault don't process the transaction they are punished. They are punished according to the size of the transaction value – the bigger the transaction, the bigger the punishment. If this failure does happen, the primary vault takes over the processing.

Balance Vaults and Ensuring Liveness

When preparing to make an outgoing transaction, the network will look for secondary vaults that have enough assets.

To make sure that secondary vaults have enough assets when outgoing transactions need to be made, the network tops them up regularly.

In general, half the assets for a pool are kept in the primary vault and half of them are kept in the secondary vault.

Primary vaults are reconstructed every few days during the node cycling process. It can also happen more often, for example if a node wants to leave. Secondary vaults are also cycled when one of its nodes leaves the network. Cycling vaults makes sure they always have active nodes.

Threshold Signature Scheme (TSS)

Implementation

The threshold signature scheme design was first introduced in Gennaro/Goldfeder 2018. TSS makes it possible for groups of nodes to approve transactions together more efficiently.

TSS is used in 2 parts of the system: key generation and key signing.

Key generation occurs when groups of nodes create a new primary vault. Through TSS the nodes create a public key together. All secondary vaults for this connected chain are based on this public key.

This key generation process supports chains based on secp256k1 (like Ethereum) and ed25519 (like Polkadot).

Key signing occurs when nodes need to approve an outgoing transaction from a secondary vault. The transaction is first given to a particular vault to approve. The nodes looking after that vault get ready to sign off on the transaction. When there are enough nodes ready, the sign off begins. Once signed off, all nodes try to broadcast to the connected network. One is accepted.

Code needs to be in place to translate this outgoing message from THORChain format to that of the external chain.

Preventing Attacks

In key generation each node checks that the other nodes haven't done anything wrong. The system also makes sure nodes don't cheat using a "commit-reveal scheme". This makes sure that nodes cannot cheat the system by saying one thing, having it accepted and then quickly changing it to their benefit.

In key signing cheating is prevented because nodes only sign messages that are off the network.

Network Security

Assumptions

There are 3 points in the system where nodes need to come to consensus—

1. transactions happening on connected chains
2. how these transactions are structured on the network's blockchain
3. agreeing when to send money from secondary vaults out of the network

In all 3 cases a supermajority of 67% is needed. This prevents sybil attacks, where one person or group takes control of multiples nodes. It prevents these attacks by requiring that nodes bond RUNE. This needs to be acquired on the open market so for an individual to gain a supermajority becomes extremely expensive.

Global Shutdown

The number of nodes in the network could drop below the minimum required to maintain consensus. It's unlikely but possible. If this does happen the network can then cause itself to shutdown. In this case all assets are returned to their owners.

Scaling

TSS Committee Limits

A committee oversees the primary vault which holds the network's RUNE. This committee can only grow so big before the TSS gets too slow. Once the key generation process begins to take too long, the primary vault is split in 2. This process repeats until the network hits either the "block consensus limit" or the "economic limit", described below.

Block Consensus Limit

The THORChain blockchain is based on Tendermint consensus. Large committees slow down the processing of transactions onto the network's blockchain. The target speed for creating new blocks is 5 seconds. When block speeds get too slow, the system lowers the rewards get per block. This should reduce the number of nodes as they have less incentive to participate.

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 this can't keep the number of nodes down then the number of nodes that can join can also be reduced through governance.

Network Economics

Economic Security

The THORChain network needs to take care of assets from connected chains. This is tricky because all these assets have fluctuating prices. Prices that are set by the free market.

RUNE is the main asset that secures the network. So the value of RUNE needs to be tied to the value of the assets from connected chains.

Furthermore, the amount of RUNE that nodes need to bond must always be higher than what can be gained from stealing assets.

The value of connected assets is always tied to the value of RUNE. The exchange formula makes sure of this. If the amount that nodes have bonded in RUNE is double the amount that has been staked in pools then the staked capital is safe. The network is made even more safe by the fact that RUNE is really only useful and valuable if the THORChain network is actually working.

Given all this, to make sure it's safe, THORChain gives rewards to keep the optimal balance of nodes and stakers. That balance is 67% of RUNE being bonded by nodes and 33% of it being staked by liquidity providers.

Sometimes this split will become unbalanced. To fix this, the system has something called an "incentive pendulum". If staking is low, the rewards for staking go up. If the split is correct there are no staking rewards. This keeps the network balanced and secure.

Bond Rewards

All active, bonded nodes get a reward each time a block is processed. The system tries to keep the amount of RUNE that nodes need to bond quite stable. Over time this increases the median bonded amount, increasing the network's security.

To stabilize the bonding amount, the system gives the same amount of rewards to each node. It doesn't matter how much you bond. Nodes just need to bond enough to get chosen and become active in the next cycle.

Node Penalties

As mentioned, the system punishes bad behaviour in nodes. This is done in order to keep the level of service high for end-users.

Nodes are punished when they fail to—

• make witness transaction s
• complete key generation (creating vaults)
• complete key signing (sending outgoing transactions)

Liquidity Incentives

Liquidity Providers are rewarded for keeping their assets in the network's pools. They're rewarded every block.

The rewards are calculated according to whether or not the block contains any trades. If it does then the amount of slip-based fees sets the amount of rewards. If the block doesn't contain trades then the amount of assets in the pool determines the rewards.

Liquidity rewards make up 1/3 of all system income. System income is the total value of fees in each block. If the total value from slip-based fees makes up more than 1/3 of system income the extra capital goes to nodes as a reward. This means that if few assets are being removed, nodes can still get paid.

A network fee is taken whenever assets are taken out of the network. These are placed into the network's reserve.

Governance

Principles

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.

Asset Listing/Delisting

The main form of governance is done when users signal which assets they want on the network. To signal that they want the network to support a new asset, users make a staking transaction into the network.

Assuming the asset is on a chain which is already connected then the user's funds get added to what's known as a "bootstrapping pool". This is a normal asset pool except swapping is disabled on it. Every few days the networks looks at all the boostrapping pools and lists the one with the highest value.

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

To relist the asset the process must be repeated.

Chain Listing/Delisting

When the community wants to support a new chain, developers can write software which connects it to THORChain. Once submitted the code gets tested and validated by a core group of developers. If accepted, it gets added to the main piece of software that all nodes run – the "primary binary".

Whenever nodes are cycled off the network they update their software. When 67% of nodes are running software and watching the new chain it gets added.

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

There are 3 main components to the software that nodes run—

1. application logic – runs the blockchain
2. schema – stores key values of vaults
3. network software – keeps the TSS protocol key generation and signing

Upgrading the software happens when nodes are cycled off the network. Application logic and schema has 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 the first thing that happens is that the 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. There's a "genesis import" to a new network and it's off.

Conclusion

THORChain makes exchange of assets possible across a wide range of blockchains. It's secured by economic rewards and punishment. The nodes who run the network are regularly cycled out and need to reapply. This keeps the service resilient and available. External assets are pooled and can be swapped easily.