RUNE as the Universal Settlement Asset

RUNE is THORChain's native asset and the common pair for the protocol's liquidity pools. This article explains the settlement model behind that design. It is not live proof of current pool depth, route availability, quote quality, chain support, or RUNE investment value.

The Settlement Layer

For an external-asset swap, THORChain routes through RUNE-paired pools. A BTC to ETH swap is modeled as:

BTC -> RUNE -> ETH

The important point is not that the user must hold RUNE manually or submit two user-visible transactions. It is that the base swap engine can price an external-asset route as two internal pool legs through RUNE:

• Each base-layer liquidity pool in this settlement model pairs an external asset with RUNE.
• Cross-pool swaps use the input asset's RUNE pool and the output asset's RUNE pool.
• Pool depth, current fees, slip, halts, and outbound conditions still determine whether a specific live swap is practical or available.

Why RUNE Pairing Matters

Without a common settlement pair, a network with many assets would need direct liquidity for every possible pair. The official docs describe this as the n*(n-1)/2 scaling problem.

RUNE pairing changes the shape:

• Instead of a BTC/ETH, BTC/AVAX, BTC/LTC, ETH/AVAX, and ETH/LTC pool graph, each asset can connect through its asset/RUNE pool.
• The protocol has one price relationship to track per external asset: asset against RUNE.
• Arbitrage and pool balancing can move prices through the shared RUNE side instead of relying on every pair having deep direct liquidity.

This is the main architectural claim this article can support: RUNE is the common settlement and intermediate asset for the base liquidity layer.

What The Settlement Model Proves

The RUNE settlement model supports a few source-backed claims:

• THORChain's base AMM design uses RUNE-paired liquidity rather than direct pools for every external-asset pair.
• A cross-chain swap can be explained as two internal pool movements through RUNE, even when the user experience and transaction intent look like one native-asset swap.
• RUNE links liquidity, incentives, and security because it appears in pools, node bonding, fee payments, and reward flows.

Those claims are architectural. They do not automatically tell you whether today's route is healthy, cheap, liquid, or safe to use.

What To Verify Before Claiming

Before turning this model into a current claim, verify:

1. The current /network#network-diagnostics state for trading, signing, chain availability, and relevant Mimir controls.
2. Current pool depth, fees, and earnings coverage from /stats, Midgard, or the exact quoting source being used.
3. Whether the route is an ordinary base-layer swap, a streaming swap, a secured-asset or trade-account flow, or an app-layer interaction.
4. Whether the interface has a fresh quote, valid inbound address, correct memo, current outbound fees, and enough output after fees.
5. Whether a security or liquidity statement is about static design, recent live data, or a dated historical incident.

Non-Claims

This page does not prove:

• Current RUNE price, fair value, or investment upside.
• Current APY, LP profitability, route competitiveness, or revenue capture.
• That every listed chain, pool, or route is currently enabled.
• That a large swap will execute without refund, delay, or material price impact.
• That RUNE pairing alone makes the protocol safe; current vault, signing, observation, liquidity, and incident evidence still matter.

Use this article as the map for the settlement design. Use live network diagnostics, current pool data, official docs, and interface-specific quote evidence before making operational or financial claims.