1 of 77

THORChain Docs

Introduction

A high-level overview of what THORChain is, does, encourages, and pursues.

New to THORChain? Check out for an easy-to-understand introduction.

Introduction

What is THORChain and RUNE?

THORChain is a Layer-1 blockchain that enables different cryptocurrencies to work together. It acts as a decentralized exchange (DEX) that allows you to swap coins across different blockchains in a single step.

Every swap on THORChain happens directly from your wallet in a safe and permissionless way. THORChain doesn't hold your funds—though it does retain your inbound asset briefly during the swap before immediately sending you the output asset. You never give up custody to a centralized entity.

Unlike centralized exchanges:

You don't need an account
There is no KYC or paperwork
You don't have to trust a company to hold your funds

Example: If you own Bitcoin and want Ethereum, you just send Bitcoin from your wallet and receive Ethereum back in a single transaction, osmos Hub (ATOM)no exchange accounts, no middlemen.

Supported Blockchains

THORChain enables native swaps between the following major blockchains:

Bitcoin (BTC)
Ethereum (ETH)
Ripple (XRP)
BNB Smart Chain (BNB)

THORChain will continue to evolve and add more chains over time, so users will be able to swap even more popular cryptocurrencies—all without wrapped tokens or intermediaries.

THORChain is a full blockchain (like Ethereum or Solana). This means that, in addition to swapping, developers can build smart contracts and decentralized apps (dApps) on top of it. This makes THORChain not only a trading tool but also a foundation for the next generation of DeFi projects.

What is RUNE?

RUNE is the native utility token of THORChain that serves four critical functions:

1. Settlement Asset

All transactions and swaps in the network are settled in RUNE
RUNE acts as the bridge connecting all supported blockchains

2. Network Security (Bonding)

Validators must bond RUNE to participate in consensus
More bonded RUNE makes the network harder to attack
Running a node allows earning a share of THORChain's revenue

3. Liquidity

RUNE is present in every liquidity pool (BTC–RUNE, ETH–RUNE, etc.)
This ensures unified pricing and constant demand for RUNE

4. Governance and Incentives

Validators and liquidity providers earn rewards in RUNE
These rewards come from real network fees, not token inflation
RUNE holders participate in network governance through validator delegation

Next Steps

Now that you understand what THORChain and RUNE are, explore how it works:

- Learn how THORChain enables direct swaps between different blockchains
- Step-by-step guide to start swapping
- Deep dive into RUNE's economics and revenue model

Native Cross-chain Swaps

How THORChain enables decentralized swaps between native L1 assets without wrapping or centralized intermediaries

THORChain is a decentralized protocol that enables cryptocurrencies to be swapped across different blockchains natively – without using wrapped tokens and without relying on centralized exchanges. This means you can directly exchange one Layer-1 coin (e.g., Bitcoin) for another (e.g., Ethereum) in a single, seamless transaction. The entire process happens without intermediaries – you don’t need to trust any company or institution.

How Swaps Work in THORChain

Liquidity Pools and RUNE

Every cryptocurrency supported by THORChain is paired with RUNE in liquidity pools. RUNE acts as a hub that connects all pools into one continuous network. When you swap one coin for another, two steps happen under the hood: your coin is first swapped into RUNE, and then RUNE is swapped into the target coin. For the user, this appears as one simple swap – you don't need to hold or manage RUNE yourself.

Decentralized Vaults

Each blockchain has its own vault, operated collectively by THORChain's node network. Your funds are deposited there, and after the network confirms the transaction, they are released as the native coin on the destination chain. Thanks to threshold signatures (a type of multi-signature technology), no single node has full control over the funds.

Example: Swapping BTC to ETH

In your wallet, you choose the swap BTC → ETH and send, for example, 1 BTC to a THORChain vault address on the Bitcoin network.
The THORChain network detects the deposit and internally swaps BTC into RUNE in the BTC:RUNE pool.
RUNE is then immediately swapped into ETH in the RUNE:ETH pool.
The network releases the equivalent amount of native ETH directly to your Ethereum address.

Why THORChain is Different

In most cases, swapping assets across blockchains requires either a centralized exchange or cross-chain bridges with wrapped tokens like WBTC. Both approaches involve trusting a third party or custodian that holds your funds. THORChain eliminates these issues:

You swap real coins (e.g., BTC, ETH, LTC), not synthetic versions
You never hand over custody of your funds to a company
The process is secured by a decentralized network of nodes, each required to bond large amounts of RUNE, incentivizing honest behavior

As a result, THORChain enables true cross-chain swaps: you can easily exchange native BTC for native ETH (and vice versa) in a fully decentralized, secure, and trustless way - with no intermediaries.

How to Use THORChain

A practical walkthrough of connecting a wallet, selecting assets, executing swaps, and accessing supported networks

Create a wallet on your preferred interface (e.g., Vultisig, Keystore, Ledger, etc.).
Go to the page to find a wallet provider.
Go to
Connect your wallet

Application Layer

Overview of the ecosystem of apps, wallets, and interfaces built on top of THORChain

Introduction

The App Layer transforms THORChain from being just a cross-chain liquidity protocol into a full ecosystem of financial applications. It provides an environment for developers to build and deploy decentralized applications (dApps) and financial services, leveraging the security and liquidity of the THORChain base layer.

The THORChain Base Layer serves as the foundation – it is responsible for:

Secure storage and transfer of value
Native asset swaps across different blockchains (e.g. BTC ↔ ETH)
Maintaining consensus and network security

The App Layer extends these capabilities by giving developers tools to:

Write and deploy smart contracts (powered by CosmWasm)
Build applications that directly use the liquidity and functions of the base layer
Create advanced financial products such as orderbook exchanges, lending protocols, perpetual trading systems, launchpads, or liquidation platforms

In practice, the App Layer works like a "construction site" on top of the THORChain foundation: instead of just simple swaps, it enables the creation of an entire DeFi ecosystem that leverages the security and cross-chain capabilities of the base layer.

Base Layer (THORChain)

Manages liquidity pools
Enables cross-chain swaps (BTC ↔ ETH ↔ ATOM, etc.)
Provides security and validation

Application Layer (App Layer = Rujira)

Built on THORChain, using its liquidity
Powered by CosmWasm smart contracts → apps can be written in Rust/WASM
Enables the creation of DeFi tools such as:
- Orderbook exchanges

Rujira Economics

The App Layer has its own economic model, centered around the RUJI token:

RUJI is the native token of the App Layer,
a portion of application fees is distributed to RUJI stakers,
revenues are shared between THORChain 50% and Rujira 50%.

Simple Analogy

THORChain (Base Layer) = highway → provides core infrastructure, traffic, and security. App Layer (Rujira) = gas stations, shops, and services along the highway → adds extra functionality and convenience.

The highway itself is essential, but it’s the services around it that make people want to use it. Similarly, Rujira expands THORChain’s appeal by enabling a full ecosystem of applications.

Liquidity

THORChain's slip-based fees, streaming swaps, and how arbitrage protects against MEV and sandwich attacks

Introduction

Most traditional exchanges (e.g., Binance or Coinbase) operate using an order book – buyers and sellers place their offers, and the system matches them. THORChain works differently: instead of an order book, it uses Continuous Liquidity Pools (CLP).

What does this mean in practice?

Each token pair (e.g., BTC-RUNE) has a shared capital pool
Users can swap one token for another at any time at a price determined by the ratio of assets in the pool
This ensures that liquidity is always available, and swaps occur without intermediaries or centralized price oracles
Pool prices are additionally "maintained" by arbitrageurs to keep them aligned with external markets

Slip-based Fees – liquidity-dependent fees

A slip-based fee is a transaction fee model tied to the size of a swap relative to pool depth. Simply put: the larger the transaction relative to available liquidity, the higher the slip (price impact within the pool during the swap), and therefore the higher the fee paid to liquidity providers.

This mechanism ensures that the fee corresponds to the demand for pool capital:

Large trades pay more
Small trades pay less

As a result:

The protocol penalizes impatient traders who execute large, sudden swaps
Liquidity providers are rewarded for making their capital available
Users who insist on forcing massive instant swaps cause high slip and pay significant fees to the pool

Meanwhile, smaller or gradual swaps create minimal slip, leading to lower fees – in extreme cases, with little demand, slip fees approach zero, allowing swaps to occur almost at market price without extra cost.

How does it work?

Every swap in THORChain changes the ratio of assets in the pool. The larger the swap relative to pool depth, the greater the price movement (slip). Slip generates a fee that goes directly to liquidity providers (LPs).

Small transactions – barely move the price → negligible slip → minimal fee
Large transactions – significantly move the price → high slip → high fee

Why is this important?

Protects against price manipulation – sudden large price moves cost attackers heavily
Forces traders to choose between:
- Speed (one large swap at once, with a high fee)
- Better price (many smaller swaps, slower, but cheaper)

Example 1: Small Swap

BTC-RUNE pool: 1,000 BTC and equivalent RUNE
User swaps 0.1 BTC → only 0.01% of the pool
Price barely changes, slip fee ≈ 0, symbolic fee

Example 2: Large Swap

Same pool
User swaps 100 BTC → 10% of the pool
Price in the pool drops significantly, slip fee amounts to several percent of trade value

Streaming Swaps – time-sliced swaps

Streaming Swaps is a THORChain mechanism that allows users to split a large swap into a series of smaller transactions (sub-swaps), executed sequentially at defined intervals.

This feature was introduced to help users optimize pricing – performing swaps with minimal slip – without manually breaking orders into smaller chunks.

Normally, a single large swap leads to high slip fees, while splitting it manually would mean paying multiple network fees (inbound/outbound fees for each part).

Streaming Swaps solve this by letting users control the swap's timeframe: one deposit internally creates many sub-swaps without additional L1 network fees beyond those of a single swap.

The Problem

When a user wants to swap a large amount (e.g., 1,000 ETH), a one-off swap causes:

Huge slip
Very high fees

Manually splitting into 100 smaller trades would require 100× network fees – uneconomical.

The Solution: Streaming Swaps

THORChain automatically splits a large swap into smaller sub-swaps executed one after another at set intervals. This works similarly to the TWAP (Time-Weighted Average Price) strategy.

Why is this better?

Slip on each part is minimal
Total slip fees can drop from several percent to ~0.1% (or whatever minimum slip set by the protocol)
User pays only one network fee, not per sub-swap
Arbitrageurs between sub-swaps rebalance the pool, improving execution prices for later parts

Example

Swap: 1,000 ETH → BTC.
Option A: one-off → slip fee ~5% (50 ETH cost).
Option B: Streaming Swap – 100 sub-swaps of 10 ETH each, every minute.
Slip per sub-swap ≈ 0.05%.

Arbitrage – balancing pool prices

Unlike many DeFi systems, THORChain does not rely on price oracles – instead, it depends on market forces. Pool prices are maintained by profit-seeking arbitrageurs.

Why is arbitrage needed?

THORChain pools derive prices solely from asset ratios. This can sometimes create gaps compared to external markets.

How arbitrage works

If a token in a pool is undervalued, an arbitrageur buys it from the pool and sells it on the external market for profit.
If a token in a pool is overvalued, an arbitrageur sells it into the pool and buys it cheaper externally.
Repeated arbitrage trades propagate price information between THORChain and external markets until equilibrium is reached. This removes the need for centralized oracles – arbitrage continuously adjusts pool prices.

Arbitrage Example

ETH-RUNE pool: 1 ETH = 100 RUNE.
On Binance: 1 ETH = 110 RUNE.
Arbitrageur buys ETH in the pool for 100 RUNE, sells it on Binance for 110 RUNE → profit 10 RUNE.
Pool price shifts upward.

Thanks to arbitrage, THORChain pool prices always reflect real market values.

Protection against MEV and sandwich attacks

THORChain is designed with built-in protection against common DEX vulnerabilities such as MEV (Maximal Extractable Value) – the manipulation of transaction ordering within blocks by privileged actors (validators or bots) to extract profit.

Examples of MEV attacks include:

Front-running – inserting one's own trade right before a victim's large transaction to profit from price movement.
Sandwich attack – placing two trades around a victim's swap (one before, one after) to profit from the induced price change.

THORChain solutions

Swap Queue – transactions are finalized and sorted deterministically by impact on price (slip fee).
- Large swaps are executed before small ones.
- A bot cannot front-run a large trader with a symbolic transaction.
Slip-based fee – attempting to front-run requires a large transaction, which itself incurs massive slip fees, destroying profitability.

MEV Protection Example

A user submits a large ETH → BTC swap.
A bot tries to front-run with a small trade.
THORChain sorts swaps by slip fee: large swap goes first.
The bot is executed after and gains nothing.

MEV attacks on THORChain are unprofitable or outright impossible.

Network Security and Governance

Introduction

THORChain is a cross-chain protocol that enables the exchange of assets across different blockchains, with RUNE as its native token.

The network relies on several mechanisms to ensure security, decentralization, and economic balance: validator bonding, TSS (Threshold Signature Scheme), threshold-signed vaults, inbound and outbound vaults, node churn, the Mimir governance system, and the Incentive Pendulum.

Validator Bonding

Staking as collateral: Each validator (node) must lock a significant amount of RUNE (currently over 300,000 RUNE) as a bond in order to become an active validator
Securing liquidity pools: Bonded RUNE secures the assets held in liquidity pools and acts as an economic deposit. If a validator attempts to steal funds, their bond is slashed - making dishonest behavior highly unprofitable
Economic target: The network aims to maintain a ratio where the total bonded RUNE is approximately twice the value of all non-RUNE assets in the liquidity pools. This makes attacks extremely costly and impractical

Note: Network paramaters can override this ratio and is controlled by the nodes. See the for more information.

TSS – Threshold Signature Scheme

Imagine a vault with multiple locks. Each validator has only one key. To open the vault and sign a transaction, several validators must agree - one key alone is not enough.

This is how TSS works in THORChain:

The private key is never stored in full on any single node
Each validator holds only a fragment of the key
Only when a sufficient threshold of validators combine their fragments can a transaction be signed

Benefits of TSS

Greater security - no single validator can steal funds
Lower costs and broader applicability than traditional multisig, since TSS operates at the cryptographic level rather than via application-layer smart contracts

Threshold-Signed Vaults

Multiple validator approvals: Funds in THORChain are stored in vaults controlled by a group of validators. To release funds, a supermajority (e.g., ⅔) of validators must sign the transaction
No single point of failure: Since no full private key exists, even if one validator is compromised, they cannot move funds alone. This eliminates single points of failure and significantly increases security

Node Churn

Cyclical validator rotation: THORChain regularly rotates its active nodes. Some validators leave, and new ones take their place
Resistance to capture: This rotation prevents the network from being dominated by a fixed group of validators, enhancing decentralization and protecting against censorship or collusion

Governance – The Mimir System

Validator voting: Governance in THORChain is managed through Mimir, where active validators vote on network parameters
Consensus requirements: Operational parameters require a small number of validator votes (typically 3+), while economic parameters require supermajority consensus (approximately 2/3 of validators)
Dynamic adaptation: This allows the protocol to make quick operational adjustments while ensuring economic changes have broad validator support

Incentive Pendulum

Balancing mechanism: The Incentive Pendulum is an economic system that balances rewards between validators and liquidity providers (LPs)
Automatic adjustment: The system monitors the ratio of bonded RUNE to pooled liquidity:
- If there is too much liquidity relative to security, the network becomes unsafe - so more rewards are directed to validators

Tokenomics of RUNE and TCY

RUNE's supply, utility, and fee distribution, plus TCY's role in sharing protocol revenue

RUNE is the native utility token of the THORChain ecosystem, and it sits at the core of how the network functions. Unlike many other crypto assets, RUNE has no vesting schedules or locked allocations – the full supply is already released, and thanks to its burn mechanism, the circulating amount decreases over time. This makes RUNE both the economic backbone and the primary incentive driver of THORChain.

RUNE Tokenomics

Total Supply: ~425M RUNE (reduced daily through the burn mechanism)
Circulating Supply: ~350M RUNE
Reserve: ~75M RUNE
Latest numbers:

All RUNE tokens have been released – there are no vesting schedules or locked allocations.

Main Functions of RUNE in THORChain

Settlement Asset

All transactions and swaps in the network are settled in RUNE.

Network Security (Bonding)

Validators (nodes) must bond RUNE to participate in consensus.
The more RUNE is bonded, the more economic security the network has.
Running a node allows you to earn a share of THORChain's revenue.
Delegating RUNE to nodes lets you participate in revenue distribution.

Liquidity

RUNE is present in every liquidity pool (e.g., BTC–RUNE, ETH–RUNE).
This ensures a unified pricing system and constant demand for RUNE.

Burn

A portion of fees collected by THORChain is burned.
This gradually reduces RUNE supply and gives it a deflationary character.

Incentives

Validators and liquidity providers earn rewards in RUNE.
These rewards come from network-generated fees, not from new token emissions.

Revenue in THORChain

One of THORChain's biggest advantages is that it generates real yield – 100% derived from network activity, not from token inflation.

The network processes thousands of cross-chain swaps and transfers daily, producing on average $50,000 - $100,000 per day in fees.

These fees are the foundation of real yield in the ecosystem.

🔗 Latest revenue data:

Revenue Distribution

The current fee distribution in THORChain is as follows:

5% → burned
5% → developer fund
5% → marketing
10% → TCY holders (explained below)

TCY Token

TCY was created to resolve THORChain's debt issue (~$210M after the ThorFi crisis).

Each $1 of debt was converted into 1 TCY. This way, creditors received tokens instead of a total loss, giving them the right to a share of the network's future revenue. This helps stabilize the ecosystem and align the community's interests with the protocol.

How to Get TCY

TCY can be claimed through the official interface:
A THORChain address is required to claim.
Claimed tokens are automatically staked and immediately start generating daily yield.
TCY can also be bought from the open market e.g. via swap.thorchain.org

TCY Supply

Total Supply: 210M
Circulating Supply: 176M

🔗 Latest numbers:

How does TCY work?

TCY holders receive 10% of all network revenue (paid in RUNE).
A RUNE/TCY liquidity pool was created, so the token can be freely traded.
Stakers retain their yield, while the yield from unclaimed or unstaked TCY is forfeited and redirected to grow protocol-owned reserves.
Fees from this pool are used to buy back TCY into the THORChain treasury.

Technical Documentation

Technical Deep Dive

Technical deep dive into THORChain's design and core mechanics

This section explains the core technical concepts behind THORChain. It is aimed at readers who want to go beyond the user-facing features and understand how the protocol is designed. Each topic links to a dedicated page with more detail.

Topics

Protocol Innovations

The main design choices that make THORChain unique, including validator selection, churning, upgrades, the Bifrost protocol, Incentive Pendulum, liquidity pools, and the swap queue.

How RUNE supply, the Incentive Pendulum, the emission schedule, and the Reserve work together to align incentives and secure the network.

THORChain’s multi-layered security approach, including bonded capital, validator rotation, solvency checks, and operational processes.

How THORChain handles minimal governance, including asset and chain listings, protocol upgrades, the Mimir system, and ADRs.

Overview of THORChain’s fee structures: swap fees, outbound fees, and network fees, and how they protect the network while rewarding participants.

The system for human-readable cross-chain addresses, simplifying transactions without needing long cryptographic strings.

– high-level explanation of how THORChain works
– running validator nodes and infrastructure details
– financial mechanisms and protocol products
– user-focused introductions

Protocol Innovations

The core innovations that make THORChain unique in cross-chain DeFi

THORChain was built with the principles of decentralisation, resistance to capture, and sustainability. It introduced several firsts in cross-chain DeFi that allow secure liquidity without wrapped tokens or trusted intermediaries.

Key Innovations

Capped Proof of Bond

Economic Model

THORChain's economic model including the Incentive Pendulum and emission schedule

THORChain’s economic model is designed to maintain network security, ensure liquidity efficiency, and sustain long-term protocol viability. It does this through a combination of the Incentive Pendulum, an emission schedule from the Reserve, and defined inflows and outflows.

Incentive Pendulum

The Incentive Pendulum automatically adjusts reward distribution between node operators and liquidity providers to maintain the correct balance between security and liquidity.

The system monitors the ratio of bonded RUNE (from node operators) to pooled assets:

THORChain Finance

THORChain Finance - A comprehensive overview of financial primitives and mechanisms within the THORChain ecosystem

THORChain Finance encompasses the core financial primitives that enable cross-chain liquidity and trading on the THORChain network. These mechanisms provide the foundation for decentralized finance (DeFi) operations while maintaining security and efficiency across multiple blockchain networks.

Core Financial Primitives

Secured Assets

Asset Type to Integrate into the App Layer

Secure Assets allow L1 tokens to be deposited to THORChain, creating a new native asset, which can be transferred between accounts and integrated with CosmWasm smart contracts using standard Cosmos SDK messages. They also replace .

See the for a more detailed description. Also see for generic Cosmos information. What notation will they have?

TOR

How THORChain's USD-pegged stablecoin TOR works.

To understand within THORChain fully, one needs to understand the mechanics of TOR.

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 . 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 were converted to and accounted for in TOR.

TOR Price Stability

Understanding THORChain

Introduction of concepts that help make sense of how THORChain is uniquely able to provide the services it does.

Automated Market Makers (AMMs) & Liquidity Pools

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

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

Roles

Roles within THORChain

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

Liquidity providers: these add liquidity to pools, earning fees for their temporary deposit
Swappers: those users who use THORChain's liquidity to swap assets ad-hoc, paying fees for the service
Arbitrageurs

Technology Overview

An overview of the technologies that make up THORChain

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

Bifrost, TSS and Vaults: THORChain is a leaderless vault manager with several components:
- 1-Way State Pegs: Syncs state from external chains to THORChain using the Bifröst Protocol.
- THORChain State Machine (TSS) protocol: Coordinates asset exchange logic, delegates transactions and enables distributed threshold key-signing.
- Bifröst Chain Client: Processes chain-specific transactions.
: Midgard is a layer 2 REST API that provides front-end consumers with semi real-time rolled up data and analytics of the THORChain network.
: The Cosmos SDK is an open-source toolkit for building multi-asset public Proof-of-Stake (PoS) blockchains. There are multiple benefits from building an application-specific blockchain using the Cosmos SDK: Flexibility, Performance, Security and Sovereignty
: CosmWasm is a smart contracting platform built for blockchains that uses the Cosmos SDK, Simply put, it's the Cosmos (Cosm) way of using WebAssembly (Wasm) hence the name. With CosmWasm, teams can deploy smart contracts on THORChain directly

Developer Resources

For technical implementation details including:

Transaction memo formats and syntax
API integration guides (THORNode, Midgard)
Chain-specific integration requirements
Smart contract deployment and aggregator contracts

See the

Midgard

What is Midgard in the THORChain tech stack

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

Midgard is heavily used in dashboards and transaction scanners like Thorchain.net, Thorchain.network and Runescan.io. You find a full overview of the REST API endpoints on:

For more information see Gitlab repo.

Developer Integration

For comprehensive integration guides including:

Complete REST API documentation
WebSocket subscription endpoints
Query optimization strategies
Rate limiting and best practices

See the

THORNodes

Fullnode

Setting up a THORNode & Midgard

The term fullnode describes a basic setup of a synced THORNode daemon and optionally Midgard and is meant to provide API endpoints for private or public use. Because the THORNode doesn't take part in the chains consensus other chain clients aren't needed.

See for more information about the different node types.

The installation guides for running a fullnode via Docker or directly on Linux are not officially supported by the development team. The preferred and supported way is by using .

Thornode - Kubernetes

Setting up a fullnode on Kubernetes

For deploying Thornode and Midgard on Kubernetes, follow the instructions for Cluster Launcher and Deployment.

Instead of TYPE=validator, use TYPE=fullnode at the Thornode deployment step.

NET=mainnet TYPE=fullnode NAME=thornode make install

Multi-node Deployment

Some node operators may desire to run multiple validators within the same cluster, while sharing a single set of daemons among them to save resource cost. This can be performed via the following method. These instructions are relevant for mainnet at the time of writing, but please ensure that correct network and current set of daemons are used.

Asset Types

Asset Notation within THORChain

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

To serve everyone, THORChain:

Archived

This section contains documentation for deprecated THORChain features that are no longer active but are preserved for historical reference.

Deprecated Features

Savers and Lending

As of January 2025, both Savers and Lending features have been deprecated and are no longer available on THORChain.

Savers FAQ (Deprecated)

DEPRECATED FEATURE: Savers have been permanently deprecated as of January 4, 2025. This feature is no longer available on THORChain. This documentation is preserved for historical reference only.

See the for more information.

Liquidity

THORChain's slip-based fees, streaming swaps, and how arbitrage protects against MEV and sandwich attacks

Introduction

What does this mean in practice?

Each token pair (e.g., BTC-RUNE) has a shared capital pool
Users can swap one token for another at any time at a price determined by the ratio of assets in the pool
This ensures that liquidity is always available, and swaps occur without intermediaries or centralized price oracles
Pool prices are additionally "maintained" by arbitrageurs to keep them aligned with external markets

Slip-based Fees – liquidity-dependent fees

This mechanism ensures that the fee corresponds to the demand for pool capital:

Large trades pay more
Small trades pay less

As a result:

The protocol penalizes impatient traders who execute large, sudden swaps
Liquidity providers are rewarded for making their capital available
Users who insist on forcing massive instant swaps cause high slip and pay significant fees to the pool

How does it work?

Small transactions – barely move the price → negligible slip → minimal fee
Large transactions – significantly move the price → high slip → high fee

Why is this important?

Protects against price manipulation – sudden large price moves cost attackers heavily
Forces traders to choose between:
- Speed (one large swap at once, with a high fee)
- Better price (many smaller swaps, slower, but cheaper)

Example 1: Small Swap

BTC-RUNE pool: 1,000 BTC and equivalent RUNE
User swaps 0.1 BTC → only 0.01% of the pool
Price barely changes, slip fee ≈ 0, symbolic fee

Example 2: Large Swap

Same pool
User swaps 100 BTC → 10% of the pool
Price in the pool drops significantly, slip fee amounts to several percent of trade value

Streaming Swaps – time-sliced swaps

Streaming Swaps is a THORChain mechanism that allows users to split a large swap into a series of smaller transactions (sub-swaps), executed sequentially at defined intervals.

This feature was introduced to help users optimize pricing – performing swaps with minimal slip – without manually breaking orders into smaller chunks.

Normally, a single large swap leads to high slip fees, while splitting it manually would mean paying multiple network fees (inbound/outbound fees for each part).

Streaming Swaps solve this by letting users control the swap's timeframe: one deposit internally creates many sub-swaps without additional L1 network fees beyond those of a single swap.

The Problem

When a user wants to swap a large amount (e.g., 1,000 ETH), a one-off swap causes:

Huge slip
Very high fees

Manually splitting into 100 smaller trades would require 100× network fees – uneconomical.

The Solution: Streaming Swaps

THORChain automatically splits a large swap into smaller sub-swaps executed one after another at set intervals. This works similarly to the TWAP (Time-Weighted Average Price) strategy.

Why is this better?

Slip on each part is minimal
Total slip fees can drop from several percent to ~0.1% (or whatever minimum slip set by the protocol)
User pays only one network fee, not per sub-swap
Arbitrageurs between sub-swaps rebalance the pool, improving execution prices for later parts

Example

Swap: 1,000 ETH → BTC.
Option A: one-off → slip fee ~5% (50 ETH cost).
Option B: Streaming Swap – 100 sub-swaps of 10 ETH each, every minute.
Slip per sub-swap ≈ 0.05%.

Arbitrage – balancing pool prices

Unlike many DeFi systems, THORChain does not rely on price oracles – instead, it depends on market forces. Pool prices are maintained by profit-seeking arbitrageurs.

Why is arbitrage needed?

THORChain pools derive prices solely from asset ratios. This can sometimes create gaps compared to external markets.

How arbitrage works

If a token in a pool is undervalued, an arbitrageur buys it from the pool and sells it on the external market for profit.
If a token in a pool is overvalued, an arbitrageur sells it into the pool and buys it cheaper externally.
Repeated arbitrage trades propagate price information between THORChain and external markets until equilibrium is reached. This removes the need for centralized oracles – arbitrage continuously adjusts pool prices.

Arbitrage Example

ETH-RUNE pool: 1 ETH = 100 RUNE.
On Binance: 1 ETH = 110 RUNE.
Arbitrageur buys ETH in the pool for 100 RUNE, sells it on Binance for 110 RUNE → profit 10 RUNE.
Pool price shifts upward.

Thanks to arbitrage, THORChain pool prices always reflect real market values.

Protection against MEV and sandwich attacks

Examples of MEV attacks include:

Front-running – inserting one's own trade right before a victim's large transaction to profit from price movement.
Sandwich attack – placing two trades around a victim's swap (one before, one after) to profit from the induced price change.

THORChain solutions

Swap Queue – transactions are finalized and sorted deterministically by impact on price (slip fee).
- Large swaps are executed before small ones.
- A bot cannot front-run a large trader with a symbolic transaction.
Slip-based fee – attempting to front-run requires a large transaction, which itself incurs massive slip fees, destroying profitability.

MEV Protection Example

A user submits a large ETH → BTC swap.
A bot tries to front-run with a small trade.
THORChain sorts swaps by slip fee: large swap goes first.
The bot is executed after and gains nothing.

MEV attacks on THORChain are unprofitable or outright impossible.

Liquidity Providers (LPs)

A deeper dive into the Liquidity Provider role

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

Liquidity providers commit capital to pools which have exposure to underlying assets. Liquidity providers THEN gain exposure to the underlying assets in each pool. Since assets can be deposited freely, LPs will experience the volatility of those assets—whether positive or negative.

While LPs are paid liquidity fees, these remain dynamic and may not be enough to cover "Impermanent Losses", which occur when price changes happen. With their deposit, Liquidity providers are voluntarily and knowingly taking on this risk. Therefore, they should not assume they are guaranteed or entitled to receive a specific quantity of their assets back when they deposit; rather, they should expect to receive their fair share of the pool's earnings and final asset balances.

How to LP

Requirements & Costs

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

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

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

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

Process

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

Anyone can add liquidity to existing pools; the same goes for proposing new asset pools (this is done simply by depositing it—see for details). Once a new asset pool is listed, anybody can add liquidity to it. It is in this sense that THORChain is permissionless.

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

Depositing Assets

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

Symmetrical vs Asymmetrical Deposits

Symmetrical deposits, the standard approach to providing liquidity, is the method in which the LP deposits an equal value of 2 assets to a pool—e.g., user deposits $1000 of BTC + $1000 of RUNE simultaneously to the BTC/RUNE pool.

Asymmetrical deposits, in contrast, is the LPing method whereby users deposit unequal values of 2 assets to a pool—e.g., a user deposits $2000 of BTC and $0 of RUNE to the BTC/RUNE pool. As this method increases the price slip of the deposit transaction, the LP is (under the hood) given an ownership of the pool accounting for this. The liquidity provider will end up with <$1000 in BTC and <$1000 in RUNE. The deeper the pool, the closer the member will approach owning their pool share equal to their original total of $2000.

Note: there is no difference between swapping into symmetrical shares, then depositing symmetrically, or depositing asymmetrically and being arbitraged to be symmetrical post-deposit. You will experience the same net slip either way.

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

Withdrawing Assets

Just as with deposits, the ability to withdraw assets is completely permissionless and non-custodial. Liquidity providers can withdraw their assets at any time. Furthermore, only the original depositor has the ability to execute the withdrawal of their pool share. The network processes their request and the liquidity provider receives their ownership percentage of the pool plus the assets they've earned. A network fee is charged whenever assets are taken out of the network. These fees go into .

Security

are economically incentivised to never manipulate user funds (i.e. they would lose more money than they would gain by doing so); they are bound by rules of the network and have less than zero economic incentive to take control of any user-deposited assets.

Yield

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

Calculation & Distribution

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

Rewards are calculated every block.
Rewards are paid out when you withdraw your liquidity.

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

If There Are Swaps in the Block

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

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

If There Are No Swaps in the Block

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

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

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

Yield Comes from Fees & Rewards

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

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

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

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

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

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

See here for an of the process.

Factors Affecting Yield

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

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

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

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

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

Yield Strategies

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

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

How it Works

Depositing Assets

Depositing assets on THORChain is permissionless and non-custodial.

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

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

Process

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

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

Symmetrical vs Asymmetrical Deposits

Symmetrical deposits is where users deposit an equal value of 2 assets to a pool. For example, a user deposits $1000 of BTC and $1000 of RUNE to the BTC/RUNE pool.

Asymmetrical deposits is where users deposit unequal values of 2 assets to a pool. For example, a user deposits $2000 of BTC and $0 of RUNE to the BTC/RUNE pool. Under the hood, the member is given an ownership of the pool that takes into account the slip created in the price. The liquidity provider will end up with <$1000 in BTC and <$1000 in RUNE. The deeper the pool, the closer to a total of $2000 the member will own.

Note: there is no difference between swapping into symmetrical shares, then depositing that, or depositing asymmetrically and being arbitraged to be symmetrical. You will still experience the same net slip.

Withdrawing Assets

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

How Yield is Calculated

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

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

Where:

Learn more about and

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

Example: calculates the APR of a pool with the previous 100 days of data rather than the default of 30 days.

Factors that affect LUVI:

Swap fees, block rewards, and pool donations increase LUVI and are the primary yield sources
An increase of the synthetic asset liability of a pool decreases LUVI
An increase in ASSET Depth or RUNE Depth of a pool increase LUVI

For more information, see:

Risks associated with providing liquidity

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

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

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

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

Managing

Accessing Logs, Metrics and more

THORNode commands

The Makefile provide different commands to help you operate your THORNode.

There are two types of make commands, READ and WRITE.

Run make help at any stage to get an exhaustive list of help options and how to interact with the system. See for an overview of each command.

READ COMMANDS

Read commands simply read your node state and doesn't commit any transactions.

To get information about your node on how to connect to services or its IP, run the command below. You will also get your node address and the vault address where you will need to send your bond.

Opens a shell into your thor-daemon deployment: From within that shell you have access to the thorcli command.

Display stream of logs of THORNode deployment:

This will print your node mnemonic (phrase). Use this to ever rescue your node funds if something goes wrong.

Note: Your bond is held at ransom in order to prevent you from stealing funds from this vault. Your bond will always be more valuable than funds on this vault, so you have no economic reason to touch these funds.

WRITE COMMANDS

Write commands actually build and write transactions into the underlying statechain. They cost RUNE from your bond, currently 0.02, but you can check this on the /constants endpoint "CLICOSTINRUNE". This will post state in the chain which will be now updated globally. The RUNE fee is to prevent DDoS attacks.

Send a set-node-keys to your node, which will set your node keys automatically for you by retrieving them directly from the thor-daemon deployment.

Send a set-ip-address to your node, which will set your node ip address automatically for you by retrieving the load balancer deployed directly.

In order to update your THORNode to a new version, you will need to update the docker tag image used in your deployments. Depending on your choice of deployment this can be done differently.

For Kubernetes deployments, you can edit the deployments of the different services you want to update using the commands below.

Tools

Note, all of these should already be installed from make tools. However you can install them separately useing the DEPLOY tabs below.

To access the tools, navigate to the ACCESS tabs below.

All of these commands are to be run from node-launcher

LOGS MANAGEMENT (LOKI)

It is recommended to deploy a logs management ingestor stack within Kubernetes to redirect all logs within a database to keep history over time as Kubernetes automatically rotates logs after a while to avoid filling the disks. The default stack used within this repository is Loki, created by Grafana and open source. To access the logs you can then use the Grafana admin interface that was deployed through the Prometheus command.

You can deploy the log management automatically using the command below:

This command will deploy the Loki chart. It can take a while to deploy all the services, usually up to 5 minutes depending on resources running your kubernetes cluster.

You can check the services being deployed in your kubernetes namespace loki-system.

Access Grafana

See previous section to access the Grafana admin interface through the command make grafana.

Browse Logs

Within the Grafana admin interface, to access the logs, find the

METRICS MANAGEMENT (Prometheus)

It is also recommended to deploy a Prometheus stack to monitor your cluster and your running services.

You can deploy the metrics management automatically using the command below:

This command will deploy the prometheus chart. It can take a while to deploy all the services, usually up to 5 minutes depending on resources running your kubernetes cluster.

You can check the services being deployed in your kubernetes namespace prometheus-system.

We have created a make command to automate this task to access Grafana from your local workstation:

Open in your browser.

As part of the tools command deployment, you also have deployed a Prometheus stack in addition to the Elasticsearch in your Kubernetes cluster. All CPU, memory, disk space, and THORNode / THORChain custom metrics are automatically being sent to the Prometheus database backend deployed in your cluster.

You should have available different dashboards to see the metrics across your cluster by nodes, deployments, etc, and also a specific THORNode / THORChain dashboard to see the THORChain status, with current block height, how many validators are currently active and other chain related information.

Click the 🔍 SEARCH ICON to find the list of dashboards

For a more in-depth introduction of Grafana, please.

Kubernetes Dashboard

You can also deploy the Kubernetes dashboard to monitor your cluster resources.

This command will deploy the Kubernetes dashboard chart. It can take a while to deploy all the services, usually up to 5 minutes depending on resources running your kubernetes cluster.

We have created a make command to automate this task to access the Dashboard from your local workstation:

Open in your browser.

View your kubernetes dashboard by running the following:

Backing up a THORNode

You should backup your THORNode in case of failures. By default, if you are using the Kubernetes deployments solution, all the deployments are automatically backed up by persistent volume disks. Depending on your provider, the volumes are usually available in the provider administration UI, for example in AWS, you can find those volumes in your regular console, in the region you chose to deploy your Kubernetes cluster.

Again by default, with Kubernetes, by using persistent volumes used in the default configuration, you are already protected again restart failures at container level, or node failures. As long as you don’t specifically use the destroy commands from the Makefile or manually delete your Kubernetes deployments, your volumes will NOT be deleted at any time.

It is still recommended, as any project, to have different backups on top of those volumes to make sure you can recover in admin error deleting those volumes or other Kubernetes resources that would imply deleting those volumes.

Also see the Create and Validator Backup guide.

For AWS, you can easily setup in your console to have snapshots of your cluster volumes be taken every day. For other provider there can be different ways to achieve this as well either manually or automatically.

It is up to the node operator to setup those extra backups of the core volumes to be able to recover in any kind of failures or human errors.

Some volumes would be more critical than others, for example Midgard deployment are also by default backed up by persistent volumes, so it can recover in case of container restarts, failures or node failures and the deployment being automatically scheduled to a different node, but if you were to delete the Midgard volume, it would reconstruct its data from your THORNode API and events from scratch. For that specific service having extra backups might not be critical, at the time of the writing of that document, Midgard implementation might change in the future.

At minimum you should also securely backup your node keys: node_key.json and priv_validator_key.json. Do this as follows:

Copy the thornode pod name, e.g. thornode-abcdefg-hijkl and replace with {thornode pod name} below:

For full disaster recovery (complete loss of cluster), it is possible to issue LEAVE command from the original BOND wallet. See for detailed procedures.

Node Security

The following are attack vectors:

If anyone accesses your cloud credentials, they can log in and steal your funds
If anyone accesses the device you used to log into kubernetes, they can log in and steal your funds
If anyone accesses your hardware device used to bond, they can sign a LEAVE transaction and steal your bond once it is returned
If anyone has access to your node's private keys through logs or configuration files, they can steal your funds

Checking diffs

Prior to git pull or make pull updates, review node-launcher repo diffs:

Regularly review patches in GitLab:

When chain clients have updated tags (version number or sha256), inspect the GitLab diffs for the relevant image in and ensure the CI build checksum matches the expected. This ensures you are executing code on your node that you are satisfied is free from exploits. Some images such as Ethereum use the 'official' docker image, e.g. .

RUNNING A NODE IS SERIOUS BUSINESS

DO SO AT YOUR OWN RISK, YOU CAN LOSE A SIGNIFICANT QUANTITY OF FUNDS IF AN ERROR IS MADE

THORNODE SOFTWARE IS PROVIDED AS IS - YOU ARE SOLELY RESPONSIBLE FOR USING IT

YOU ARE RESPONSIBLE FOR THE CODE RUNNING ON YOUR NODE. YOU ARE THE NETWORK. INSPECT ALL CODE YOU EXECUTE.

When running a node, it is quite common to get slashed. The network relies on slash points to rate node quality. When your node is slashed, the first thing you need to do is run make status, and make sure all your chains are 100% in sync. If any of the external chains are not 100% in sync, then it will cause node to be slashed due to missing observations.

The best prevention is to have a cluster with lots of fast resources (cpu, memory, IO, network) and good backups/redundancy to prevent downtime.

Unfortunately even when your node is fully in-sync, it is still possible to be slashed due to external chain events.

Constantly accumulating slash points

Problem: Sometimes bifrost fails to forward observations to thornode, due to an account number / sequence number mismatch. Here is what you need to check:

run make logs , and choose bifrost
Search your bifrost logs for {"level":"error","service":"bifrost","module":"observer","error":"fail to send the tx to thorchain: fail to broadcast to THORChain,code:32, log:account sequence mismatch, expected 26806, got 26807: incorrect account sequence","time":"2021-05-30T07:28:18Z","message":"fail to send to THORChain"} 3. Solution: make restart and choose bifrost

THORChain Docs

Introduction

Introduction

What is THORChain and RUNE?

Supported Blockchains

What is RUNE?

1. Settlement Asset

2. Network Security (Bonding)

3. Liquidity

4. Governance and Incentives

Next Steps

Native Cross-chain Swaps

How Swaps Work in THORChain

Liquidity Pools and RUNE

Decentralized Vaults

Example: Swapping BTC to ETH

Why THORChain is Different

How to Use THORChain

Application Layer

Introduction

Base Layer (THORChain)

Application Layer (App Layer = Rujira)

Rujira Economics

Simple Analogy

Liquidity

Introduction

Slip-based Fees – liquidity-dependent fees

How does it work?

Why is this important?

Example 1: Small Swap

Example 2: Large Swap

Streaming Swaps – time-sliced swaps

The Problem

The Solution: Streaming Swaps

Why is this better?

Example

Arbitrage – balancing pool prices

Why is arbitrage needed?

How arbitrage works

Arbitrage Example

Protection against MEV and sandwich attacks

THORChain solutions

MEV Protection Example

Network Security and Governance

Introduction

Validator Bonding

TSS – Threshold Signature Scheme

Benefits of TSS

Threshold-Signed Vaults

Node Churn

Governance – The Mimir System

Incentive Pendulum

Tokenomics of RUNE and TCY

RUNE Tokenomics

Main Functions of RUNE in THORChain

Settlement Asset

Network Security (Bonding)

Liquidity

Burn

Incentives

Revenue in THORChain

Revenue Distribution

TCY Token

How to Get TCY

TCY Supply

How does TCY work?

Technical Documentation

Technical Deep Dive

Topics

Protocol Innovations

Related Sections

Protocol Innovations

Key Innovations

Capped Proof of Bond

Economic Model

Incentive Pendulum

THORChain Finance

Core Financial Primitives

Secured Assets

TOR