1da2fa19c6
- M3 hub: add L3 invariant (360:1 minimum sim speed), six-horizon time table - M3a: add Heston stochastic vol, rough volatility (fBM), HMM regime detection, DCC-GARCH copula, jump-diffusion; six-horizon mapping - M3b: add Hegselmann-Krause bounded confidence, complex contagion, bandit- replicator hybrid, MFG (HJB+FP), pump-and-dump 3-type ABM; six-horizon mapping - M3c: add six-horizon time table - M3d: add Kolokoltsov adversarial (non-linear FP + WENO), DSMFG bilevel optimization, cross-chain adversarial arbitrage; six-horizon mapping - M3e: add kinked lending rate model, DeXposure inter-protocol credit network, composable yield optimizer; six-horizon mapping - M3f: add MFG for validator populations, six-horizon time table - M3g: add Almgren-Chriss optimal execution, six-horizon mapping - CLAUDE.md: add subagent productivity note Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
5.1 KiB
M3 — Sims hub (market prediction simulations)
1. Component
The economy organ's prediction engine: always-running simulations ("Sims") populated by autonomous simulation agents ("Pops") that model market dynamics across multiple mathematical domains and time scales. Sims are queryable at any time by Traders (M5) — they produce predictions with explicit upper and lower bounds on every output value. This is the hub spec; individual sim types have dedicated sub-specs (M3a–M3g).
The academic foundations span AMM mechanism design [1,2], MEV game theory [3,4,5], macro tokenomics via SDEs [6,7], and evolutionary consensus games [8–11].
2. Status / certainty
DESIGN-FIRST · ABSENT. Role C3; implementation C1. Mathematical foundations C4 (literature established); specific model parameters C1.
3. Language & location
TBD · src/economy/sims/. Numerical computing (Julia, Python/NumPy, Octave, or Rust) for the
simulation cores. A query facade accessible to Traders. Each sim type (M3a–M3g) may use a
different runtime suited to its math.
4. Does / does-not
- Does: run continuously at ≥ 360:1 speed (360 simulated seconds per wall-clock second)
across six concurrent time horizons — tick/hourly, daily, weekly, monthly, annual, and
5-year forecast windows; maintain populations of Pops whose behaviors emerge from the sim's
mathematical model; ingest live data from Data Feeds (M2) for calibration; respond to Trader
queries with bounded predictions; produce outputs with explicit upper/lower bounds on
every prediction value.
Horizon Window Sim cadence at 360:1 Tick–hourly Next 1–60 min Real-time (360 sim-sec/s) Daily Next 24h 4 sim-minutes per wall-second Weekly Next 7d ~28 sim-minutes per wall-second Monthly Next 30d ~2 sim-hours per wall-second Annual Next 365d ~1 sim-day per wall-second 5-year Next 1825d ~5 sim-days per wall-second - Does-not: trade (Traders/Marketplace do); make decisions for traders (it informs, they decide); enforce laws (Marketplace does); supervise behavior (Conductor/SAE do); run slower than 360:1.
5. Interface contract
query(sim_type: SimType, query: PredictionQuery) -> BoundedPrediction.SimType∈ {statistical,sociological,amm_liquidity,mev_adversarial,tokenomics_macro,consensus_staking,market_microstructure} (M3a–M3g).BoundedPrediction { value, lower_bound, upper_bound, confidence, time_horizon, sim_type, timestamp }. Every output is bounded — no point estimates without uncertainty ranges. Example:{ value: 7.2, lower_bound: 5.8, upper_bound: 8.9, confidence: 0.73, time_horizon: "4h", sim_type: "amm_liquidity" }.status(sim_type?) -> { running, pop_count, last_calibration, data_freshness }— health check.calibrate(sim_type, feed_data: [NormalizedDatum])— Data Feeds (M2) pushes live data for model recalibration.
6. Dependencies & stubs
- M2 Data Feeds — calibration data source; stub: canned market data.
- M5 Traders — query consumers; stub: canned queries.
- M3a–M3g sub-specs — individual sim implementations; stub: each returns fixed predictions.
7. Invariants / laws
- L1 (C5): sims are always running — they are not invoked on demand. Traders query current state; they don't trigger computation.
- L2 (C5): every prediction output includes explicit upper and lower bounds — no unbounded point estimates. Uncertainty is a first-class value, not an afterthought.
- L3 (C5): sims advance at a minimum speed of 360:1 — 360 simulated seconds per 1 wall-clock second. Sims may run faster but never slower. This ensures predictions stay ahead of real-time market state across all horizons.
- L4 (C4): sims are read-only from traders' perspective — a query never mutates sim state. Calibration happens only from Data Feeds (M2).
- L5 (C4): each sim type is independent — failure in one sim does not cascade to others. Degraded sims report their status; traders handle missing predictions.
- L6 (C3): Pops are simulation constructs, not AI actors — they follow mathematical rules within the sim. Traders (M5) are the AI actors.
8. Build steps
- Define
BoundedPredictionshape and query protocol. - Build the sim runner (lifecycle management for always-on sims).
- Wire M2 Data Feeds → calibration pipeline.
- Implement sub-specs M3a–M3g as they land.
- Wire trader query interface.
9. Tests
Always-on: sim running after init without external trigger. Bounded output: every prediction has lower ≤ value ≤ upper. Query: trader receives prediction without mutating sim. Independence: one sim's failure doesn't affect others. Calibration: new data updates model state.
10. Open items
- Pop lifecycle (birth/death/mutation within sims, or fixed populations?).
- Cross-sim aggregation (do traders query individual sims, or is there a meta-prediction layer?).
- Calibration frequency per sim type.
- Computational budget per sim (how much CPU/GPU each can consume).