Introduction - THORChain, Midgard, Wallets, and the rest of the ecosystem.

THORChain is a decentralised cross-chain liquidity protocol based on Tendermint & Cosmos-SDK and utilising Threshold Signature Schemes (TSS). It does not peg or wrap assets, it simply determines how to move them in response to user-actions.

THORChain observes incoming user deposits to vaults, executes business logic (swap, add/remove liquidity), and processes outbound transactions. THORChain is primarily a leaderless vault manager, ensuring that every stage of the process is byzantine-fault-tolerant.

THORChain's key objective is to be resistant to centralisation and capture whilst facilitating cross-chain liquidity. THORChain only secures the assets in its vaults, and has economic guarantees that those assets are safe.

How It Works

Fees

Conceptually, fees are both value-capture, access-control and resource-subsidisation mechanisms.

Value Capture

The fees need to capture value from those accessing the resource, and pay it to those providing the resource, and in this case the resource is liquidity. However liquidity is relative to the size of the transaction that demands it over the depth of the market that will service it. A small transaction in a deep pool has less demand for liquidity than a large transaction in a small pool.

Access-control

The other reason for fees is access-control; a way to throttle demand for a fixed resource and let natural market forces take over. If there is too much demand for a resource, fees must rise commensurately. The resource in this case is liquidity, not market depth, thus fees must be proportional to liquidity.

Resource Subsidisation

Every swap on THORChain consumes resources (Disk, CPU, Network and Memory resources from validators). These costs are fixed in nature. In addition, every outgoing transaction demands resources on connected chains, such as paying the Bitcoin mining fee or Ethereum gas cost. As such, THORChain charges a single flat fee on every transaction that pays for internal and external resources.

Other Benefits

In addition to the above, fees also create the following benefits:

1.Avoid dust attacks

2.Store up income after the initial Emission Schedule reduces

3.Give the user a stable fee, rather than a dynamic one which changes with the external network's fees

Fee Process

THORChain maintains an awareness of the trailing gas price for each connected chain, saving both gas price as well as gas cost (inferring transaction weight). Nodes are instructed to pay for outgoing transactions using a gas price that is a multiple of the stored value.

The gas is consumed from each chain's base asset pool - the BTC pool pays for Bitcoin fees, the ETH pool for Ethereum fees etc.

The network then observes an outgoing transaction and records how much it cost in gas in the external asset. The final gas cost is then subsidised back into each pool by paying RUNE from the reserve.

Outbound Fee

The user is charged an amount that is three times the stored gas cost for each chain. The Node can then pay a gas price that is 1 times the gas price, and the pool is subsidised a value that is twice what was observed. This means the pool earns a margin of 1x, and the Reserve earns a margin of 1x.

The Network Fee is collected in RUNE and sent to the Protocol Reserve. If the transaction involves an asset which is not RUNE the user pays the Network Fee in the external asset. Then the equivalent is taken from that pool's RUNE supply and added to the Protocol Reserve.

If the transaction is in RUNE then the amount is directly taken in RUNE.

Slip-Based Fee

The CLP algorithm includes a slip-based fee which is liquidity-sensitive. Since demand for liquidity is defined as the size of the transaction over the depth of the market that will service it, then a fee which is proportional to liquidity solves key problems.

Firstly it has better value-capture when demand for liquidity is high, no matter the size of the transaction or the depth of the market. This means that over time, pool depths will settle to an equilibrium that is relative to the sizes of transactions that are passed over it. This solves the bootstrapping problem, because low-depth pools may turn out to be more profitable than high-depth pools to liquidity providers.

Secondly it has better access-control, since the more a trader (or attacker) demands liquidity, the more they have to pay for it. This makes sandwich attacks prohibitively expensive allowing pools to become reliable price feeds.

Network Fee

The third fee to discuss is the Network Fee. This is what users pay to make transactions on THORChain ledger itself. Currently, this is fixed and available on the /constants endpoint, but it is intended to be dynamic and set to be a fixed $ qty of assets. Additionally, THORChain has custom gas logic where users pay fees in the asset they send, because all assets on THORChain have protocol pricing, either being RUNE, or synths, where synths are derived from the pools themselves.

Advantage Over Alternative Reference Price Designs

THORChain's reference price model differs to other decentralised exchanges. Other exchanges use external oracles and weighted averages to set their prices. This has proven problematic as these external sources become attack vectors.‌

These external sources are problematic because people can manipulate them. Technical and ecosystem factors can also affect them. For example, the network underlying oracles can become congested and affect their performance. Weighted averages are better than taking direct price references, but large actors can still manipulate them.‌

THORChain is able to sense both the instantaneous price of an asset, as well as its purchasing power (how much would the asset purchase of another asset if it was instantly sold). The latter is important when it comes to collaterising debt, because the spot price is irrelevant - the purchasing power is needed.

Roles

There are four key roles in the system:

1.Liquidity providers who add liquidity to pools and earn fees and rewards

2.Swappers who use the liquidity to swap assets ad-hoc, paying fees

3.Traders who monitor pools and rebalance continually, paying fees but with the intent to earn a profit.

4.Node Operators who provide a bond and are paid to secure the system

Liquidity Providers - Providing liquidity to THORChain liquidity pools.

Liquidity providers provide assets to the THORChain liquidity pools. They are compensated with swap fees and system rewards. Compensation is affected by a number of factors related to the pool and the state of the network.

Note: Liquidity providers commit capital to pools which have exposure to underlying assets, thus liquidity providers gain exposure to those assets, which have free-floating market prices.

While they are paid block rewards and liquidity fees, these are dynamic and may not be enough to cover "Impermanent Losses", which occur when price changes happen.

Liquidity providers should not consider they are entitled to receive a specific quantity of their assets back when they deposit, rather that they will receive their fair share of the pool's earnings and final asset balances.

Liquidity Compensation

Liquidity providers deposit their assets in liquidity pools and earn yield in return. They earn tokens in Rune and the pool's connected asset. For example, someone who has deposited in the BTC/RUNE pool will receive rewards in BTC and RUNE.

Yield is calculated for liquidity providers every block. Yield is paid out to liquidity providers when they remove assets from the pool.

Rewards are calculated according to whether or not the block contains any swap transactions. If the block contains swap transactions then the amount of fees collected per pool sets the amount of rewards. If the block doesn't contain trades then the amount of assets in the pool determines the rewards.

This ensures that yield is being sent to where demand is being experienced - with fees being the proxy. Since fees are proportional to slip, it means the increase in rewards ensure that pools experiencing a lot of slip are being incentivised and will attract more liquidity.

Factors Affecting Yield

Ownership % of Pool – Liquidity providers who own more of a pool receive more of that pool's rewards.

Swap Volume – Higher swap volumes lead to higher fees. Higher fees lead to higher rewards for liquidity providers.

Size of Swaps – Swappers who are in a hurry to exchange assets will tend to make larger swaps. Larger swaps lead to greater price slips and therefore higher fees.

Incentive Pendulum – The Incentive Pendulum balances the amount of capital bonded in the network versus pooled. It does this by changing the amount of rewards given to node operators versus liquidity providers. Sometimes rewards will be higher for liquidity providers to encourage them to deposit assets; sometimes the opposite. Learn more.

Change in Asset Prices -- If the price of the assets change, then liquidity providers will receive more of one and less of the other. This may change yield if yield is being priced in a third asset, ie, USD.

Yield - How it Works

Depositing assets on THORChain is permissionless and non-custodial.

Liquidity providers can propose new asset pools or add liquidity to existing pools. Anybody can propose a new asset by depositing it. See asset listing/delisting for details. Once a new asset pool is listed, anybody can add liquidity to it. In this sense, THORChain is permissionless.

The ability to use and withdraw assets is completely non-custodial. Only the original depositor has the ability to withdraw them. Nodes are bound by rules of the network and cannot take control of user-deposited assets.

Process

Liquidity can be added to existing pools to increase depth and attract swappers. The deeper the liquidity, the lower the fee. However, deep pools generally have higher swap volume which generates more fee revenue.

Liquidity providers are incentivised to deposit symmetrically but should deposit asymmetrically if the pool is already imbalanced.‌

Withdrawing Assets

Liquidity providers can withdraw their assets at any time. The network processes their request and the liquidity provider receives their ownership % of the pool along with the assets they've earned. A network fee is taken whenever assets are taken out of the network. These are placed into the network reserve.

Yield Comes from Fees & Rewards

Liquidity providers earn a yield on the assets they deposit. This yield is made up of fees and rewards.

Fees are paid by swappers and traders. Most swaps cause the ratio of assets in the liquidity pool to diverge from the market rate.

Note: The ratio of assets in a liquidity pool is comparable to an exchange rate.

This change to the ratio of assets is called a 'slip'. A proportion of each slip is kept in the pool. This is allocated to liquidity providers and forms part of their staking yield. Learn more about swapping.

Rewards come from THORChain's own reward emissions. Reward emissions follow a predetermined schedule of release.

Rewards also come from a large token reserve. This token reserve is continuously filled up from network fees. Part of the token reserve is paid out to liquidity providers over the long-term. This provides continuous income even during times of low exchange volume.

Requirements, Costs

Liquidity providers must have assets to deposit and their assets must be native to a supported chain. There is no minimum amount to deposit in existing pools. However new assets must win a competition to be listed – larger value deposits will be listed over smaller value deposits.

Liquidity providers must pay for security of their assets, since security is not free. This "payment" is the requirement for liquidity providers to hold RUNE, which acts as a redeemable insurance policy whilst they are in the pool. Holding RUNE allows liquidity providers to retain an ability to economically leverage nodes to ensure security of assets. When the liquidity provider withdraws, they can sell their RUNE back to the asset they desire. H

The only direct cost to liquidity providers is the network fee, charged for withdrawing assets (pays for the compute resources and gas costs in order to process outbound transactions). An indirect cost to liquidity providers comes in the form of impermanent loss. Impermanent loss is common to Constant Function Market Makers like THORChain. It leads to potential loss of liquidity provider purchasing power as a result of price slippage in pools. However, this is minimised by THORChain's slip-based fee.

Swappers

THORChain's value proposition for Swappers.

On THORChain, users can swap their digital assets for other digital assets. The network aims to give users access to: (1) A large variety of assets through cross-chain compatibility and simple asset listing

(2) Superior user experience through open finance protocols and permissionless access

(3) 1-transaction access to fast chains (Binance Chain), smart chains (Ethereum), censorship-resistant chains (Bitcoin) and private chains (Monero).

How Swaps Work - Available Assets

Users can swap any assets which are on connected chains and which have been added to the network. Users can swap from any connected asset to any other connected asset. They can also swap from any connected asset to RUNE.

Decentralisation

THORChain manages the swaps in accordance with the rules of the state machine - which is completely autonomous. Every swap that it observes is finalised, ordered and processed. Invalid swaps are refunded, valid swaps ordered in a transparent way that is resistant to front-running. Validators can not influence the order of trades, and are punished if they fail to observe a valid swap.

Swaps are completed as fast as they can be confirmed, which is around 5-10 seconds.

Continuous Liquidity Pools

Swaps on THORChain are made possible by liquidity pools. These are pools of assets deposited by Liquidity providers, where each pool consists of 1 connected asset, for example Bitcoin, and THORChain's own asset, RUNE. They're called Continuous Liquidity Pools because RUNE, being in each pool, links all pools together in a single, continuous liquidity network.

When a user swaps 2 connected assets on THORChain, they swap between two pools:

1.Swap to RUNE in the first pool,

2.Move that RUNE into the second pool,

3.Swap to the desired asset in the second pool with the RUNE from (2)

The THORChain state machine handles this swap in one go, so the user never handles RUNE.

Traders

Balancing pools to exploit price deltas between markets.

Prices on THORChain are maintained by profit-seeking traders. Traders find assets that are mispriced between markets. They buy assets on markets with low prices and sell them on markets with high prices. This earns them a profit.

Traders compare the exchange rates on THORChain with the rates on external markets. If they find the price is lower on THORChain they can buy there and sell on an external market. If they find the price is lower on external markets they can buy there and sell on THORChain. This process is repeated at high-frequency. Over time, price information propagates and THORChain settles with external markets.

This is how THORChain avoids the need for oracles and how prices are set.

How it Works - Process

A swap takes place in the MATIC/RUNE pool, as described in Prices. This leaves the pool unbalanced. The ratio on THORChain is 20:1 MATIC:RUNE, but is 16:1 on external markets. This means that RUNE is undervalued on THORChain.

Traders can now buy cheap RUNE on THORChain and sell it for a profit on external markets. To do so, they swap MATIC into the pool and get RUNE out. They sell this RUNE on external markets and make a profit.

The economics of the swap formula mean that traders should aim to restore balance to the pool in a single trade. Rebalancing should be done incrementally. If larger rebalancing trades are attempted, arbitrage may not be profitable for traders.

Specifically, each rebalancing trade should be 40–50% the imbalance size. So if the imbalance starts at $100 in value, the first rebalancing trade should be between $40–50. This will leave the imbalance at $50–60. The next rebalance should be $25–30. This process repeats until a satisfactory balance is restored.

Impact of Liquidity

Trading profits are impacted by liquidity on THORChain and on external markets. As an example, if the price of the asset in a THORChain pool is $1.20, but the same asset on an external market is $1.00, then someone can buy off that external market and sell into the THORChain pool for profit.

Infinitely Deep Liquidity

If both markets are infinitely deep, then the following will occur:

• Buy on External Market for $1.00, no price slip.

• Sell on THORChain for $1.20, no price slip.

• Total Profit: 20%

The trader can then continue to arbitrage for a profit of 20% continuously.

Finite, but Uneven Liquidity

If both markets have finite liquidity, but one is much deeper than the other, then the one of the markets will slip in price after the trade. However, the trader will experience a price that is roughly the average of the price before and after the trade:

• Buy on External Market for $1.00, no price slip.

• Sell on THORChain for $1.20, realised price of $1.10, price slip to $1.00.

• 
  

• Total Profit: 10%

After the trade, there is no more price differential, but the trader made 10% in profit. The trader has made the pool price equal to the secondary market. They have transferred price information from one market to another.

Low Liquidity

If both markets have low liquidity, then the trader is attempting to make trades that slip each market towards each other:

• Buy on External Market for $1.00, realised price of $1.05, price slip to $1.10.

• Sell on THORChain for $1.20, realised price of $1.15, price slip to $1.10.

• Total Profit: >10%

Compensation, Requirements, Costs & Penalties

THORChain does not offer explicit incentives to traders – it does not reward or punish them. Trading profits are determined by the capacity of traders to seek out and capitalise on price differentials between THORChain and external markets.

The majority of arbitrage opportunities will be exercised by software bots. These are under development by 3rd party entities and will be released in due time. They will be open-source and available for anybody to run.

Node Operators

THORNodes service the THORCHain network, of which there is intended to be initially 120. Each THORNode is comprised of several independent servers. All THORNodes communicate and operate in cooperation to create a cross-chain swapping network.

Running a node is a serious undertaking. While Node Operators are well compensated for running a node, there are also risks, skills required and costs.

1.Set up manually (not recommended unless you are an expert)

2.Set up via Kubernetes (recommended)

3.Set up via Provider (coming soon).

Risk of Running a Node

Deciding to run a node should be carefully considered and thought through. While the payoffs/rewards can be significant, there can also be an equally significant costs.

Risks to Bond

To run a node, you must obtain a significant amount of Rune, minimums apply. This RUNE is sent into the network as “bond” and held as leverage on each node to ensure they behave in the best interest of the network.

Running a malicious node or stealing from the network results in a slashing of this bond. Here are the ways in which a validator’s bond can get slashed.

• Double Sign (5% of minimum bond) - if it is observed that a single validator node is committing blocks on multiple chains. To avoid this, never run two nodes with the same node account at the same time.

• Unauthorised transaction (1.5x transaction value) - if a node sends funds without authorization, the bond is slashed 1.5x the value of the stolen funds. The slashed bond is dumped into the pool(s) where the funds were stolen and added to the reserve.

Bond slashing takes directly from the bond and does not affect rewards.

Risk to Income

When a node is active, it earns rewards from the network in RUNE. Sufficient rewards are required to be earned in order for a Validator to be profitable. Running an unreliable node results in rewards being slashed. Here are the ways in which a validator’s rewards can be slashed.

• Not Observing (2 slash pts) - if a node does not observe transactions for all chains, while other nodes do, they get slash points added.

• Not signing a transaction (600 slash pts) - if a node does not sign an outbound transaction, as requested by the network, they will get slash points added.

• Fail to keygen (1 hr of revenue) - When the network attempts to churn, and attempts to create a new Asgard pubkey for the network, and fails to do so due to a specific node(s), they will lose 1 hr of revenue from their bond.

Slash points undo profits made on the network. For every 1 slash point a node receives, they lose 1 block of rewards. Rewards slashing reduces earned rewards and does not affect a validator’s bond.