THORChain aims to replace CEXs, by allowing users to swap between native L1 assets. For example, you could swap native $BTC on the Bitcoin network, for native $AVAX, on the Avalanche Network, all without a CEX. Currently, 8 native assets are supported: $BTC, $ETH, $DOGE, $BNB, $ATOM, $LTC, $BCH, and most recently, $AVAX.
THORChain is an autonomous and decentralized cross-chain network that aims to decentralize the liquidity of crypto assets via a network of public THORNodes and ecosystem products. The protocol takes its inspiration from Tendermint and the Cosmos-SDK and introduces Threshold Signature Schemes (TSS) to determine how to move assets in response to user-submitted transactions.
THORChain watches for incoming user deposits to its vaults and executes business logic based on the transaction request, such as adding or removing liquidity or swapping assets. The ethos behind the protocol architecture is to achieve and sustain high levels of decentralization while capturing enough liquidity to provide cross-chain services to its users.
THORChain’s native $RUNE token is used for governance, as well as to secure the network. $RUNE uses a unique tokenomics design, where the token is used to pair with native L1 assets, like $BTC or $ETH. This liquidity pairing design is implemented to allow the protocol to scale while making liquidity pools reliable. $RUNE operates on a 3-1 ratio, meaning RUNE in the protocol should be 3x the value of the combined native L1 assets in the pool. This provides an inherent value-accrual system to the token, as $RUNE will grow in value as long as the TVL of the protocol grows.
THORChain has faced many challenges in its development but has grown to become a large protocol. With skepticism of CEXs growing as a narrative, THORChain’s use case has become even more apparent. The team continues to expand to new blockchains and add new features, including their Savers vaults, which aim to make it easy for people to deposit native L1 assets single-sided, meaning they don’t have to worry about pairing the asset with $RUNE. This feature could be seen as a way to take market share from CEXs and bring this liquidity on-chain into the THORChain ecosystem. An additional governance proposal being discussed is THORFi, a lending and borrowing system for the native L1 assets on THORChain.
THORChain was founded in 2018 to be an interoperable cross-chain decentralized exchange where users can directly exchange tokens from different networks without wrapping it or leaving the protocol.
In August 2020, Single chain Chaosnet was launched.
In April 2021, Multi chain Chaosnet was launched.
In July 2022, Mainnet was launched.
The roadmap is now focused on scalability and adoption for THORChain.
There are 3 Pillars of Scalability:
There are some proposed features that are discussions in progress, which may or may not be implemented. It consists of the following:
| Proposed Features | Effects on 3 Pillars of Scalability |
| Lite Nodes – to allow $RUNE holders with smaller capital to bond $RUNE and profit without being a validator | Increase $RUNE bonded into nodes |
| Multi-sig Wallet – signers can pool together to bond a node or add to a liquidity position | Increase $RUNE bonded into nodes, increase total assets in LP, generate more swaps and volume |
| Single-Sided Asset Yield – allows users to earn a yield on L1 assets without price exposure to $RUNE | Increase liquidity |
| DEX Aggregation – enable THORCHain to tap into isolated liquidity on respective chains | Increase total swaps and volume |
| Chain Integrations – add more chains to integrate with | Increase liquidity, generate more swaps and volume |
| Integrations with more wallets and DEX utilizing THORChain | Increase liquidity, generate more swaps and volume |
| Orderbook – using an orderbook to allow limit orders | Increase liquidity |
| THORFi – lending features | Increase liquidity |
THORChain has no defined organizational structure, with the network itself being community owned. It is a decentralized project with no company, no CEO, and no founders.
The THORChain team includes both Project Custodians and Community Members.
Project custodians are individuals who were part of the project launch, responsible for managing treasury and orchestrating activities to achieve the project vision.
Community members are those who have become contributors to the project and have begun to lead and build various elements of THORChain.
Core Protocol Developers
THORChain core protocol developers have a deep understanding of the main ecosystem products such as THORNodes, DevOps, BiFrost, MIDGARD, TSS, THORFi, as well as the network’s economic design.
Ecosystem Developers
Ecosystem developers typically write dApps, dashboards, explorers, wallets, user interfaces, developer libraries… or other pieces of software that help to secure the network. All of these components seek to facilitate the integration of other products into the network
Chain Client developers
Network clients are maintained by the community and currently support UTXO chains, EVM chains, BFT chains.
There are 2 parts to each chain client:
UTXO Chains:
EVM Chains:
BFT Chains:
THORChain is a public good and anyone can contribute to the ecosystem by connecting more chains, adding more business logic to the current tools available, upgrading the chain to be more robust… The ecosystem is, therefore, community-driven.
For example, node operators must have knowledge about:
THORChain is a layer-1 blockchain built using the Cosmos-SDK and optimized for interoperability and cross-chain liquidity. Its selling points are:
As a layer 1 blockchain, THORChain seeks to become a neutral and amoral platform where node operators can run their services in an anonymous manner that does not signal any personally identifiable information to other participants in the network.
In alignment with this ethos, public delegation is not permitted. Delegation undermines both the decentralization of the protocol as well as its security and censorship resistance. This ensures that the platform holds no opinion on the nature of the transactions processed on its network, nor the source/destination of funds. THORChain seeks to avoid all sources of subjectivity or bias.
If public delegation was permitted, then Node Operators would begin running initiatives that would try to attract delegated funds from marketing campaigns, lower commissions… This is a type of behavior that is well-known in other dPoS (delegated Proof of Stake) networks. THORChain made the decision not to allow it in order to enhance its principles of decentralization and credible neutrality. If public delegation was permitted, there would be a smaller set of validators that would gain all the market share and amass the majority of the funds. Over time more and more nodes would start public signaling to build their brands and gain public trust by buying domain names, and promoting on-chain identification within their own node monitoring systems… all of which would facilitate the process of easily identifying each unique user and associating its credentials with a real identity.
Within certain limits, private delegation is permitted. THORChain allows for private delegation because it does not erode the issues mentioned above.
Private delegation requires node operators to keep track of a whitelist with its bonders, and there can only be up to 6 bonders per node. The limit of 6 bonders per node ensures that Operators can’t attempt to scale their business beyond that limitation. This model assumes that bonders trust each other with their operators and have their own means to ensure that the operators run in accordance with their obligations. Hence, from the network’s point of view, a solo node would be no different than a privately delegated node.
Exchanges:
Integrated wallets and exchanges:
Wallets:
Education:
Analytics:
Infrastructure:
Community Dev Projects:
When it comes to the underlying tech, THORChain works as a State Machines and TSS protocol. Its processes are facilitated by a leaderless vault manager that supports the following function:
There are 2 types of Vaults in THORChain:
This model allows the system to use the security of the large vaults to hold the majority of assets while delegating smaller amounts to faster outbound vaults. Otherwise, it would take 10-20 seconds to sign 27 of the 40 TSS and the system would be extremely limited if that was the only solution. However, with each node running an outbound vault, the system can handle 1 transaction per vault per second.
In order to increase the number of nodes beyond 40, the system shards Asgard vaults into 2 when it approaches its maximum constant, and merges them into one whenever this number falls below. A constant monitoring system also instructs users about what vaults have the highest security at any given time.
THORChain’s State Machine is constantly monitoring the performance and activity of outbound vaults to limit them to holding up to 25% of the value in its bond assets.
The Incentive Pendulum is responsible for keeping the protocol in a state of balance over time.
The Incentive Pendulum ensures that the blockchain remains in an optimal state, such that the bonded capital and the pooled capital is roughly equal.
This ensures that :
A witness transaction is a transaction that is recorded by a node on a connected network. For example, it could be a node saying ‘I saw somebody send 1 BTC into THORChain’. All nodes are constantly sending witness transactions into the system.
All witness transactions have a standard structure regardless of network.
To reach consensus about a transaction, the network looks at all witness transactions related to it. When 67% of nodes agree on a transaction, it is approved and considered correct. Nodes are punished for missing witness transactions and getting transactions wrong.
Nodes have ‘slash points’ marked against their names when mistakes are made. When nodes leave the network, they lose rewards based on the number of slash points received.
Sometimes blockchains record a set of transactions but will change them in the future. This may happen due to double-spending, chain re-orgs, and network forks.
THORChain needs to resolve this because it needs an accurate record of what is going on in those chains. To resolve this, nodes keep their own copy of transactions on each external chain. This allows the network to stay in sync with external chains despite their updates.
THORChain uses a continuous and incentivized liquidity model with impermanent loss protection.
Instead of using a limit order book, the CLP model offers the following advantages:
The CLP model has improved thanks to a slip-based fee model that adds a liquidity-sensitive fee to the model and ensures that the fee that is being paid is commensurate with the demand of the pool. For protocols that can’t order trades, this can cause issues, because traders will compete with each other for Ethereum blockspace in network fees. However, THORChain is able to order trades based on fee and slip size. This is known as the Swap Queue and ensures that fees are collected to prevent low-value trades. This offers the following benefits:
Lastly, Impermanent Loss Protection ensures that LPs always make a profit or at least remain neutral after a minimum period of time of 100 days. This alleviates Impermanent Loss, which is one of the biggest barriers to entry for liquidity providers.
Bifröst enables multi-chain connectivity by building a bridge between blockchains. Using multi-sig security, PoS, and CLPs, Bifröst is an interoperable cross-chain bridge.
Once a bridge is created, random parties are assigned to the bridge’s multi-sig so that no parties can ever collude to attack a bridge. Bridges can be created with different security and performance characteristics. This allows participants to choose between low security but highly operable bridges such as 3 out of 4 multi-sig arrangements, or more secure bridges with 20 out of 21 multi-sig arrangements.
Each node has a “Bifröst” service that handles the nuances of connecting to each chain. Once nodes are synced, they watch vault addresses. When they see an inbound transaction, they read it and convert it into a witness transaction.
The Synthetic Asset Model is one of the primitives that allow THORChain to enable synthetic assets trading with no impermanent loss and with single asset exposure. THORChain synthetic assets allow for the creation of assets that can be sent anywhere in the Cosmos IBC Ecosystem and that will always retain the guarantee they can be redeemed for the underlying assets. Synthetic assets are unique in that they are 50% backed by the underlying asset and 50% backed by $RUNE. This is possible by being collateralized by a liquidity pool as a form of ownership that also ensures always-on liquidity and fair pricing.
Synthetic Assets are minted by adding $RUNE to a pool or swapping from one asset into $RUNE, then adding $RUNE. The $RUNE collateral is then represented as synth units. Synth units are issued to allow for minting the newly created synthetic asset. These units are held by the pool and, therefore, are not owned by anyone.
Pool Units are the sum of Synth units and Liquidity Units. The main use cases for synthetics are the trading benefits from faster speed and lower transaction costs:
The minting of Synthetic Assets is capped at 33% of the assets in the pool or about 16.5% of the pool depth. Minting assets increases the total $RUNE pooled amount, which cannot be greater than the total bonded amount.
Synth Assets hold the value in the same way as normal assets and can be redeemed 1:1 (e.g. swapping 1BTC for 1 unit of Synthetic BTC that can later be redeemed to $RUNE and swapped for 1 BTC excluding fees. In order to redeem the underlying backing, Synthetic Assets are burned by swapping the Synth representation for $RUNE.
Synth swaps can be classified as follows:
The economic reasoning behind synthetic swaps is that synth holders do not experience any gain/loss caused by price changes when minting/redeeming. However, users do pay a slip-based fee on entry/exit plus transaction fees. This is possible because synth units keep track of the accounting gain/loss caused by the price divergence realized by LPs. Since liquidity providers are protected by Impermanent Loss Protection, the price risk is being taken by the Protocol Reserve.
Synths have a minting cap because liquidity providers are taking a leveraged position on the $RUNE asset. This can help LPs to earn more rewards if $RUNE outperforms the underlying Layer 1 asset, but can also go the other way. The higher the percentage of Synthetic Assets in circulations relative to the pool depth, the higher the leveraged position that is being taken by liquidity providers. If this percentage were higher than 50%, the network would be unhealthy overall.
Combined with Synthetic Assets, Yield Bearing Synths allow for Protocol Owned Liquidity (POL). Introducing yield-bearing synths might increase the demand for Synthetic Assets. As a consequence, the minting can reach the maximum cap by using the $RUNE collateral within the Protocol Reserve. This rate of utilization is monitored by the network on a per-pool basis such that the economic security remains at a healthy level at all times. By having the Reserve add $RUNE into the pool, it is essentially derisking the positions held by liquidity providers from their consequent $RUNE leverage.
What Yield Bearing Synths offer is single-sided exposure to Synthetic Assets. This exposure comes in the form of a yield that increases the network’s capital efficiency while also allowing for faster and more efficient arbitrage opportunities.
Synthetic Assets are locked up in Saver Vaults to generate yield. Since synths are single-sided assets, these positions are not subject to Impermanent Loss. Locked synth holders take on significantly less risk than LPs. At most, they can earn 50% of the yield generated by the synth collateral.
The growth of Yield Bearing Synths can be measured with a LUVI equation that reflects the yield of a pool.
Before this, arbitrageurs were the only holders of synths, since there was no yield. However, Saver Vaults introduced a mechanism by which users could deposit native gas assets that would get auto-converted into synths and allow the user to earn a yield representing 50% of the earnings of the respective LP.
Saver Vaults have the following characteristics:
Lending allows users to deposit native collateral, and then create a debt at a collateralization ratio (CR). The debt is always denominated in USD (aka TOR), regardless of what L1 asset the user receives. All loans have 0% interest, no liquidations, and no expiration. Risk is mitigated by:
Lending allows users to:
Lending benefits the protocol by:
Derived assets, such as thor.btc and thor.tor, are algorithmic coins that are backed by the liquidity of $RUNE, and the liquidity of that is based on the $RUNE-ASSET pair. Derived assets are swapped from or swapped to L1 assets, via $RUNE, using derived asset pools that are based on the equivalent L1 pools. Unlike, Synthetic Assets, derived assets are independent of Liquidity Pools and all swap fees are burnt. Derived assets are for accounting and there are no plans for them to be exportable or held by users.
TOR (thor.tor) is a non-transferable unit of account within THORChain designed to match the value of $1 USD and has been in use since ADR 003. It cannot be exported anywhere and always has a market cap of $0. TOR is valued by taking the median price of the active USD pools.
All collateral, debt and repayments within Lending are converted to and accounted for in TOR.
The user provides Bitcoin collateral and can receive the debt in any asset however it is all accounted for in TOR.
Users can repay loans at any time, with any amount in any asset. Repayment is converted into TOR.
Derived/virtual pools are created for each derived asset, including TOR, to allow swapping between L1 assets and derived assets va RUNE. Their depths expand and contract to throttle the amount of slippage users pay when swapping from an L1 asset to a derived asset. In periods of volatility, pool depth contracts to increase the slippage on swaps during this period of time. This incentivizes users to wait for a period of lower volatility to exit/enter lending and protects the system against pool manipulation.
The TOR pool is a derived asset pool and operates the same as other derived asset pools except the TOR price comes from the medium of the four pools instead of one L1 Asset Pool.
The totalRuneDepth is the sum of all RUNE in anchor pools (i.e. – USDC, USDT, BUSD-BD1 for TOR or just BTC.BTC for the L1)
Lending is capped by limited the collateral that can be received by the protocol. The lendingLeverthrottles the amount of RUNE available for lending, in basis points.
The protocol setting loanRepaymentMaturity defines the number of blocks before a loan can be repaid/closed. There is no option for repayment before this period.
Opening new loans creates a deflationary effect on the $RUNE asset, whereas closing loans creates an inflationary effect on $RUNE.
If the value of $RUNE relative to $BTC is the same when the loan is opened and closed, there is no net inflationary effect on $RUNE (same amount burned as minted minus the swap fee). However, if the value of the collateral asset increases relative to $RUNE between the time the loan is opened and closed, there will be net inflation of $RUNE supply.
Lending controls are in place to address these concerns.
THORNames allow any network participant to register a cross-chain wallet address and associate it to a case-insensitive and emoji-compatible name representation.
There is a one-time registration fee of ~10 $RUNE with a 20 tor block fee for THORNames:
Streaming swaps allows users to stream their swaps, gaining a better price execution.
A streaming swap specifies two parts:
The “m” interval part allows arbs enough time to rebalance intra-swap – this means the capital demands of swaps are met throughout, instead of after, a swap. So if a swapper starts with a price of X (assuming no volatility), the final swap will be executed closer to X.
The “n” count part increases the size of the swap to pool ratio so each is executed with less slip – and in aggregate less total slip.
For example, a user can send a single inbound of 50 $BTC (paying a single inbound gas fee), internally split into 100 swaps, then consolidate all the outbounds into one single $ETH on-chain outbound transaction (again, paying a single outbound gas fee).
Users are free to select the number of swaps and the number of THORChain blocks between each swap; bounded by a minimum slippage of 5 bps (or 0.05%), configurable via Mimir. Streaming a swap from a L1 asset will be capped to a maximum of 24 hours to complete the swap, while swapping from a Synth will be capped to a maximum of 1 year. There will not be a cancellation option for an ongoing swap.
In essence, the large swap is “streamed” across multiple blocks, and that is why this feature is named as a “Streaming Swap”. With this mechanism, there must be a multi-block time component in play, since if each of the individual swaps are executed in the same block, there would not be any time for arbers to rebalance the pool between each swap, and users would progressively receive lesser quality rates for each subsequent swap. This is not much different vs the “single large swap” scenario.
Savers deposits and withdrawals will automatically use the Streaming Swaps feature to deposit and withdraw, with no additional input from the user. The swaps will use a sub-swap interval of 1.
Loans can be entered and exited using the Streaming Swaps feature. The amount of swaps in a stream that can be performed for a loan open or close is dictated by the respective virtual pool depth. As the virtual pool depth shrinks, less streams can be performed. Below a virtual pool depth of 50% the parent pool, a streaming swap cannot be performed.
There are 4 key roles in the system: Liquidity providers, swappers, traders, and node operators.
Users do not need $RUNE to interact with the network. They can perform swaps or add/remove liquidity without $RUNE. To do that, the user needs a THORChain-connected wallet. However, most users will find themselves providing symmetrical liquidity to pools or bonding as a Node. To do that, they need to hold $RUNE
There are several ways to acquire $RUNE:
Once the user buys $RUNE, it must be sent to their custody wallet.
Liquidity providers, or LPs for short, are the network participants that deposit their assets into decentralized pools that allow traders to swap from one asset to another. These pools follow the logic of an AMM (Automated Market Maker) algorithm that varies from one exchange to another. The main services of these AMMs is to offer deep liquidity, low transaction fees, and 100% uptime for its users. By depositing assets to a decentralized pool, LPs earn rewards from swap fees. As users transact and swap the assets in the liquidity pool, the underlying AMM will incur fees and distribute them pro-rata with its liquidity providers.
While symmetrical liquidity provisioning is recommended, it is also possible to supply asymmetrical liquidity according to the below rules:
Investing Strategies
Users can track their liquidity positions using frontend interfaces like THORYield.
THORYield guide: https://thorswap.medium.com/introducing-thoryield-v2-%EF%B8%8F-a6618c1cfcdb
How LPs can calculate their profits:
There are 5 factors affecting the returns of a position:
Liquidity providers earn tokens in $RUNE and the pool’s connected assets. For example, an LP of $BTC/$RUNE will receive rewards in $RUNE and BTC. The yield of a position is calculated on a block-by-block basis. This yield is paid out to liquidity providers when they remove assets from the pool.
This ensures that the yield is being sent to where demand is being experienced – with fees being the proxy. Since fees are proportional to slip, it means that the increase in rewards ensures that pools experiencing a lot of slip are also being incentivized to attract more liquidity
As swappers and traders exchange assets in a pool, their actions will cause the ratio of assets to diverge from the market rate. This change to the ratio of assets is called ‘slip’
The yield of a pool on THORChain is calculated using a metric called the Liquidity Unit Value Index (LUVI), which can be viewed on Midgard.
When a user deposits assets into a pool, they are given ownership of Liquidity Units that represent a percentage of ownership over the total assets in the pool. LUVI is a measure of the relative value of each liquidity unit and is independent of price.
The yield of a pool uses LUVI data from the previous 30 days and extrapolates the results to an APR where the performance is repeated over the course of a year.
An exception is the Nine Realms Pools on Midgard, which calculates the APR of a pool with the previous 100 days of data rather than the default period of 30 days.
The following factors affect the LUVI:
Swaps on THORChain require native assets. For instance, a swap between $RUNE and $BTC requires that $RUNE is sent into the THORChain network by the user and $BTC is sent out from one the THORChain’s vaults to the user. Accordingly, inbound gas is paid in native $RUNE, and the outbound fee is paid in $BTC.
Decentralized exchanges need a mechanism for accurate prices so that users can swap across the supported assets. THORChian keeps the exchange rates accurate by using the internal design of the pools and relying on arbitrageurs. This avoids relying on external resources such as oracles and weighted averages (these are well-known attack vectors).
Arbitrageurs do not fix the imbalance of assets in a single transaction. This would not be an economical solution (swapping would be cheaper on centralized external exchanges). Instead, they split the arbitrage swaps into smaller transactions to keep their activity profitable.
For working out the pricing or exchange rate between any 2 external assets, the following formula is used:
Using the model, THORChain is able to sense both the instantaneous price of an asset as well as its purchasing power (how much would one asset purchase of another asset if it was instantly sold). This is especially important when it comes to collateralizing debt, where users and protocols need to account for relative purchasing power, not spot price.
THORChain’s value proposition for swappers is to give them access to:
Users can swap from any connected asset to any other connected asset and from any connected asset to $RUNE. All swaps are managed according to the rules of THORChain’s State Machine, which is responsible for finalizing valid transactions and refusing invalid ones. All swaps are confirmed within 5-10 seconds.
How swappers can calculate their profits
Since all swaps are facilitated by THORChain’s liquidity pools, it is possible for users to swap $RUNE in one pool, then move that $RUNE to another pool and swap $RUNE there for the desired asset. This is allowed thanks to Continuous Liquidity Pools.
The output of a swap can be calculated as follows:
Traders are the users who balance the ratio of assets across pools to exploit and benefit from the price deltas between markets. Because of this, prices on THORChain are maintained by profit-seeking traders and arbitrageurs. These actors look for asset mispricings and buy them at undervalued prices to later sell them on overpriced markets, thus earning a profit.
To do this, traders compare the exchange rates on THORChain with the rates on external markets. I
This process is repeated at a high frequency and usually in an automated manner. Over time, the asset mispricing information is propagated and the prices on THORChain settle in agreement with external markets. This avoids relying on external resources such as price oracles.
How traders can calculate their profits:
The economics of the swap formula means that traders should aim to restore balance to the pool in a single trade. This rebalancing should be done in an incremental manner. Otherwise, large rebalancing attempts would make the arbitrage not profitable for traders.
Specifically, each rebalancing trade should be around 40-50% of the imbalance size. For example, if the imbalance starts at $100 in value, the first rebalancing trade should be $50-$40 to leave the imbalance at $50-$60. The next rebalance would be $25-$30 and so on. This process would repeat until a satisfactory balance is restored.
Trading profits are largely impacted by the liquidity on THORChain compared to the liquidity available on external markets. For instance, if the price of an asset in a THORChain pool is $1.2 and the price for the same asset on an external market is $1.00, then someone could buy on the external market and sell on THORChain for a profit. There are three possible scenarios:
Infinitely deep liquidity
Finite but uneven liquidity
Low liquidity
Liquidity refers to the ease of selling/buying an asset without affecting its market price. In other words, liquidity refers to the degree to which an asset can be quickly bought/sold in the market at a price that reflects its current market value.
Liquidity or market depth is the ability to absorb relatively large orders without significantly impacting the price of the underlying asset.
The majority of arbitrage opportunities are executed by trading bots developed by third-party entities.
THORNodes are the service that powers the THORChain network. Each THORNode consists of several servers that live together in a cluster of individual nodes. For the THORChain network to operate, node operators will run THORnodes as anonymous and distributed entities.
To make the process of decentralization possible, nodes bond their $RUNE capital as a safety guarantee for liquidity providers to deposit their assets in the THORChain network. For the network to operate in an optimal state, each unit of pooled capital requires two units of bonded capital. This game-theoretical mechanism disincentivizes anonymous network validators from stealing assets from the network since they have more capital to lose than to earn.
While 100% of the bonded capital is $RUNE, the pooled liquidity is 50% $RUNE and 50% other assets. This means that 66.7% of the capital is bonded and 33.3% is pooled, which puts a lot of economic pressure on node operators who are expected to bond 66.7% of the $RUNE TVL.
The network currently operates with 82 THORNodes, where at least ⅔ of them need to come together in a TSS ceremony to sign a transaction. With Shared Vaults, the system could rely on multiple groups of 54/82 vaults, which means that only 10 vaults could power the network as a total of 820 THORNodes.
When it comes to individual skills for running a node, there is an expected level of technological skills and dedication. The best operators are characterized by their extensive knowledge of DevOps and software infrastructure. Beyond that, it is also important to keep in mind that most node operators are subject to a 24/7/365 “on-call” schedule, due to the important role they play in supporting the THORChain network.
The setups for a THORChain node range between $1,500 and $2,000 per month in operating costs. As more chains are added to the network, this cost is expected to increase. Besides that, every node operator must also bond the minimum required amount of $RUNE in order to participate as a validator. As of now, the lowest bond is 302, 506 $RUNE.
Yggdrasil
Yggdrasil are also known as “hot nodes” since they store a small amount of funds in THORNodes. These nodes facilitate faster transactions when users perform swaps. While “hot nodes/wallets” are known for being more vulnerable to “cold storage solutions”, a node operator would not steal assets from a Yggdrasil, since they are still operators who need to bond the minimum amount of $RUNE to participate. Today, the lowest bond for a Yggdrasil is 661,400 $RUNE. If a node operator running a “hot node” were to steal funds from their own vault, they would get slashed from their bond 1.5X the amount stolen. Therefore, any attempt to act in a dishonest manner would result in bigger losses than gains.
Every THORNode runs an outbound Yggdrasil vault.
Vault Nodes
Mathematically, both bond value and number of nodes can grow ad infinitum. However, in practice, this is not the case. Validator nodes need to hold big amounts of $RUNE and also be technically skilled to run a node. On top of that, there are also some technical limitations involved that limit the total number of nodes that can participate in the network.
The amount of $RUNE and knowledge required to run a node make it a more complicated endeavor than, for example, being a liquidity provider. Because of that, the network also sets a limit on the amount of liquidity that can be in the network.
Both of these limitations explain the origin of Vaults Nodes, a design that allows anyone with relatively basic technical skills to bond any amount of $RUNE. This contributes a significant amount of TVL that helps the network to continue growing.
Vault nodes process transactions upon request and are paid for their services. These nodes are free to participate or leave the network whenever they want. Because of this, vault nodes do not hold any funds apart from their own. This is the reason why vault nodes contribute to the liquidity, but not to the security of the network.
Vault nodes are not validator nodes. The funds of a vault never leave their wallet until a swap transaction is executed. They also don’t contribute to the decentralization of the network. Nevertheless, they are usually referred to by the community as “Yggdrasil on steroids”.
Deep dive into THORNodes: https://youtu.be/_G8SuXenMus
Vaults and the Pendulum Incentive: https://youtu.be/_G8SuXenMus
How can node operators realize their profits:
Node operators earn 67% of the system income when it is stable
The system income collects value from liquidity fees and block rewards. This is a representation of all of the income revenue generated by the protocol.
The Incentive Pendulum decides how to split the System income between Liquidity Providers and Nodes. The starting point is a 67% to 33% split. After the costs are considered, the system adjusts to direct 50% to Liquidity Providers and 50% to Nodes.
In THORChain, fees meet the following functions: capture value, manage control accesses, and act as a resource-subsidization mechanism. Given that $RUNE is a native currency and is consumed as transaction fees on the network, all swaps are charged both a fixed network fee and a dynamic slip-based fee. This prevents attacks such as denial of service attacks, sandwich attacks…
Sandwich attacks are attacks where a user’s transaction sits between 2 other transactions, one before, and another one after. These attacks often occur in Dexes and result in price manipulation. The malicious actor will be waiting and watching out for the victim’s transaction and will place an order just before the victim (for example to increase the price). When the victim’s transaction is executed, the attacker will back-run the user’s order, thus creating an artificial price increase and making a profit for himself.
The main Denial of Service attack impacting blockchains is transaction flooding. Most blockchains have a fixed block capacity with which they can operate at regular intervals. If an attacker sends too many transactions to the network at once, they can fill up blocks with spam transactions, causing legitimate user transactions to not be added to the ledger. This often leads to software crashes, node failures, network congestions, bloated ledgers…
THORChain charges a fixed Outbound fee and a dynamic Liquidity fee. THORChain keeps track of the trailing gas price of the connected chains, thus saving both gas prices as well as gas costs. Nodes are then instructed to pay for outgoing transactions using a gas price that is a multiple of the stored value. As the gas is consumed from the base chain assets, the network records how much it costs to transact each one of those external assets (e.g. BTC for Bitcoin mining fees, ETH for Ethereum gas costs…)
Outbound fee
The user is charged an amount that is 3 times the stored gas cost for each chain.
| Chain | Typical | Outbound fee | Network Fee (paid by the pool) | Pool reward | |
| Bitcoin | $1 | $3 | $1 | $2 | |
| Ethereum | $10 | $30 | $10 | $20 | |
| Binance Smart Chain | $0.03 | $0,09 | $0.03 | $0.06 |
The Network Fee is collected in $RUNE and then sent to the Protocol Reserve. If the transaction involves an asset other than $RUNE, then the user pays the network fee in the external asset. Afterward, the equivalent is taken from the pool’s $RUNE supply and added to the Protocol Reserve
Slip-based Fee
The slip-based fee is a liquidity-sensitive fee that is algorithmically set based on the transaction demand over the depth of a liquidity pool. This is a stateless and non-opinionated charge that is always commensurate with the demand for internal and external resources. You can see the exact formula that calculates the fee here.
Network fee
The network fee represents what users pay to make transactions on the THORChain blockchain itself.
This fee is dynamic averaging a set of recent gas prices. THORChain has a custom gas logic where users pay fees for the asset they send.
Fee distribution and functions
Advantages of this fee distribution:
There is a one-time registration fee of ~10 $RUNE with a 20 tor block fee for THORNames:
Depending on the specific setup for a node, costs are estimated to be between $1,000 and $2,000 per month. This is estimated to increase as the network continues to scale. The main costs come from the allocation of computing resources and hosting services.
The impact of costs is heavily reliant on Liquidity Providers and Node Operators based on their contributions to the network as a consequence of the Incentives Pendulum.
Given these assumptions, the Node operator can expect a margin of 30% years after 3 years of operating in the network
Liquidity Providers
Liquidity providers must have assets to deposit in the pools, and their assets must also support a supported external chain. Although there is a minimum requirement for a deposit, the new assets must win a competition to be listed. This has the side effect that larger value deposits will be listed over smaller value deposits.
Impermanent loss is a common and well-known loss that impacts most liquidity providers that operate on decentralized exchanges. It leads to the potential loss of liquidity providers’ purchasing power as a result of the price slippage in the pools.
Swappers
The cost of a swap is made up of 2 parts:
All swaps are charged a dynamic network fee that is calculated by averaging a set of recent gas prices.
Note that users who force their swaps through quickly cause large slips and, therefore, end up paying larger fees to LPs.
Traders
THORChain does not offer explicit incentives for traders, since they rely solely on arbitrage opportunities. The trading profits are, therefore, determined by the traders’ ability to seek out and capitalize on price differentials between traders and external markets
The $RUNE token is aiming for deterministic value. This means that, for instance, if over 80% of circulating $RUNE gets locked into THORChain liquidity pools, then, by economic design, $RUNE’s market cap should be a minimum 3x the value of all non-$RUNE assets ($BNB, $ETH, $BTC, $AVAX, $ATOM…) locked into the THORChain liquidity pools. The more liquidity is provided by $RUNE holders, the more accurate the deterministic results will become.
$RUNE’s deterministic value can be simulated by predicting market outcomes and TVL, driven from (3 x Non-$RUNE TVL) / $RUNE Circulating Supply).
For example, if the current Non-$RUNE TVL is $1mil USD, the current $RUNE circulating supply is 3mil, then the current $RUNE deterministic value = (3 x $1mil) / 3mil = $1 USD.
As the asset that powers the THORChain ecosystem and provides the economic incentives required to keep the network secure and coordinate its liquidity, the token serves 4 primary functions:
Sybil resistance is the ability to prevent malicious actors from impersonating or falsifying an identity in order to maliciously attack a network. For example, in Bitcoin, this is achieved by requiring that each CPU can only vote once, and in Ethereum by requiring that every 32 staked ETH can only vote once…
In addition to the roles mentioned above, $RUNE’s price is also impacted by:
The 2:1 bond:stake ratio, combined with the 1:1 pool ratio, means that the amount of $RUNE required to be in the network is 3 times the amount of non-$RUNE assets in THORChain. By this logic, if the network is securing $1M worth of non-$RUNE tokens staked, then the market cap of $RUNE would be at least $3M. This 3:1 ratio is the minimum deterministic value of $RUNE.
$RUNE token release official schedule.
The goal of the monetary policy is to have a fixed $RUNE supply at all times instead of constantly emitting or reducing emissions. There is currently a progressive emission of 500M $RUNE tokens that will provide security and liquidity to the THORChain network. 100% of the tokens were created and distributed through different mechanisms:
The Reserve also backstops Impermanent Loss Protection and is used to underwrite debt. Block by Block the Reserve is depleted in block rewards and continually topped up from system income.
THORChain aims to be a governance-minimized chain. However, there are some parts of the protocol where governance is needed. One example of this is the listing process of external assets. The protocol maintains a queue of standby assets and, every few days, a voting poll decides when to make the listing effective.
Similarly, when a connected chain loses its value or economic security, then all the liquidity providers will abandon that chain. Once a pool becomes empty, it will automatically be delisted.
THORChain follows the premise of one-node-one-vote. Approximately, every 3 days, the pending pool with the deepest liquidity becomes an active pool in the network. This is called a Pool Churn. For a pending pool to become active, there is a minimum requirement of 10k $RUNE. There is also a set maximum of 100 active pools. Once achieved, deeper pending pools are allowed to replace the shallowest active pools.
Developers from the community submit THORChain Improvement Proposals (TIP) to suggest and discuss software improvements such as:
There are also emergency upgrades that are handled by forcing nodes to leave the system such that the number of nodes falls below 4 and the network can be shut down. This process is called Ragnarok.
Overall, THORChain Governance decides:
While Node Operators are compensated for their services, they must also be aware of risks associated with THORNodes. This is a combination of intrinsic risks, skills, and costs.
To compensate for the risks, node operators are compensated for their service with:
THORChain operates with several layers of security within the code base to ensure the solvency of the network while minimizing the impact of any possible exploit.
There are a set of emergency procedures that describe how to react in a network-wide emergency that could put funds at risk. Once the bug has been identified, an admin should make a decision on the level of response.
As an extra layer of security THORChain also relies on THORSec’s Red Team, a group of cybersecurity experts that have overseen the security of the network since inception. Its responsibilities include:
A detailed report and structured review were conducted on THORChain’s and Bifrost codebase by seasoned security researchers with whom they discussed 10 vulnerabilities of varying degrees. All disclosures can be reviewed at https://gist.github.com/HildisviniOttar and each vulnerability has now been patched.
Since the deployment on mainnet, a Github repository keeps track of all the protocol audits. Audits on THORChain have been completed by some of the leading teams such as Halborn Security and Trail of Bits
There is also a formal bug bounty program in place for reporting bugs. Every report is formalized with Immunefi and must include:
Immunefi serves as the neutral third party in charge of administering payments and the verification of bounties. Several bug bounties have already been fully serviced, including a disclosure by Trail of Bits with respect to a critical TSS vulnerability that could affect not only THORChain but also other projects using TSS.
Every time there has been an exploit, the team has kept track of Post-mortem reports that help to fully understand what happened and why it happened:
As a result of every investigation, new security measures were announced as a THORChain Development Team Response – Hardening the Protocol
In one of these unfortunate events, the protocol treasury decided to fully reimburse users for the losses suffered during an exploit. Once the chain was fully restarted, Liquidity Providers and Node Operators were fully subsidized with ~$16M
When it comes to economic security, the most important aspect of the game theory supporting the network is that Nodes must pay for their Bond, since this is a core assumption to operate the blockchain. For instance, if the bonding mechanism did not exist and a node paid only a specific amount, then the malicious node could make a profit from the stolen funds.
Similarly, if public delegation was permitted, then a Node operator could contemplate stealing assets as soon as they are received.
By design, none of these behaviors is allowed to exist. THORChain relies on a bonding mechanism to ensure that the economic assumptions of the network are being upheld.
THORChain does not have a dedicated insurance fund that protects LP capital. In fact, it is not ideal for protocols to rely on third-party insurance funds since it adds an extra dependency to the network. Because of that, THORChain maintains a Reserve backstop mechanism that protects against Impermanent Loss among other things.
Since it is yield-generating, the Reserve can:
The most perceived risk for liquidity providers is often impermanent loss.
When a user provides liquidity into a pool, the two assets are bound together by the AMM to ensure that the value of your LP deposit remains the same. However, if the price of one asset changes drastically with respect to the other, the user might suffer impermanent loss.
This happens because the way most AMMs work is that the user’s initial position sells one of the assets on the way up, and buys on the way down. What ends up happening is that the assets are sold at a price that is an average of the starting and ending prices. If the user compares the original deposited prices with the return after providing liquidity and he/she is at a loss, he/she has experienced impermanent loss.
This is called impermanent loss because the loss is only realized if/when the user withdraws the assets from the pool. For instance, if the assets’ ratio goes from 5x (25.5% IL) but then reverts back to the same ratio as when the user entered the pool, there would be no impermanent loss.
The bigger the price divergence between two assets, the higher the exposure to impermanent loss. Despite this risk, LPs are encouraged to provide liquidity in the pools where they believe their position will stay neutral, such that they can collect revenue from swap fees.
So far, this works in a similar way to other protocols. However, THORChain protects its LPs with 100% Impermanent Loss Protection after they have been in a pool for 100 days. This takes place by giving LPs 1% coverage for each day they have remained in the pool. (50 days would grant 50% protection, and 100 days would grant 100% IL protection..).
On THORChain, Impermanent Loss Protection ensures that users are not worse off depositing their assets into a liquidity pool than simply holding them in their wallets. Impermanent Loss Protection is recorded and applied symmetrically to both assets after the deposit is rebalanced 50/50
THORChain has raised funding over 2 rounds in 2018.
In the venture round, on Jul 1, 2018, Mapleblock Capital and Yield Ventures invested in THORChain. In the ICO, on Jul 1, 2018, Jon Carr-Haris invested in THORChain as the lead investor. According to Messari, investors of THORChain also include Delphi Digital, Multicoin Capital, Zee Prime Capital, and X21 Capital.
THORStarter, a Venture DAO and IDO launchpad, raised $1.5 million in a private round led by True Ventures on Jun 2, 2021. The private round also saw participation from other VC firms such as NineRealms Capital, IDEO CoLab Ventures, Proof Group, MetaConstant, Qi Capital, Brilliance, and Next Ventures.
To access the features of THORChain, users go through one of the 7 user interfaces that have built exchanges on THORChain, which are how you can earn yield or make swaps. These exchanges include ThorWallet, THORSwap, Edge Wallet, XDEFI Wallet, Defispot, Asgardex, and ShapeShift.
On Dec 1, 2019, THORChain announced its Exchange Partners program, which offered developer assistance in acquiring and staking the native $RUNE token, listing $RUNE on exchanges, and integrating THORChain into exchanges. This program was used to bootstrap liquidity in a THORChain ecosystem.
THORChain exchanges can permissionlessly partner with other protocols. Following the addition of Avalanche into the THORChain ecosystem, THORSwap made their first partnership with Pangolin, an Avalanche native DEX, in October 2022. This allows THORSwap users to gain access to a host of assets on Avalanche, all through the THORSwap DEX aggregator.
Desktop interfaces:
Mobile interfaces:
Native Rune Wallets:
Community media:
Dashboard and Analytics:
Communities and support:
Community Chain Chats:
Guides and info:
Regional socials:
