The Stellar DEX Explained: Order Book, Path Payments, Pools

The order book in the ledger

The SDEX stores buy and sell offers in the Stellar ledger alongside balances. Offers behave like limit orders: a marketable offer fills immediately against the best prices, and the rest rests on the book until filled or cancelled. Matching follows price-time priority, and every resting offer is guaranteed to be fully fundable.

Accounts trade with three operations: Manage Buy Offer, Manage Sell Offer and Create Passive Sell Offer. Internally every order is stored as a sell, so "offer" and "order" mean the same thing on Stellar. Prices are stored as fractions of two 32-bit integers rather than floating-point numbers, so there is no rounding drift.

The design detail that matters most is liabilities. Each open offer creates a selling liability on the asset offered and a buying liability on the asset wanted, recorded on the account or trustline. Any operation that would leave the account unable to honour them fails, which, in SDF's words, "guarantees that any order in the orderbook can be executed entirely". There is no phantom liquidity from offers whose owners have spent the funds.

Passive offers do not take an existing offer at the same price. They exist so that market makers can quote two equivalent assets, say USD from two anchors, at exactly 1:1 without their own orders filling each other. Each open offer also adds 0.5 XLM to the account's reserve, and trading fees are just the normal network fee: 100 stroops per operation without surge pricing, as covered in Stellar fees explained.

Path payments

A path payment sends one asset and delivers a different one, converting through intermediate markets within a single operation. If any step cannot fill within the sender's limit, the whole operation fails and nothing moves. Stellar considers paths of up to five hops between the sent and received asset.

There are two operations. Path Payment Strict Send fixes how much you send and lets you set a destination min; Path Payment Strict Receive fixes how much the recipient gets and sets a send max. Those limits are the slippage protection: if the markets have moved, the payment fails rather than filling at a bad rate.

SDF's example route is XLM → ETH → BTC → USDC, with the recipient never touching XLM. This is how a sender can pay in one currency while the recipient receives another, with no exchange account in the middle. It is also how many wallets implement "swap": a path payment to yourself. Balances are only settled at the end of the operation, and a path cannot cross the sender's own offers.

Classic liquidity pools (CAP-38)

Protocol 18, live on 3 November 2021, added automated market makers to the protocol through CAP-38. Each classic pool holds two assets, prices them with the constant-product rule x × y = k, and charges a fixed 0.30% fee that accrues to depositors. Pool shares cannot be transferred, only deposited and withdrawn.

Ownership is proportional. In the documentation's example, an account holding 30 of a pool's 150 shares can withdraw 20% of both reserves at any time, including its share of accumulated fees, which are only collected on withdrawal. These AMM fees are entirely separate from network fees, which are still paid in XLM on every deposit, withdrawal and swap.

The documentation gives the invariant a concrete example. A pool holding 1,000 EUR and 1,170 USD has a product of 1,170,000. Selling 1 EUR for 1.18 USD leaves a product of 1,170,008.82, so the pool accepts it; selling it for 1.16 USD would shrink the product, so it refuses. Because the fee is folded into the invariant, k grows with every trade, which is how providers earn.

Joining a pool needs trustlines to both assets (unless one is XLM) and to the pool share itself, and the pool-share trustline costs two base reserves, 1 XLM. Only one classic pool can exist per asset pair, with the fee fixed at 30 basis points. On 2 October 2026 Horizon showed the classic XLM/USDC pool holding 22.68M XLM and 5.09M USDC, with 833 accounts holding shares. Providers face the usual impermanent loss.

How a trade picks a venue

Classic pools can only be traded through path payments. For each hop, the protocol prices the trade against the order book and against the pool for that pair, and executes the whole hop on whichever is better. It does not split one hop across both, so the result is never worse than the book alone but is not guaranteed optimal.

CAP-38 is candid about this. Requiring the best possible price would mean interleaving fills between book and pool, and the authors chose the simpler rule "by construction it cannot be worse than executing against the order book alone". For large trades this matters: splitting across several transactions, or using an aggregator, can beat a single path payment.

Here is what depth means in practice, using the classic XLM/USDC pool above (spot price about $0.2246) and its 0.30% fee:

XLM sold into the pool	USDC received	Effective price	Worse than spot by
1,000	223.88	$0.22388	0.30%
100,000	22,291	$0.22291	0.74%
1,000,000	214,462	$0.21446	4.5%

The order book was competitive at the same moment: best bid $0.2243 and best ask $0.2247, with roughly 200,000–240,000 XLM within the top 20 levels on each side. A path payment would use whichever venue was better for the size.

SDEX vs Soroban AMMs like Aquarius

Aquarius AMMs are Soroban smart contracts launched in July 2024, separate from the protocol's own pools. They offer volatile constant-product pools, stable-swap pools of up to three assets and concentrated-liquidity pools, with selectable fees. Classic path payments cannot route through them, so wallets and aggregators query both systems.

The differences are practical:

	SDEX and classic pools	Aquarius AMMs
Where it lives	Stellar protocol	Soroban contracts
Pool types	Order book; constant product	Constant product, stable swap, concentrated
Swap fee	0.30% fixed (pools)	0.1%, 0.3% or 1% (volatile and concentrated); set at creation (stable)
Pools per pair	One	Several, by type and fee
Trading interface	Classic operations, path payments	Router contract calls
Network fee	Inclusion fee only	Inclusion plus resource fee
Extra risk	No contract layer; protocol risk only	Smart-contract risk on top

The split runs in both directions. The Stellar Asset Contract exposes no order-book functions, so a Soroban contract cannot place an SDEX offer; DEX trading stays with classic operations. Aquarius pools, in turn, are reached through Aquarius's router. Aquarius also layers AQUA rewards onto pools through ICE voting, covered in the Aquarius AMM explained and Aquarius concentrated liquidity.

Thin markets and price risk

An order book is only as trustworthy as its depth. Where a pair has few offers, one trade can move the price arbitrarily far, and any system that reads that price inherits the error. The February 2026 YieldBlox exploit was exactly this: a thin USTRY market on the SDEX fed a lending pool's oracle.

As covered in our account of Blend's 2026 incidents, the YieldBlox pool priced USTRY collateral through a Reflector feed sourced from the USTRY/USDC market on the SDEX. Liquidity had been temporarily removed. The attacker moved the price from about $1.06 to about $107, the oracle reported it, and about $10M was borrowed against collateral worth a fraction of that. Nothing in the SDEX malfunctioned: it reported what had traded.

The same logic applies to every venue, AMM or order book. Before relying on a Stellar price, for a trade, a collateral value or an APY calculation, check:

• Depth: how much can trade within 1–2% of the quoted price;
• Spread: a wide gap between bid and ask means the "price" is a guess;
• Recent volume: a last trade from hours ago says little about now;
• Limits: always set destination min or send max on path payments;
• Venue: compare the SDEX, classic pools and Soroban AMMs before large trades.

Protocol changes also touch the exchange occasionally. Protocol 29, activated on 1 October 2026, lists "Improve DEX offer crossing accuracy" and "Don't count pool hops against limit" among its changes; see Stellar's 2025–2026 upgrades. For the broader risk list, see DeFi risks.

The takeaway

The SDEX gives Stellar something most chains lack: an exchange that is part of the ledger, with fully funded offers, atomic multi-hop payments and fees of a fraction of a cent. Classic pools add passive liquidity, and Soroban AMMs like Aquarius add more pool types at the cost of smart-contract risk. None of them removes the basic rule: a price is only as good as the liquidity behind it.

Sources: Stellar developer docs (Liquidity on Stellar: SDEX and Liquidity Pools; Path Payments; List of Operations); CAP-38; stellar.org protocol-upgrades page; stellar-core v29.0.0 release notes; Aquarius docs (What are Aquarius AMMs?); Horizon mainnet XLM/USDC order book and liquidity pool data, 2 October 2026; BlockSec and Script3 analyses of the YieldBlox exploit as summarised in our Blend article.