990ecd5cc2
sim/economy/sim.py: 1,000 operators choosing MINE, PROVE, HYBRID or OFF per card class with their own clients; sortition by weight with the 10-s window then open claiming, external jobs with the 90/10 split, backlog rule, difficulty clamps, GBM price. Scenarios a to f, 5 seeds: no backlog, no window miss, hash floor 0.74 of pre-event. Traffic sensitivity finds the shortage oscillation only above the proving fleet's capacity (100 to 300 shards per block); at 100 the sortition window (10 s to 20 s) is the lever that removes it. docs/analysis/economy-2026-10-04.md holds the model, assumptions, results, worst case and the proposal (window = p90 shard time plus a swap, 25 s at today's targets; B_p tied to the live fleet), not applied. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
3.1 KiB
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.