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.

→ Paired tokens · NAV math · Full reference

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.

Where to go next

Paired tokens

Why mint is paired, how the long/short pair settles.

NAV math

The constant-product formula and what it implies for P&L.

CLP and the venues

Book geometry, committed-order mechanics, vault plumbing.

Keeper

Oracle push, book management, settlement crank, yield routing.