MM0
Launch
Launch a coinCoinsActivitySimulationsShadow runStress testsPerformanceDepthRiskDocsSettings
DOCS / VENUE-INTERFACE

MM0 Venue Interface

Version: 0.1 (Stage 0) · Interface: src/venues/types.ts · Reference implementation: src/venues/synthetic/

1. Rule

MM0 domain logic never knows how a venue represents bins, ticks, arrays or position accounts. The strategy says "deploy X capital, with shape Y, within range Z", and the adapter translates. Venue-specific code lives in exactly one adapter per venue.

2. Interface

interface VenueAdapter {
  venueId; programIds; venueAccounts            // identity + accounts allowed to receive vault tokens
  getPoolState(): PoolState                     // price, step, fee, paused, reserveIntegrity, mints
  getPositionState(owner): VenuePosition[]      // amounts, pending fees, range, inRange
  getQuote(side, amountIn): SwapQuote           // dry-run
  depth(band, owner?)                           // executable depth within ±band (total or owner's share)
  requiredSplit(lower, upper, shape)            // bid/ask value split a range needs at current price
  externalLiquidityPerStep(owner)               // for fee-share estimates
  stepsForLogWidth(w)

  simulateAddLiquidity / buildAddLiquidity
  simulateRemoveLiquidity / buildRemoveLiquidity
  simulateSwap / buildSwap
  simulateRebalance / buildRebalance            // ordered legs, atomic
  collectFees

  simulate(ctx, legs) / buildTransaction(ctx, intentId, legs)
  simulateTransaction(ctx, tx) / sendTransaction(ctx, tx)
  drainFills(owner)                             // fills against owner liquidity → markout analytics
}

2.1 Contract every adapter must satisfy

  1. Build is pure with respect to live state. Instructions for later legs are generated against a scratch copy that reflects earlier legs (e.g. an add after a swap sees the post-swap active bin).
  2. Every instruction is tagged with its leg index (data.leg) and declares every account with a role (authority | source | destination | pool | position). The verifier relies on this.
  3. Only four instruction families map to legs: add_liquidity, remove_liquidity, claim_fee, swap. An adapter must refuse anything else (UNSUPPORTED_LEG).
  4. Atomicity. A multi-leg rebalance either fully executes or not at all.
  5. Simulation fidelity. simulate* must return the same vault delta and positions that send* produces on unchanged state. The executor rejects drift.
  6. Position chunking is the adapter's job. If a venue caps bins/ticks per position, the adapter splits a range into several position accounts.
  7. Active-bin/tick composition rules are enforced (no deposit-withdraw free swaps).

3. Synthetic DLMM (Stage 1 reference)

SyntheticDlmmPool models DLMM-style mechanics: price(id) = p₀ · (1+binStep)^id, constant-sum within a bin, quote-only bins below active and base-only above, fee on input credited per share to the bins that filled the trade, a max of 70 bins per position, active-bin deposits trimmed to bin composition, reserve-integrity tracking, and pro-rata haircuts when reserves are missing. It deliberately omits dynamic/variable fees, protocol fee share, rent, and decimals. The resulting model is conservative and simple.

4. V1 production venue: Meteora DLMM (research candidate)

Why: the bin model gives MM0 real managed-liquidity primitives: discrete placement, shape control (spot / curve / bid-ask), and single-sided liquidity for inventory correction.

Integration checklist. Everything below must be verified against current official documentation and audited source before any Stage 3 work. Nothing here has been verified for this document:

  • Program ID and upgrade authority; audit reports; incident history
  • Current SDK (TypeScript) and whether to build instructions via SDK or IDL directly
  • Bin price formula incl. token decimals; bin-step and fee-tier set per pool
  • Max bins per position (historically limited; check current extended-position support) and position account rent
  • Liquidity distribution parameters (strategy types / weights) and rounding
  • Fee model: base fee + variable (volatility-accumulator) fee, protocol share, claim mechanics
  • Active-bin deposit rules / composition fee
  • Bin array account management (initialization cost, who pays)
  • Token-2022 support and which extensions are accepted
  • Pool pause / admin capabilities (feeds ABNORMAL_POOL_STATE)
  • Event/log format for fills (feeds markouts), plus indexer options
  • Compute-unit budget for remove + swap + add in one tx, or whether rebalances need multiple txs (then define a partial-failure policy)

Later adapters: RaydiumAdapter (CLMM ticks) and OrcaAdapter (Whirlpools ticks, position NFTs) implement the same interface. Tick-based venues map stepsForLogWidth to tick spacing, and requiredSplit to the standard CL amount formulas. No domain code changes.

5. Multi-venue (not V1)

Venue routing starts only after single-venue performance is established. Allocation must compare existing liquidity, volume, fee tier, capital efficiency, expected fees, depth, routing behavior, integration risk, and tx cost. Fragmenting liquidity without a measured benefit is a regression.