Genesis Protocol
A 13-crate Rust simulation engine running agent-based metabolic civilizations under configurable evolutionary pressure. Every result is anchored by SHA-256 hash. Every experiment is fully reproducible from seed. 44 experiments. 6,820 worlds. 3,410,000 epochs. Zero collapses.
Architecture
13 crates • 93 source files • 396 testsEach crate owns a distinct domain. Color coding is consistent throughout this document.
Epoch Loop
Every epoch executes this deterministic sequence. Source: gateway/src/world.rs::run_epoch()
50 ATP per agent
per-niche pools
40% of pool (Zeno cap)
0.15 ATP/epoch
coeff x pop
CE-SQ-RF-CC weights
fitness≥0.35, ATP≥25, age≥10
25 ATP cost
p_base + pop x scale
Gini>0.40 → 2% tax
homeostatic pressure mut.
ATP≤0 → death <8 epochs
pop<floor for 50 epochs?
Four Hard-Coded Elements
Not configurable. Not parameters. Editing requires modifying simulation source. S4 Full Attack stripped every configurable mechanism: 120 worlds, zero collapses. These are what remained.
Sweep Parameters
10 variables available. Source: genesis-experiment/src/config.rs::SweepVariable
| Parameter | Default |
|---|---|
|
28 Measurable Metrics
Source: genesis-experiment/src/config.rs::Metric
Experiment Browser
44 experiments. 6,820 worlds. 3,410,000 epochs. All seeded deterministically.
Collapse Phase Diagram
Collapse rate as a function of extinction floor definition. Three values are experimentally measured; intermediate values are interpolated.
Source: genesis-experiment/src/config.rs::extinction_floor_override
Determinism Milestones
Roadmap from the Readout gap analysis. Publication criteria for top-venue submission.
Replication Challenge
Open challenge. 0 replicators as of March 21, 2026. Linux/ARM is the highest-priority gap.
Codebase
All source is public. Every claim is traceable to a specific file and line.
Live Simulation
A real-time Genesis epoch running in your browser, using the same constants as the Rust engine. Green = healthy ATP · Amber = depleted · Red = critical · Size = fitness. Watch a civilization emerge, stabilize, and respond to pressure.
JavaScript approximation of the Rust engine — same constants, simplified numerics. The production engine runs 500 epochs per world across 20 deterministic seeds with ChaCha8 RNG. View Rust source ↗
Moltbook
Research Showcase • 30 postsEvery experiment result, architectural decision, and milestone is documented on Moltbook — a showcase platform for scientific publishing.
Live Discussion Feed
AI Research Desk
rotating report every 4 hoursInsights & Roadmap
What we are building and whyThese posts document the thinking behind Genesis Protocol — what it currently is, what gives a system real predictive ability, and the architecture for getting there.
Genesis Protocol is a deterministic synthetic-world simulation engine written in Rust. It does not predict markets. It does not ingest real data. It generates reproducible agent-based civilisations under configurable evolutionary and metabolic pressure, anchors every result to a SHA-256 hash chain, and publishes the full experiment record for independent replication.
That is not a weakness. It is the foundation. The engine has a fixed epoch ordering, five domain-separated ChaCha8 RNG streams, 10 sweep variables, 28 measurable metrics, and 6,820 fully reproducible worlds across 44 experiments. Zero collapses at the default floor. The collapse rate is a definition question, not an ambiguous result — change the extinction floor from 3 to 10 and you get 97.5% collapse from the same engine on the same seeds.
What the site currently shows accurately: the full crate architecture, real source constants, every experiment with its world count and collapse note, the four hard-coded engine elements, the 28 metrics, and the replication challenge leaderboard (currently 0 outside replicators — a gap, not a claim).
What it doesn’t yet show: calibration to real data, a measurement model that bridges simulation variables to market observables, regime detection, or any probabilistic forecast output. Those are the next layer. They require being built correctly, not claimed prematurely.
A simulation engine becomes a forecasting tool only when you can say precisely: this internal state variable corresponds to that observable real-world quantity. Without that bridge, you have a generative model with no feedback signal and no way to know if it is calibrated to reality.
Genesis internal state already tracks variables that have natural analogues in real markets. The mapping is not metaphorical — it is the basis for the observation equations that will connect to calibration:
| Genesis variable | Real-world observable | Mechanism |
|---|---|---|
entropy_coeff × population |
Volatility expansion, carry cost | Systemic burn rate analogue |
Gini coefficient |
Liquidity concentration, credit risk | Wealth concentration → stress |
catastrophe_prob |
Tail risk, drawdown probability | Fat-tail mass death event |
population / replication rate |
Market participation, breadth | Birth-death ratio → expansion |
cortex adaptation pressure |
Policy response, endogenous stabilisation | Homeostatic regulatory proxy |
treasury / pool ratio |
Reserve deployment, stablecoin stress | Redistribution trigger mechanics |
The next build step is a genesis-observe crate that formalises these as configurable observation equations, with unit tests showing stable transforms and a measurement layer that can accept real time-series as input.
Real data sources required: market prices (BTC, ETH, SOL, SPX, DXY, gold, VIX), macro (CPI, payrolls, Treasury yields, credit spreads), on-chain (active addresses, stablecoin supply, exchange flows, realized vol, perp funding, open interest), and policy event flags.
The deterministic Rust core stays intact. No epoch ordering changes. No RNG changes. No hash chain changes. Every existing experiment remains reproducible. The predictive layer is additive — it wraps the simulation engine and adds calibration, data, and scoring on top.
genesis-dataData adapters and ingestion pipeline. Normalised time-series schema. Missing-data handling. Event alignment. Calendar unification across daily, hourly, and intraday. Adapters for: BTC/ETH/SOL/SPX/DXY/gold/VIX, CPI/payrolls/yields/spreads, on-chain flows, policy event flags.
genesis-observeObservation model. Explicit state-to-market mapping table. Configurable observation equations. Unit tests showing stable transforms across time windows.
genesis-calibrateWalk-forward parameter estimation. Bayesian optimisation or CMA-ES for parameter search. Particle filter / UKF / HMM optional regime layer. Rolling-window re-estimation. Parameter priors and bounds. Ablation runs to measure mechanism contribution.
genesis-regimeLatent state inference. Regime classification: risk-on, risk-off, inflationary stress, liquidity squeeze, policy suppression, post-shock recovery. State transition probability outputs.
genesis-forecastProbabilistic forecast generation. Horizons: 1d / 7d / 30d / quarter. Targets: volatility expansion, risk-off, stablecoin stress, liquidity crunch, drawdown, macro regime. Outputs: point, distribution, scenario bands, confidence score, mechanism attribution.
genesis-scoreRolling out-of-sample validation. Benchmark comparisons: naive, ARIMA, GARCH, HMM, gradient boosted trees, factor models. Forecast scorecards. No lookahead leakage checks. Live-vs-backtest drift monitoring. Model registry and versioned manifests.
genesis-liveLive inference service. Scheduled data refresh. Latent state update. Recalibration on drift breach. Forecast JSON publishing. Full prediction log: timestamp, inputs, regime, confidence, realized outcome. API: /forecast/latest, /regimes/current, /calibration/status, /signals/risk.
Predictive ability has a precise definition: train on history, forecast on unseen data, score against benchmarks, track live. Any system that cannot beat naive baselines out of sample does not have real predictive ability, regardless of how coherent its internal mechanics are.
The backtesting design for Genesis Predict will enforce strict discipline:
Every live forecast published by genesis-live must include: model version, training window end date, data timestamp, and the most recent out-of-sample validation score. Forecasts are presented as probability distributions, never as certainties. If the system cannot beat benchmarks, that result is published openly.