> ## Documentation Index > Fetch the complete documentation index at: https://continuum-ec12e897.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # How Continuum works > The full mental model - paired tokens at NAV, three protocol-native trading venues, and the keeper that runs them. Continuum has three moving pieces. Two live on-chain, one runs off-chain. * **`mint-redeem`** - issues and burns paired long/short tokens against cUSDC collateral at NAV, and holds each market's risk state and solvency target. * **`clp`** - the protocol's trading and treasury program. It hosts all three trading venues and the vaults that provision them. * **The keeper** - an off-chain bot that pushes oracle prices, manages the on-chain order books, settles committed orders, and routes collateral yield. ## The system at a glance ``` ┌────────────────────────────────────────┐ │ Frontend / SDK │ └───────┬───────────────────┬────────────┘ │ │ mint / redeem at NAV trade either leg │ │ ▼ ▼ ┌──────────────────────────┐ ┌─────────────────────────────────┐ │ mint-redeem │ │ clp │ │ │ │ │ │ mint_paired │ │ 1. CLMM books (pool_swap) │ │ redeem_paired │◄──┤ 2. Committed (commit_swap │ │ risk state + TWAP │CPI│ orders settle_swap)│ │ dynamic buffer target │ │ 3. Oracle swap (clp_swap) │ │ unified vault (γ-decay) │ │ per-market inventory vaults │ └──────────────────────────┘ └─────────────────────────────────┘ ▲ ▲ │ │ ┌───────────┴───────────────────┴───────────┐ │ Keeper bot (off-chain) │ │ oracle push · book manager · settler · │ │ refill/trim · buffer + fees · yield │ └────────────────────────────────────────────┘ ``` Everything a user touches is protocol-native. There is no external AMM in the call path. ## Minting and redeeming The only program a regular user writes to for issuance is `mint-redeem`: * **`mint_paired(amount)`** deposits cUSDC, mints matched long (`L`) and short (`S`) tokens at NAV. * **`redeem_paired(l_amount, s_amount)`** burns long + short (in independent quantities) and returns cUSDC at NAV. NAV is bound by a constant-product invariant: `L_NAV = oracle price`, `S_NAV = K / L_NAV` where `K = initial_l × initial_s`. As one side appreciates the other depreciates reciprocally, so a paired mint or redeem is solvency-neutral by construction. There is no path for a user to mint single-sided - see [Solvency](/concepts/solvency). → [Paired tokens](/concepts/paired-tokens) · [NAV math](/concepts/nav) · [Full reference](/programs/mint-redeem) ## The three trading venues Trading individual legs happens on the `clp` program, which deliberately splits flow across three venues: | Venue | Instruction | Fill | Best for | | ------------------- | ----------------------------- | ----------------------------------------------- | ---------------------------------- | | **CLMM book** | `pool_swap` | Instant, walks on-chain bins with real slippage | Small trades, immediate execution | | **Committed order** | `commit_swap` → `settle_swap` | Next oracle print, NAV ± 10 bps, any size | Large trades | | **Oracle swap** | `clp_swap` | Instant at NAV ± 30 bps, breaker-guarded | Small instant trades (legacy path) | ### 1. CLMM books - instant, small Each market has one protocol-native pool **per side** (8 pools live: QQQ/SPY/VXX/XAU × L/S). Bins live inline in the `Pool` account with a 2-zone geometry: fine core steps near NAV, wide wings further out (QQQ: 20 bps core, 300 bps wings). The keeper re-pins the book base to NAV when drift exceeds a per-market gate (20 bps for QQQ/SPY/XAU, 40 bps for VXX). Standing depth is deliberately lean - sized to organic demand, not TVL, because toxic-arb loss scales with deployed depth. Books converge to roughly \$5k of bids and ≤\$7.5k of asks per side. ### 2. Committed orders - any size The large-order path. You escrow your input into an `Order` PDA; the fill executes at the **first oracle print strictly after** your commit, at NAV ± 10 bps. Because the price is set after you commit, there is no stale quote to pick off - latency arbitrage is impossible by construction, so there is **no size or window cap**. The bounds are oracle health, the collateral floor, and keeper-provisioned inventory. * Settlement is **permissionless**; the keeper cranks it (typically 12-25 s end to end, bounded by the \~15 s oracle cadence). * A `min_out` miss refunds in full - terminal, not a revert loop. * `cancel_swap` refunds unconditionally after the 180 s TTL and checks nothing else - funds are always recoverable regardless of oracle, keeper, or admin state. * Every terminal path closes the Order account and returns rent. The frontend auto-switches to committed mode above \$5k notional (overridable). ### 3. Oracle swap - the legacy facade `clp_swap` fills instantly from pre-stocked CLP inventory at NAV ± a configured spread (30 bps), guarded by oracle-health breakers (60 s staleness, confidence, 25% deviation), a rolling notional window cap, and a collateral floor. It is retained for small instant trades; committed orders bypass it and do not consume its window. ## End-to-end mint flow ``` 1. User wallet ─── mint_paired(100 cUSDC) ──► mint-redeem program 2. mint-redeem reads ─── user_twap_price (NAV) from the Market account 3. mint-redeem transfers ─── 100 cUSDC ──► collateral vault 4. mint-redeem mints ─── L_qty long tokens ──► user's long ATA 5. mint-redeem mints ─── S_qty short tokens ──► user's short ATA ``` The user's transaction is independent of the keeper - the keeper is never in the mint/redeem call path. ## End-to-end committed-order flow ``` 1. User ─── commit_swap(market, side, direction, amount, min_out) ──► clp input escrowed into an Order PDA, TTL = 180 s 2. Keeper ─── update_risk_state (next oracle print, ~15 s cadence) ──► mint-redeem 3. Anyone ─── settle_swap(order) ──► clp fills at NAV ± 10 bps using the post-commit print; min_out miss → full refund; either way the Order closes 4. (fallback) after 180 s: cancel_swap refunds unconditionally ``` ## Why this design | Question | Answer | | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Why no funding rate? | The constant-product NAV invariant `L_NAV × S_NAV = K` bounds combined pair value. Gains on one side mirror losses on the other. There's nothing to redistribute. | | Why no liquidations? | A paired position prepays full collateral. There is no margin to call. | | Why three venues? | Each venue is optimal for a different trade. Instant small trades get an on-chain book with real slippage; large trades get an uncapped NAV ± 10 bps fill that cannot be latency-arbed; the oracle swap covers small instant flow with breakers. Splitting them lets each be priced for its own adverse-selection profile. | | Why is committed-order spread (10 bps) thinner than instant (30 bps)? | A price set strictly after the commitment carries zero adverse selection - there is nothing to select against, so the venue can quote tighter. | | Why is book depth so lean? | Toxic loss scales with deployed depth; organic revenue is demand-capped. Depth is sized to demand, with excess swept to vaults where it provisions committed orders. See [CLP](/concepts/clp). | ## Where to go next Why mint is paired, how the long/short pair settles. The constant-product formula and what it implies for P\&L. Book geometry, committed-order mechanics, vault plumbing. Oracle push, book management, settlement crank, yield routing.