LibraryMarkets2020Design paperCorpus record
THORChain: a decentralised liquidity protocol
THORChain. The THORChain team.
THORChain's design for continuous liquidity pools that cross native chains. Nodes bond capital, observe external chains, and sign outbound transactions as a threshold set. It is a liquidity network, not a wrapped-asset bridge run by a single custodian.
THORChain's paper describes a network of continuous-liquidity pools that swap native assets across chains, with bonded node operators who can be slashed if they mishandle the vaults.
The five-minute read
The hard part is custody across chains
An automated pool on one chain is a contract. A swap from native bitcoin to native ether needs a set of operators who hold those assets and can be punished. The paper is about that set.
Pools use a constant-product style invariant
Each pool pairs the network's own asset with an external asset. Swaps move along that curve. The pricing idea is familiar. The custody idea is not.
Bonding is the security budget
Nodes post a bond. The paper's argument is that the bond, and the income nodes earn, should make theft less attractive than honesty. If the pools outgrow the bonds, the argument weakens.
Churn keeps the set fresh
Membership rotates. A static multisig of founders is not the design. Whether the rotation is real is an operational fact.
Observation of other chains is a consensus job
Nodes must agree that a bitcoin transaction happened before they credit a pool. A failure of observation is a failure of the swap, even if the pool math is right.
One action, walked through
- A user sends native asset A to a vault address the network controls.
- Nodes observe the inbound transaction on A's chain and agree it is final enough.
- The protocol credits the swap and computes the output of asset B from the pool invariant, minus the fee.
- A vault on B's chain sends the outbound transaction. Nodes sign it under the threshold scheme.
- If an outbound fails or a vault is mishandled, the paper's slashing rules take the cost from bonds.
The argument, unpacked
The invariant is not the risk
Constant product will do what it always does. The new risk is a vault key. Threshold signatures, rotation, and an economic bond are the actual design. A review that spends its time on the AMM curve has reviewed the easy half.
Security scales with the bond, not with the brand
The paper's honesty condition is roughly that stealing the pooled assets should be worth less than the bond that would be lost, given the chance of being caught. When total value locked races ahead of bonded value, that sentence stops being true. It has to be re-measured. It cannot be inherited from the white paper's examples.
Cross-chain finality is heterogeneous
Bitcoin's idea of final and a fast chain's idea of final are different ages. The protocol must pick a confirmation depth per chain. Pick too small, and a reorg double-spends the pool. Pick too large, and the swap is no longer what users call instant.
What has to be true
- Bonded value remains large relative to pooled assets under the paper's security argument.
- A threshold of nodes is honest and online for both observation and signing.
- Each external chain's confirmation rule is conservative enough for that chain's reorg behaviour.
- Outbound transactions can actually be built. A chain that changes address rules or fees can stall withdrawals.
What happened after the paper
THORChain launched and suffered exploits around router and vault logic that were about implementation and operational security, not about the constant-product formula. Those losses are part of how the design should be taught: the bond did not make buggy signing code harmless. The paper's model remains the right checklist, and it is not a claim that the checklist was always met.
What to check before you use the idea
- What is bonded value relative to pooled value today, not in the paper's illustration?
- How many confirmations does each chain require before credit?
- How is the vault key threshold set, and how often do members rotate?
- Which failures were implementation bugs rather than failures of the invariant?
Terms
- Bond
- Collateral posted by a node, intended to be slashable if the node participates in mishandling funds.
- Vault
- An address on an external chain controlled by a threshold of nodes, holding pooled assets.
- Observation
- The network's agreement that an inbound transaction on another chain is final enough to credit.
- Continuous liquidity pool
- The on-network curve that prices the swap once custody and observation have done their jobs.
The problem the paper names
Trading bitcoin for ether, in the native assets, usually means a custodian or a trusted wrapper. THORChain's paper proposes pools on its own chain, plus a signer set that can move the native asset on the external chain when the pool accounting says so.
What the design proposes
- Pools pair an external asset with the network's settlement asset.
- Nodes are bonded and churned. Outbound signing is a threshold, not a single key.
- Continuous liquidity pools, in the paper, are the pricing mechanism. The signer set is the delivery mechanism.
How the mechanism is specified
- An observer network reports external deposits. A supermajority must agree before value is credited.
- Slashing and bond size are the economic answer to a signer who steals or who stays offline.
- The design's safety is the overlap of honest observers, an honest threshold of signers, and correct pool accounting.
What this page does not treat as proven
- A threshold signer set can still collude. The paper prices that risk with bonds. It does not define it away.
- Later parameters, vault schemes and incident history are not the white paper, and this page does not narrate them as if they were.
- We do not describe returns for liquidity providers.
Why a venture studio still reads it
This is the document to use when a venture says 'native cross-chain swap' . Ask who holds the outbound key, what bond is slashed if they sign wrongly, and which chain is allowed to disagree.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.