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.

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 protection can exceed swap fees in volatile markets. LP returns depend on pool depth, price movement, ILP mechanics, and current availability — not on the existence of swap fees alone.
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.