How Continuum works

The mental model, covering paired tokens at NAV, two protocol-native trading venues, and the keeper that prices them.

Continuum has three moving parts. Two are on-chain programs and one runs off-chain.

• mint-redeem issues and burns paired long and short tokens against cUSDC collateral at NAV. It also stores each market’s price, risk state and solvency target.
• clp is the protocol’s trading and treasury program. It hosts both trading venues and the vaults that stock them.
• The keeper is an off-chain service run by the protocol. It pushes prices on-chain, manages the bin books, settles committed orders, and posts fees and volatility decay.

The system at a glance

                  ┌────────────────────────────────────────┐
                  │             Frontend / SDK             │
                  └───────┬───────────────────┬────────────┘
                          │                   │
              mint / redeem at NAV      trade either leg
                          │                   │
                          ▼                   ▼
   ┌──────────────────────────┐   ┌─────────────────────────────────┐
   │       mint-redeem        │   │              clp                │
   │                          │   │                                 │
   │  mint_paired             │   │  1. Committed      (commit_swap │
   │  redeem_paired           │◄──┤     orders          settle_swap)│
   │  price + risk state      │CPI│  2. Bin books      (pool_swap)  │
   │  buffer target, γ index  │   │     only while price is stale   │
   │  collateral vaults       │   │  per-market inventory vaults    │
   └──────────────────────────┘   └─────────────────────────────────┘
                          ▲                   ▲
                          │                   │
              ┌───────────┴───────────────────┴───────────┐
              │              Keeper (off-chain)           │
              │  price 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 user writes to for issuance is mint-redeem:

• mint_paired(collateral_amount) deposits cUSDC and mints matched long (L) and short (S) tokens at NAV.
• redeem_paired(l_amount, s_amount) burns long and short tokens and returns cUSDC at NAV. Both amounts must be above zero and are maxima: the program burns the largest value-balanced pair inside them, and the rest of the larger leg stays in your wallet.

Both need at least 10 cUSDC of value and a keeper price push no more than 300 s old.

NAV comes from one price P and a constant K = initial_l_price × initial_s_price. L_NAV = P and S_NAV = K / P × γ, where γ (at most 1) is the short leg’s volatility decay. So L_NAV × S_NAV = K·γ, and as one leg rises the other falls reciprocally. A paired mint deposits exactly the NAV value of the tokens it creates. No user path mints one side alone; see Solvency.

→ Paired tokens · NAV math · Full reference

The trading venues

Trading a single leg happens in the clp program, which has two venues of its own. Which one fills depends on whether the market’s price is live:

Venue	Instruction	Fill	When
Bin book	pool_swap	Instant, walks on-chain bins with real slippage, small capped size	Only while the price is stale
Committed order	commit_swap → settle_swap	At a keeper push after the commit, NAV ± the committed spread (10 bps floor), any size	While the keeper pushes prices

Every market has its two bin books. Since 11 Oct 2026, committed orders are switched on for every live market, and they are the only one of the protocol’s own venues that fills while prices are pushing. pool_swap fails with PoolClosedWhileLive until the price is more than 300 s old outside Normal. The instant oracle swap (clp_swap) was retired the same day and always fails with SwapDisabled. The order book is a third venue. It is a Manifest book where traders trade with each other, reached through the trading program, and it is open at any hour, and while a market is closed the app shows its orders and the bin books’ quotes as one book.

1. Bin books: closed hours, small

Each market has one protocol-owned pool per side: 26 books across the 13 live markets. The bins sit inline in the Pool account in two zones, with fine core steps near the centre and wide wings further out (QQQ: three 20 bps core steps, then 300 bps wings). The keeper centres each book on NAV plus a small inventory shift, and repositions it when NAV drifts past a gate of at most 20 bps.

Standing depth is deliberately lean. It is sized to organic demand rather than TVL, because the loss to toxic arbitrage grows with deployed depth. Depth is sized per market to measured demand, at least $500 a side. They fill only while the market’s price is stale: when mint and redeem freeze off-hours, the keeper replaces them with a demand-sized free-float book and pool_swap opens.

2. Committed orders: open hours, any size

This is the open-hours path, at any size. You escrow your input into an Order PDA. The order fills at a keeper push made after your commit (not necessarily the first one), at NAV ± max(commit_spread_bps, 10) bps, where the keeper posts commit_spread_bps from the books’ volatility model. Because the price is set after you commit, there is no stale quote to pick off, so there is no size or window cap. The limits are oracle health, the collateral floor and the inventory the keeper has provisioned.

• Only the keeper can settle (clp.authority or market.keeper_authority), at the first push it sees after the commit, so the owner can’t pick the price.
• If a payout or refund can’t reach the owner’s recorded account, the order is held and a permissionless claim pays the owner later.
• A min_out miss refunds in full and closes the order, so it can’t loop on reverts.
• After the 180 s TTL, anyone can send cancel_swap, and the escrow goes back to its owner. The keeper does it about 5 s after expiry. It checks nothing else, so escrowed funds come back whatever the oracle, keeper or admin state.
• Every terminal path closes the Order account and returns its rent to the user.

In the app, a market order is a committed order while the market is open, unless traders’ orders on the order book fill all of it now for less when you buy, or for more when you sell.

End-to-end mint flow

1. User wallet            ─── mint_paired(100 cUSDC)       ──►  mint-redeem program
2. mint-redeem reads      ─── user_twap_price (≤ 300 s old)      from the Market account
3. mint-redeem transfers  ─── 100 cUSDC less the dev tax   ──►  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 keeper isn’t part of the transaction, but the transaction depends on its pushes. Mint and redeem revert with TwapNotAvailable when the last push is more than 300 s old.

End-to-end committed-order flow

1. User    ─── commit_swap(side, direction, amount_in, min_out, nonce) ──►  clp
            input escrowed into an Order PDA, TTL = 180 s
2. Keeper  ─── update_risk_state_v2 (a price push after the commit)    ──►  mint-redeem
3. Keeper  ─── settle_swap() with the Order account                    ──►  clp
            fills at NAV ± committed spread at the first push it sees;
            min_out miss → full refund; either way the Order closes
4. (fallback) after 180 s: the keeper, or anyone, sends cancel_swap;
            the escrow goes back to the user

Why this design

Question	Answer
Why no funding rate?	Long and short supply is issued in pairs and every token is fully backed when minted, so there is no open-interest imbalance to fund. One-sided demand shows up as inventory in the CLP, and the keeper prices it by shifting the book centres: a lone long buyer pays a small premium that funds a lone short buyer’s discount. The short leg does carry volatility decay for the pair’s convexity. Longs carry nothing.
Why no liquidations?	A paired position prepays full collateral. There is no margin to call.
Why two venues?	Each fits a different market state. While prices are pushing, every trade gets a NAV fill at a price set after the commitment, which can’t be latency-arbitraged. While the market is closed no push arrives to settle one, so a lean on-chain book with real slippage fills small trades at once. An instant fill at a live oracle price is a stale quote between pushes, which is why the instant oracle swap was retired and the books close while the price is live.
Why is the committed spread so thin?	The price is set after the commitment, so there is nothing stale to select against. The retired oracle swap charged 30 bps on QQQ, SPY and XAU. The spread still prices the protocol’s convexity exposure on large fills, so it follows the book’s half-spread with a 10 bps floor.
Why is book depth so lean?	Toxic loss grows with deployed depth, while organic revenue is capped by demand. Depth is sized to demand, and the excess goes back to the CLP vault, 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, volatility decay and what they imply for P&L.

CLP and the venues

Book geometry, committed-order mechanics, vault plumbing.

Keeper

Price pushes, book management, settlement crank, fee and decay posting.