Skip to content
⬡
THORChain Wiki
Deep DiveCurated

Continuous Liquidity Pools (CLP) And The Decentralized Exchange

How THORChain's constant-function, slip-priced pools support native swaps, and where formula evidence stops before current route, refund, LP, or yield claims.

About this article's sourcing
CuratedChecked 2026-07-14·
THORChain Docs
retrieval details
Source retrieved 2026-07-05Official documentation root used for curated protocol background; it still describes GG20 at review time, but current safety and migration state require dated incident and release sources.
+3 sources
THORChain Dev Docs
retrieval details
Source retrieved 2026-07-05Official developer documentation root used for API and integration concepts; pair with live endpoints for current state.
Native cross-chain swaps
retrieval details
Source retrieved 2026-07-14Official user-facing explanation of native cross-chain swaps routing internally through RUNE-paired pools; current execution still needs quote and operational evidence.
THORChain Swap Guide
retrieval details
Source retrieved 2026-07-05Official quote, expiry, streaming swap, refund-address, and swap error-handling guidance.

Use this article for: A mechanism and evidence-boundary guide for CLP pricing, slip/liquidity fees, route availability, and refund non-claims.

Verify elsewhere before claiming: Current quote, route availability, pool depth, LP action state, source quality, transaction evidence, and whether the claim belongs in the refund or liquidity-action evidence ladder.

Your reading path

Path selection stays in this URL. Progress is stored only on this browser after you enable it. Reading marks describe navigation, not understanding or competence.

Import a progress file

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. THORChain is increasingly described as a decentralized exchange (DEX); "liquidity protocol" remains accurate as mechanism context, but community-maintained docs are phasing it out as a product label.

What CLP Can Prove

CLP explains how THORChain prices a pool-based swap and why larger trades pay more slip/liquidity fee. THORChain pools external assets with RUNE; the formula links input size, depth, slip, fee, and output; shared settlement liquidity composes cross-chain routes. It does not prove that a current route is quoteable, cheap, available, or safe to execute.

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: official docs for mechanics, a fresh THORNode quote for a specific route, Network diagnostics for availability, labeled Midgard data for depth/APY, Liquidity Actions for LP operations, and the Streaming Swaps And Refunds ladder for refund causes. A formula alone is only partial evidence for a present-tense action.

Swap Lifecycle and Refunds

A normal swap journey starts before the CLP math is executed, but the full lifecycle — including quote, inbound, observation, execution, signing, and refund — is covered in depth in the Streaming Swaps And Refunds article. For operational triage of refunds and failed swaps, use that article before assigning a cause.

The CLP pricing formula — slip, fee, and output — runs at step 4 of that lifecycle, after quote validation and before outbound signing. Refunds can occur at any point when the swap cannot proceed, for reasons ranging from stale quotes to halted chains.

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.

A static formula is neither wallet guidance nor support diagnosis. Route execution, refunds, LP actions, depth/APY, and future outcomes all need the matching live evidence described above.

Common Misreadings

  • "The slip ratio IS the fee." The slip ratio is the input size relative to pool depth. The fee is derived from that ratio but denominated in the output asset, not equal to the slip ratio itself.
  • "LPs always earn from swap fees." Impermanent loss can exceed swap-fee income when relative asset prices move. LP returns depend on pool depth, price movement, fees and current availability. Impermanent loss protection (ILP) is historical: the official CLP documentation says it was removed for all liquidity providers. ADR-005, amended 7 November 2023, describes the permanent sunset. The older protection formulas on that page do not promise current coverage. This specific removal claim was source-checked on 2 October 2026; the article as a whole retains its existing review date.

Try A Single-Leg CLP Scenario

Use hypothetical model units to compare input size with input-side and output-side depth. The model shows slip ratio, liquidity fee and output as separate values. Source and version review belong to this lab alone; the article-wide review date is unchanged. Explain what the lab omits before using the separate live route check.

Explore input, depth and slip

Change one hypothetical input or depth to see the single-leg CLP equations. No live pool balances or prices are loaded.

Official CLP equations 4–6, reviewed 3 October 2026 alongside THORNode v3.20.3. This algebraic model does not reproduce exact protocol execution.

Use ordinary decimals from 0 to 1,000,000,000 with at most eight decimal places. Both depths must be positive. Values are abstract model units; output and fee use output-side units.

Model slip ratio
9.09090909%
Model liquidity fee (output-side units)
8.26446280
Model output after liquidity fee (output-side units)
82.64462809

The displayed amounts round down to eight model decimals. Slip ratio is not the fee amount. This is one fixed-depth algebraic leg; it omits streaming, queue ordering, two-pool routing, live fee floors, outbound fees, rounding rules and halt state.

A toy result is not a quote, investment return, price target or proof a route can execute. Check current route evidence separately.

CuratedChecked 2026-10-03·Review due 2026-11-03·
Source: CLP equations 4–6 (3 October model review)
source retrieval details
Source retrieved 2026-10-03Single-leg algebraic slip ratio, liquidity fee and emission equations. This model excludes live minimum slip floors and current availability.
+1 source
THORNode v3.20.3 swap arithmetic
retrieval details
Source retrieved 2026-10-03CalcAssetEmission/CalcLiquidityFee match the algebra; GetSwapCalc can instead apply a minimum slip floor, and CalcSwapSlip rounds basis points. The toy lab does not reproduce those execution rules. File SHA-256 58e6413829ece2e95ef716eab0def293e7e63e789b6159f659d2570931d4cf6e.
Glossaryclpfeesswaps
Reader paths for this article

Use these paths to connect this explainer with the current-state checks needed before making live protocol claims.

View all paths
New to THORChain

Readers who need the protocol shape before diving into live state.

Step 2 of 5

Verify Before Claiming

  • Current supported chains, halts, or inbound-address availability.
  • Current implementation constants, active Mimir overrides, or provider-independent dashboard numbers.

Continue This Path

Continue with Midgard And THORNode Data before treating this path as complete.

New to THORChain step 2/5
Swap Economics

Readers comparing settlement, slip, liquidity, rewards, and fee signals.

Step 2 of 7

Verify Before Claiming

  • Current liquidity depth, APY, and earnings coverage from live Midgard snapshots.
  • Current RUNEPool enablement, provider PnL, POL-enabled pool scope, or deposit/withdraw availability.
  • Whether a fee claim is ordinary fee mechanics or the ADR-026 dynamic-fee experiment.

Continue This Path

Continue with Midgard And THORNode Data before treating this path as complete.

Swap Economics step 2/7
Liquidity Actions

Readers deciding how to describe LP adds, withdrawals, pool-deposit pauses, asymmetric withdrawals, or LP metrics without making wallet-flow claims.

Step 3 of 6

Verify Before Claiming

  • Current LP action, pool-deposit, asymmetric-withdrawal, RUNEPool, and source-warning state.
  • Whether the claim is about availability, memo shape, RUNEPool/POL accounting, pool data, historical transaction evidence, or future yield.

Continue This Path

Continue with Mimir And Halt Controls before treating this path as complete.

Liquidity Actions step 3/6
App Layer And Integrations

Readers trying to separate base-layer swaps, CosmWasm contracts, secured assets, trade accounts, and live halt controls.

Step 3 of 4

Verify Before Claiming

  • Current secured-asset, trade-account, oracle, WASM, signing, trading, and chain-specific Mimir state.
  • Whether source wording about replacing Trade Assets versus Trade Accounts describes a current module migration rather than terminology drift.
  • That a specific interface, contract, deployer, checksum, or asset flow is safe, supported, or currently available.

Continue This Path

Continue with Bifrost Bridge and Cross-Chain Observability before treating this path as complete.

App Layer And Integrations step 3/4

Browse All Deep Dives

Article library order, separate from reader-path order.