Continuous Liquidity Pools (CLP) Deep Dive

The Continuous Liquidity Pool is the core innovation that allows THORChain to offer native cross-chain swaps without order books or wrapped assets.

What CLP Can Prove

CLP explains how THORChain prices a pool-based swap and why larger trades pay more slip/liquidity fee. It can support narrow mechanism claims:

1. THORChain pools pair external assets with RUNE rather than isolated asset-to-asset order books.
2. The CLP formula links input size, pool depth, slip, liquidity fee, and output amount.
3. RUNE-paired pools let a cross-chain route compose through shared settlement liquidity.
4. Slip-based pricing makes depth-consuming trades progressively more expensive and directs the liquidity fee to pool capital; it does not eliminate LP risk.

It does not, by itself, prove that a current route is quoteable, cheap, available, or safe to execute. Current execution still depends on a fresh quote, live pool depth, inbound address state, chain/trading/signing controls, outbound fee economics, memo validity, and source quality.

How CLP Works

Every pool consists of RUNE paired with an external asset. THORChain docs describe slippage as the input size relative to pool depth, then use that slippage to derive the liquidity fee and final output:

slip = x / (X + x)
fee = (x^2 * Y) / (x + X)^2
output = (x * X * Y) / (x + X)^2

Where x is the input amount, X is the input-side pool depth, and Y is the output-side pool depth. The slip ratio is not itself the fee amount; the fee is denominated in the output asset.

Key Properties

• Quoteable through pool depth: CLP pricing can produce a quote across available pool depth, but execution still depends on current halt state, quote limits, outbound fees, recommended minimums, and refund rules.
• Progressive slippage: Larger trades pay proportionally more, making abrupt pool-price movement more expensive without guaranteeing LP protection or route safety.
• Separate LP action availability: Pool mechanics do not prove that LP adds, withdrawals, pool-specific deposits, or asymmetric withdrawals are currently open. Use the Liquidity Actions evidence guide before turning CLP mechanics into LP workflow claims.
• Historical single-sided products: Savers previously offered single-asset exposure, but official archived docs now mark Savers and Lending as deprecated.

If a swap limit is not met, the amount is below the recommended minimum, fees exceed the practical output, or a relevant chain/trading/signing control is halted, the transaction can be refunded or remain unavailable. Treat swap availability as live/current-only, not as a static property of the CLP formula.

Evidence Ladder

Use the narrowest evidence that matches the claim:

1. Mechanism claim: use the CLP formula and official THORChain docs to explain slip, liquidity fee, and RUNE-paired pools.
2. Current quote claim: use a fresh THORNode quote for the exact route and amount. Keep expected output, fees, slippage bps, recommended minimum input, expiry, and warning text attached.
3. Current availability claim: use Network diagnostics for trading, signing, chain observation, source warnings, and quote-probe posture.
4. Pool-depth or APY claim: use Midgard pool and earnings data with source labels, unavailable-interval counts, and degraded-state warnings.
5. LP action claim: use the Liquidity Actions guide before saying add, withdraw, pool deposit, asymmetric withdrawal, or RUNEPool actions are open.
6. Refund or failure claim: use the Streaming Swaps And Refunds evidence ladder with the exact quote, memo, transaction hash, and network state.

If a statement jumps from the formula straight to a present-tense action, label the result as partial evidence.

Swap Lifecycle and Refunds

A normal swap journey starts before the CLP math is executed:

1. The user or interface asks THORNode for a quote and checks the current inbound address, router, fees, limits, and expected wait time.
2. The user sends the native asset to the current inbound address with a memo that names the action, target asset, destination, and optional affiliate or streaming parameters.
3. Bifrost observers report the inbound transaction to THORChain, where current Mimir controls, chain state, memo validity, pool status, and quote limits determine whether the swap can proceed.
4. The state machine prices the swap through RUNE-paired pools, applying slip, liquidity fees, outbound fees, and current protocol rules.
5. If execution is valid and signing is available, nodes sign the outbound transaction. If the memo, limits, pool state, dust amount, fee economics, halt state, or outbound path make the action invalid or impossible, the protocol can refund instead.

Refunds are therefore not one single failure mode. They can point to user-input problems, stale quotes, minimum-output protection, paused chains, signing/trading controls, exhausted practical output after fees, or source-state changes between quote and execution. Use live network diagnostics before concluding that a refund was caused by the CLP formula itself.

For operational triage, use the dedicated Streaming Swaps And Refunds article before assigning a refund cause.

Comparison to Traditional AMMs

THORChain's CLP is a constant-function pool design with slip-based pricing, adapted to native cross-chain settlement through RUNE-paired pools. Its distinctive claim is the shared RUNE settlement graph and native-asset execution model, not an escape from constant-product-style pool economics. Current chain availability should be checked from live inbound-address and pool status, not from a hard-coded chain count.

What To Verify Before Claiming

Before making a CLP, swap, fee, liquidity, or LP statement, verify:

1. Whether the statement is about the formula, a current quote, route availability, pool depth, LP availability, or a historical product.
2. The current quote response for the exact route and amount if the claim is user-facing or route-specific.
3. Current Network diagnostics for trading, signing, chain halts, LP controls, and source-warning state.
4. Current Midgard pool and earnings source quality before quoting depth, APY, or recent earnings.
5. Whether the claim belongs in the refund guide, liquidity-actions guide, RUNEPool/POL guide, or dynamic-fee tracker instead of the CLP formula page.
6. The source provider, checked time, block height when available, and whether missing fields were shown as unavailable rather than zero.

Non-Claims

This page does not prove:

• A route is currently quoteable, executable, cheap, or safe.
• A swap will not refund, expire, miss minimum output, or fail on memo, dust, fee, halt, signing, or outbound conditions.
• Current pool depth, APY, liquidity provider earnings, or route competitiveness.
• That LP adds, withdrawals, pool deposits, asymmetric withdrawals, RUNEPool, Savers, Lending, or secured-asset flows are available.
• That a static formula is wallet guidance, transaction construction, or support diagnosis.
• That a current quote or dashboard number proves future yield, profitability, safety, or investment suitability.