About

THORChain is an independent, cross-chain liquidity protocol that operates as a Layer 1 decentralised exchange (DEX). Built on the Cosmos SDK, it utilizes the Tendermint consensus engine, the Cosmos-SDK state machine, and the GG20 Threshold Signature Scheme (TSS) to execute its purpose, which is to allow users to swap native assets across multiple chains with zero reliance on centralised third parties. In doing so, it stands as one of the few exchanges that verifiably ensures transparent and fair prices for cross-chain swaps of native assets.

THORChain's design renders no need for wrapped or pegged assets. Instead, the protocol deploys what are called continuous liquidity pools (CLPs), which—with highly complex algorithms—maximise the efficiency of its transactions. These CLPs allow for THORchain to manage funds directly in on-chain vaults, and it secures those funds via an economic security model. For all this, THORChain might be best described as a "cross-chain automated market maker (AMM), like Uniswap", or even a "decentralised Binance".

THORChain Finance

Building on the foundation of liquidity pools, THORChain pursues two important financial primitives:

1. Allow a user to Swap {Asset X on Chain A}, to {Asset Y on Chain B}.

2. Allow a user to Pool RUNE across liquidity pools,

Developers

Developers can create innovative products that integrate with THORChain, including wallets, exchanges, and various services, monetising these efforts via affiliate fees (e.g., up to 10% in affiliate fees for swaps and liquidity additions). All that is needed is a focus on creating engaging front-end interfaces and attracting users.

Developers interested in integrating THORChain should read the Dedicated Developer Documentation, as well as the quick start guide for Swapping.

Innovations

All created with the first principles of being decentralized, resistant to capture, as sustainable as possible, there are many novel innovations embedded within the THORChain Protocol:

1. Capped Proof Of Bond: Validator selection keeps the network decentralised and Nakamoto Coefficient high

2. 3-Day Validator Churning: eliminates validator stagnation, proves spendability of funds, and upgrades the network—all with minimal governance

3. Asynchronous Network Upgrades: allows validators to upgrade to a new protocol version in their own time; network upgrades occur without ever breaking consensus

4. Chain-agnostic Bifrost Protocol: handles UTXO, EVM, BFT and Cryptonote chain connections with minimal core-logic nuances

5. Incentive Pendulum: streams rewards to Validators and Liquidity Providers to target a Network Security ratio that ensures funds are always secured

6. Continuous Liquidity Pools: allow single-sided liquidity provision, use liquidity-sensitive or "slip-based" fees to resist price attacks

7. Swap Queue: orders swaps based on price impact in each block, stopping sandwich attacks and most other forms of Miner Extractable Value (MEV).

3-Pillars of THORChain: Security, Liquidity, Volume

THORChain contributors work only towards three goals:

1. Security: Perpetually improve the security of the network, via either Functional Security—e.g., Solvency Checker, Node Pause, TxOut Throttler; Procedural Security—e.g., THORSec, Stagenet testing, PR reviews; or Economic Security—e.g., bonded RUNE value

2. Liquidity: Perpetually increase the liquidity of the network by incentivizing users to deposit into liquidity pools, thereby increasing the network's Total Value Locked (TVL)

3. Volume: Improve the volume of the network via swap UX and wallet integrations (Quotes Endpoint, Dev UX, BD)

You can learn how THORChain works here:

THORNodes

THORNodes are anonymous individuals who bond their RUNE to the network in order to provide validation services. As a fully permissionless network, THORChain allows anyone with the required funds to do this—all while maintaining user security. To further elevate network security, THORChain maintains a high churn schedule for these validators, every three days kicking out the oldest, slowest, and lowest bonded. This high-churn model ensures that THORChain remains resistant to centralization, capture, and censorship.

Each individual THORNode is comprised of several independent servers in a cluster, which run full-nodes for each connected chain. Initially intended to max out capacity at 100 nodes, the protocol is now able scale to 250+ nodes.

CONTRIBUTING

THORChain is an open-source, public project. If you want to join the community or work on THORChain Core, please do join the Dev Discord.

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.

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.

How a block with swap fees splits the reward. In this example, 1000 RUNE is being divided as rewards:

How a block with no swap fees splits the rewards. In this example, 1000 RUNE is being divided as 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.

How it Works

Depositing Assets

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.

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.

Learn about how factors affecting yield and how yield is calculated.

Strategies

Passive liquidity providers should seek out pools with deep liquidity to minimise risk and maximise returns.

Active liquidity providers can maximise returns by seeking out pools with shallow liquidity but high demand. This demand will cause greater slips and higher fees for liquidity providers.

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.

Liquidity providers are not subject to any direct penalties for misconduct.

How Yield is Calculated

The yield of a pool on THORChain is calculated using a metric called Liquidity Unit Value Index (LUVI) which can be viewed on Midgard.

When a user deposits assets into a liquidity pool, they are given ownership of Liquidity Units which represent a percentage of ownership of the pool. LUVI is a measure of the relative value of each liquidity unit and is independent of price.

Where:

The yield of a pool uses LUVI value data from the previous 30 days and extrapolates an APR if that performance is repeated over the course of a year. A period parameter may be used to change the number of days of data that are taken into consideration.

Factors that affect LUVI:

• Swap fees, block rewards, and pool donations increase LUVI and are the primary yield sources

• An increase of the synthetic asset liability of a pool decreases LUVI

• An increase in ASSET Depth or RUNE Depth of a pool increase LUVI

• Changes in the ratio of ASSET Depth and RUNE Depth in a pool change LUVI

• Changes in ASSET Price or RUNE Price do not necessarily change LUVI.

On THORChain, users can swap their digital assets for other digital assets. The network aims to give users access to:

• A large variety of assets through cross-chain compatibility and simple asset listing

• Superior user experience through open finance protocols and permissionless access

• 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.

See this example for further detail and the page below for broader detail on Continuous Liquidity Pools.

Calculating Swap Output

The output of a swap can be worked out using the formula

where

• x is input asset amount

• X is input asset balance

• y is output asset amount

• Y is output asset balance

Example

The BTC.RUNE pool has 100 BTC and 2.5 million RUNE. A user swaps 1 BTC into the pool. Calculate how much RUNE is output:

This user swaps 1 BTC for 24,507.40 RUNE.

Costs

The cost of a swap is made up of two parts:

1. Outbound Fee

2. Price Slippage

All swaps are charged a network fee. The network fee is dynamic – it's calculated by averaging a set of recent gas prices. Learn more about Network Fees.

Note that users who force their swaps through quickly cause large slips and pay larger fees to liquidity providers.

Using THORChain

THORChain offers a suite of decentralized and permissionless services:

*THORChain does NOT currently support Taproot addresses (BTC, LTC or otherwise).

Interacting with the RUNE token

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.

What are automated market makers and liquidity providers?

Automated market makers (AMMs) are decentralised exchanges (DEX) that pool liquidity from users and price the assets within the pool by using algorithms. The exact mechanics vary from exchange to exchange, but generally, AMMs offer deep liquidity, low transaction fees, and 100% uptime for as many users as possible.

Liquidity Providers (LPs) are network participants who deposit their assets into these pools (i.e. virtual, asset-specific reservoirs), and by doing so, come to own a share of that particular pool for as long as they retain their assets within. In exchange for adding their assets to the pools, LPs earn rewards, as swappers (who use pools to exchange assets) incur fees, which are proportionally distributed to the pool owners. Some protocols also boost the liquidity APY by emitting block rewards (for example, $BNT by Bancor and $RUNE by THORChain).

What is THORChain?

THORChain is an independent blockchain that operates as a Layer 1 cross-chain decentralised exchange (DEX). Built using the Cosmos SDK, THORChain enables the exchange of assets across disparate blockchains in a non-custodial manner. THORChain is the backend for many user interfaces.

Key selling points of THORChain are:

• The ability to swap Layer 1, or native, assets across multiple chains - e.g. native BTC to ETH swap.

• No user-registration required - simply send a transaction and THORChain will execute it.

• No wrapped assets - all assets are natively secured.

• Transparent, fair prices, without relying on centralised third-parties.

• Continuous Liquidity Pools that maximise the efficiency of the protocol.

➜ An Introduction to THORChain for Bitcoiners

What is RUNE?

THORChain features a native token RUNE, which owners can use to participate in the network and is used to pay for the swap/gas fees for RUNE pairs. RUNE has specific utility within the THORChain ecosystem, as it fills four key roles:

• Settlement Asset

• Network Security

• Governance

• Incentives

RUNE as a Settlement Asset

RUNE is the settlement asset for all pools, so a 1:1 ratio of RUNE:ASSET is required for pooling. For example, a pool with $100,000 in BTC will necessarily hold $100,000 worth of RUNE. Within a pool, all assets will have a 50% pairing with RUNE regardless of how assets are added or withdrawn.

RUNE for Network Security

In order to provide network security, THORChain requires twice as many RUNE to be bonded by Node Operators as there is RUNE pooled. For this security provision, node operators are economically incentivised to work within the network’s best interest.

RUNE for Governance

Users can vote with their liquidity (RUNE:ASSET symmetrically added) for the pools they want to be active. The pools with the most liquidity (i.e. deepest) become active.

RUNE as Incentives

Block rewards are paid to Liquidity Providers and Node Operators on a set emission schedule - which are in addition to swap fees.

How Swapping Works

Swaps in THORChain use native assets. Example: When a swap from RUNE to BTC occurs, RUNE is sent into THORChain from the user and BTC is sent out from one of THORChain’s vaults - Inbound gas is paid in RUNE, Outbound Fee is paid in BTC.

When Swapping from BTC to ETH, BTC is sent into THORChain from the user and ETH is sent out from one of THORChain’s vaults. Internally, once the BTC is received, RUNE moves from the BTC pool to the ETH Pool - thus it is a double swap (BTC:RUNE, RUNE:ETH). Inbound gas is paid in BTC, Outbound Fee is paid in ETH. See Swappersfor more information.

Risks associated with providing liquidity

Alongside the obvious investment risks of any asset, with liquidity provision, there also comes the risk of impermanent (price-divergent) loss. The bigger the divergence of price between the two assets, the more you are exposed to impermanent loss.

When you provide liquidity in a liquidity pool, the two assets are bound together by the system because it will ensure that both sides of the pool have the same value. If the price of your deposited assets changes in the wider markets, then swappers will sell one side of the pool for the other. Thus your assets are continuously sold "on the way up" or "on the way down". In fact, your assets are sold at a price that is an average of the starting price and ending price. If you then compare your original deposited assets with what you finally get, you will think you "could have got a better price based on today's value"

This is called impermanent loss because the losses are only realised when you withdraw from the pool. If the ratio swings to 5x (25.5% IL) but comes back to the same ratio when you entered the pool and withdrew your liquidity at that time, you will not have suffered any impermanent loss. It is similar to traditional finance’s unrealized losses. However, when you withdraw your liquidity from the pool at any other time, the loss becomes real and permanent. The fees you earn are generally able to compensate for those losses, or you may experience no loss at all and withdraw well compensated for your time in the pool.

LPs are encouraged to provide liquidity in pools that they are bullish on, or neutral on (don't care what the final price is). If an LP provides assets in a pool that they become bearish on, then they will be emotionally affected by the price draw-down, and may pull their assets out and realise a permanent loss.

➜ Liquidity Pooling Example High Level

Overview

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.

Rewards

Node Operators earn 67% of the system income when it is stable. You can read more here:

Set up Instructions

Follow these setup up instructions

Anonymity

Node Operators should stay anonymous and never socially signal that they are running a node.

Tools

There are a variety of tools available in the ecosystem for Node Operators, such as the Telegram Alerts bot:

Security

The most important aspect is that Nodes must pay for their Bond, since this is a core assumption to the security of the network. If a node pays $1m for their bond, then they will never try to steal assets unless if they can access more than $1m of funds. If they can, then they will make a profit.

If delegation was permitted, a Node Operator that paid $100k in RUNE, can possibly receive $900k in delegated funds to qualify and meet the $1m bond requirement. They will now contemplate stealing assets the moment they get access to more than $100k in capital, which is likely.

Private Delegation

THORChain makes private delegation possible, because it does not erode towards the issues discussed above.

Private Delegation requires Node Operators to know and whitelist in their bonders, and there can only be up to 100 per node. This assumes the bonders are in trust circles with their operators and have their own recourse to ensure operators act in accordance to their obligations. From the point of view of THORChain, a solo node is no different to a delegated node. The network will operate identically.

In addition, there is no discretion as to fee commissions per operator. This means bonders will prioritise on engaging with operators based purely on their trust circles, not fees.

Overview

RUNE is the asset which powers the THORChain ecosystem and provides the economic incentives required to secure the network. RUNE has four key roles which are described below.

1. Liquidity (as a settlement asset)

2. Security (as a sybil-resistant mechanism, and a means for driving economic behaviour)

3. Governance (signalling priority on-chain)

4. Incentives (paying out rewards, charging fees, subsidising gas)

1. Liquidity

Transmitting Purchasing Power

Since RUNE is pooled 50:50 alongside external assets in its pools, when the value of those assets increase/decrease, the RUNE pooled will also increase/decrease by being arbed out or in. The RUNE unit value may not change, but the quantity of RUNE in the pool does. This means the system is always aware of the value of the assets it is trying to secure - it's simply the quantity of RUNE in all its pools.

Once it is aware of the value of the assets it is securing, it can use incentives to ensure security of those assets.

Providing Liquidity Incentives

Since RUNE is the pooled asset, incentives can be paid directly into each pool. This extra capital is owned by the liquidity providers, and over time, slowly "purchases" the paired asset via arbitrage. Thus RUNE liquidity incentives can drive real yield to LPs.

Solving O(n^2) Problem

Without a native settlement currency, each asset would need to be pooled with every other asset, which would eventually result in hundreds of new pools to be created for just one new asset, diluting liquidity. Having RUNE as the base pair allows any asset to be guaranteed to swap between any other asset.

2. Security

Sybil-resistance

Sybil-resistance refers to the ability to prevent someone masquerading as many identities in order to overcome a network. Bitcoin uses Proof-of-Work (one-cpu-one-vote) to prevent a network take-over. Ethereum 2.0 will use Proof-of-Stake (32-eth-one-vote) to prevent a network take-over.

THORChain is a Proof of Bond network instead. THORNodes commit a bond in order to be churned in. However, this bond isn't just used to identify a node (give them a voting slot), it is used to underwrite the assets in the pools. If the node attempts to steal assets, then their bond is deducted to the amount of the assets they stole (1.5x), and the pools are made whole. Additionally, if nodes misbehave their bond is slashed, ensuring reliable service.

Underwriting Assets

The Incentive Pendulum ensures that Nodes are incentivised to continually buy and bond enough Rune each time to maximise their gains - which is a maximum when there is 67% of RUNE bonded and 33% pooled in pools. If the pools are holding $100m in capital, then the value of RUNE in the aggregate bond is $200m. Thus all assets can be underwritten.

The bond is extremely liquid - any RUNE holder can immediately enter or exit their position since RUNE is the settlement asset in all pools. Thus, when a node churns in, the cost basis of their bond is known to them and not an arbitrary figure. This means a node bonding $1m in RUNE will never contemplate making a decision to steal <$1m in capital from the network, else they will lose overall.

3. Governance

LPS: Signalling Priority for Assets

While THORChain strives to be governance-minimal, there are some parts of the protocol that use committed capital to signal priority. This is the case for the asset listing process, where every few days a new asset can be listed as a pool. In a queue of standby assets, the one with the deepest commitment of RUNE is the one that is listed first.

LPs: Signalling Priority for Chains

Additionally, if a connected chain is no longer economically valuable, then all liquidity providers in that chain can leave. If a pool is empty, it will be delisted, and this will cause the network to immediately sever ties with that chain in a process call a "ragnarok".

One-Node-One-Vote

THORNodes each occupy one of the 100 slots in the system can can vote on changing network parameters using a mechanism called node-mimir.

4. Incentives

Fees

RUNE is the native currency of THORChain and is consumed as transaction fees on the network. All swaps are charged both a fixed network fee, as well as a dynamic slip-based fee. This prevents various attack paths such as denial-of-service attacks, as well as sandwich attacks on a pool. Learn more about fees here:

Subsidising Gas

The network continually consumes gas as it makes outgoing transactions (as well as internal transactions). Gas on networks such as Bitcoin and Ethereum becomes complicated fast, so THORChain doesn't make much of an effort to track every minutia of gas consumed. Instead, nodes are free to use at-will the base assets BSC.BNB, ETH.ETH, BTC.BTC, etc in order to pay for gas. These assets are used directly from the vaults. THORChain then observes outgoing transactions, reports on the gas used, and then pays back the liquidity providers in those pools to the value of twice the amount of gas used (in RUNE).

Paying out Emissions

After fees are charged and gas is subsidised, then THORChain computes the block reward, divides it based on the Incentive Pendulum algorithm, and then pays out to Bonders and Liquidity providers.

This drives Nodes to bond the optimal amount, and pays Liquidity providers for their contribution of liquidity.

Learn about the Incentive Pendulum here:

Deterministic Value of RUNE

In addition to the roles mentioned above, RUNE’s price has two factors; 1 a deterministic value based on the liquidity within the network and 2; a speculative premium.

This 2:1 bond:stake ratio, combined with the 1:1 pool ratio, means that the amount of RUNE needed in the network is three times the amount of the non-RUNE assets locked. Thus, if $1,000,000 worth of non-Rune tokens are staked in THORChain, the market cap of RUNE will be at least $3,000,000. And like any token, stock, or asset in the world of finance, speculation around future value encourages additional upward price pressure.

The 3:1 ratio is just the minimum or the deterministic value of RUNE.

For more informaiton on RUNE see

• THORChain Tokenomics Article

• Under the Hood: Rune Supply

• Currnet Supply Data

• THORChain Tokenomics Dashboard

High Level Overview

Getting Started

Technical Info

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

Users signal which assets they want on the network by staking in a new pool. THORChain will realise it is a new asset it hasn't been seen before and create a new pool and place it in bootstrap mode. 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.

Asset Delisting

Assets are delisted when all liquidity providers have taken all their assets out of it, or its pool depth drops too low. The logic is:

1. When a new bootstrap pool is enabled, its depth is compared with the depth of the smallest active pools.

2. If it is deeper, the smallest active pool is placed back into bootstrap mode, and the new pool replaces it.

The process is repeated to re-list an asset.

Chain Listing/Delisting

When the community wants to support a new chain

2. THORChain developer community decides whether or not to approve it

3. If approved, the code gets tested and validated by core developers

4. If accepted, it gets added to THORNode software

5. Nodes upgrade their software as they are cycled off and back onto the network

6. 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.

Change Management within THORChain

Developers from the community submit Architecture Decision Records (ADR) which are then voted on by node operators. An ADR should provide:

• Context on the relevant goals and the current state

• Proposed changes to achieve the goals

• Summary of pros and cons

• References

• Changelog

Emergency Changes

Emergency changes are difficult to coordinate because nodes cannot communicate. To handle an emergency, nodes should leave the system. When the number of nodes falls below 4, funds are paid out and the system can be shut-down. This process is called Ragnarök.

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 system is ever found to be always under-bonded or over-bonded, the minimum bond limit can be changed.

Mimir

Mimir is a feature to allow changes in the constants of the chain, such as MinimumBond, ChurnSpeed and more.

There are two types of mimir

• Node Mimir: set by each node. Once 2.3rds have set a mimir, it is enacted. Only active nodes have their votes counted

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.

A full overview of the THORChain fees:

Inbound 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.

Additionally a slip-based fee is stateless and non-opinionated. The final fee paid is always commensurate to the demand of resources (both internal and external) no matter what it is.

This fee is retained on the output side of the pool, ensuring it counters the trade direction.

Streaming Swaps has greatly increased the swap capital efficiency. A minumum 5 pbs fee now applies to all swaps.

Outbound Fee

Any outbound liquidity incurs a fee to pay for the outbound gas cost and a network fee which is deducted from the outbound amount. The outbound gas will be sufficient for the outbound to be in the next block.

The network fee is collected in RUNE and sent to the Protocol Reserve. If the transaction involves an asset that is not RUNE the user pays the Network Fee in the external asset. If the transaction is in RUNE then the amount is directly taken in RUNE.

Network Fee

Overview

The network launched with a set number of constants, which has not changed. Constants can be overridden via Mimir and nodes have the ability to vote on and change Mimir values.

Mimir setting can be created and changed without a corresponding Constant.

Values

• Constant Values:https://midgard.ninerealms.com/v2/thorchain/constants

• Mimir Values: https://thornode.ninerealms.com/thorchain/mimir

Value details has been moved to the developer docs here.

Reserve

There are a maximum of 500m RUNE. All 100% was created at genesis and distributed via different mechanisms:

• In return for capital: 5% (SEED) and 16% (IDO) was sold for capital to start the network and give it value. They took on risk to support the network.

• In return for time and effort: 10% was allocated to a group of devs who worked since 2018. They took on risk to deliver the network.

• In return for bootstrap participation: 24% was given to users who participated in the bootstrapping of the network.

• In return for through-life participation: 44% has been placed in the Protocol to pay out to Nodes and LPs for the next 10+ years.

The Reserve module and other modules can be viewed here.

Block Rewards

Block rewards are calculated as such:

So if the reserve has 180m rune, a single block will emit ~4.28 Rune from the reserve, which means half of that is awarded to the node operators. The rest is paid to liquidity providers.

The exact distribution between node operators and liquidity providers (and therefore savers) is controlled by the Incentive Pendulum.

The emission curve is designed to start at around 30% APR and target 2% after 10 years. At that point, the majority of the revenue will come from fees.

System Income

The Reserve is continually topped up by income, such as transfer fees and outbound fees. Other sources of revenue include THORName fees and excess liquidation fees on collateral.

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 BTC/RUNE pool. This leaves the pool unbalanced. The ratio on THORChain is 20:1 BTC: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 BTC 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%

The market now has no more price differential. The trader has made each market equal to each other.

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.

Website: https://thorname.com/

Overview

THORNames allow anyone to register cross-chain wallet addresses to a 1-30 long string of hexadecimal characters which include special characters -_+ This makes them compatible to represent emojis ⚡️. THORNames are case insensitive.

Users use a special memo and a THORChain MsgDeposit transaction to register their addresses. This then allows the system to lookup the name and retrieve the correct corresponding address for the specified chain.

A THORChain address can be assigned one (1) THORName to manage the other addresses associated. For example: the THORName chris can receive $BTC to the chris.btc address, chris.eth to receive $ETH and so forth. Wallet providers will easily be able to integrate to resolve cross-chain addresses for a user.

Example from https://midgard.ninerealms.com/v2/thorname/lookup/td

{
  "entries": [
    {
      "address": "0xee7ba2d9eca389928a628bf26ea87e65a5c27eca",
      "chain": "AVAX"
    },
    {
      "address": "qznskghhug46gxkx8ykxqxj4kmczge6zjg9trsgf5d",
      "chain": "BCH"
    },
    {
      "address": "bnb157sj7wvdju5td2hkgmkvkt2ngzlnyy7y46fswh",
      "chain": "BNB"
    },
    {
      "address": "0xee7ba2d9eca389928a628bf26ea87e65a5c27eca",
      "chain": "BSC"
    },
    {
      "address": "bc1qqtuq6td6enadcz8v7t2eafph0pq0cfjw2mzug9",
      "chain": "BTC"
    },
    {
      "address": "DBVz9bMNtDYrVLGqwhiFUzpYGcQu1B3PuR",
      "chain": "DOGE"
    },
    {
      "address": "0xe020c8934b23e5bcca1e7eecdb6f39674029fe47",
      "chain": "ETH"
    },
    {
      "address": "cosmos10w52zp06zccjq8zv9sh77p3n2c8sc559q5yl0z",
      "chain": "GAIA"
    },
    {
      "address": "thor1ymkrqd4klk2sjdqk7exufa4rlm89rp0h8n7hr2",
      "chain": "THOR"
    }
  ],
  "expire": "23726750",
  "owner": "thor1ymkrqd4klk2sjdqk7exufa4rlm89rp0h8n7hr2"
}

Currently, there are seven (8) native L1 chains available on THORChain: Bitcoin, Ethereum, Litecoin, Binance, Bitcoin Cash, Doge, Cosmos and BSC. THORNames are limited to 30 characters, including ^[a-zA-Z0-9+_-]+$.

Query a THORName

A THORName can be queried by going to /thorname/{thorname}

A THORName can be checked using /thorname/lookup/{thorname}

While there is no reverse on-chain reverse lookup, a reverse lookup is possible within THORChain via using a given THORName /thorname/lookup/{address}.

Fees

There is a one-time registration fee of around 10 RUNE, with a 20 tor block fee, which works out to be around 1 RUNE annually. A user who pays 2 RUNE will then keep their name registered for 2 years. Fees are controlled by Constants/Mimir, the current settings are:

• TNSRegisterFee: 10 RUNE

• TNSFeeOnSale: 1000 Basis Points

• TNSBlockFee: 20 tor per block (roughly 1 RUNE per year)

Example: a 20 Rune registration registers the THORName for 10 years. (10 RUNE Registration Fee + 1 RUNE every year).

Creating a THORName

THORNames are created by sending a memo in a MsgDeposit with memo prefix: name, n or ~

Memo template is: ~:name:chain:address:?owner:?preferredAsset:?expiry

Expiry is a block height that can be set in the past to unregister the THORName.

Technical Rationale

Bitcoin has a memo length limitation of 80 bytes and Monero has an address length of 97 bytes. This means swapping from Bitcoin to Monero is not possible using addresses, THORNames solves this issue and can also be used when specifying the affiliate address.

Interfaces like AsgardEx Desktop allow you to create your own memo.

More Information

THORChain launched THORNames in June 2021, read more here https://medium.com/thorchain/thorchain-launches-thorname-service-abe42ba11df8.

The Incentive Pendulum controls the flow of system income between node operators and liquidity providers based primarily on the Effective Security Bond and Total Vaulted. However, it also accounts for the Effective Bond and the Total Pooled to ensure an equitable and stable reward distribution. This mechanism adjusts the rewards dynamically to maintain a balanced network by incentivising either bonding or pooling as needed.

Key variables to the Incentive Pendulum are:

• Total Bonded: Sum of all RUNE bonded by active node operators.

• Bond Hard Cap : The highest bond in the bottom 2/3 of active node operators to ensure no single node has excessive influence on the Total Bond.

• Total Effective Bond: The sum of all active node operator's bonds up to the Bond Hard Cap. For each node, the bond amount added is capped by the Bond Hard Cap. This maintains a balanced and secure network by distributing bonding power more evenly among node operators.

• Effective Security Bond. The sum of the total bond of the bottom 2/3rds active node operators.

• Total Pooled: Sum of liquidity in all pools by liquidity providers which also includes synthetics and savers.

• Vault Liquidity: Sum vaule of L1 assets within all Asgard Vaults valued in RUNE. Includes Pooled L1s and Trade Account L1s.

The capital on THORChain can lose its balance over time. Sometimes there will be too much capital in liquidity pools; sometimes there will be too much bonded by nodes. If there is too much capital in liquidity pools, the network is unsafe. If there is too much capital bonded by nodes, the network is inefficient.

If the network becomes unsafe, it increases rewards (block rewards and liquidity fees) for node operators and reduces rewards for liquidity providers. If the network becomes inefficient, it boosts rewards for liquidity providers and reduces rewards for node operators.

Balancing System States

THORChain can be in 1 of 5 main states:

• Unsafe

• Under-Bonded

• Optimal

• Over-Bonded

• Inefficient

These different states can be observed through the relationship between bonded RUNE and Vaulted Liquidity, reflecting the amount of RUNE bonded by node operators, the amount of liqudity held in the Asgard Vault within or outside the of the liquidity pools.

Optimal State

In the optimal state:

1. Effective Security Bond is roughly double the Vault Liquidity.

2. Total Effective Bond is roughly 1.5 times the Effective Security Bond.

3. Total Pooled RUNE represents approximately two-thirds of the Vault Liquidity.

This results in:

1. An approximate 67% to 33% split between the Total Security Bond and pooled RUNE.

2. A 50% to 50% split between the Total Security Bond and Vault Liquidity.

It is important to note that yield is paid based on the liquidity provided and not on income share splits, as explained below in the Algorithm section.

Unsafe State

The system may become unsafe. In this case, vaulted capital is higher than bonded capital. Vaulted Rune is now equal to the Effectivity Security Bond – a 50/50 split.

This is undesirable because it means that it's become profitable for node operators to work together to steal assets.

To fix this, the system increases the amount of rewards going to node operators and lowers the rewards going to liquidity providers. This leads to more node operators getting involved, bonding more Rune and increasing bonded capital. This also disincentivises liquidity providers from taking part. They receive less return on their investment, so they pull assets out and reduce the amount of pooled capital. With time, this restores balance and the system moves back towards the optimal state.

Inefficient State

The system can also become inefficient. In this case, vaulted capital would be much lower in value than bonded capital. This is a problem because it means that much more capital is being put into securing pooled assets than those assets are actually worth.

To fix this, the system increases rewards for liquidity providers and decreases rewards for node operators. This attracts more liquidity providers to the system, and fewer node operators. Liquidity providers add more capital to receive more rewards, increasing pooled capital. Some node operators remove their bonded Rune, seeking more profitable places to put their capital. Bonded capital falls. In this way, the system returns to the optimal state.

Under and Over-Bonded States

The under- and over-bonded states are less severe intermediary states. Being under-bonded is not a threat in itself because it is not yet profitable for node operators to steal. Being over-bonded is not a problem in itself because the system is still operating quite well.

The THORChain team does not expect the unsafe or inefficient states to come up often. The system will be in the over-bonded state most of the time, particularly as it gets easier for people to run nodes.

Algorithm

The algorithm that controls the Incentive Pendulum is as follows:

1. Check Security Bond: No payments to liquidity providers when the effectiveSecurityBond is less than or equal to the vaultLiquidity:

1. Determine the Initial Share of rewards for node operators based on the vaultLiquidity and effectiveSecurityBond:

1. Calculate Base Pool Share after allocating the baseNodeShare to node operators:

1. Adjust Node and Pool Shares:

• Adjust the Node Share if totalEffectiveBond exceeds the effectiveSecurityBond so Nodes are rewarded up to the Bond Hard Cap:

• Adjust Pool Share based on the ratio of pooledRUNE to vaultLiquidity as non-pooled liquidity is not yield-bearing:

1. Aggregate the adjusted shares for both node operators and liquidity providers:

1. Calculate the final amount of rewards allocated to liquidity providers and node operators, ensuring it does not exceed the totalRewards:

Liquidity Providers are paid the finalPoolShare and node operators are paid the remainder. However, the income received is based on the liquidity they provided.

1. Yield Adjustment based on Liquidity Provided

Ensure the yield (rewards per unit of liquidity) for liquidity providers and node operators is balanced, taking into account the total effective bond and the vault liquidity:

• Yield for Node Operators:

• Yield for Liquidity Providers:

This ensures that the rewards are balanced according to the liquidity provided, maintaining the desired incentives for both liquidity providers and node operators.

Stable Example

Values are:

Steps

1. Check Security Bond:

   Since effectiveSecurityBond (66,000,000 RUNE) is greater than vaultLiquidity (33,000,000 RUNE), we proceed with the calculations.

2. Determine the Initial Share:

   Base node share calculation:

1. Calculate Base Pool Share:

1. Adjust Node and Pool Shares:

   • Adjusted node share calculation:

• Adjusted pool share calculation:

1. Aggregate the Adjusted Shares:

1. Calculate the Final Amount:

   Since adjustmentRewards (1,083.33 RUNE) exceeds totalRewards (1,000 RUNE), we cap the rewards:

   • Final pool share:

• Final node share:

1. Yield Adjustment:

   • Yield for node operators:

• Yield for liquidity providers:

Summary

• Final rewards for liquidity providers: 307.69 RUNE

• Final rewards for node operators: 692.31 RUNE

• Node yield: 6.993x10^-6 RUNE per RUNE

• Pool yield: 6.993x10^-6 RUNE per RUNE

In this stable state, node yield matches pool yield meaning the system is in equilibrium based on the liquidy provided. This ensures that the rewards are balanced according to the liquidity provided, maintaining the desired incentives for both liquidity providers and node operators.

Driving Capital Allocation

As a by-product of the Incentive Pendulum's aggressive re-targeting of the 50:50 yield split between node:pool yield, the system aims to maintain an equilibrium where the value of BONDED RUNE is proportionally aligned with the value of Vaulted RUNE. This ensures that:

1. For every unit of POOLED RUNE, there is approximately around 3 times that amount in effectiveSecurityBond, creating a balance that maintains network security and efficiency.

2. As POOLED RUNE is paired 1:1 with pooled assets (due to liquidity pools), the total market value of RUNE is targeted to be three times the value of the pooled assets.

3. There is sufficient bond to secure the non-pooled assets.

If there is any disruption to this balance, the Incentive Pendulum will reallocate rewards to correct the imbalance by incentivising node operators to bond more RUNE or liquidity providers to pool more assets. With the use of RUNEPool and Pooled THORnodes users can play both sides of the Incentive Pendulum in order to maximise their return and help return the network back into equilibrium.

THORChain has several layers of security within the code base to ensure solvency of the network, stability of the protocol and minimise the impact of any exploit. These measures are in addition to human security efforts, see more information here.

Confirmation Counting

To protect against double-spend attacks and re-orgs (non-instant finality chains), THORChain users Confirmation Counting for specific chains when receiving incoming value. Bifrostinforms THORChain when to process the incoming value. How many confirmations are required is dependent on the size of the incoming value.

See more full details here.

Note, THORChain and Binance Beacon Chain have near-instant finality so confirmation counting is not required.

Outbound Transaction Throttling

To prevent large amounts of funds from leaving the network in an instant, large outbound transactions are throttled from immediately leaving the network. Each block has an outbound value limit (currently 1000 RUNE worth) and each outbound transaction has a maximum time limit that it can be processed. This has three effects:

• Each outbound transaction to compete for the next outbound block, else, it will be processed in the following block, effectively throttling the total outbound capacity of the network. This is independent of conf-counting.

• Large outbounds to spread across multiple blocks, up to 720 blocks (approx one hour).

• Ensures one large outbound request of $1,000,000 is handled the same as one million $1 outbound requests.

This feature is controlled by several Mimir values that can be changed by Node Operators as required. Relevant PR.

This serves as a defensive layer buying time and allowing a vigilant node operator to pause trading or automatically halt checks to engage before the large malicious outbound transaction is irreversibly executed and funds are lost. While the feature negatively impacts the user experience of THORChain, but it is necessary in ensuring the protection of liquidity provider funds.

The feature is designed to grow as the network grows and is controlled by several Mimir values that can be changed by Node Operators as required. Additionally, the feature is designed to promote bug disclosure instead of directly attacking the network as a bug disclosure is likely more profitable.

The THORSwap team has created a dashboard to view delayed outbound transfers which is available here.

Granular Halting Controls via Node Mimir

THORChain has different levels of halt controls within the network which are controlled by Mimir values or by nodes, depending on the type and level.

The halts that can affect an individual chain are:

1. Halt Signing- outbounds que

2. Halt LP - add/remove stopped, swapping allowed.

3. Halt Trading - no trading allows

4. Halt Chain - nodes stop observing that chain

There are also network level halts for trading, synths and lending. To get more information see here.

Automatic Solvency Checker

The solvency checker of the network’s primary vault was introduced to catch issues early or prevent them before they happened. Detected issues can trigger an automatic trading halt on a specific chain. There are two types of automatic solvency checks:

• Reactive: The network continually compares the assets the network believes it has in its primary vault (Asgard Vault) to what assets are actually stored in the network’s chain wallets. For every connected chain, each node compares the stored Asgard vault value to each chain Asgard Wallet amount. If the Asgard Vault value is more than the wallet value by 1%, the node reports insolvency for that chain. Relevant PR.

• Proactive: This mode is more powerful and is intended to catch insolvencies even before they appear. When a node attempts to sign a txOut, it will do a calculation to check if by executing the txOut the vault becomes insolvent. If so, then it refuses to sign and reports insolvency. Relevant PR.

Automatic Trading Halting

If more than 66% of nodes, report an insolvency with a chain (reactive or proactive), trading for all assets on that chain is automatically halted (Halt{Chain}Trading). The halt will also emit a security event to ThorSec.

Why 1% difference allowance?

THORChain builds an awareness of balances purely by adding the incoming funds, then subtracting the outgoings. Thus the expected balance is the aggregate of the ins and outs. Divergences can occur when actual on-chain balances start to diverge. For gas assets (assets used to pay gas), small divergences can be intermittent, but normally less than +/- 1%.

Node Operator Triggered Halts

Node Operators have the ability to halt trading within THORChain if they detect malicious activity. This is in addition to automatic chain-specific halting functionality. The ability has been made with the potential for abuse in mind.

A single node can pause trading (HaltTrading) for up to an hour (720 blocks). Any additional node that calls for a halt will add 720 blocks to the halt timer. Any node that calls for the resumption of trading removes 720 blocks from the timer. The halt functions can only be called once by each active node per churn cycle (3 days). This gives the network the ability to respond to a malicious threat without giving any node unilateral control. Relevant PR.

Unauthorized Transaction Detection

This blanket protection will automatically pause THORChain on a specific chain (Halt{Chain}Trading) and stop Yggdrasill vault funding if an unauthorised transaction is detected. This will emit a security event and be sent to THORSec. The halt will allow Node Operators, THORSec, and the development team to investigate and react immediately following an unauthorised transaction and issue a fix and restore service as quickly as possible. Relevant PR.

Automatic Security Flagging

Security events have been added within the code which automatically emits events when certain conditions are met such as node slashing for unauthorized transactions, attempted double-spending, or very large withdraws. Emitted events are sent to a THORSec Discord monitoring channel for immediate review. These emitted on-chain events can also be seen on Midgard. Relevant PR.

The Inter-Blockchain Communication Protocol (IBC) is a protocol that allows blockchains to talk to each other. Chains that speak IBC can share any type of data as long as it's encoded in bytes, enabling the industry’s most feature-rich cross-chain interactions. IBC is secure and permissionless.

To get an overview of the adoption that IBC has seen, checkout MapofZones to get a graphical representation of the different chains that has IBC enalbed and how many IBC transactions that flow between these chains:

You can find more information about IBC in their official docs.

Overview

THORChain is a leaderless vault manager:

1. 1-way State Pegs allow syncing state from external chains

2. A State Machine to coordinate asset exchange logic and delegate outgoing transactions

3. Bifröst Chain Client to process chain-specific transactions

4. A TSS protocol to enable distributed threshold key-signing

The Bifröst Protocol: 1-way State Pegs

Each node has a "Bifröst" service that deals with the nuances of connecting to each chain. Once nodes are synced, they watch vault addresses. If they ever see an inbound transaction, they read it and convert it into a THORChain witness transaction.

The witness transaction has the following parameters that are essentially the same for each chain, no matter the type:

type Tx struct {
	ID          TxID    `json:"id"`
	Chain       Chain   `json:"chain"`
	FromAddress Address `json:"from_address"`
	ToAddress   Address `json:"to_address"`
	Coins       Coins   `json:"coins"`
	Gas         Gas     `json:"gas"`
	Memo        string  `json:"memo"`
}

THORChain processes each observed transaction and waits for consensus. Once a super-majority of nodes agree on a particular transaction, it moves from a pending state to a finalised state.

type ObservedTx struct {
	Tx             common.Tx        `json:"tx"`
	Status         status           `json:"status"`
	OutHashes      common.TxIDs     `json:"out_hashes"`
	BlockHeight    int64            `json:"block_height"`
	Signers        []sdk.AccAddress `json:"signers"`
	ObservedPubKey common.PubKey    `json:"observed_pub_key"`
}

Each chain client is quite light-weight, containing only as much logic as is necessary to connect to that particular chain. Most of the logic is in the observer itself.

THORChain State Machine (TSS)

The state machine processes the finalised transaction and performs logic, such as ordering transactions, computing state changes, and delegating them to a particular outbound vault. Finally, a txOut item is created and stored in the Key-Value store.

The txOut looks like the following:

type TxOutItem struct {
	Chain       common.Chain   `json:"chain"`
	ToAddress   common.Address `json:"to"`
	VaultPubKey common.PubKey  `json:"vault_pubkey"`
	Coin        common.Coin    `json:"coin"`
	Memo        string         `json:"memo"`
	MaxGas      common.Gas     `json:"max_gas"`
	InHash      common.TxID    `json:"in_hash"`
	OutHash     common.TxID    `json:"out_hash"`
}

The Transaction Out item details which chain it should be sent on, the destination address, the vault it should be sent from, and the maximum gas that should be spent. It also has fields for the transaction that initiated it (the InHash) and the transaction that will complete the accounting (the OutHash).

Signer (Bifröst)

Once the finalised transaction is created, the Signer loads it from their local copy and serialises it into a correct transaction for the destination chain using the respective chain client. This is then sent to the TSS module which coordinates key-signing. The final signed transaction is then broadcast to the respective chain.

THORChain Vaults

There are two types of vaults in THORChain's system - "inbound vaults" and "outbound vaults":

1. Asgard TSS Vaults - inbound vaults with large committees (27-of-40)

2. Yggdrasil Vaults - outbound vaults with 1of1 single-signer

This allows the system to use the security of the large vaults to hold the bulk of assets, but delegate to the small, fast outbound vaults the outgoing assets. Every THORNode runs an outbound vault.

Sharded Asgard Vaults

In order to further increase the node count to beyond 40 nodes, the system shards Asgard vaults into two when it approaches the MaxNodesForAsgard constant (and merges them if two ever drop below half of this). As such, with 100 nodes, there would be 3 Asgard vaults, with 100 yggdrasil vaults. The system constantly checks which vault has the highest excess security, and instructs users to send funds there.

Managing Yggdrasil Funding

The state machine constantly monitors and tops up each yggdrasil outbound vault, limited to 25% of the value of its bond in assets. Thus if a node bonded $4m, then up to $1m in assets would arrive on its vault. These top up transactions are identified with yggdrasil+ memos.

When the node churns out, it automatically returns these assets back to Asgard with a yggdrasil- memo.

Not all assets are funded to yggrdrasil vaults since it would split the funding up far too much. Instead, all pools with a depth less than minimumDepthForYggdrasil keep their funds on Asgard vaults.

Migrating

When the network churns, it creates new public keys and migrates the funds forward. The churning process is split up in 5 different transactions, 1 per asset (identified by migrate memo). It typically takes a few hours to complete. Users are instructed to only send funds to the newest vault, but the retiring vault is monitored. Once the last of the 5 migrations is complete, the previous vault is discarded and no longer monitored.

THORChain Website and Socials

All the following are community-run resources. There are no "official" channels.

Community Projects

Below is a list of active THORChain community projects. If you would like to be funded to build something in the THORChain ecosystem please build something then reach out.

Exchanges Only

Integrated Wallets and Exchanges

(Non-Exchanges) Wallets that Supports RUNE

Keystore Json/txt File - Password Encrypted File Supported by Many THORChain Exchanges

Education

Analytics

Infrastructure

Community Dev Projects

Community Socials

Regional Socials

• Flexibility

• Performance

• Security

• Sovereignty

Flexibility

THORChain offers developers maximum flexibility:

• Programming Language Choice: Developers can use the programming language they prefer for building the state-machine, thanks to the ABCI (Application Blockchain Interface).

• Framework Selection: Various frameworks are available, such as the Cosmos SDK (in Golang) or Lotion (in JavaScript), allowing developers to choose based on their preferred language.

• Customizable Consensus Engines: Developers can swap or tweak the consensus engine to better suit their needs. Currently, CometBFT is production-ready, but more options will emerge in the future.

• Tradeoff Exploration: Developers can adjust parameters like the number of validators vs. transaction throughput, or choose different storage models like DB or IAVL tree.

• Automated Logic Execution: The Cosmos SDK enables automatic execution of code at the beginning and end of each block, providing further customization.

• Cryptographic Flexibility: Developers are free to choose their cryptographic libraries, avoiding constraints imposed by underlying environments in virtual-machine blockchains.

This flexibility allows developers to create optimized, tailored solutions for THORChain, enhancing overall performance and adaptability.

Performance

THORChain, being an application-specific blockchain, provides several performance advantages:

• Efficient Consensus: Using a consensus engine like CometBFT BFT offers higher throughput compared to Proof-of-Work blockchains.

• Focused Resources: THORChain operates a single application, eliminating competition for computation and storage resources seen in non-sharded virtual-machine blockchains.

• Reduced Complexity: Avoiding the need for a virtual-machine to interpret transactions significantly lowers computational complexity and boosts performance.

Security

Application-specific blockchains like THORChain enhance security in several ways:

• Proven Languages: Developers can use established programming languages like Go, which are more mature than many smart contract languages.

• Custom Cryptography: Developers can implement well-audited crypto libraries, rather than relying on the limited functions available in virtual-machines.

• Simplified Security: By eliminating the complexities of a virtual-machine, developers can more easily ensure the security of their application.

Sovereignty

One of the major benefits of THORChain as an application-specific blockchain is sovereignty:

• Full Control: Stakeholders have complete control over the chain, ensuring that governance and application requirements are aligned.

• Responsive Upgrades: If bugs are found or new features are needed, the community can quickly act without waiting for the broader blockchain’s consensus.

• Community Alignment: The community governing THORChain is directly aligned with the application’s stakeholders, providing a streamlined and responsive governance process.

CosmWasm is a smart contracting platform built for blockchains that uses the Cosmos SDK, Simply put, it's the Cosmos (Cosm) way of using WebAssembly (Wasm) hence the name.

CosmWasm Contracts on THORCHain

There would be a module placed into TC called x/wasm and self-executing .rs contracts are placed in it. These "contracts" would be whitelisted in via developers because they would go in via the 2-weekly upgrade cycle. They would be rolled out on stagenet for testing first, then flagged on mainnet after sometime.

Tokens

Derived assets TOR and L1 RUNE will work easily. Notably, trade assets are missing because they are not assets, they are deposit slips.

There are multiple modules and protocols that makes up THORChain. The tech stack can be broken down in the following key pieces:

• • 1-Way State Pegs: Syncs state from external chains to THORChain using the Bifröst Protocol.

  • THORChain State Machine (TSS) protocol: Coordinates asset exchange logic, delegates transactions and enables distributed threshold key-signing.

  • Bifröst Chain Client: Processes chain-specific transactions.

Midgard is a layer 2 REST API that provides front-end consumers with semi real-time rolled up data and analytics of the THORChain network. Most requests to the network will come through Midgard. This daemon is here to keep the chain itself from fielding large quantities of requests. You can think of it as a “read-only slave” to the chain. This keeps the resources of the network focused on processing transactions.

Multiple asset representations

With many Cosmos chains running on various bridged assets, Cosmos teams often end up with multiple representations of the same asset, e.g. Axelar bridged BTC, Nomic bridged BTC, and wBTC bridged from multiple different layer 2s. This splits liquidity and causes significant user confusion.

THORChain will only have one bridged asset for per asset. E.g. ETH.ETH on L1 will be represented as a bridged asset with ETH-ETH.

Buggy RPC/gRPC node software

With multiple node providers validating blocks around the world, the risk of node crashes that disrupts work flow, testing and live implementations can happen. Some teams resort to spending significant amount of time adding fairly complex fallback and retry logic in our backend Cosmos library to deal with the situation, but it still occasionally causes alerts to go crazy.

Derivation path/wallet address incompatibility

Most chains in the Cosmos ecosystem use the same public key hash method and derivation path, making their addresses convertible (works for Osmosis, Neutron, Juno, and Sei v1). Other chains attempt to keep Ethereum compatibility (Injective and Sei v2). The result is that addresses cannot be converted between these chains, which makes things like cross-chain incentivization difficult.

THORChain will have have addresses compatible with at least one other Cosmos chain as the "canonical chain". There is all work being done to try and link different wallet addresses together so that matching accounts can be found across many chains.

CosmWasm contract size limit

Many CosmWasm contracts quickly move beyond the default 800kb limit for a contract. The CosmWasm team has previously discussed bumping this limit.

THORChain will push on bumping up the contract limit to 1.5mb or more.

Differing transaction size limits across nodes

Having different settings between nodes for transaction size limits causes P2P sharing of mempool entries to sometimes get stuck. This can cause a node to be “starved” and none of the transactions broadcast to it to be picked up by the network. Levana’s workaround for this is quite involved:

• They run a backend server, the querier, which provides a transaction broadcast endpoint

• Their backend library has added support for an “all nodes broadcast,” where any broadcasts are sent to both the primary node and any fallbacks we’ve configured

• Their frontends do not rely on the standard RPC interface leveraged by cosmjs, but instead have custom code to talk to the querier

Congestion attacks/lack of MEV

Some Cosmos chains have had periods of high traffic, either due to roll-up syncs, large NFT mints, or direct attacks on the chain. Most Cosmos chains have no concept of MEV or fee markets. Osmosis has implemented a basic fee market system, but it was at least initially buggy, and only gate-keeps entrance to the memory pool. It does not prioritize transactions within the pool.

Poor wallet compatibility/frontend library support

The Cosmos ecosystem generally uses CosmosKit for wallet integration. It’s a workable library, but has historically suffered from integration bugs, and the documentation has been poor. Furthermore, slight differences in behavior of different wallets has made broad wallet support difficult to achieve.

THORChain is actively working with wallets like XDEFI/Ctrl, Keplr and Leap to alleviate compatibility issues, yet its an iterative process where there will be back and forth.

Mishandling of multiple gas coins

Many Cosmos chains allow for multiple coins to pay for network/gas fees rather than just one. Having this option is suboptimal. As a recent example from Levana on Osmosis:

• Governance contract lives on Osmosis

• Governance token, LVN, is a native coin on Osmosis, and it can be used for gas fees

• An option in the Levana governance UI allows users to stake the entirety of their LVN holdings

• Keplr has on occasion selected LVN as the gas token to be used in such transactions, even when a user has another gas coin available

• All simulations and checks within the Levana dapp will indicate that this transaction will succeed, since selection of gas coin occurs after our app initiates the signing process

• Keplr provides no useful warning about the fact that more LVN will be used than are available in the wallet

General FAQs

Who founded THORChain?

It was founded in 2018 by a pseudo-anonymous core team of contributors, of which Chad Barraford is a member. Today Nine Realms has publicly taken over THORChain operations which is led by Gavin McDermott.

How many developers are there?

There are approx 8 core devs and 9 devs from Nine Realms working on the protocol. There are approx 40 devs + community members working within the ecosystem.

What are the Vesting and Allocation Details?

All tokens have fully vested since August 2023.

What is the Roadmap?

Where can I buy Rune?

Directly on THORChain by swapping any supported asset for RUNE or exchanges like Binance list RUNE. Only RUNE is supported on THORChain.

What is the circulating supply of RUNE?

What is the inflation rate of RUNE?

How are swap fees calculated?

What Interfaces / Exchanges are there? How to access THORChain?

What is Outbound Throttling?

Are there withdrawal fees and why is there a withdrawal fee premium?

Yes, there is a fee for every on-chain withdrawal from THORChain, whether it is a swap outbound, savings withdrawal, opening a loan, redeeming a collateral, or withdrawing from LPs.

The outbound fees that THORChain levies is 1.5x t0 3x the “fast” fee recommended for the respective blockchain, depending on network load.

The outbound fees that THORChain levies could be up to 2.5x the “fast” fee recommended for the respective blockchain.

Is there a place where I can see the THORChain Ecosystem?

Technical FAQs

How fast is THORChain?

Why use BFT Tendermint?

THORChain uses Tendermint which is a classical BFT algorithm. 2/3 of the validators need to agree and the network values safety. The chain has instant finality and this is needed to secure cross-chain bridges.

What is TSS and how is it used to hold network funds?

Thorchain uses Threshold Signature Scheme (TSS) as a leaderless vault to hold funds within the network. TSS works like a multi-sig wallet but there there is no one or set of private keys that can be stolen. As a collective, all node operators work together to create a TSS vault and the super majority are required to sign a transaction for funds to leave the vault. Node operators need to bond more than 1.5x in bond the vault they can secure to ensure they do not collude to steal funds.

Does THORChain need external sources for price feeds, like oracles or weighted averages?

THORChain depends on its continuous liquidity pool design and arbitrageurs to set prices. When pools become imbalanced, arbitrage bots trade to rebalance them. THORChain knows the exchange rates between external asset pairs because RUNE binds all pools together.

Unbalanced pools represent a profit opportunity for arbitrage traders -- if a trader can purchase a token at a lower price on THORChain and sell it for a profit elsewhere, they will. These trades re-balance the pool and ensure that prices accurately reflect the market value. These pool-balancing trades happen 24/7 via arbitrage bots interacting with the protocol's API directly. It's even possible to run an arbitrage bot of your own!

Is there a liquidity cap?

Why does RUNE need to be the settlement asset in every pool?

If each pool is comprised of two assets (e.g. BTC:ETH) then there will be a scaling problem with n*(n-1)/2 possible connections. By having RUNE on one side of each pool, $RUNE becomes a settlement bridging asset allowing swaps between any two other assets. Additionally, having $RUNE in a pool ensures that the network can become aware of the value of assets it is securing.

Why use 1-way state pegs instead of atomic swaps or 2-way asset pegs?

Simply put, Cross-chain bridges are a better solution than Atomic Swaps. Atomic Swaps involve a complex process of signing cryptographic keys between two parties that require interactivity. You also need a counter-party on all trades. Cross-chain bridges, coupled with continuous liquidity pools means you don't need a designated counter-party, and swaps can happen in less than a second. 1-way state pegs are better than 2-way asset pegs because assets don't need to be wrapped or pegged. Instead of having IOU tokens, real native assets can be used instead.

How does THORChain prevent MEV?

THORChain is designed to minimize the risk of Miner Extractable Value (MEV), which is a common issue in many blockchain networks. MEV refers to the ability of validators or miners to manipulate the order of transactions within a block, such as front-running trades or causing liquidations. Here’s how THORChain is resistant to MEV:

1. Multi-Chain Architecture: Unlike Ethereum and other EVM architectures—where MEV is more prevalent due to the single-chain structure and longer block times—THORChain operates across multiple blockchains. This makes it nearly impossible to manipulate transaction ordering simultaneously across different chains.

2. Limited Node Control: Nodes in the THORChain network cannot reorder transactions—whether observed from external chains or internal. Their only power is to censor transactions, which further limits the potential for MEV. 2/3 of Nodes need to colloude to censor a transactions.

3. 1. Liquidity Fee: Transactions with higher liquidity fees are prioritized.

   2. Slip (Price Impact): Transactions with higher price impacts are given priority.

   3. Scoring and Sorting: Each transaction is scored based on its liquidity fee and slip, and then sorted to determine the final order. This reduces the chances of MEV attacks like sandwiching.

How much RUNE do you need to run a THORNode?

How are new pools added in THORChain?

Approximately every three days, the pending pool with the deepest liquidity is churned in (becomes an active pool). This is called a Pool Churn. Note: A pending pool must have a minimum 10K RUNE to be eligible for a churn.

This means there is an open decentralised liquidity competition where the community can vote with their liquidity. N.B. Caps will prevent voting with liquidity.

What is the Contract Address of RUNE?

There is no contract address for RUNE, as it is the native asset on its own blockchain.

Frequent Issues

My transaction failed, I can’t add liquidity or make swaps?

Make sure you have a sufficient amount of RUNE to process transactions. Also be sure to check if the liquidity caps are full. If so, you will not be able to add liquidity at that time. If you see errors like “No UTXOs to send” or “Need to wait for more UTXO confirmation”; likely you are trying to spend UTXO assets (BTC, LTC, BCH) that you have just transferred into your wallet. Please wait for more blockchain confirmations, and try again later!

THORYield is displaying incorrect information?

THORYield is a 3rd party app, sometimes there is a lag between sync, so yes, it may display incorrect information. In this case use THORSwap to see what liquidity you have provided.

I deposited liquidity before Ledger and TrustWallet support but I want to migrate to those wallets without removing liquidity

You can use THORChain’s keystore wallet seed phrase for xDefi, or TrustWallet. It uses the standard BIP39 mnemonic phrase, it is compatible with all multi-coin wallets and Ledger. Simply input the seed phrase and your wallet should be imported. If you are using Ledger or cold storage, it is recommended to create a new wallet.

Please be aware of the implications of inserting seed phrase previously used in hot wallets; into a cold hardware wallet.

THORChain is a liquidity protocol that is made up of multiple types of assets to provide the best experience for all types of users - from retail investors to professional traders to institutional investors.

To serve everyone, THORChain:

• Native Assets

• Derived Assets

• Synthetic Assets

• Trade Assets

Native Assets

Ex: BTC.BTC

Native Assets are L1 assets (eg BTC) available on its native L1 (eg Bitcoin Network).

Derived Assets

Ex: THOR.BTC

Derived Assets are Native Assets (eg BTC) available on another L1 (eg THORChain if THOR.BTC). This allows the Native Asset to be sent, received and swapped on another L1 than it's native L1.

Synthetic Assets

Ex: BTC/BTC

THORChain synthetics are fully collateralized while they exist and switch to a 1:1 peg upon redemption. This unique design combines the benefits of over-collateralization and pegging, ensuring capital efficiency and stability. The system aims for 100% collateralization but can handle drops below this without losing the peg, using fees to regain balance. Collateral comes from liquidity pools, with 50% in the asset and 50% in RUNE, rebalancing as prices change. Minting involves swapping RUNE or the asset into its synthetic form using pool liquidity, maintaining equal purchasing power.

Trade Assets

Ex: BTC~BTC

Trade Assets, a new class of primitives on THORChain, offer double the capital efficiency of synthetic assets, enhancing arbitrage and high-frequency trading. They settle with THORChain’s block speed and cost, enabling 6-second finality swaps without high fees. Redeemable anytime with no slippage, Trade Assets emulate centralized exchange trading but maintain on-chain transparency and security. Custodied by THORChain outside of liquidity pools, they provide user credits while holding funds 1:1 as L1 assets until withdrawal, making THORChain more user-friendly for active traders.

See https://dev.thorchain.org/concepts/asset-notation.html for more informaiton.

What is a Savers Vault?

Savers Vaults are way to supply single-asset liquidity on THORChain. Any user can simply deposit native Bitcoin, earn in-kind yield, and withdraw their principal any time since they maintain full control of their keys.

• Orginal Launch Article

Is Savers Vault yield fixed rate or variable rate?

Yield is variable and driven by swap fees, block rewards, pool depth, and the incentive pendulum. Annual percentage rates (APRs) are calculated using an extrapolation of past performance data from the last 30 days. Past performance does not guarantee or predict future results.

Are there fees to enter and exit a Savers Vault?

Yes. There are slippage fees paid on entering and exiting a Savers Vault. There is a 5 pbs for entry and exit fee for all savers position due to streaming swaps regardless of the size of the transaction.

Which assets are eligible to deposit in a Savers Vault?

All L1 Assets and Selected Stables. See full list at https://thorchain.net/thorfi/savers

Where can I access Savers Vaults?

Users can manage a THORChain Savers Vault positions through many interfaces. See Exchanges for a complete list.

Where can I track my Savers Vault yield?

Users can track their Savers Vault positions on any supported interface including:

• RUNEScan.io

• THOR Infobot

Should I use THORChain Savers Vaults?

You should use THORChain Savings if you are planning on keeping your funds in the vault long enough for the fees accrued to offset the entry/exit costs, as well as the outbound fee(s) assessed when withdrawing.

Example: a user deposits 1 BTC in a pool 1000 BTC deep; thus pays a 0.1% slippage fee (1/1001) and is credited 0.999 BTC in the vault. If the pool is paying 3.65% APR, this is 0.1% earned every 10 days. Thus the user should plan to stay at least 20 days to pay for the entry and exit fee as a minimum. If the user does not stay long enough, they risk having the yield they earn not offsetting the fees paid to enter and exit the vault, thus causing them to experience a loss of principal.

What are the risks associated with Savers Vaults?

Savers Vaults are not risk-free. Although Savers has been designed to mitigate risk, the possibility of loss cannot be eliminated completely. It is the user’s responsibility to be aware of the risks before entering a Savers Vault.

Can my Wallet / DEX / DeFi Product / Yield Aggregator / App offer Savers Vaults to its customers?

Yes, any person, service, or dApp can create a frontend interface to offer THORChain Savers Vaults to its users. Interested parties should review the THORChain Developer Documentation and contact Nine Realms.

How do I integrate with Savers?

See the developer quick start guide here

What is RUNEPool?

RUNEPool is a feature of THORChain that allows RUNE holders to join the Protocol Owned Liquidity (POL). By participating, users get a share of the liquidity that Thorchain owns across all its pools, earning Annual Percentage Rate (APR) returns and improving the protocol's liquidity efficiency, supporting Thorchain's growth.

How does RUNEPool work?

RUNEPool matches external capital with various pools in the system. It manages multiple pools, distributing RUNE across them to smooth out price curves and reduce volatility. This makes Thorchain products more attractive to investors.

What are the key components of RUNEPool?

• PoL-Enabled Pools: Defined via the mimir key POL-{Asset}, enabling all eight native assets and five USD stable coins.

• RUNEPool Units (RPU): Represent a pooler’s share in the pool. When redeemed, the holder's share of the total POL size in RUNE is distributed.

• Impermanent Loss Management (IL): Users experience aggregate IL across PoL-Enabled pools, reducing risk compared to any single pool.

What are the benefits to RUNE holders?

RUNEPool simplifies user experience by focusing on the Incentive Pendulum and fees generated from the pools, allocating funds based on yield. This abstracts away complexities and enhances decision-making for users.

What is the use case for RUNEPool?

RUNEPool gathers idle RUNE from centralized exchanges and custodial services, moving them into Thorchain's decentralized infrastructure to generate yield. This enhances asset productivity and builds up POL through community participation.

How can I track RUNEPool performance?

Multiple dashboards are available to track RUNEPool performance:

• thorchain.network/runepool

• thorchain.net/thorfi/runepool

• runescan.io/txs?type=runepool

How to add to RUNEPool?

1. Create a Transaction: Use a MsgDeposit transaction with the memo pool+.

2. RUNE Only: RUNEPool only works with RUNE.

3. Instructions: Refer to the "Deposit to the RUNEPool" section in the documentation for detailed steps.

How to withdraw from RUNEPool?

1. Create a Transaction: Use a MsgDeposit transaction with the memo pool-:<basis-points>:<affiliate>:<affiliate-basis-points>.

2. Minimum Term: You can only withdraw after the minimum term defined by RUNEPoolDepositMaturityBlocks.

3. Instructions: Refer to the "Withdraw from the RUNEPool" section in the documentation for detailed steps.

How to view RUNEPool holders?

1. All Holders: Use the rune_providers endpoint to see a list of all RUNEPool holders.

2. Specific Holder: Use the rune_providers/{thor owner address} endpoint to view the position of a specific RUNEPool holder.

How does RUNEPool manage Impermanent Loss (IL)?

• Aggregate IL: Users experience aggregate IL across all PoL-enabled pools, reducing individual pool risks.

• Idle RUNE: Undeployed RUNE reduces yield but also limits exposure to impermanent loss.

How can I see the Profit and Loss (PnL) of RUNEPool?

The PnL can be split into Global (for all providers) and Individual:

• Global PnL: The /thorchain/runepool endpoint returns the global PnL of RUNEPool, including details for the reserve and independent providers.

• Individual Provider PnL: The /thorchain/rune_provider/{thor_addr} endpoint provides position information for a single provider.

For more detailed instructions, refer to the developer docs.

General Questions

What is Lending?

Lending allows users to deposit native collateral, and then create a debt at a collateralization ratio with 0% interest, no liquidations, and no expiration.

• More information

• Launch Article

• Explnation Video

• Health Dashboard

What is TOR?

TOR (thor.tor) is a non-transferable unit of account that debt is always denominated in within THORChain. TOR maintains its stability by anchoring to a median value of a basket of USD-pegged stablecoins (USDC, USDT, BUSD), ensuring it stays closely pegged to $1 USD. The RUNE<>TOR mechanism works through a two-way burn process: minting TOR burns an equivalent value of RUNE, and burning TOR mints the same value of RUNE. See more under TOR.

Can I partially repay my loan?

Debt can be partially repaid, but a borrower will only receive their collateral back when the debt is repaid in full.

What happens if I overpay my debt?

Overpayments are credited towards the next loan the borrower opens.

Is there a best time to open or close a loan?

Yes, it is best to open and close loans during times of low volatility. To protect the network from price manipulation, virtual pool depths for lending shrink during times of increased volatility, meaning liquidity fees can greatly increase. Managing loans during times of low price volatility on THORChain will yield the most desirable results. Patient borrowers pay the least fees.

Will I always receive my full collateral back?

You will receive your full collateral back upon repayment minus slip-based liquidity fees incurred from the loan opening and closing process. During low volatility periods, fees will be lower. During times of high volatility, fees will be higher due to the constricting virtual pool depth.

When will lending be available for more collateral options?

The lending protocol is initially supporting BTC and ETH. The functionality to support lending on all Layer 1 gas assets on THORChain is already available and simply needs to be turned on by the validators.

Which assets can I use to pay down my debt?

Debt can be repaid with any THORChain-supported asset. Assets used to repay loans will be sold for TOR to repay the debt, since debt is denominated in TOR.

Is streaming swaps used for lending?

Yes. There is a 5 bps default fee.

Why are there no liquidations?

In this design, if collateral falls below the debt value, it’s not problematic since the collateral, stored as equity (RUNE), is the liability. Liability grows only when the RUNE-ASSET price drops and the loan is repaid. Liquidating collateral poses individual loan risks, worsens user experience, and makes users monitor RUNE’s price, conflicting with design objectives. Rather than liquidations, the protocol can bear a slight rise in RUNE supply (around 15m or 3%) before activating a circuit breaker, pausing the lending feature. With the RESERVE covering remaining collateral payouts and unchanging loan terms post-circuit breaker, a rush-exit becomes less probable.

Why is there no interest?

Interest rates generate income on collateral but make users more likely to repay loans. THORChain’s design thrives when users opt for long-term loans or never repay. A 0% interest rate, being highly attractive, means users seldom repay as their principal remains intact. Users incur slip-based fees upon entering or exiting positions, which boosts yield for network participants and permanently burns RUNE.

Why is there no expiry?

The protocol wants to attract as much exogenous capital as possible (L1 assets like BTC and ETH) since it converts them to equity (RUNE IOUs). Eg, $1bn in collateral stored means $1bn in bought RUNE, minus the amount of sold RUNE to debt at the collateralization ratio, (if it’s an aggregate 300%, then around $300m has been sold), with a total net buy pressure of $700m. This $700m in stored equity is the liability, and THORChain does not want to be called on this liability, since it would have to sell RUNE. Thus there is no expiry.

How does lending help THORChain scale?

THORChain has strict rules on economic security. Value at stake by the validators must always be greater than the value of the assets in the vaults, measured in RUNE. Due to Protocol-Owned-Liquidity and Savers, the network is likely to max out pooled RUNE and send all yield to nodes. The protocol stops scaling until RUNE can be added to the bond module, but this takes time. The lending design buys and burns RUNE from the pools, directly affecting the relationship between liquidity and security. Whilst the loan was opened, it creates a net reduction in RUNE in the pools, allowing more TVL to enter. It also bids on RUNE, allowing security to increase, so the network can securely store more exogenous capital.

Who is the counterparty to the loans?

The THORChain protocol and all RUNE holders are the counterparty to each loan. The RUNE burn/mint mechanism means RUNE concentration/dilution effects (among all RUNE holders) as loans are opened and closed. Liquidity providers and Savers are not directly lending their assets to borrowers. The pools are just the conduit to swap between collateral and debt. Savers and LPs also benefit directly from liquidity fees generated from these swaps.

How do I integrate with Lending?

See the developer quick start guide here

In Depth Questions

See this Twitter Thread

What does it mean to provide liquidity?

Providing liquidity on THORChain creates an opportunity for holders of stagnant assets (e.g. BTC, ETH, BNB) to earn a return or yield on their asset. Traditionally, with a CEX or 0x style exchange, trades require an order book of bids/asks (buys/sells) at a specific price, because if an investor wants to trade one asset for another, you need a buyer and a seller. Decentralised exchanges like UniSwap and THORChain utilise liquidity pools to provide more fluid access to trades. Liquidity pools are the way decentralised exchanges maintain a reservoir of assets, enabling buyers and sellers to exchange assets on demand. Liquidity Providers are therefore those network participants who deposit their assets into liquidity pools in exchange for a share of the trading fees generated by the trading of buyers and sellers.

What assets can you swap and provide liquidity for?

• Current Chains — BTC, ETH, LTC, BCH, DOGE, Cosmos, AVAX, BSC

• Native gas/base assets on each chain

• See full list at https://runescan.io/pools or https://thorchain.net/#/pools

Can I stake RUNE?

Not quite. “Providing liquidity” in THORChain is not the same thing as staking because even if you provide only 1 asset (asymmetrically add), THORChain will automatically be separated into 2 equal parts: 50% Assets and 50% Rune. You will always have exposure to both assets.

Is there a lockup period if I provide Liquidity?

There is no minimum or maximum time or amount. Join and leave whenever you wish. There is however a required confirmation time before THORChain credits you with liquidity when adding or swapping to protect against Reorgs. Wait time is based on:

• Total Asset amount (in a specific block of a specific blockchain)

• Per block reward of the chain

• Block time Required confirmations = Total Asset Amount (in a specific block of a specific blockchain) divided by the chain's per block reward Then that is multiplied by block time to get the approx "wait time". See Confirmation-Counting.

➜ THORChain - Wait Times and Fees Explained!

Will I have Impermanent Loss Protection if I provide liquidity in THORChain?

No. IL protection has ended on THORChain.

Asymmetrical / Symmetrical FAQs

I entered asymmetrically but received less than anticipated

Yes, because when you pool asymmetrically your asset is swapped into 50% rune and 50% asset. When swapping you are subject to slippage and fees. There are 2 types charged on asymmetrical deposits/withdrawals:

1. The on-chain deposit transaction fee (inbound tx)

2. The liquidity fee as a function of slip

Upon withdrawal, there will also be a transaction fee (outbound tx)

Are there slippage fees for symmetrical deposits?

No, there is only the deposit transaction fee.

What ways can I withdraw my asymmetrical deposit?

If you deposit asymmetrically you can ONLY withdraw asymmetrically, to the same asset/address that was used for deposits.

What ways can I withdraw my symmetrical deposit?

You can withdraw your symmetrical deposit both asymmetrically (in either asset) and symmetrically.

Will all ERC20 assets be supported and listed on THORChain by default?

No. Only short tail assets with high MarketCap, good velocity and economic activity would have chances to win liquidity competition to get listed.

Adding and Removing Liquidity

Entering and Leaving a Pool

To deposit assets on THORChain, you need a compatible wallet with your assets connected to one of the many User Interfaces. Liquidity providers can add liquidity to any of the active or pending pools. There is no minimum deposit amount, however, your deposit will have to cover the deposit and later a withdrawal fee costs. The ability to manage and withdraw assets is completely non-custodial and does not require any KYC or permission process. Only the original depositor has the ability to withdraw them (based on the address used to deposit the assets). Note, every time you add liquidity, Impermanent Loss Protection time resets.

While Symmetrically additions are recommended, Asymmetrical additions are supported, below are the rules:

If you add symmetrically first;

• You will be able to add asymmetrically with RUNE later

• You will be able to add asymmetrically with ASSET later but it would create a new LP position

• You will be able to add symmetrically later

If you add asymmetrically with ASSET first;

• You will be able to add asymmetrically with RUNE later but it would create a new LP position

• You will be able to add asymmetrically with ASSET later

• You will be able to add symmetrically later but it would create a new LP position

If you add asymmetrically with RUNE first;

• You will be able to add asymmetrically with RUNE later

• You will be able to add asymmetrically with ASSET later but it would create a new LP position

• You will not be able to add symmetrically later

Withdrawing Liquidity

Liquidity providers can withdraw their assets at any time and without any cooldown period, aside from the confirmation time. The network processes their request and the liquidity provider receives their ownership percentage of the pool along with the assets they’ve earned. Fees do apply when withdrawing, see Outbound Fee.

How to track your position

You can see your position if you connect to THORChain via an Interface you can use THORYield.

➜ THORYield Guide

There are four factors affecting returns:

• Proportion of transaction volume to pool depth — If there is high volume compared to the depth of the pool then there will be higher rewards available to liquidity providers. If there is low volume compared to the depth of the pool then there will be lower rewards available.

• Share of the pool — If you have a large share of the pool, you’ll earn higher returns. If a liquidity provider has 1% of a pool they receive 1% of the rewards for that pool.

• Fee size — fees are determined by the underlying blockchain and the rewards from fees are proportional to the fees charged. A chain with higher fees will generate higher rewards for liquidity providers.

• Synth leverage — With the introduction of Synths and Savers, Liquidity Pool providers underwrite the Synths’ share of the pools. Thus Liquidity Pool providers has a leverage effect based on the RUNE:Asset price ratio changes and Synth utilization level

*Of significant note is that this mechanism of providing liquidity into the protocol; creates an opportunity for holders of non-yield generating assets (e.g. BTC, ETH) to earn a return on their investments.

Asset Notation

While ETH.tc is pictured, that may change to ETH-ETH.

How will Secured Assets Move Between Base and App Layer?

Secured assets are x/bank tokens on the App Layer (Rujira) representing claim to the native asset on base layer (THORChain).

The native asset is secured to and from the app layer with the following flow:

Mint and Burn Secured Assets

Example shows the mint and burn process for BTC

Swapping Secured Assets

Examples below explain how a user:

1. Swap a Secured Asset (SA)—BTC—to another Secured Asset—ETH

2. Swap a Secured Asset—BTC—to a base asset—ETH

1. Secured Asset Swapping, swapping the L1 under the hood

Synthetic Assets

THORChain synthetics are unique in that they are 100% collateralised when they exist but switch to being 1:1 pegged at the time of redemption. Other synthetic or wrapped asset designs are either over-collateralised or pegged, never both. This means they are either capital-inefficient (requiring over-collateralisation) or capital-sensitive (can depeg if <100% collateralisation). The advantage of THORChain's design is that the collateralisation is managed by the system on a best-effort basis to be aspirationally 100%. However, when the asset is redeemed, it switches to being pegged 1:1, which means they can tolerate going below 100% collateralisation without losing the peg. The deficit is regained by liquidity-sensitive fees on the redemption so that the last holders of the asset can achieve re-collateralisation.

The collateral for synthetic assets is constant-product liquidity, always 50% in the asset, with the other 50% in RUNE. As the price changes, the pool rebalances on the curve, having much stronger inertia than if it were 100% collateralised by the endogenous asset (RUNE). The price-shift is subsidised by the other liquidity in the pool.

Minting - 1:1 pegged

Synthetic Assets are created by swapping RUNE (or the Asset), into its synthetic counterpart, using the pool liquidity depth. This process is identical if the asset was swapped into the L1 instead. Thus when minting, the pool treats both the synthetic and its L1 as identical in purchasing power:

• r = rune deposited

• R = Rune Depth (before)

• A = Asset Depth (before)

The total Synth Supply is then updated:

Synth Units - 100% collateralisation

In the above swap - an asset was added to the pool (the RUNE or ASSET), but none taken out since the swap output is minted from nothing. Thus the pool has extra liquidity that needs to be isolated from other LPs. This is the purpose of Synth Units.

Synth Units represent the liquidity collateral value that is required to "back" the synths 100%, and stops other dual-LPs from claiming ownership of it. They are computationally derived at any point which ensures there is exactly enough at any time to represent the outstanding supply.

The ratio of Synth Units to Liquidity Units should be the same as the ratio of synth supply to the total value of the pool without the synths (since LP units are all pool units without the synth units).

• U = Synth Units (what needs to be isolated to back the synthS)

• L = Liquidity Units (dual-LPs)

• S = Synth Supply (the synths to be backed)

• A = Asset Depth (the assets in the pool)

Redeeming: 1:1 pegged

Synthetic Assets are redeemed by swapping the Synth across the pool. The synth is swapped using the same formula as though it was an L1 asset, thus the synth has the same purchasing power to the L1. It is therefore pegged.

• s = Synths to Redeem

• R = Rune Depth (before)

• A = Asset Depth (before)

The Synth Supply is thus decremented, and this in turn updates the oustanding Synth Units since it is computationally derived.

Swapping

Synth Swaps can be done as follows:

• Layer 1 to Synth: L1 in, Synth Minted

• Synth to Layer 1: Synth REDEEMED, L1 swapped out

• Synth to Synth: Synth REDEEMED, RUNE moved between pools, synth MINTED

To specify the destination asset is synth, simply provide a THOR address. If it is Layer 1, then provide a layer 1 address, e.g. a BTC address.

Economics

Fees

All swaps pay fees, and a synth Mint or Redeem to an L1 is two swaps. Thus 10.0 btc/btc swapped across a pool of 1000 BTC.BTC will receive 10 - ((10/1000)*10)*2 = 9.8 minus any outboundFees. Is the synth pegged 1:0.98? No, because the same holder could swap 10 BTC in 1.0 BTC increments and receive 10*(1 - ((1/1000)*1)*2) = 9.98 minus 10 outboundFees. Both outboundFees and liquidityFees as a function of the swap size can be controlled by the user.

Effect on Dual-LPs

The dynamic synth unit accounting is to ensure that gain or loss caused by price divergence in the synths is quickly realised to LPs. If Synths as a function of Pool Liquidity goes to 100%, then dual-LPs are diluted to 0%.

Synth Minting Cap

Due to synths, Liquidity Providers are taking a leveraged position on the RUNE asset today. This can help them earn more rewards if RUNE outperforms the asset, but can also go the other way. The higher the percentage of synths that exist on the network relative to pool depth, the higher the leveraged position Liquidity Providers are taking.

Protocol Owned Liquidity (POL)

The network can monitor the synth utilisation on a per pool basis, and add liquidity (asymmetrically addition of RUNE) if utilisation is greater than cap - 5% (if economic security allows). If synth utilisation is under this figure, then the reserve would remove liquidity (if the PoL has an LP position in this pool).

• cap = e.g. 1500 (in basis points)

• range = 500 (in basis points)

• PA = pool asset depth

• S = synth supply

By having the reserve add rune into the pool, it de-risks LPs from over RUNE leverage, as the reserve takes on some of that risk. The Reserve is long on its own (and only) asset. This, in turn, creates synth space in the pool, more synth minting and more single-sided asset deposits in the form of synths to enter.

Staged Pools

If an active pool that minted synths becomes staged, then swaps are disabled. However, synth holders can always redeem for RUNE, or the underlying asset, by specifying that on the way out.

Alternate Synth Derivation

• Provides “always-on” liquidity to all assets in its system.

• Allows users to trade assets at transparent, fair prices, without relying on centralised third-parties.

• Functions as source of trustless on-chain price feeds for internal and external use.

• Democratises arbitrage opportunities.

• Allows pools prices to converge to true market prices, since the fee asymptotes to zero.

• Collects fee revenue for liquidity providers in a fair way.

• Responds to fluctuating demands of liquidity.

Benefits of the CLP Model

Assuming a working Swap Queue, the CLP Model has the following benefits:

• The fee paid asymptotes to zero as demand subsides, so price delta between the pool price and reference market price can also go to zero.

• Traders will compete for trade opportunities and pay maximally to liquidity providers.

• The fee paid for any trade is responsive to the demand for liquidity by market-takers.

• Prices inherit an "inertia" since large fast changes cause high fee revenue

• Arbitrage opportunities are democratised as there is a diminishing return to arbitrage as the price approaches parity with reference

• Traders are forced to consider the "time domain" (how impatient they want to be) for each trade.

Slip-based Fee Model (CLP)