Status lines updated from the bench-log, sim/results_v2.md, sim/difficulty/attacks and sim/economy where the evidence existed and the ledger still said Open (M15, M17, M19, M24 fixed and live; F1, F7, F19, E12, E15 answered with evidence; M26, M27, X21 fix built on miner-reliability; the rest annotated with what the experiment needs). New: sim/economy/security_budget.py (E15 fee grid, price paths, hashrate response), fud-fixes section 2.5 (rows 117 to 126), docs/review/ledger-sweep-2026-10-05.md (the running table). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| levers.md | ||
| README.md | ||
| results.md | ||
| security_budget.py | ||
| sim.py | ||
sim/economy
Agent-based economy simulator for Igneum (4 October 2026): 1,000 GPU operators choosing between
mining and proving, each with its own client and its own profit. Model, scenarios, lever study and
results behind docs/analysis/economy-2026-10-04.md. Nothing here is a measurement of hardware;
the one measured input is the RTX 5090 hash rate (229 MH/s, docs/bench-log.md).
Files
| File | What |
|---|---|
sim.py |
the simulator: population, per-tick market (lottery, sortition, open claiming, external jobs, backlog), per-operator decisions, metrics, scenario and lever tables as markdown |
results.md |
raw output of the six-scenario run (5 seeds) |
levers.md |
raw output of the lever study on the worst scenario at launch traffic and at 100 shards per block, with the traffic and observation-window sensitivities |
Model in one paragraph
Ticks of 180 s over 30 days. Each operator holds cards of four classes (5090, 3090, 3060, small) and sets a mode per class: MINE, PROVE (proving-ready, answers assignments and races open claims), HYBRID (mines, swaps program to answer assignments and open claims it can win; 24 GB cards only) or OFF. Per tick: hash rate, a difficulty controller with the spec 2.3 clamps, Poisson blocks, blocks attributed by hash (multinomial), internal shards (Poisson, 3 per block at launch traffic), a 30-day weight per operator (its mined blocks), sortition of 8 assignees by weight with a 10-s exclusive window, open claiming in order of latency (fastest responder wins, race losers waste work), a backlog queue, external jobs (Poisson, dollars, same sortition then open, claim timeout limits which classes may take a job, undeliverable jobs expire), the pool paid per block divided by shards, 90/10 on external jobs, electricity by card and mode, a GBM coin price. Every 12 minutes (own phase) an operator compares expected profit per card-hour by mode from what it observed over the last hour and switches when the gain beats its own hysteresis (5 to 25%) and it has not switched in the last hour.
Runs
python3 sim.py six scenarios, 5 seeds (about 10 minutes)
python3 sim.py --scenarios b --seeds 1 one scenario
python3 sim.py --levers b --seeds 2 lever study on scenario b
python3 sim.py --set ema_ticks=80 --scenarios a,b --seeds 2 behavioural sensitivity
python3 sim.py --dump b --seeds 1 hourly CSV of one run
Requirements: Python 3, numpy (3.10.10, numpy 2.2.6 on 3 October 2026). One run of 30 days takes about 20 s on the M5 Max at nice 19.
Limits
No DAG (blocks are attributed by hash share, no reds); the within-tick market is closed-form, so shard-level luck is averaged over each tick; the difficulty controller is a clamped tracker of the spec rule, not the rule itself; the price process is exogenous (burns do not move it); operators are myopic (they do not value the sortition weight that mining builds); no pool protocol (small operators are treated as pooled for eligibility); no reputation. The assumptions table in the analysis document lists every number and its label.