Overview

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.

 

Why The Protocol Was Created

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. 

Roadmap

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:

• Total $RUNE bonded into nodes
• Total assets in liquidity pools
• Swap volume

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

Team

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:

• Observer (Scan blocks and packages events to be witnessed to THORChain)
• Signer (Receives outgoing transaction data from THORChain and converts into chain-specific signing data, either by YGG node or TSS routine)

UTXO Chains:

• Consists of chains like Bitcoin and its forks.
• Scanning blocks
  • Block scanner monitors Asgard addresses and looks for incoming UTXOs spending to those addresses.
  • When it sees one, it performs validation on it and witnesses to THORChain.
  • The output forms the amount and memo witness to THORChain.
• Confirmation Counting
  • txValue is the sum of all transactions received in a block to Asgard vaults.
  • blockValue is the Coinbase value, including fees and subsidy.
  • If a miner forgets to add a Coinbase value, a default of 6.25 is used. (This value should be updated every 4 years or use logic to auto-update).
• Re-orgs
  • Every time it detects a new block at a previous height it has seen, it checks for the presence of every transaction it has reported. 
  • If the transaction is missing then it has been re-orged out.  
  • The missing transaction ID will be reported to THORChain as ErrataTx.
• Network fee
  • Where the fee rate is computed over the last block.
  • Reports the highest seen in the last 20 blocks.
• Handling Gas
  • The gas amount for a transaction is the difference between outputs and inputs.

EVM Chains:

• Router
  • A router is used to handle deposits in and out of THORChain vaults.
  • The Router is a means for capturing token deposits and emitting memos.
  • The Router allows the TSS vault and YGG vault to call into it to move tokens into the vaults.
  • It is a permissionless contract.
• Scanning Blocks
  • The block scanner monitors the Router events and can create witness transactions based on these events.
• Confirmation Counting
  • Incomings are counted by comparing their value with ETH, using THORChain pool pricing, and delayed based on the ETH value of the deposits compared with the ETH block reward + fees.
• ETH Cancellation Logic
  • Each node has a transaction cancellation logic that invokes if it finds that gas has been made and is still pending after 20 minutes.
  • It does this by spending 0 ETH back to itself using the same nonce as the transaction that is stuck, using the latest gas prices.
• Gas Fees and Limits
  • Each node will use up to 200k gas for outbound transactions, but the real cost is closer to 80k gas units so the user is charged based on spending 80k.
  • ETH Bifrost uses a gas fee that is 1.5x the current average gas price for a block to minimize transactions from not going through.
• Re-orgs
  • ETH chain re-orgs a lot and is able to monitor and post re-org data to THORChain.

BFT Chains:

• Such as BNB and Cosmos connections.
• Assets on BFT chains are generally native tokens and can pay their fee in their native tokens.
• No router is required.
• BFT chains do not re-org, so no re-org logic is required.
• Do not require any confirmations.
• Generally have static fees, so fee rates do not need to be updated regularly.

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:

• Linux server administration and security
• Kubernetes
• Experience running a host of nodes on cloud services like Google Cloud, Amazon Web Services, Digital Ocean…
• Knowledge of running full nodes of other chains like Ethereum, Binance Smart Chain…
• Willingness to be “on-call” 24/7/365

Sector Outlook

THORChain is a layer-1 blockchain built using the Cosmos-SDK and optimized for interoperability and cross-chain liquidity. Its selling points are:

• The ability to swap native assets across multiple chains (e.g. native BTC to ETH)
• No user registration or identification required
• Liquidity does not contain wrapped assets – all assets are natively secured
• Transparent and fair pricing independent of centralized third parties
• Continuous liquidity pools maximize the efficiency of the protocol

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. 

• Thorchain treats liquidity providers as first-class citizens and does everything needed to protect their capital
• Thorchain treats node operators as second-class citizens, paying them for their services and ejecting them when they misbehave. 

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.

Ecosystem

Exchanges:

• ASGARDEX Desktop – Wallet and Exchange Client for THORChain
• THORSwap – World’s first multi-chain dex powered by THORChain
• Rango Exchange – First Multi-chain DEX Aggregator
• Brokkr – Investment Platform for optimized DeFi Investing
• DefiSpot – Buy and earn BTC, ETH, and more fully decentralized
• SKIP – An exchange powered by THORChain
• THORGram – THORSwap in Telegram

Integrated wallets and exchanges:

• Liquality – Browser Extension Crypto Wallet with Built-In Swaps
• XDeFi – Cross-chain Wallet & Dex, Browser Extention
• THORWallet Dex – Crosschain mobile wallet and dex
• Shapeshift – Multichain trading and DeFi platform

Wallets:

• Cross-platform Progressive Web Application
• Edge Wallet – Cross-platform Mobile Application

Education:

• GrassRoots Crypto – Educational videos
• LP University – Educational, Liquidity Pooling Strategy Discussions
• RuneBase – News and Updates on THORChain
• THORNoob – Weekly Community Updates and Educational Articles

Analytics:

• THORChain Vision – Key stats and figures related to core Thorchain operations
• THORYield – View your added liquidity on THORChain
• THORChain Data Digest – THORChain Data Reports / Analysis
• DecentralFi – Track positions  – https://decentralfi.io/liquidity?wallet={thor address}
• THORChain Information Bot – Useful commands to fetch network info
• THORChain Monitoring Bot – Monitoring of major events in THORChain
• THORChain Twitter Bot – Posts network stats
• RuneData – LP Prediction Tool
• LP Calculator – THORChain LP Calculator
• THORChain Vision – Contains key stats and figures related to core Thorchain operations.
• Swapalyzer of THORChain – View swap information

Infrastructure:

• THORNode Official Docs | THORNode Official Announcements
• THORChain Network Explorer – THORChain Network Explorer
• THORmon – Detailed THORNode Dashboard
• Constants – Current THORChain Constants
• Mimir – Overrides for Constants
• Midgard Docs – Documentation for Midgard API to query THORChain.
• Thornode Docs – Documentation for Thornode API to query Thornode.
• Tx Queue – THORChain Transaction Queue
• Viewblock Dashboard – THORChain Block Dashboard
• Viewblock Explorer – THORChain Block Explorer

Community Dev Projects:

• XChainJS – A library with a common interface for multiple blockchains, built for simple and fast integration for wallets and more, in JS. Docs link.
• Ledger – Client library to communicate with a THORChain App running in a Ledger.
• xchainpy-lib – A library with a common interface for multiple blockchains, built for simple and fast integration for wallets and more, in PY.
• thorchain-arb – Thorchain Arbitrage bot

For Users

How THORChain Works

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:

• 1-way State Pegs to allow synching the internal state from other chains
  • Each node has a Bifrost service that deals with connecting to each chain and watching out for vault addresses to keep track of inbound transactions into THORChain.

• A State Machine coordinates the asset exchange logic and delegates external transactions.

• A Bifrost Chain Client processes chain-specific transactions
  • Once a transaction scheme has been created, the Signer loads it from the local copy and serializes it into the corresponding destination transaction format using the respective chain client.

 

• A TSS protocol enables the distribution of the key-signing process.

 

There are 2 types of Vaults in THORChain:

• Inbound Asgard TSS vaults with large committees (27-40)
• Outbound Yggdrasil vaults with 1 of 1 single-signing

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.

Sharded Asgard Vaults

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.

Yggdrasil Vaults

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

The Incentive Pendulum is responsible for keeping the protocol in a state of balance over time. 

• Sometimes there will be too much capital in liquidity pools.
  • If there is too much capital in liquidity pools the protocol is unsafe.
  • If the network becomes unsafe, the mechanism increases block rewards and liquidity fees for node operators while reducing rewards for liquidity providers.
• Sometimes there will be too much capital bonded by nodes.
  • If there is too much capital bonded by nodes, the network is inefficient.
  • If the network becomes inefficient, it boosts the rewards for liquidity providers and reduces the rewards for node operators.

 

The Incentive Pendulum ensures that the blockchain remains in an optimal state, such that the bonded capital and the pooled capital is roughly equal. 

• Bonded capital is 100% $RUNE
• Pooled capital is 50% $RUNE and 50% external assets

This ensures that :

• 67% of $RUNE in the system is bonded
• 33% of $RUNE in the system is pooled

Witness Transactions

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.

Transaction Consensus

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.

Network Variability

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.

Continuous Liquidity Pool (CLP)

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:

• There is always liquidity available for all assets on the chain
• Users can trade at transparent prices without relying on centralized third parties
• Arbitrage opportunities are democratized since all users have equal opportunities to make a profit
• Allows pools to converge to a fair price
• Collectes fee revenues for liquidity providers
• Responds to fluctuating demand for liquidity

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:

• As demand subsides, the fees go toward zero, which means that the price delta between the pool price and the reference market price also trends to zero
• Traders will compete for opportunities in the market and pay a maximal fee to liquidity providers
• The fee being paid for any trade is responsive to the demand for the asset’s liquidity
• Since the fee is time-sensitive, traders will be urged to pay the fee in a time-sensitive manner to prevent other traders from profiting from the same market opportunity.

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 Protocol

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. 

Synthetic Asset Model

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:

• Before synths, swapping from $BTC to $ETH might cost $30 and take ~11 minutes. 
  • The trader would pay fees on the Bitcoin, THORChain, and Ethereum networks
  • The trader would be forced to wait for at least 3 block times – Bitcoin (~10 minutes), THORChain (~5 seconds), and Ethereum (~12 seconds)
• With synths, an equivalent swap from $BTC to $ETH would cost ~%0.75 and take around 5 seconds
  • The trader would only pay for THORChain fees (3*0.02 $RUNE)
  • The whole transaction would be executed in 1 block (~5 seconds)

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:

• From layer 1 asset to synth:
  • $RUNE is moved over to the pool and the synth is minted.
• From synth to layer 1 asset:
  • The synth is redeemed, and $RUNE is moved to the next pool, where it will be swapped for the desired layer 1 asset
• From synth to synth:
  • The synth is redeemed, and $RUNE is moved over to the corresponding pool where the other synth is minted.

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.

Yield Bearing Synths

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:

• Saver Vaults are backed by the respective LP.
• Saver Vaults earn a part of the yield from swap fees by using THORChain’s LPs.
• The yield is redeemable at all times to the native coin.
• The yield has no price exposure to $RUNE.
• There is no Impermanent Loss.

 

Lending

Overview

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:

• Limits on collateral for the network and each pool
• Slip-based fees when opening and closing loans
• Dynamic collateralization ratio
• A circuit breaker on $RUNE total supply

Lending allows users to:

• Create a loan using native assets as collateral
• Hold a loan without the risk of liquidation
• Be short on USD and long on crypto assets such as Bitcoin

Lending benefits the protocol by:

• Increased capital efficiency of the pools which increases system income and real yield.
• Increased trading volume
• Increased total bonded, allowing THORChain to scale.
• Providing an attractive sink for capital

Fundamentals

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.

• The user sends in collateral (BTC.BTC -> RUNE, RUNE -> THOR.BTC)
• THOR.BTC is held as collateral in the Lending module
• Convert THOR.BTC value to TOR terms
• Calculate debt in TOR based on CR and collateral TOR value
• Mint TOR
• TOR -> RUNE, RUNE -> L1 out (e.g. – ETH)

Users can repay loans at any time, with any amount in any asset. Repayment is converted into TOR.

• L1 -> RUNE (optional, user can also pay back with RUNE)
• RUNE -> Mint TOR
• Burn TOR (amount deducted from loan debt)
• Burn Derived Asset (THOR.BTC) (amount is the same percentage of collateral as a percentage of loan debt paid) -> Mint RUNE
• RUNE -> BTC.BTC (loan originator)

Derived/Virtual Pool Depth

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 Controls

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.

Concerns + Considerations

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.

THORChain Name Service

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:

• TNS Registration Fee: 10 $RUNE
• TNS Fee Sale: 1000 Basis Points
• TNS Block Fee (20 tor block): ~1 $RUNE/year

Streaming Swaps

Streaming swaps allows users to stream their swaps, gaining a better price execution.

A streaming swap specifies two parts:

• “m” interval
• “n” count

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.

Streaming Savers

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.

Streaming Loans

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.

Users

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:

• Buy any THORChain-supported assets, such as $BUSD, $BTC, $ETH… and then swap them for $RUNE
• Buy native $RUNE on a centralized exchange that offers it
• Buy $RUNE on a centralized exchange and upgrade it to Native $Rune

Once the user buys $RUNE, it must be sent to their custody wallet.

Liquidity providers

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. 

• Liquidity providers can add liquidity to any of the active or pending pools
• To deposit/withdraw liquidity, users need a compatible wallet with their assets connected to one of the user interfaces. 
• There is no minimum deposit amount
  • The deposit will have to cover a later withdrawal fee
• The assets provided as liquidity are managed in a non-custodial manner and do not require KYC or extra permissions
• Only the original depositor can withdraw their own deposits
• Every time liquidity is added, the Impermanent Loss Protection resets
• Liquidity providers can withdraw at any time and there is no cooldown period aside from the confirmation time.
  • The network will process the request and the LP will receive the corresponding percentage ownership of the assets from the pool. 
  • An outbound fee is applied.

While symmetrical liquidity provisioning is recommended, it is also possible to supply asymmetrical liquidity according to the below rules:

• If you add symmetrically first:
  • You will be able to asymmetrically add $RUNE later
  • You will be able to asymmetrically add a non-$RUNE asset later (but it would create a new LP position)
  • You will be able to add symmetrically later
• If you add asymmetrically with a non-$RUNE asset first:
  • You will be able to add asymmetrically with $RUNE later (but it would create a new LP position)
  • You will be able to add asymmetrically with a non-$RUNE asset later
  • You will be able to add symmetrically later (but it would create a new LP position)
• If you add asymmetrically with $RUNE first:
  • You will be able to add asymmetrically with $RUNE later
  • You will be able to add asymmetrically with a non-$RUNE asset later (but it would create a new LP position)
  • You will not be able to add symmetrically later.

Investing Strategies

• Passive liquidity providers should seek out pools with deep liquidity to minimize risk and maximize returns.

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

 

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:

• The proportion of the transaction volume to the pool depth 
  • If there is high volume compared to the depth of the pool, then there will be higher rewards for LPs.
  • If there is low volume compared to the depth of the pool, then there will be lower rewards for LPs.
• Share of the pool
  • If the LP share is large compared to the total deposited assets in the pool, the returns will be higher.
  • If the LP share is small compared to the total deposited assets in the pool, the returns will be lower.
• Fee size
  • Fees are determined by the underlying blockchain.
  • The rewards are proportional to the fees being charged.
  • A chain with higher fees will generate higher rewards for LPs.
• Incentive Pendulum
  • The incentive Pendulum balances the amount of capital bonded in the network versus the amount of capital that is pooled. 
  • Sometimes rewards will be higher for LPs (incentivizing them to deposit assets in liquidity pools) and sometimes it will be the opposite.
• Changes in asset prices
  • If the price of assets changes, the LPs will receive more of one and less of the other.

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.

• If the block contains swap transactions then the amount of fees collected per pool sets the amount of rewards
• If the block does not contain any traders, then the amount of assets in the pool determines the rewards

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’

• Yield comes from fees paid by swappers and traders

• Rewards come from THORChain’s own reward emissions

• Rewards also come from the token reserve, which is filled up from network fees:
  • Part of the token reserve is paid to LPs over the long-term

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:

• Swap fees
• Block rewards
• Increases in the synthetic asset liability of a pool decrease the LUVI
• Increases in the asset or RUNE depth of a pool increase the LUVI
• Changes in the ratio of the asset or RUNE depth also change the LUVI
• Changes in the price of the asset or RUNE of a pool do not necessarily change the LUVI

Swappers

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:

• A large variety of assets through cross-chain compatibility and simple asset listings
• A superior user experience through transparent and permissionless access
• 1-transaction access to externally supported chains such as Bitcoin, Ethereum, Binance Smart Chain, Monero…

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

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

• If the price is lower on THORChain, they will buy the asset there and sell it on an external market
• If the price is lower on an external market, they will buy the asset there and sell it on THORChain.

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

• If both markets are infinitely deep, then the following will occur:
  • Buy on the external market for $1 with no price slip
  • Sell on THORChain for $1.2 with no price slip
  • Total profit: 20%

Finite but uneven liquidity

• If both markets have finite liquidity but one is much deeper than the other, then one of the markets will cause a lot of price slip compared to the other. For example, assuming deeper liquidity on the external market
  • Buy on the external market for $1, with no price slip
  • Sell on THORChain for $1.20 but only realize a price of $1.10 due to a price slip
  • Total profit: 10%

Low liquidity

• If both markets have low liquidity, then the trader’s attempts would experience price slip in both markets
  • Buy on the external market for $1 but get a realized price of $1.05 and price slip to $1.10
  • Sell on THORChain for $1.2 at a realized price of $1.15 and price slip to $1.1
  • Total profit > 10%

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.

Node operators

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

For Investors

Revenue Streams

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.

• Liquidity fees from the slip-based fee that swappers pay whenever they make a trade. This fee is based on how much a given swap causes the price of an asset to move.
  • Liquidity fees are given as rewards to liquidity providers and nodes
• Block rewards are paid whenever a block is successfully added to the ledger. They are paid to network nodes for taking part in consensus

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.

Economics

Fee Breakdown

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. 

• The Node pays a gas price that is 1 times the gas costs
• The pool is subsidized a value that is twice the observed value
  • The pool earns a margin of 1x
  • The Reserve earns a margin of 1x

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

• Value capture
  • Fees that capture value from those accessing a resource in the network (charge to those providing the service).
  • Liquidity fees are relative to the size of the transaction’s demand over the depth of the underlying pool.
  • E.g. a small transaction in a deep liquidity pool has less demand for liquidity than a larger transaction in a small pool.
• Access control
  • This is a way to throttle demand for a fixed resource and let market forces naturally take over the supply and demand.
  • If there is too much demand for a resource, fees increase.
  • The resource in this case is liquidity, not market depth. Because of that, fees are proportional to liquidity.
• Resource subsidization
  • Every swap on THORChain consumes resources from validator nodes (CPU, disk, network, memory…). These costs are fixed in nature
  • Other costs include outbound transaction demand on connected chains, such as paying the Bitcoin mining fee or Ethereum gas costs
  • THORChain charges a single flat fee on every transaction to pay for both internal and external resources
  • As a layer-1 blockchain, THORChain continuously consumes gas for outgoing and internal transactions. Gas on networks like Bitcoin or Ethereum, however, becomes complicated. Because of that, THORChain does not keep track of the amount of gas being consumed. Instead, nodes are free to use at-will the base assets like $BNB, $BTC, $ETH… in order to pay for gas. These assets are used directly in the vaults. THORChain then observes the 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). After fees are charged and the gas subsidized, then THORChain computes the block reward, divides it based on the Incentive Pendulum Algorithm, and then pays out to Bonders and Liquidity Providers. 

Advantages of this fee distribution:

• Avoid dust attacks
• Store up income after the initial Emission Schedule reduces its emission rate
• Gives the user a stable and predictable fee rather than a dynamic one which changes with the external network’s fees.

There is a one-time registration fee of ~10 $RUNE with a 20 tor block fee for THORNames:

• TNS Registration Fee: 10 $RUNE
• TNS Fee Sale: 1000 Basis Points
• TNS Block Fee (20 tor block): ~1 $RUNE/year

Operating Expenses

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. 

• Nodes spend money to run network software and need technical expertise. The graph below shows the potential margins over a 36 months period based on the assumptions that:
  • The network goes from 12 to 99 active nodes.
  • There is a monthly increase of 5% in the value of $RUNE.
  • There is a monthly increase of 2% in the cost of running a node.

Given these assumptions, the Node operator can expect a margin of 30% years after 3 years of operating in the network

• Compared to Node Operators, Liquidity Providers have minimal costs, although they must bear with Impermanent Loss during the first 100 days after a liquidity deposit. 

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.

• Since security is not free, liquidity providers must pay for the security of their assets. 
  • This payment is the requirement for LPs to hold $RUNE, which acts as a redeemable insurance policy whilst they are in the pool
  • Holding $RUNE allows LPs to retain an ability to economically leverage nodes to ensure their assets are secure
• The only direct cost to liquidity providers is the network fee, which is charged when assets are withdrawn
  • This allows node operators to pay for compute resources and transaction costs
• An indirect cost to liquidity providers is impermanent loss, although this is minimized with THORChain’s slip-based fee

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:

• Outbound Fee
• Price Slippage

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

Tokens

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:

• Liquidity as a settlement asset. 
  • $RUNE is the asset required at a 1:1 ratio for all pools in the protocol. For example, a pool with $100,000 in BTC requires $100,000 in $RUNE
  • By imposing pools split 50:50 of $RUNE with external assets, the system is always aware of the value of the assets being secured by the network, which will be inferred from the quantity of $RUNE in all of its pools.
  • As a rule of thumb, for every $1M of multi-chain assets pooled into the liquidity pools $1M of $RUNE is required to be deposited alongside.  Because of the Incentive Pendulum that powers the network, this also means that $2M in $RUNE are bonded. Therefore, $1 in external assets will cause the total required value in $RUNE to be $3M. This is the reason why liquidity pools have a positive effect on the monetary policy of $RUNE.
  • $RUNE is also the reward being paid as an incentive for liquidity providers. 
• Security and sybil-resistant mechanism designs that guarantee a game-theory optimal economic behavior
  • By bonding $RUNE, node operators are economically incentivized to work in the network’s best interest
  • THORChain is a proof of bond network where THORNodes commit a bond in order to be allowed to participate in the network. Nodes identified in the network not only gain access to voting power but they are also required to follow the logic of the bonding mechanism. This means that if a node attempts to steal assets, then their bond will be deducted from the amount of assets being stolen to make the pools whole. This results in a 1.5X slash for malicious nodes.
  • Nodes are incentivized to keep re-bonding due to the Incentive Pendulum. This is what allows them to maximize their gains while keeping the network safe. The bond is extremely liquid, which means that nodes can enter or exit their positions at any given time without impacting the network
• Governance (via on-chain signaling)
  • Users can vote with their symmetric liquidity ($RUNE:ASSET) for the pools they want to be active and gain more liquidity depth
• Incentives such as rewards payoffs, fee charges, and gas subsidies…) 
  • Block rewards are paid to both Liquidity Providers and Node Operators on $RUNE according to a set emission schedule

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:

• A deterministic value based on the liquidity within the network.
• A speculative market premium.

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:

• 5% for Seed Investment
• 16% for IDO to bootstrap the network
• 10% allocated to a group of developers involved with the project since 2018
• 24% of users who participated in the early stages of protocol operations
• 44% of tokens have been placed in the Protocol Reserve to pay out Nodes and LPs for the next 10 years.

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.

• Block rewards
  • The emission curve is designed to start at around 30% APR and target 2% after 10 years, where the majority of the revenue will come from fees.
• System income
  • This includes transfer and outbound fees on top of other sources of revenue such as THORName fees and excess liquidation fees on collateral.

Governance

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:

• Application logic
• Schema and store of key values
• Network software – keeps the TSS protocol signing and key generations processes secure

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:

• Which assets are listed/delisted
• Which chains are listed/delisted
• When the protocol is upgraded
• The economic limit – how many nodes can participate in the network at a maximum
• Mimir. Mimir is a feature that allows changing constants in the chain, such as the minimum bond, the churn speed… There are two types of Mimir:
  • Node Mimir: set by each node.
  • Admin Mimir: set by admins to override constants and set parameters.

Risks

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.

• Risk to bond. To run a node the operator must obtain a significant amount of $RUNE that must be sent to the network as a bond that will be held as leverage on each node. This ensures that the node will behave in the best interest of the network. Attempts to steal from the network will result in being slashed:
  • If a validator node is observed double signing (committing blocks on multiple chains), the node will be slashed with a minimum of 5% of its bond.
  • If a validator signs an unauthorized transaction, the bond is slashed 1.5x of the stolen funds.
• Risk to income
  • Not observing transactions for all connected chains results in a slash of 2 slash points
  • Not signing a transaction is punished with 600 slash points
  • Failure to generate a key results in a punishment of the revenue earned in 1 hour. This happens when the network attempts to create a new Asgard public key and fails to do so due to a specific node failure.

To compensate for the risks, node operators are compensated for their service with:

• Bond rewards are paid out in $RUNE. The funds are only collected when the node churns out of the network. Each operator makes the same amount of income, regardless of how much they bonded to the network. 

• The income for a node can be based on the following inputs:
  • Number of active nodes
  • Reward emission rate
  • % rewards allocated to nodes (set by the Incentive Pendulum)
  • Price of $RUNE

Security

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.

• Conformation counting  protects against double-spend attacks and non-instant block reorgs

• Outbound transaction throttling prevents large amounts of funds from leaving the network in an instant. This is achieved by assigning a limit outbound value to every block (currently 1,000 $RUNE) and a maximum time limit for block processing. This is controlled by several Mimir values that can be changed by Node Operators as required/
  • Large outbounds are spread across multiple blocks, up to 720 blocks (approximately 1 hour)
  • One large outbound request of $1M is handled as 1 million $1 outbound requests
• Granular halting controls via Node Mimir:
  • Halt Signing Outbound queue
  • Halt LP add/remove stopped, swapping allowed
  • Halt trading – No trading allowed
  • Halt Chain – nodes stop observing the chain
• Automatic Solvency checker catches issues earlier and prevents them from executing. There are 2 types:
  • Reactive – the network compares the assets it believes it has in its primary vault (Asgard Vault) to the assets that are actually stored in the network’s chain wallets. For every connected chain, each node compares the stored Asgard Vault value to each chain Asgard Wallet amount. If the Asgard Vault value is more than the Wallet value by 1%, the node reports insolvency for that chain
  • Proactive – the node attempts a calculation to catch insolvencies before they appear. The node calculates the value before the transaction outside of the network is executed.
• Automatic trading halting when more than 66% of nodes report insolvency with a chain

• Node operator triggered halts. Node operators have the ability to halt trading if they detect malicious activity. This is in addition to the automatic chain-specific halting functionality. A single node can pause trading for up to an hour. Any additional node that calls for the resumption of trading removes 720 blocks from the timer. The halting function can only be activated by the same node operator after 3 days.

• Unauthorized Transaction Detection will automatically pay THORChain on a specific chain and stop the Yggdrasil vault funding if an unauthorized transaction is detected. This will emit a security event that will be sent to THORSec. The halt will allow Node Operators, THORSec, and the development team to investigate and react immediately following an unauthorized transaction and issue a fix to restore service
• Automatic Security Flagging of emitted events when certain conditions are met such as node slashing, unauthorized transactions, large withdrawals, attempts to double spend… These emitted on-chain events can also be seen on Midgard

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:

• Review and approve THORChain’s open-source Pull Request
• Provide 24/7 protocol health monitoring
• Incident response services
• Creating run books and procedures for network updates, chain additions, and hard forks
• Monitoring for vulnerabilities on connected chains, upgrades, or hard forks that could impact the network 

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.

Audits

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:

• Description of the bug
• Steps to reproduce
• Whether funds are at risk or not

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:

• ETH parsing error exploit
• ETH router upgrade error
• Halborn Security Incident Analysis

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

Economic Attack Vectors

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.

Dependencies and Access Controls

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:

• Act as the LP of last resort for all pools (since its liquidity will never be removed).
• Provide a capital buffer to protect against the risk of Impermanent Loss.
• Continuously buy up liquidity for the protocol, effectively deepening the liquidity pools and improving the overall user experience.
• Form a liquidity “black hole” that has no theoretical upper bound, since it accumulates assets and never goes down in value.

Liquidity Risk

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

• The coverage will reset every time the user deposits liquidity to the same pool.
• Withdrawal fees affect the withdrawal amount.
• Partial withdrawals do not reset the Impermanent Loss Protection counter.

Project Investors

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.

Additional Information

Partnerships

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.

FAQ

• What does “provide liquidity” mean?
  • Providing liquidity on THORChain consists of depositing an external asset paired with $RUNE at a 50:50 ratio inside a liquidity pool in a decentralized exchange. The assets will be used by traders and swappers to go from one asset to another. As an exchange for providing this service, liquidity providers earn a return or yield on their assets. 
• Does THORChain rely on external sources for price feeds, like price oracles?
  • No, THORChain relies on its own continuous liquidity pool design to allow arbitrageurs to reflect the fair market price of the assets on the network. When pools become imbalanced, arbitrage bots intervene to rebalance their ratios. The network knows the adequate exchange rate between the assets by pairing $RUNE with external tokens and binding all pools together. 
• What are the best places to buy $RUNE?
  • It is recommended to only buy Native $RUNE. 
  • There is no BEP-20 $RUNE
  • You can only buy Native $RUNE, BEP-2 $RUNE, or ERC-20 $RUNE from the market
  • Support for BEP-2 $RUNE and ERC-20 $RUNE will be deprecated
  • Only Native $RUNE is used in THORChain.
• I bought BNB.RUNE (or ETH.RUNE) and put them in my Keystore wallet, why can’t I upgrade them to THOR.RUNE?
  • To upgrade to THOR.RUNE, you will need a small amount of BNB (or ETH) to cover the upgrade transaction.
• What assets can be swapped in THORChain?
  • The currently integrated chains are Cosmos, Bitcoin, Ethereum, Binance Smart Chain, Bitcoin Cash, Litecoin, and Avalanche.
  • Full list of assets: https://viewblock.io/thorchain/pools or https://thorchain.net/#/pools 
• Can users stake $RUNE?
  • Not quite. “Providing liquidity” on THORChain is not exactly the equivalent of “staking”. Even if the user is providing one single asset, this is known as asymmetric liquidity which will be separated into two parts at a 50/50 ratio: one external asset and $RUNE.
• Is there a lockup period for liquidity providers?
  • There is no minimum/maximum amount and the liquidity is allowed to enter/exit at any time. However, there is a required confirmation time before the liquidity is credited when adding or swapping. This prevents block reorgs and the waiting time is based on:
    • Total assets amount
    • Per block reward of the chain
    • Block time required confirmations, which at the same time depend on the total asset amount divided by the external chain’s block reward. That is then multiplied by the block time to get the approximate waiting time.
  • https://docs.thorchain.org/chain-clients/overview#confirmation-counting 
• Is there an impermanent loss for liquidity providers on THORChain?
  • Yes, liquidity providers on THORChain suffer impermanent loss. However, they will receive 100% Impermanent Loss Protection for every 100 days the liquidity remains in the pool. This means that for every day, a 1% Impermanent Loss Protection is being paid to the liquidity provider to offset the losses from Impermanent Loss.
• Are there withdrawal fees?
  • Yes, there is a fee for both symmetrical and asymmetrical withdrawals
• If I provided asymmetric liquidity, why did I receive less than anticipated?
• When users provide asymmetric liquidity, the asset is then swapped into 50% $RUNE and 50% the given asset. When this happens, the original deposit is subject to both slippage and fees:
  • On-chain deposit transaction fee
  • Liquidity fee as a function of slip
  • Outbound withdrawal transaction fee
• Can I withdraw another asset after an asymmetric deposit?
  • No, if you deposit asymmetrically you can only withdraw asymmetrically.
• Can I withdraw a symmetrical deposit?
  • Symmetrical deposits can be withdrawn in both symmetric and asymmetric ways.
• Are asymmetric deposits covered by Impermanent Loss Protection?
  • Yes, but the Impermanent Loss Protection is only applied to the asymmetrical deposit after it has been converted into a symmetrical deposit, such that the Impermanent Loss Protection can cover both assets.
• How much $RUNE do I need to run a THORNode?
  • The minimum requirement is 300k $RUNE plus a bond requirement at the average bond price, which can be seen at: https://thorchain.net/#/nodes 
  • When the protocol is fully mature, THORChain is expected to have a minimum bond requirement of 1M $RUNE.
• Why does $RUNE need to be the settlement asset in every pool?
  • This is a requirement to solve a scaling problem. If the protocol allowed pools like BTC/ETH, then there would be a scaling problem, since there would be a requirement to stable n*(n-1)/2 connections for swapping from one asset to another
  • By using $RUNE as the base asset, it also becomes the settlement bridging asset that allows swapping between any two other assets
  • Having $RUNE in a pool ensures that the network is aware at all times of the total value of the assets it is currently holding.
• Has the introduction of Saver Vaults decreased the demand for $RUNE?
  • No. Saver Vaults are only offered for gas assets of external chains (BTC, ETH, BNB, BCH, LTC, ATOM, AVAX, LTC). Even if in the future non-gas assets are introduced saver vault will only represent the minting of the equivalent synths assets that are split 50:50 into an LP position paired with $RUNE
• Do Saver Vaults negate the 3x non-$RUNE deterministic TVL pricing?
  • No. The additional dynamics only increase the amount of Protocol Owned Liquidity. However, this could mean that the target Incentive Pendulum of 2 bonded $RUNE per 1 pooled $RUNE may not be the equilibrium point anymore. Nonetheless, the hard cap will still ensure minimum deterministic pricing of 2x non-$RUNE TVL
• How do Saver Vaults benefit THORChain?
  • Saver Vaults deepen the liquidity of liquidity pools, which reduces slippage for traders and is prone to increasing trading volume. Increases in trading activity also lead to more fees being collected. This leads to more users depositing in Saver Vaults to earn yield.
• In Thorfi, if the value of the collateral increases and becomes higher than the initially deposited amount, is there a way to withdraw that original collateral without repaying the loan, since the collateral asset is now more valuable?
  • The term for this is called loan refresh. For example, with an original deposit of $10,000 worth of BTC as collateral and a partial repayment of $5,000, if the price of BTC increases to, for example, $20,000, then the user gets $20,000 worth of BTC, even if the original collateral amount was $10,000. This means that the user can take the same amount of $BTC and refresh their loan such that they can now have access to a higher amount of debt
• When it comes to borrowing on ThorFi, what happens if a stablecoin goes down for any reason? How would that affect the existing loans?
  • There would be no side effects as a result of that de-pegging event. Even if the stable drops to 0, the price of THOR would remain unchanged because it is not taking an average price. Instead, it is taking the median. In order to manipulate the price of THOR, the attacker would have to manipulate the price of the majority of stablecoins in the industry. Because THOR’s price operates from a median of all the states, that means that the price of THOR will be more stable to the dollar than any other stablecoin in the industry.
• What happens if the value of a loan in ThorFi gets bigger than the collateral?
  • ThroFi is innovating in this field and doing something different than most other protocols. As a result, nothing happens. At the moment of getting the loan, the protocol will have already burned the loan amount worth of $RUNE, which means that the loan value is already sold and collected at the moment when the loan was opened. Therefore, the best-case scenario from the protocol’s perspective is that users never pay back their loans.

Community Links

• Website: https://thorchain.org/ 
• App: https://thorchain.net/pools/savers 
• Docs: http://docs.thorchain.org/
• Medium: https://medium.com/thorchain 
• Whitepapers: https://github.com/thorchain/Resources/tree/master/Whitepapers 
• Github: https://github.com/thorchain 
• Gitlab: https://gitlab.com/thorchain 
• Twitter: https://twitter.com/THORChain
• Developer Discord: https://discord.gg/KjPVnGy5jR 
• The Runebase Podcast: https://open.spotify.com/show/0A2gwzO7VnFPAgpaSyMq2O 
• Reddit: https://www.reddit.com/r/THORChain/
• Research Labs: https://thorchain.org/research-labs 

Desktop interfaces: 

• Thorswap Earn: https://app.thorswap.finance/earn 
• Savers Vaults Analytics: https://thorchain.net/pools/savers 
• ThorWallet Web App: https://app.thorwallet.org/ 
• DeFispot: swap, manage liquidity, track yield: https://www.defispot.com/trade 
• Rango Exchange: http://app.rango.exchange/ 
• xDeFi swap: http://app.xdefi.io/ 
• Lends: https://app.lendscape.so/ 
• Decentralfi: https://decentralfi.io/ 
• AsgardEx Desktop App: https://github.com/thorchain/asgardex-electron/releases 

Mobile interfaces:

• Thorwallet: https://thorwallet.app.link/4MoUX7GFzmb
• Edge wallet: https://deep.edge.app/promotion/thorchain  
• Ferz Wallet: http://i.ferz.com/ 

Native Rune Wallets:

• xDEFI wallet: https://www.xdefi.io/ 
• Thor wallet: https://thorwallet.app.link/4MoUX7GFzmb 
• Trust wallet: https://trustwallet.com/ 
• Ferz wallet: http://ferz.com/ 
• Liquality: https://liquality.io/ 
• Ledger: https://support.ledger.com/hc/en-us/articles/4402987997841-THORChain-RUNE-?docs=true 

Community media:

• RUNEBase – News and podcast: http://runebase.org/ 
• Grassroots Crypto – Tutorials and guides: https://www.youtube.com/grassrootscrypto 
• Nine Realms Youtube: https://www.youtube.com/channel/UCbFpanHLe5ZdTE96C_8YC7w 
• Thorswap Youtube: http://youtube.com/c/THORSwapCommunity?sub_confirmation=1 
• Thorguards NFT: https://opensea.io/collection/thorguards 
• Thor Force 1 sneaker NFT: http://vanirthreads.com/ 
• Thorchain collectibles: https://opensea.io/collection/thorchain-collectibles 

Dashboard and Analytics:

• Thorchain alerts – Telegram: http://t.me/thorchain_alerts 
• ThorYield LP position tracker: http://thoryield.com/ 
• Thorchain explorer: http://thorchain.net/ 
• Thorchian calendar bot: https://twitter.com/THORCalendarBot 
• Pulsar Finance LP position tracker: https://app.pulsar.finance/ 
• DeFiYield LP analytics: https://defiyield.app/ 
• Flipside Crypto: https://thorchain.vision/bounty 
• Rune valuation breakdown: https://datastudio.google.com/u/0/reporting/f84004fc-8ca9-4d91-a7d5-1a6abca018a6/page/1M 
• Scheduled outbound transactions tracker: https://app.thoryield.com/tx_tracker 
• Thornode network monitor: http://thornode.network/ 
• Viewblock.io – block explorer: https://viewblock.io/thorchain 

Communities and support:

• Community telegram: http://t.me/thorchain_org 
• LP University: http://discord.gg/lpuniversity 
• Thorswap Discord: https://discord.gg/thorswap
• XDEFI discord: http://discord.gg/xdefiwallet 
• Defispot discord: https://discord.gg/defispot 
• Thorwallet discord: https://discord.gg/NkkyVayNy6 
• ThorChads DAO discord: http://discord.gg/thorchads 
• Thorchain developer discord: https://discord.gg/qrnnXqnWYt

Community Chain Chats:

• Arbitrum
• IBC Chains
• Avalanche
• Matic
• Binance Smart Chain
• Monero
• Dash
• Rootstock Sovryn
• Decred
• Solana
• DogeChaiin
• Polk
• adot
• Firo
• Zcash
• Haven
• Zilliqa

Guides and info:

• RUNE tokenomics: https://medium.com/thorchain/thorchain-tokenomics-what-is-rune-52d339633260 
• Into to thorchain for bitcoiners: https://erikvoorhees.medium.com/an-introduction-to-thorchain-for-bitcoiners-3f621bf0028e 
• Thorchain layers of security: https://medium.com/thorchain/thorchains-layers-of-security-e308d537acf1 
• Beginner introduction to Thorchain: https://asian0xv.medium.com/a-beginner-introduction-to-thorchain-%EF%B8%8F-e634a0d3234a 
• Impermanent loss protection: https://crypto-university.medium.com/impermanent-loss-and-impermanent-loss-protection-a4a0f78d1701 
• Upgrade BEP-2 or ERC-20 RUNE to Native: https://youtu.be/pRw1zDzTgY4 
• How to earn yield on RUNE: https://www.youtube.com/watch?v=AIWzJvr4nDA 
• Synthetic Assets Tutorial and guides: https://twitter.com/THORChain/status/1501696488816185344 
• Project funding: https://thorchain.org/ecosystem/project-funding 
• Data Analyst tools: https://thorchain.org/ecosystem/data-analyst-tools 
• Liquidity Providers tools: https://thorchain.org/ecosystem/liquidity-provider-tools 
• Insurance: https://thorchain.org/ecosystem/insurance 
• DAOs: https://thorchain.org/ecosystem/daos 
• Network explorers: https://thorchain.org/ecosystem/network-explorers 
• NFT collections: https://thorchain.org/ecosystem/nft-collections 
• Name Services: https://thorchain.org/ecosystem/thornames 
• Software/Hardware wallets: https://thorchain.org/ecosystem/wallets 
• Swap/Pool interfaces: https://thorchain.org/ecosystem/interfaces 

Regional socials:

• Russian: https://t.me/ThorchainRussian
• Chinese: https://t.me/thorchain_chinese
• Italian: https://t.me/+2h7NgzNJ4KIxNzFk
• Portuguese: https://t.me/thorchainportuguese
• France: https://t.me/THORChainFr
• Spanish: http://t.me/THORChain_es
• Dutch: https://t.me/nl_be_thorchain_rune
• German: https://t.me/ThorChainGermany
• Vietnamese: https://t.me/Thorchain_Rune_Vietnam
• Indian: https://t.me/thorchainIndia