MM0 Protocol Specification

Version: 0.1 (Stage 0) · Status: draft for review · Applies to: V1 (one token, one vault, one venue, one strategy)

EVERY TOKEN GETS A MARKET MAKER. MM0 makes markets. It does not fake markets.

1. Scope and thesis

MM0 lets an onchain asset fund and attach its own autonomous market maker. A project deposits real, disclosed market-making capital into a Maker Vault. MM0 deploys and manages that capital across approved onchain liquidity venues inside a strict, public Maker Mandate.

The quality of MM0 is measured by how much legitimate market quality it creates per dollar of risk capital, never by how much volume it can generate.

1.1 Non-goals (V1)

Cross-chain MM, CEX accounts or API-key custody, leverage, perps, borrowed inventory, options hedging, derivatives, HFT order-book quoting, MEV extraction, sniper/holder/volume bots, price support, and any form of wash or self-trading. V1 is one token, one vault, one venue, one strategy.

1.2 First principle: no price objective

MM0 never targets price, market cap, volume, transaction count, holder count, or chart appearance. MakerMandate.priceTarget is typed as the literal null, and validateMandate rejects any other value.

2. The Maker

THE MAKER = TOKEN + MAKER VAULT + MAKER MANDATE + MARKET OBSERVER
          + STRATEGY ENGINE + RISK ENGINE + EXECUTOR + PUBLIC LEDGER

Schema: MakerInstance in src/domain/types.ts. Every field in the brief is represented: id, chain, governedToken, quoteAssets, makerVault, mandate (+hash), approvedVenues, strategyConfiguration, riskConfiguration, currentInventory, activePositions, performance, executor, eventLedger, emergencyControls.

2.1 Intelligence stack (seven layers)

The LLM is never the trading engine. The supervisor can only propose one of: strategy selection, widthMultiplier, reserveAdjust. Each is bounded by mandate.strategyBounds, published to the ledger, and activated after a timelock. Risk-increasing changes must also pass a replay simulation gate (§9).

2.2 Control flow (per tick)

MARKET DATA → OBSERVER → REGIME → ACCOUNTING → BREAKERS → STATE
           → (SUPERVISOR, slow) → STRATEGY PLAN → RISK ENGINE ─ fail → REJECT (ledger)
                                                              └ pass → EXECUTOR
                                    EXECUTOR: build → verify tx → re-simulate → send → RECEIPT (ledger)

Implemented in Maker.tick() (src/maker/maker.ts). There is no code path from strategy, supervisor or admin to the venue that bypasses evaluateIntent and verifyTransaction.

3. Objects

3.1 Intent legs

Only four leg kinds are executable: ADD_LIQUIDITY, REMOVE_LIQUIDITY, COLLECT_FEES, SWAP (approved pair only). FORBIDDEN_LEG_KINDS (TRANSFER_EXTERNAL, BORROW, LEND, LEVERAGE, BRIDGE, APPROVE_PROGRAM, STAKE, SET_AUTHORITY, BUY_ASSET) exist in the type system only so tests can prove they're rejected. No builder emits them, and no venue adapter can translate them.

4. Maker Mandate

The mandate defines the box. Presets live in src/domain/mandate.ts:

ACTIVE is not marketed as more profitable. It deploys more capital in narrower ranges, re-ranges more often, and accepts larger loss limits. That means more fee capture and more divergence loss, adverse selection and drawdown.

Turnover definition. Turnover is measured as swap notional plus net increase in deployed value. Re-ranging the same capital (remove → add) isn't turnover, but it's capped separately by maxRerangesPerDay and the cooldown. Initial deployment therefore ramps, one maxActionSize step per cooldown.

Mandate validation (validateMandate) rejects: any forbidden permission set to anything but false; a non-null price target; inconsistent inventory bands; maxDeploy that violates the reserve or venue exposure; undisclosed funding sources. The mandate hash (sha256(canonicalJson(mandate))) is published to the ledger at creation and stamped on every receipt.

5. Objective function

MM0 does not optimize gross volume. For an evaluation window [0, T] with no external flows (flows are removed by unitization, see the Accounting Spec):

J(θ) =  F_T                                   legitimate LP fees earned (collected + accrued)
      + w_D · ∫₀ᵀ D_t dt                       value the mandate assigns to MM0's ±2% depth contribution
      − L_T                                   divergence loss (LP value vs HODL, excl. fees, costs, own swaps)
      − R_T                                   rebalance cost: impact + fees paid on MM0's own inventory swaps
      − C_T                                   transaction costs (base + priority fees, rent not refunded)
      − λ_I · ∫₀ᵀ (s_t − s*)² · NAV_t dt       inventory risk: squared deviation of base share from target
      − λ_DD · MDD_T · NAV_0                   drawdown penalty
      − λ_C · ∫₀ᵀ HHI_t · NAV_t dt             venue concentration (zero in single-venue V1)

subject to every mandate constraint holding at every action (§6), where:

• θ is the strategy's parameter vector (width multipliers k_r, deploy fractions d_r, thresholds), which may vary only inside mandate.strategyBounds;
• s_t is base share of NAV, s* is the mandate target;
• D_t is MM0-owned quote value executable within ±2% of the active price;
• w_D, λ_I, λ_DD, λ_C are mandate-specific (objectiveWeights). w_D = 0 by default, which makes J purely economic. A project that values depth as a public good can set w_D > 0 explicitly and publicly.

There is no universally optimal weighting. The strategy is a parametric policy π_θ, and θ is calibrated to maximize E[J] on in-sample data, then validated out-of-sample (walk-forward, Stage 2). MM0 never claims the policy is optimal, only that its parameters were chosen and tested this way.

In code: the simulator reports every component (RunMetrics: fees, divergence, costs, drawdown, depth, time in range). The replay gate uses J = netPnL − λ_DD · MDD · NAV₀.

6. Invariants

Every executable action satisfies all of the following, checked by the risk engine (evaluateIntent) before execution and by verifyTransaction before signing. IDs match RiskCheckId.

Invariants I1–I23 are unit-tested in test/risk-invariants.test.ts, I24–I25 in test/execution.test.ts, and I26–I27 in test/core.test.ts. I8 is also checked externally: ledgerTimelineChecks replays the public ledger and confirms that no risk-increasing action was executed under a blocking condition, which is what an outside auditor would do.

7. Agent states and modes

INITIALIZING → OBSERVING (warm-up) → MAKING ⇄ DEFENSIVE
                                       ↓ ↑
                              REBALANCING (transient, inside an action)
any → CIRCUIT_BREAK (CIRCUIT_BREAK/HALT breaker) · PAUSED (emergency authority)
    · OUT_OF_CAPITAL · SHUTTING_DOWN

Modes: BOOTSTRAP (history < minHistoryMinutes or no oracle), NORMAL, DEFENSIVE, SAFE. The bootstrap caps (lower deployment, wider ranges, no swaps without an oracle) apply alongside defensive caps.

Safe mode on CIRCUIT_BREAK or PAUSED follows the mandate: WITHDRAW_TO_VAULT (default) removes all liquidity and performs no swaps. Withdrawal is a non-trading operation and does not panic-sell. HALT (vault invariant failure) freezes everything, withdrawals included, until a human reset, because the maker can no longer trust its own view of the vault.

8. Range engine and strategy (V1: VOLATILITY_ADAPTIVE_CL)

Inputs: reference price, spot, σ (EWMA, half-lives 1h/24h, σ_eff = max(short, long), prior-seeded for new tokens), regime, inventory, NAV, 24h volume, fee rate, external liquidity near the active price.

h       = clamp(k_r · m_w · m_boot · σ_eff · √T, h_min, h_max)            log half-width
shift   = clamp(g · (s − s*), −0.5, 0.5)
center  = ref · exp(shift · h)          range = [center·e^(−h), center·e^(h)]
deploy  = min(d_r, maxDeploy, 1 − minReserve − reserveAdjust, maxVenueExposure, caps(mode))
P(exit) = 1 − Σ_{n odd} 4/(nπ) · sin(nπx/L) · exp(−n²π²σ²T / 2L²)      x = ln(spot/lower), L = 2h
U       = E[min(τ, T)] / T                                              time-to-first-exit utilization
E[fees] ≈ V₂₄ · (T/24h) · fee · share · U,   share = m/(m + ext) per price step

P(exit) is the exact survival probability of driftless Brownian motion in an interval (validated against Monte Carlo in test/core.test.ts). All outputs are estimates under a lognormal model, and receipts present them as such.

Decisions. The engine first collects fees above threshold. It then reduces deployment when it is above target (risk-reducing, always allowed). With no positions it deploys. With positions, it re-ranges on OUT_OF_RANGE (after a grace period), EDGE_PROXIMITY, EXIT_PROBABILITY, REGIME_WIDTH_CHANGE, INVENTORY_HARD_LIMIT, or INVENTORY_SKEW. Otherwise it tops up toward target, and doing nothing is a valid and frequent outcome. A re-range is atomic: REMOVE ALL → optional bounded SWAP → ADD, so an inventory swap never trades against MM0's own liquidity.

Inventory. Soft breach: the range is skewed so the over-held asset sits on the side that sells it. Hard warning: in addition, an optional bounded swap toward the soft edge is made, capped by action size, turnover and impact, and only with a fresh oracle. Hard breach: liquidity goes only on the reducing side (ask-only when base-heavy), and the DEFENSIVE breaker caps deployment. Symmetric top-ups are suspended near the hard limits. MM0 never buys inventory back "at any price".

Regimes (src/strategy/regime.ts): CALM < 40%, NORMAL < 90%, VOLATILE < 160%, else STRESSED (σ_eff annualized). Acceleration (σ_short / σ_long > 2.5) bumps the regime one level. A 1-minute reference move > 8% or venue/oracle deviation > 1% → DISLOCATED. External ±2% depth < 40% of its 24h EMA → LIQUIDITY_SHOCK. Escalation is immediate, de-escalation needs 60 minutes of persistence. Every regime carries its numeric reasons.

Multi-range bands (CORE / ACTIVE / TAIL) are deliberately not in V1. They are a Stage 2 experiment, adopted only if walk-forward simulation shows a material improvement in J.

9. Strategy governance

Execution and strategy change are separate. Re-ranging an approved position may happen several times a day. Changing the strategy is slow and goes through four steps:

1. Propose: a supervisor recommendation passes validateSupervisorOutput: strict keys, enum reasons, bounded numbers, and summary treated as display-only text.
2. Validate: validateStrategyConfig checks that the proposed config stays inside the mandate box. For risk-increasing changes (narrower width, less reserve, leaving WIDE_DEFENSIVE_CL), a replay gate also runs current vs proposed over the maker's own last 72h of reference prices and requires J_proposed ≥ J_current − 0.1% NAV. With no validator configured, risk-increasing changes are rejected.
3. Publish: STRATEGY_CHANGE_PROPOSED goes to the ledger with direction, reasons and simulation metrics.
4. Activate: after a timelock (default 60 min), STRATEGY_CHANGE_ACTIVATED is recorded.

10. Public surfaces

10.1 Action receipts

Every executed, failed or verification-rejected action produces an ExecutionReceipt with: action number, action, venue, previous and new range, capital, structured reason codes + rationale, inventory before/after, risk result, tx id, vault delta, fees collected, tx cost, model version, strategy version, and mandate hash. No chain-of-thought is ever recorded; rationales are generated from numbers by templates.

10.2 Ledger

EventLedger (src/ledger/ledger.ts) is append-only and hash-chained (hash = sha256(canonical(body ∥ prevHash))). Event types include MAKER_CREATED, MANDATE_PUBLISHED, TOKEN_PREFLIGHT, DEPOSIT, STATE/MODE/REGIME_CHANGED, ACTION_EXECUTED/FAILED/REJECTED, CIRCUIT_BREAKER, INVENTORY_WARNING, SUPERVISOR_*, QUANT_*, STRATEGY_CHANGE_*, EMERGENCY_CONTROL and DAILY_SNAPSHOT. In production the head hash is anchored onchain periodically.

10.3 Maker page (mm0.pro/maker/[token])

This page shows capital, deployed, reserve, state/mode, venue, ±1/2/5% depth with MM0's contribution, fees, net MM P&L with attribution (fees / inventory / costs), realized vs unrealized, vs-HODL, max drawdown, inventory split, active breakers, positions, actions, mandate, and ledger head. A text rendering is produced by makerPage() in src/simulator/report.ts.

10.4 Market Quality Score (specified, not shipped in V1)

If shipped, the score must be decomposable:

Every input and weight is shown next to the score.

11. Protocol economics

Options, with their incentive analysis:

Preliminary recommendation: a low NAV-based management fee plus a performance fee on flow-adjusted net market-making P&L versus the HODL benchmark, above a high-water mark. "Performance" means ΔNAV_unitized − ΔHODL, net of fees, costs, realized and unrealized inventory, and adjusted for capital flows. Gross LP fees are never called profit. The final choice is deferred until Stage 2 and 3 data exist.

12. Numerics

The simulator uses float64. Onchain programs must use fixed-point integer math (u64 amounts, Q64.64 prices) with explicit rounding toward the vault on deposits and away from the vault on withdrawals, checked-arithmetic everywhere, and property tests against the float reference model.

13. Development stages

Stages are not skipped because the UI looks good.