What is THORChain?

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's Financial Offerings

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

Created with the first principles of decentralisation, resistance to capture, and sustainability, the THORChain protocol includes several novel innovations:

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)

THORChain contributors work 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)

To learn how THORChain works, feel free to jump 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 able scale to 250+ nodes.

CONTRIBUTING

THORChain is an open-source, public project with a vibrant and growing ecosystem. Whether you’re a user, an interface developer, or an app builder on top of the network, there’s a way to get involved.

1. Join the Community

2. Build Interfaces

Interface developers are welcome to build wallets, dashboards, exchanges, and more that integrate with THORChain. You can monetize your apps through affiliate fees, earning up to 10% on swaps and liquidity actions. Focus on building great frontends and bringing in users — the protocol takes care of the rest.

3. Build Apps with Rujira

In the THORChain ecosystem, there are four key roles that network participants may play:

1. Liquidity providers: these add liquidity to pools, earning fees for their temporary deposit

2. Swappers: those users who use THORChain's liquidity to swap assets ad-hoc, paying fees for the service

3. Arbitrageurs: expert traders who continually monitor and rebalance pools; still paying fees but with the intent to earn a profit

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

A single user may take on multiple roles simultaneously.

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

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.

How Swapping Works

There are two modes possible for THORChain's swap mechanism: A single swap, and a double swap.

Single Swap

A single swap occurs when a user swaps some native asset for an equivalent value of RUNE, or vice versa.

Example: RUNE<>BTC swap.

1. User RUNE —> sent into THORChain. Inbound gas paid in RUNE

2. BTC —> sent out from one of THORChain’s vaults to user wallet. Outbound gas is paid in BTC.

Double Swap

A double swap occurs when a user swaps some native asset for some other native asset (that is not RUNE). While the user only sees one transaction, there is actually an additional one that occurs internally within THORChain.

Example: BTC<>ETH swap

1. User BTC —>THORChain. Inbound gas paid in BTC

2. Once the BTC is received, RUNE in BTC pool —> sent to ETH Pool

3. ETH —> sent out from one of THORChain’s vaults to user wallet. Outbound Fee is paid in ETH

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

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

Liquidity providers contribute native, network-supported assets to the THORChain liquidity pools. They may deposit any number of assets they choose of any value, doing so for their chosen amount of time; in short, there are no restrictions to LPing other than the need to pay deposit and withdrawal fees. “As stated, these LPs are compensated for their temporary contributions with swap fees, which are dynamically affected by several factors.

How to LP

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.

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

Process

The process of providing liquidity to THORChain pools is permissionless, non-custodial, and quite simple. First, a user—anyone at all—would deposit their asset(s) to the pool. They would remain in that pool for some amount of time, entirely of their choosing. When they wish to withdraw their pool share, they simply reverse the first step.

Liquidity can be added to existing pools at any time, increasing its depth and attracting swappers with low fees, for the deeper the liquidity, the more affordable the cost of the swap. With that said, deep pools generally have higher swap volume; this in turn generates more fee revenue for LPs.

Depositing Assets

Liquidity providers have two modes by which they can deposit assets: symmetrically or asymmetrically.

Generally, LPs are encouraged to deposit symmetrically. However, if the pool is already imbalanced, they should deposit asymmetrically; this helps the pool return to balance, which in turn improves the network as a whole, as well as making the pool more attractive to swappers.

Withdrawing Assets

Security

Yield

Liquidity providers deposit their assets into liquidity pools and in return earn dynamic yield. Their earnings arrive both in RUNE and the deposited pool's respective asset—e.g., BTC/RUNE LP receives fees in BTC & RUNE.

Calculation & Distribution

When liquidity providers (LPs) deposit their assets into liquidity pools, they earn rewards over time. These rewards come in two tokens: RUNE and the asset paired in the pool (e.g. BTC in the BTC/RUNE pool).

• Rewards are calculated every block.

• Rewards are paid out when you withdraw your liquidity.

How rewards are calculated depends on whether there are any swaps (trades) in that block.

If There Are Swaps in the Block

When a block includes swap transactions, the rewards are based on fees collected from those swaps. Pools that earn more fees get a larger share of the rewards.

Example: 1000 RUNE in rewards split based on swap fees:

If There Are No Swaps in the Block

If a block has no swaps, the rewards are based on the size of the pools. Larger pools receive a bigger portion of the rewards.

Example: 1000 RUNE in rewards split based on pool depth:

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.

Yield Comes from Fees & Rewards

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

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

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.

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

Yield Strategies

Passive liquidity providers should seek 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.

How it Works

Depositing Assets

Depositing assets on THORChain is permissionless and non-custodial.

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

How Yield is Calculated

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.

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.

What is RUNE?

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)

Governance

RUNE as a Settlement Asset

RUNE is the settlement asset for all liquidity pools, meaning that when a user pools their liquidity, a 1:1 ratio of RUNE:ASSET is required. This means the value of each native asset pool holds within it an equal value of RUNE. For example, a pool with $100,000 in BTC will necessarily hold $100,000 worth of RUNE. The reasoning for this is explained here.

RUNE for Network Security

RUNE for Governance

By symmetrically adding liquidity to a staged pool, users vote for the pools they want to become active. The deepest pools (i.e. with the most liquidity) become active.

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

THORNodes Overview

THORNodes support the THORChain network. While the initial design target is 100 nodes, the network can scale to over 250+. The design goal of THORChain is such that anyone can join the network with the required funds (permissionless) and be anonymous, yet still be secure. THORChain takes this a step further by having a high churn schedule, kicking out nodes continuously. This high-churn network ensures that it is censorship-resistant, evades capture and resists centralisation.

Each THORNode is comprised of several independent servers in a cluster, which run full-nodes for each connected chain. 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.

Automated Market Makers (AMMs) & Liquidity Pools

Automated market makers (AMMs) are decentralised exchanges (DEXs) that rely on users to voluntarily deposit network-supported assets into what are called liquidity pools—this is called liquidity pooling. Each supported asset has its own dedicated liquidity pool; these algorithmically price its respective asset, also providing the liquidity for the exchange's transactions.

By depositing their capital into the asset-specific pools, these Liquidity Providers (LPs) become owners of a proportional share of that pool for as long as their assets remain deposited. In exchange for contributing liquidity to the network, LPs earn rewards, which are distributed regularly. These rewards come directly from swap fees paid by swappers.

While each AMM carries distinct design mechanics with regard to its liquidity pool functionality, all generally aim to offer their users deep liquidity, low transaction fees, and 100% uptime for as many users as possible. THORChain is no different in this regard.

THORChain: A Novel AMM Protocol

Unlike other AMMs, THORChain is unique in that it offers swappers the ability to seamlessly swap native assets on their native blockchains. It offers this in perhaps the most decentralized, trustless, permissionless way available. It is precisely for these reasons (and more) that THORChain is the functional backend for many user interfaces.

Key features of THORChain are:

• Native Asset Swaps: Swap Layer 1 assets across multiple chains—e.g., native BTC to ETH swap

• Permissionless: No user registration is required; send a transaction & THORChain will execute it

• Decentralized Pricing: Gives transparent, fair prices without reliance on centralised third-parties

• Supports App Layer development via Cosmwasm Smart Contracts

Using THORChain's Services

THORChain offers two decentralized and permissionless services:

Interacting with the RUNE token

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

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.

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.

High Level Overview

Getting Started

Technical Info

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

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) were 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 Reserve to pay out to Nodes and LPs for the next 10+ years.

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

Reserve Outflows and Inflows

Reserve Inflows

1. Native Transaction Fee: The Native THORChain transaction fee (0.02 RUNE) applies to transactions made on the THORChain blockchain for assets such as RUNE, Synthetic Assets, and Secure Assets. This fee represents the cost for processing transactions on the THORChain blockchain and is charged independently of any outbound transactions. Unlike outbound fees, which are applied to external-chain transactions, the Native Transaction Fee only applies to transactions made on the THORChain blockchain itself.

2. Outbound Fees: Fees collected from all outbound transactions to users, which vary depending on the asset type:

• Native Outbound Transaction Fee: A fixed 0.02 RUNE is charged on RUNE and other native asset outbound transactions. This is the THORChain network native transaction fee covering the costs for processing the native outbound transaction on the THORChain blockchain and not an additional outbound fee.

1. Withdrawal of Reserve POL: Occurs when a RUNEPool addition replaces Reserve-backed POL or when a POL requirement is reduced.

2. Slashing Income: Derived from node bond slashes, particularly for failures during keygen or other operational breaches.

Reserve Outflows

1. Gas Reimbursement:

• Churn Gas Reimbursements: Covers migration gas costs during vault churns. These costs are reimbursed by the Reserve and factored into the ongoing adjustments of outbound fees to maintain a balance.

• Non-Churn Gas Reimbursements: Reimburses gas costs for external-chain transactions (e.g., user-initiated outbound transactions). Over time, the total outbound fees collected for a given coin (including adjustments for surplus) are designed to equal the total gas reimbursements for that coin, which include both user-initiated transactions and churn migration costs. This reimbursement mechanism ensures that inflows from outbound fees balance the Reserve's gas reimbursement outflows on average, maintaining sustainability without accumulating an ongoing surplus.

1. Reserve Adding to POL: Occurs when there isn’t enough undeployed RUNE in RUNEPool to cover a withdrawal, requiring the Reserve to add RUNE to meet POL requirements. If sufficient undeployed RUNE is available in RUNEPool, no Reserve contribution is needed.

2. Block Rewards: Paid out to incentivise node operators and liquidity providers.

Additional Points

• The Reserve balance is minimally impacted by gas reimbursements and outbound fees as these inflows and outflows are generally balanced over time.

• POL funding prioritises RUNEPool, with the Reserve only stepping in as a fallback when RUNEPool cannot meet the need.

• System income (e.g., fees from swaps) is immediately distributed to developers, burns, pools, and nodes, rather than being retained by the Reserve.

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:

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

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

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.

Confirmation Counting

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:

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

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

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:

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.

Unauthorized Transaction Detection

Automatic Security Flagging

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.

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

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.

More Information

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

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.

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

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.

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.

This FAQ is designed to help node operators coming to THORChain to set up and manage their nodes effectively on THORChain. Below you’ll find answers to common questions, key tips, and important warnings to ensure smooth operation.

What should I know before setting up and bonding to a node?

Make sure you do not bond with the validator’s wallet. Unlike other "normal Cosmos chains", the first person to bond to the node owns the node. Ensure that you’re using the correct wallet, as ownership cannot be transferred after the bond.

How does THORChain handle external updates?

THORChain handles external updates differently compared to Cosmos. When a Cosmos upgrade (e.g., using Gaia CLI or Ignite) occurs, you need to follow the specific THORChain process for node updates. Always refer to the latest node upgrade instructions in the documentation to ensure compatibility.

What are common mistakes, and how can I avoid them?

Common mistakes include not syncing to the top, going offline unexpectedly which can lead to being slashed for not observing. Regular monitoring, keeping your node updated, and ensuring that it remains synced with the network can help you avoid these issues.

How is node income calculated and what are the risks and costs?

What is Churning, and how does it affect my node?

What should I know about Bond Providers?

How does early exit work for Bond Providers?

Nodes can manually signal to exit the active validator set during the next churn by sending a MsgDeposit with a LEAVE memo. During each churn, the lowest bond, worst performer, and the oldest churned-in node get automatically churned out, along with any nodes that request to leave.

Most nodes impose a penalty for bond providers requesting early exit, which results in missed rewards. However, some nodes offer this service without charge. When a node is churned out, it no longer earns rewards, which means bond providers and node operators both miss out on potential earnings. Additionally, a bond provider cannot unbond while the node is active but can add more bond if desired.

Rewards for bond providers are auto-compounded back into their bond with each churn. These rewards remain locked until the node is churned out, at which point the bond providers can unbond and access their funds. Meanwhile, node operators receive their operator fee directly to their wallet each churn. For more details, you can refer to the following resources:

Why are there so many slashes, and is it normal?

Slashes can happen for various reasons, including node downtime or failing to observe or sign transactions correctly. While some slashing is normal, consistent slashing could indicate a problem with your setup. Monitoring slash points and correcting any issues immediately is essential.

Why is Geth being used instead of Argon, given its size?

What are the steps to Unbond or Leave a Node?

How do I safely destroy my node after leaving?

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.

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

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

Ex: BTC.BTC

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

Derived Assets

Ex: THOR.BTC

Synthetic Assets

Ex: BTC/BTC

Trade Assets

Ex: BTC~BTC

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.

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?

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?

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