Composability

What you can build on top of Continuum. Use cases, patterns, design tradeoffs.

L and S are SPL tokens. The protocol is open. Here are concrete things you can build.

1. Long-only or short-only wrapper

The simplest integration. Most users want a one-click long or short, not “here’s a paired primitive”. Wrap it.

User clicks "Buy QQQ Long"
   │
   ▼
1. mint_paired(amount)             → 0.104 QQQL + 49.95 QQQS
2. sell QQQS (pool_swap, or commit for size) → 0.104 QQQL + ~49.5 cUSDC
3. user wallet ends with long-only QQQ exposure

The reverse for short:

User clicks "Buy QQQ Short"
   │
   ▼
1. mint_paired(amount)             → 0.104 QQQL + 49.95 QQQS
2. sell QQQL (pool_swap, or commit for size) → 49.95 QQQS + ~49.5 cUSDC
3. user wallet ends with short-only QQQ exposure

Implementation: a TypeScript helper that builds both ixns in one transaction (mint + pool_swap are atomic in one tx for book-sized amounts). For larger size, mint then commit_swap the unwanted leg - it fills at the next oracle print at NAV ± 10bps.

UX win: users don’t think about pair mechanics. They think “long” or “short”.

2. Arb bot

In v2 the venues self-peg (every venue prices off the same NAV), so the v1-style “race the pool back to NAV” bot is mostly gone. What remains:

loop:
    for (market, side) in books:
        nav  = read on-chain NAV
        base = read Pool.base_price_1e6
        drift_bps = (base / nav - 1) × 10_000

        if a fast move left in-the-money bins ahead of the keeper's re-pin:
            lift them with pool_swap (no privilege required), close the
            position via the paired round trip (mint/redeem at NAV)

What to know before building one:

• The profit window is one keeper cycle (~30s) and the take is capped at the deliberately lean depth of the in-the-money bins - this is the protocol’s worst case by design, not a leak.
• Closing one-sided exposure risklessly requires the paired round trip, whose hurdle is the mint/redeem fee plus both spreads. Near NAV it rarely clears.
• Committed-order settlement (settle_swap) is permissionless - cranking other users’ pending orders is a public good with no profit, but it means your bot never depends on the keeper’s liveness.

Design tip: the honest expected value here is small. The interesting bot on v2 is a settlement watchdog (crank stuck orders, alert on TTL expiries), not an arb engine.

3. Structured products

Combine multiple Continuum positions to express more complex views.

Dispersion: long index, short components

Buy QQQ-long (paired mint, sell short leg)
Buy NVDA-short (paired mint, sell long leg)
Buy AAPL-short
Buy TSLA-short

Pay-off: profits when the index rises but individual components lag. Captures dispersion / correlation breakdown.

The structured product can be:

• Off-chain orchestrator: a TypeScript service that mints/sells across markets when a user clicks one button.
• On-chain wrapper: a program that bundles the multi-mint into one instruction (atomic, but heavier on accounts).

Delta-neutral basket

Hold paired QQQL+QQQS in equal NAV value.
At small moves, position value barely changes (curve is flat near origin).
At large moves (>20% in either direction), position value increases due to convexity.

This is essentially a long-vol / long-tail bet on QQQ. Pair it with a short straddle on options for a cheap “sell vol on small moves, buy convexity on large moves” structure.

Equity-vs-FX cross

Long S&P 500 (long SPY)
Short USD (long EUR/USD short, short JPY/USD short)

Once forex markets are added, this becomes feasible directly on-chain.

4. Portfolio analytics

L and S have on-chain NAV. P&L attribution is trivial: read the user’s L+S balances per market, compute n_L × L_NAV + n_S × S_NAV, compare to deposit cost.

async function portfolioValue(wallet: PublicKey, markets: Market[]) {
  let total = 0;
  for (const m of markets) {
    const longBal  = await getBalance(m.longMint, wallet);
    const shortBal = await getBalance(m.shortMint, wallet);
    const lNav = navL(m);
    const sNav = navS(m, lNav);
    total += longBal * lNav + shortBal * sNav;
  }
  return total;
}

No off-chain price feed required. NAV is on-chain, signed by the keeper, verifiable by anyone.

5. Custodial UX

A custodian (centralized wallet, broker, fintech app) takes user deposits and:

1. Mints Continuum positions on the user’s behalf.
2. Reflects them in the user’s UI as “QQQ exposure” without exposing the paired primitive.
3. Manages fees/slippage internally.

This abstracts crypto entirely from the user. They see “100 USD long QQQ, currently $103.40” in their app; the custodian handles the on-chain mechanics.

The custodial path is regulatory-sensitive. We don’t take a position on it; the protocol enables it but doesn’t depend on it.

6. Liquidation-free leverage (off-protocol)

Continuum has no leverage. But you can synthetically leverage:

1. Mint paired QQQ                 → 0.104 QQQL + 49.95 QQQS
2. Sell QQQS (book or committed)   → 0.104 QQQL + cash
3. Borrow against QQQL on Kamino   → cash to mint more
4. Mint paired QQQ again           → repeat

Caveats: each loop pays mint+swap fees. Borrow rates apply. And - most importantly - this introduces liquidation risk on the lender’s side (Kamino), not on Continuum. Continuum positions themselves remain unliquidatable.

This is a power-user composition; not something to expose to retail without disclosure.

7. Vault that auto-rebalances

A user deposits cUSDC into a program. The program:

• Mints a target NAV-weighted basket of Continuum markets.
• Periodically (cron, or trigger-based via Switchboard) rebalances by mint/redeem to maintain target weights.
• Charges a management fee.

Implementation: an Anchor program that holds positions in a PDA, exposes deposit/withdraw/rebalance instructions, CPIs to Continuum for the actual mint/redeem.

8. Cross-protocol routing

Aggregate Continuum’s mint/redeem with other DEX swap paths.

For example, a user wanting to short QQQ has three paths:

1. Mint paired Continuum, sell the long leg on the book.
2. Buy QQQS directly on the book or via a committed order (no mint).
3. Borrow USDC on Kamino, buy QQQS, hold.

A router contract can compare quotes across these paths and pick the best one. Continuum benefits because the router will use mint-redeem when it wins on price.

9. Predictive UI / pre-trade simulation

Use the on-chain NAV + your client-side knowledge of the constant-product invariant to simulate a trade before submission:

function simulateMint(amount: BN, market: Market): { qtyL: BN, qtyS: BN } {
  const lNav = market.userTwapPrice.gtn(0)
    ? market.userTwapPrice
    : market.initialLPrice;
  const sNav = market.initialLPrice.mul(market.initialSPrice).div(lNav);

  const fee = amount.mul(new BN(market.mintFeeBps)).div(new BN(10_000));
  const halfValue = amount.sub(fee).div(new BN(2));
  return {
    qtyL: halfValue.mul(new BN(1e6)).div(lNav),
    qtyS: halfValue.mul(new BN(1e6)).div(sNav),
  };
}

Show the user “you’ll get 0.104 QQQL and 49.95 QQQS for 100 cUSDC” before they sign. The actual transaction will produce the same numbers (modulo NAV moving in the seconds between simulation and confirmation).

10. Data product

Continuum’s on-chain state is rich - every mint/redeem, every TWAP push, every CLP allocation is on-chain. Indexers can:

• Track keeper profitability over time (deposit_profit ix history).
• Plot TWAP vs Pyth-spot divergence (where Continuum users got better/worse than spot).
• Aggregate per-user P&L across paired positions and pool trades.

A historical index of pool depth, NAV, and arb spread is a marketable dataset for HFT or analytics shops.

Patterns we like

• Use NAV as the price-of-record. It’s on-chain, signed, and tamper-evident. Don’t roll your own price.
• Route by size. Small instant trades → pool_swap. Anything that would walk the book → commit_swap (NAV ± 10bps at the next print, no size cap). Want the pair itself → mint/redeem.
• Watch the risk state. Don’t queue mints during Stress; surface to the user.
• Don’t build keeper dependencies. Your integration shouldn’t break if the keeper is down for 5 minutes. Use NAV; redeem still works.

Patterns to avoid

• Don’t pre-mint and hold. Continuum positions are NAV-tracking; they don’t need pre-positioning. Mint at the moment of need.
• Don’t assume per-market NAVs are correlated. They are not - QQQ NAV is set by QQQ’s oracle, SPY by SPY’s. Your basket math should treat them independently.
• Don’t skip ATA creation. Idempotent ATA creation costs ~0.002 SOL once per (user, mint). Less than a transaction’s worth. Always pre-create.
• Don’t assume infinite OI. Each market has an oi_cap. If your integration is cap-blowing for a small market, expect rejection. Surface this to the user.

Talk to us

If you’re building, drop a note in Discord - we’d love to feature your project and help with integration. Mainnet partner integrations get prioritized listing slots.

See also

CPI integration

On-chain integration via Cross-Program Invocation.

Reading state

Pull all the data your integration needs.