THORChain: a decentralised liquidity protocol

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.