This section is a first cut draft. More changes to come!

Continuous Liquidity Pools

Decentralised exchanges are notorious for having low or zero liquidity to the point where they can be unusable for low liquid pairs. This can also be the case for low-tier centralised exchanges. Solving liquidity has been a large focus for Bancor Network and arguably a successful endeavour.

Bancor introduced the concept of continuous liquidity by using smart tokens and connectors built on smart contracts deployed on Ethereum. Tokens and Ether are held in smart contracts in such a way that they become bonded and are priced according to the ratio at which they are held. Users can send either tokens or ether to these smart contracts and the other asset is emitted according to a slip-factored price, which takes into account the liquidity depth of the pool. As a result, liquidity is “always available” for these tokens.

THORChain integrates two on-chain liquidity strategies; an adaption of Bancor’s continuous liquidity strategy, the CLP, and on-chain order-book liquidity multiplication adapted from the Komodo blockchain.

The CLP is arguably one of the most important features of THORChain. By building in on-chain liquidity the ecosystem receives the following benefits:

  • Provides “always-on” trustless liquidity to all tokens in the ecosystem.

  • Improves the user experience for low-liquidity tokens.

  • Functions as source of trustless on-chain price feeds to power all aspects of the ecosystem, including advanced trading types.

  • Generates arbitrage opportunities, further increasing token liquidity.

  • Allows users to trade tokens at trustless prices, without relying on centralised third-parties.

  • Provides trustless price-anchors to the Layer 2 Flash Network, allowing instant trading at the layer 2 level.

Bonding Theory

Tokens on one side of the pool are bound to the tokens on the other. The output can be determined by the input and pool depth as shown below.

Continuous Liquidity Pools were first proposed by an alien in 2016.






Balance of TKN in the input side of the pool




Balance of TKN in the output side of the pool





XY=KX * Y = K
yY=xx+Xy=xYx+X{y \over Y}={x \over x + X} \rightarrow y = {xY \over x+X}


THORChain implements Tendermint, a byzantine fault tolerant state machine replication algorithm. Tendermint has the necessary maturity, performance and security to serve THORChain’s requirements. Tendermint is most useful in that it supports instant finality, which is an indispensable property for a blockchain.

Tendermint achieves this by only committing transactions that have already reached super-majority consensus, rather than waiting for consensus to be achieved after a transaction is committed (such as Bitcoin and Ethereum V1). As such, Tendermint can support sub-second block times and process up to 10,000 TPS.


Tendermint requires full-nodes as Validators or block producers, and each Validator must have a weight on the network. The weight is determined by their staking, so Tendermint can support Proof-of-Stake out of the box. The first implementation of THORChain has a single Validator Set drawn from all available Validators through an auction; the 100highest staked Validators form the Validator Set.

Validators propose blocks, agree and commit them. To join the Validator Set, a Validator must stake higher than the lowest Validator, and by this process ensures that the Validators with the greatest economic investment secure the network. Staking pools are possible to allow wider participation, and anyone can delegate their stake to a chosen Validator. Validators are paid from the block reward, and are paid evenly regardless of stake held.

An in-protocol penalty is required to discourage validators from misbehaving on the network. This is heavily researched in both Casper and Cosmos. Misbehaviour may be double-signing blocks, being off-line or lack of participation in on-chain voting. The amount that a validator is slashed depends on the severity of the incident and will likely be finalised with on-chain voting prior to mainnet. If a Validator is slashed to a level below the highest waiting Validator, the dishonest Validator is evicted and the waiting Validator automatically joins the Validator Set. As a result of the flat group, the heavy level of competition and the likelihood that dishonest participation will cause both economic loss to stakes and eviction from the Validator Set, an attacking Validator is heavily discouraged.

Network security is a consideration for THORChain. Historically on-chain voting has extremely low turn-out, as shown by EOS, CarbonVote and Steemit voting events. Cosmos is attempting to solve this by increasing the rate of inflation of the staked token to increase the incentives to bond tokens to validator stakes (directly or via pools). Inflation pivots between a floor of 7% and a ceiling of 20% to drive holders to bond tokens at a desired bond state of 2/3 of the entire circulating supply. With ⅔ bonded, the network is optimally secure and resistant to cartels and plutocracy. A downside to this that the staked token loses ideal currency properties, and as such Cosmos have introduced a dual-token system, with a secondary token being used to pay for transaction fees.

THORChain will adopt a single token for simplicity but research the real-world economics of other Proof-of-Stake chains until mainnet. If a secondary token is implemented, it can be done using THORChain on-chain governance.

The Bifröst Protocol: Cross Chain Bridges

The Bifröst Protocol forms one of the cornerstone innovations of THORChain, and aims to solve the single biggest issue for asset transfer, interoperability between blockchains.

Because of this Bifröst is the glue that holds the entire THORChain ecosystem together, enabling the seamless trading of any digital asset across any distributed ledger.

While Bifröst is not the first cross-chain solution, it could be the most evolved. In fact, THORChain’s protocol improves upon the weakness of preceding cross-chain architectures like Rootstock 2WP, Liquid Sidechain, POA Network Bridge and COSMOS Peg Zone.

Cross-chain Bridges are simple in concept; an asset is locked on one chain; whilst an identical asset is atomically “minted” on the other and sent to an address owned by the original party.

The newly minted asset is fungible with the original one by virtue of the fact that it can be used to redeem the original asset at the same ratio that it was minted.

This newly minted asset represents the rights to unlock assets on the original chain; so as long as the bridge continues to exist without censorship or interference, then the tokenised asset can be handled as though it was the original asset.

When the owner (anyone who has keys to spend) wishes to move back to the original chain, it is done via the same bridge; the asset is destroyed on the ‘bridged’ chain and atomically unlocked on the original chain. In short:

  1. An asset is locked on one chain

  2. The exact amount is then minted on another chain.

  3. The assets are perfectly fungible, as they are pegged to each other, but can’t be double-spent.

  4. If the owner decides, the minted assets can revert back to their original state (and chain) and the newly minted asset will be destroyed.

  5. The original assets will be unlocked and exactly as they begun.

Validators secure all transactions across the THORChain protocol by validating and relaying transactions, and by extension producing blocks.

Validators will stake their own tokens (Rune) as a representation of their self-interested responsibility to the governance of the protocol. There will be a limited number of validators, currently 100, who will be required to execute reliable multi-sig infrastructure to reach consensus.

THORChain will require protocol level slashing rules to immediately slash a validator’s stake if they attempt to spend from any of the multi-signatures without posting a valid txid first, or they spend to an incorrect user address with a valid transaction. THORChain will also have native cross-compatibility with UTXO, Account and Contract-based cryptocurrencies. The heart of this is are Trustless Two-Way-Pegs (2WP) known as the Layer 1 Bridges, and multi-signature accounts. The core Validator Set (100 staked Validators) are signatories to 67/100 multi-sig accounts to external chains, and a 2 / 3 signature threshold on THORChain. This allows Bitcoin, Ethereum (and their forks) as well as ERC-20 tokens to be seamlessly moved onto the THORChain ecosystem and off again. The external coin is moved into a multi-sig account, signed by the Validator Set.

After observed finality, the Validator Set create a signature threshold to mint new tokens in THORChain via CLPs. BLS signature thresholds are used to prevent issues during Validator Set re-orgs, as only a threshold of signatures is required to be achieved. The reverse occurs to move the coin off the ecosystem. BLS signature threshold theory has been extensively researched by DFinity. The benefits of signature thresholds is that it only requires a threshold of signatures from a super-set, and not specifically a certain sub-set from that super-set. This translates to flexibility in who can be part of a sub-set, and tolerates validators leaving and re-entering the Validator Set, which could be a frequent occurrence in a healthy and competitive environment of validators. Cryptonote Coins such as Monero and Loki do not support m of n multi-signature, but can support n of n or n-1 of n. It is possible to support these coins, however there is a risk in a Validator Set re-org that more than one of the signatories is replaced. If the evicted Validators do not stay online, then the Cryptonote coins that require their signature will remain locked indefinitely on THORChain. There is no risk of theft, and indeed the user can trade from tXMR to tBTC and exit on the Bitcoin bridge safely, putting this inconvenience on a low significance. A mitigation plan to this is to re-shuffle validators immediately if just 1 validator is lost. The BiFrost paper contains additional research on Thorchain’s bridge protocol research.

Threshold Signature Schemes

coming soon