igneum/docs/analysis/economy-2026-10-04.md

Igneum economy: mining versus proving under stress, agent-based simulation

4 October 2026. Model, not hardware. Simulator sim/economy/sim.py, raw output sim/economy/results.md (six scenarios, 5 seeds) and sim/economy/levers.md (lever study and sensitivities on the worst scenario). Answers the external reviewer's point 3 (round 3, operator of a large GPU farm; ledger P8, P9, E6, M14): do the pricing, rewards, capacity limits and recovery rules keep both roles filled under stress, or does the system oscillate between shortages?

Every number in this document is a model output or a model assumption. The one measured input is the RTX 5090 lottery hash rate, 229 MH/s (docs/bench-log.md, RTX 5090 first run). Everything else is labelled approximate in the assumptions table and should be replaced by the phase 2 and phase 4 measurements as they land.

1. The question and the thresholds, fixed before running

Thresholds, defined before the first run:

Id	Failure	Threshold
T1	Miner shortage that threatens security	Total hash under 50% of the scenario's own days 1 to 7 mean for one hour or more (half the pre-event hash is the point where a renter of the pre-event size holds a majority)
T2	Backlog	Oldest unproven block older than 600 s at any time (the design's own backlog-rule trigger, docs/design/execution-layer.md 4.3)
T3	Growing backlog	Daily maximum of the oldest unproven age has a positive linear trend over the last 10 days and is above 60 s on day 30
T4	Window miss	Any day with under 90% of blocks proven within 60 s of the block (the design's 20 to 60 s lag)
T5	Oscillation	The share of cards in proving mode has a 10th-to-90th percentile range over 10 points across the last 10 days

2. The model

Agent-based, 1,000 operators, 30 simulated days, ticks of 180 s, 5 seeds per scenario. Each operator owns a fleet of cards in four classes and sets a mode per class with its own client, every 12 minutes at its own phase, by comparing expected profit per card-hour:

Mode	What the card does	Who can
MINE	Hashes; earns its hash share of the 80% producer emission	Every class
PROVE	Proving-ready; answers shard and job assignments, races open claims; idle power while waiting	5090, 3090, 3060
HYBRID	Hashes; swaps program (5 s each way, approximate) to answer its own assignments and open claims it can win	5090, 3090 only (the mining dataset and the prover must both be resident; a 12 GB card cannot hold both, approximate)
OFF	Nothing	Every class

Per tick the market resolves in this order: hash rate; a difficulty tracker with the spec 2.3 clamps (3% harden, 10% ease per block, 120-block estimate); Poisson blocks; blocks attributed by hash (multinomial); each operator's 30-day weight (its mined blocks, the finality-rule population of spec 7.2); internal shards (Poisson, 3 per block at launch traffic); external jobs (Poisson, dollars); for each class of work, sortition of 8 assignees by weight with a 10-s exclusive window, assignee responds if it has proving-ready or hybrid capacity, the assignee's proof wins when it lands before the fastest open claimer's (window plus the fastest responder's shard time), else the shard is open and the fastest responder wins, race losers waste half an attempt per open shard; a backlog queue served by any capacity; the proving pool (20% of emission) paid per block divided by the block's shards; external jobs paid in dollars with 10% burned; electricity by card, mode and busy fraction; a GBM coin price. Operators observe the last hour (EMA) of realised rates: mining income per hash, open-claim income per proving card by class, assigned income per unit of weight (internal and external separately), and value PROVE and HYBRID at their own weight. A switch needs a gain above the operator's own hysteresis (5 to 25%) and at least an hour since its last switch. Operators are myopic: they do not value the weight that mining builds for future assignments.

What the model keeps from the design: the 80/20 split, the fixed pool per block divided by shards, sortition by weight with 8 assignees and a 10-s window then open claiming with no bond (spec 7.2), the eligibility population (spec 3), the 90/10 external split (spec 5.4), the backlog rule halving B_p per 600 s of oldest age (design 4.3), the claim timeout limiting which cards can take a job (design 6, O-5.6), the controller clamps (spec 2.3), emission per block (spec 2.5, ramp complete, pre-halving).

2.1 Assumptions table

Item	Value	Label
Operators	1,000; fleet size lognormal (median 5 cards, mean about 15); operator 0 is a farm of 5090s holding 20% of hash (30% in scenario e) at $0.05/kWh	Assumed
Card mix by count	5090 25%, 3090 25%, 3060 30%, small 20%	Approximate
Hash rate	5090 229 MH/s (Measured); 3090 57 (a quarter), 3060 46 (a fifth), small 25	Approximate except the 5090
Power while hashing	450, 320, 170, 120 W	Approximate
Power while proving / idle-ready	500 / 60, 350 / 50, 170 / 30 W	Approximate
Shard time	3060 20 s (the phase 2 gate target, Target, unmeasured); 3090 12 s, 5090 6 s scaled by throughput; small cards cannot prove (8 GB)	Approximate; ledger P1
Electricity	Lognormal around $0.10/kWh (sigma 0.4), larger fleets cheaper, clipped to $0.02 to $0.40	Assumed
Emission	31.688 IGN per block, ramp complete, first halving period (spec 2.5)	Designed
Coin price	$0.012 at t=0 (chosen so the median-electricity 3060 mines at a thin margin); 5% daily volatility, geometric	Assumed; only the ratio of price to electricity matters
Internal traffic	3 shards per block at launch; sensitivity at 30, 100, 300	Assumed
External demand	$2,000 per day in $50 jobs of 10 shard-equivalents (the customer brief's "low millions a year" market, a share of it)	Approximate
External price shock (b)	Price per job x10 from day 7	Scenario
Program swap	5 s each way (hybrid)	Approximate; ledger M11 measured 69 to 129 ms for the lottery kernel, the prover side is unmeasured
Aggregation plus inclusion	4 s added to every block proof	Approximate
Open-claim waste	0.5 wasted attempts per open shard	Assumed
Claim timeout (external)	300 s: a class may claim a job only if its shard time x job work fits	Assumed; O-5.6 is open
Observation window	1 h EMA; decisions every 12 min; 1 h minimum dwell; hysteresis 5 to 25%	Assumed; sensitivity at 20 min, 3 h, 24 h
Pools	Small operators are treated as pooled for eligibility; the pool forwards assignments to members by weight	Assumed; no pool protocol exists (spec 9 pending)
Burn	Reduces prover take only; no price effect modelled (the burn is 0.01% of supply per day at baseline)	Assumed

2.2 Scenarios

Id	Scenario	Event
a	Baseline	none
b	External demand pays 10x while the coin price falls 70% over a week	from day 7; price falls days 7 to 14
c	No external demand	whole run
d	The largest operator (20% of hash) disappears	day 10; its weight stays in the window
e	A 30% operator never fulfils its assignments	whole run; it mines only, keeps its weight
f	A pool with hash equal to the network's switches in (2x hash)	day 10; 200 new operators with no weight

3. Results, six scenarios, 5 seeds

Means over seeds, with the seed minimum and maximum in sim/economy/results.md.

Metric	a	b	c	d	e	f
Hash share of potential hash that is mining (mean)	0.93	0.85	0.96	0.92	0.91	0.93
Cards in PROVE mode, day 10 / day 30	0.15 / 0.15	0.27 / 0.34	0.08 / 0.09	0.15 / 0.13	0.22 / 0.21	0.15 / 0.17
Cards in HYBRID mode, day 30	0.54	0.45	0.54	0.45	0.42	0.50
Cards OFF, day 30	0.01	0.10	0.01	0.09	0.01	0.06
Hash minimum / pre-event mean	0.95	0.82	0.97	0.75	0.98	0.95
Hash day 30 / pre-event mean	1.00	0.87	1.00	0.80	1.00	1.92
Hours with hash under 50% (T1)	0	0	0	0	0	0
Backlog maximum, shards	0	0	0	0	0	0
Oldest unproven age maximum, s (T2)	0	0	0	0	0	0
Blocks proven within 60 s, mean / worst day (T4)	1.00 / 1.00	1.00 / 1.00	1.00 / 1.00	1.00 / 1.00	1.00 / 1.00	1.00 / 1.00
Blocks proven within 20 s	0.26	0.41	0.29	0.21	0.14	0.27
Blocks per second, mean (hourly min to max)	1.00 (0.95 to 1.05)	same	same	same	same	same
Difficulty day 30 / day 1	1.00	0.86	1.00	0.80	1.00	1.91
External jobs delivered	1.00	1.00	none	1.00	1.00	1.00
Proving-share 10-90 range, last 10 days, points (T5)	8.5	7.4	2.8	8.5	3.8	5.7
Mode switches per operator-class per day	2.0	1.2	1.7	2.1	1.0	2.1

Flags (seeds tripping / 5): T1 0 in every scenario; T2 0; T3 0; T4 0; T5 0 except f, 1 of 5 (range 10.1 points).

Operator profit by card class, $ per card-day, every mode including OFF, and the share of shards each class proves:

Scenario	5090	3090	3060	small	shards 5090	shards 3090	shards 3060
a	6.37	1.66	0.78	0.39	0.59	0.26	0.16
b	5.17	1.82	1.36	0.15	0.63	0.19	0.18
c	6.12	1.57	0.76	0.39	0.62	0.29	0.09
d	6.48	2.34	1.06	0.57	0.53	0.31	0.16
e	5.08	1.53	0.85	0.31	0.43	0.28	0.29
f	3.35	0.69	0.43	0.15	0.56	0.25	0.19

3.1 What the runs show

1. No backlog in any scenario, and no shortage of provers. At launch traffic the chain needs about 3 shard-seconds of 3060 time per second; the fleet has thousands of proving-ready card-seconds. The 20% pool is a fixed subsidy per block, so provers are competing for a fixed pot, not filling a capacity. The equilibrium is a surplus of proving capacity in every scenario, including c (no external income) and e (30% of draws wasted). Every block is proven inside 60 s in every hour of every run.
2. The dominant strategy on 24 GB cards is HYBRID: mine, answer your own assignments. About half of all cards end there in every scenario. It costs the card nothing while no assignment arrives, and sortition by weight hands assignments to the cards that mine. This is what the design intends ("the same cards") and it is what a profit-maximising client does on its own. The 20 to 60 s window is met with margin; the under-20-s share is 14 to 41% because a hybrid 3090 (12 s plus a 5 s swap) and a 3060 (20 s) cannot land inside 16 s.
3. The stress lands on hash, not on proofs. Scenario b (price down 70%, external up 10x) takes 10% of cards off and moves a third into PROVE; hash troughs at 82% of its pre-event level and ends at 87%. Scenario d removes 20% by construction and the remaining operators do not fill the gap (hash 80% at day 30; the dead operator's weight wastes its draws for 30 days with no effect on the 60-s window). Neither reaches T1. The design's own observation (ledger C7) stands: hash follows price, and the proving income does not change that because it is 20% of the same emission.
4. No shortage oscillation. The proving share moves 3 to 9 points across a day (T5 range), driven by 3060 owners parking in PROVE when mining is marginal and leaving when a job lands elsewhere. It is churn among the cards that matter least for latency, not a swing between shortages: hash never moves more than 5 points with it (a, c, e, f). The one T5 trip (f, one seed) is the arriving pool's 3090s settling into hybrid.
5. Shard income concentrates on fast cards. The 5090 class (25% of cards, 57% of hash) proves 53 to 63% of shards; the 3060 class proves 9 to 29%. The acceptance test of spec 7.2 ("the fastest prover wins under 25% of shards", R7) is written per prover, not per class; by weight the 5090 share matches its hash share, so sortition by weight does what F17 asked. Open claiming is where the fast cards win beyond their weight (scenario c, 3060 share 0.09).
6. Scenario f: a pool with the network's own hash arrives with no weight. It mines, difficulty doubles within the hour, incumbents' income halves, 6% of cards go off (the expensive 3060s and small cards). The newcomers cannot be assigned shards for 30 days and only win open claims, which they do (their 5090 hybrids win the open race). No backlog, no window miss.

4. The worst case

Scenario b. Hash 82% of pre-event at the trough and 87% at day 30, 10% of cards off, 34% of cards in PROVE mode (up from 15%), every external job delivered, no backlog. It is the worst on the two thresholds that moved (T1 distance and cards off) and it is the one with a mechanism that could get worse: when the coin falls and dollar jobs rise, cards leave the lottery for the job market, and nothing in the protocol pulls them back except the lottery's own difficulty fall. In this run the fall was 14%, far from the 50% line. A deeper price fall or a longer one scales it: the 3060 at median electricity is at break-even at $0.012 x 0.3 and the small cards are below it.

The worst case that does cross the thresholds is scenario b with chain traffic above the proving fleet's capacity (section 5.2): at 100 shards per block the oldest unproven block reaches 325 s (85 s in the 3-shard sensitivity run with its different seeds; 2 seeds each) and hash troughs at 62% of pre-event; at 300 the backlog is permanent, 17.5% of blocks miss the 60-s window on the worst day, and hash spends 22 hours under the T1 line swinging between 6% and 60% of pre-event. That is the shortage oscillation the reviewer described, and it needs traffic 30 to 100 times the launch assumption to appear. The lever study is run at 100 shards per block, the first traffic where the design's rules are load-bearing.

5. Lever study on scenario b

Two runs, 2 seeds each, one parameter at a time with the rest at the design values (sim/economy/levers.md). The balance score is the mean of three terms: hash at day 30 over pre-event (capped at 1), the worst day's share of blocks within 60 s, and 1 minus the maximum oldest-unproven age over 600 s (floored at 0).

5.1 At launch traffic (3 shards per block): no lever is load-bearing

Lever	Value	Hash min / pre	Hash d30 / pre	Age max, s	Worst day within 60 s	Cards off d30	3060 shard share	Score
pool	0.10	0.81	0.84	0	1.000	0.09	0.15	0.947
pool	0.20 (design)	0.81	0.84	0	1.000	0.13	0.18	0.947
pool	0.30	0.82	0.87	0	1.000	0.12	0.20	0.955
pool	0.40	0.77	0.78	0	1.000	0.19	0.19	0.927
window	5 s	0.75	0.78	0	1.000	0.15	0.10	0.927
window	10 s (design)	0.81	0.84	0	1.000	0.13	0.18	0.947
window	20 s	0.84	0.85	0	1.000	0.11	0.23	0.951
window	30 s	0.84	0.85	0	1.000	0.11	0.23	0.951
burn	0	0.80	0.83	0	1.000	0.13	0.18	0.944
burn	0.10 (design)	0.81	0.84	0	1.000	0.13	0.18	0.947
burn	0.25	0.78	0.82	0	1.000	0.15	0.17	0.940
burn	0.50	0.82	0.84	0	1.000	0.14	0.17	0.947
timeout	60 s	0.83	0.86	0	1.000	0.25	0.06	0.954
timeout	120 s	0.79	0.84	0	1.000	0.24	0.05	0.946
timeout	300 s (default)	0.81	0.84	0	1.000	0.13	0.18	0.947
timeout	600 s	0.81	0.84	0	1.000	0.13	0.18	0.947

All four levers move the score by under 3 points because the proving side is never binding at this traffic. The pool share and the burn move money between miners and provers and change little else; a 40% pool takes 19% of cards off (the lottery's 60% can no longer carry the expensive cards). A short claim timeout (60 to 120 s) shuts the 3060 class out of jobs: a quarter of cards go off, hash does not fall because the cards that leave were not hashing.

5.2 Sensitivities at launch traffic

Sensitivity	Value	Hash min / pre	Hash d30 / pre	Hours hash under 50%	Age max, s	Worst day within 60 s	Proving share range, points	Score
Traffic, shards per block	3 (default)	0.81	0.84	0	0	1.000	7	0.947
Traffic	30	0.82	0.89	0	0	1.000		0.962
Traffic	100	0.63	0.85	0	85	0.994		0.902
Traffic	300	0.06	0.75	22	(see note)	0.825		0.525
Observation window	20 min	0.80	0.86	0	0	1.000		0.952
Observation window	1 h (default)	0.81	0.84	0	0	1.000		0.947
Observation window	3 h	0.85	0.85	0	0	1.000		0.951
Observation window	24 h	0.81	0.82	0	0	1.000		0.939

Traffic is the variable that matters. At 100 shards per block (33x the launch assumption; about 2,000 3060-cards busy full time, 13% of the fleet) a backlog of 85 s appears and hash troughs at 63% of pre-event. At 300 the fleet cannot keep up at all: the backlog is permanent, the backlog rule halves B_p repeatedly, blocks miss the 60-s window (82.5% on the worst day), and the hash swings between 6% and 60% of pre-event with 22 hours under the T1 line, because every card that can prove chases the backlog's open claims and then returns when it clears. That is the shortage oscillation the reviewer asked about, and it exists only above the proving fleet's capacity. (The 300 row's age column in levers.md is invalid, produced before the age formula was corrected; its other columns stand.) The operators' observation window changes the churn and almost nothing else.

5.3 At 100 shards per block: the window is the lever

Lever	Value	Hash min / pre	Hash d30 / pre	Age max, s	Blocks within 60 s	Worst day within 60 s	Cards off d30	3060 shard share	Score
pool	0.10	0.59	0.81	168	1.000	0.994	0.05	0.22	0.841
pool	0.20 (design)	0.62	0.84	325	1.000	0.994	0.07	0.22	0.765
pool	0.30	0.64	0.86	16	1.000	0.999	0.07	0.21	0.945
pool	0.40	0.67	0.79	0	1.000	1.000	0.10	0.21	0.931
window	5 s	0.53	0.79	565	0.993	0.929	0.04	0.11	0.592
window	10 s (design)	0.62	0.84	325	1.000	0.994	0.07	0.22	0.765
window	20 s	0.77	0.84	0	1.000	1.000	0.08	0.24	0.948
window	30 s	0.77	0.84	0	1.000	1.000	0.08	0.24	0.948
burn	0	0.58	0.75	325	1.000	0.994	0.11	0.19	0.733
burn	0.10 (design)	0.62	0.84	325	1.000	0.994	0.07	0.22	0.765
burn	0.25	0.63	0.83	325	1.000	0.994	0.07	0.21	0.761
burn	0.50	0.64	0.80	325	1.000	0.994	0.10	0.21	0.750
timeout	60 s	0.45	0.82	325	1.000	0.994	0.20	0.08	0.757
timeout	120 s	0.75	0.89	325	1.000	0.994	0.09	0.07	0.780
timeout	300 s (default)	0.62	0.84	325	1.000	0.994	0.07	0.22	0.765
timeout	600 s	0.62	0.84	325	1.000	0.994	0.07	0.22	0.765

The sortition window is the single parameter that restores balance: 10 s to 20 s takes the worst backlog from 325 s to 0, the hash trough from 62% to 77% of pre-event, the worst day from 99.4% to 100% within 60 s, and the score from 0.765 to 0.948. Nothing else reaches it except a 30% pool (0.945), which buys the same backlog relief by pulling more cards into proving at a cost to the lottery. The burn and the claim timeout do not touch the backlog at all (325 s in every row): they move external money, and external jobs are not what fills the queue.

Why the window works. With a 10-s window and a 20-s shard, no 3060 and no hybrid 3090 (12 s plus a 5-s swap) can land its assigned proof before the open race starts, and the fastest open claimer (a 5090, 6 s, or a hybrid 5090 at 11 s) beats it. So the assignment is wasted work for the slow classes, they stop answering, every such shard is proved by an open race in which losers waste capacity, and the pool concentrates on the 5090 class. At 20 s or more the assignee finishes first, the duplicated work disappears, the 3060 class's share rises from 0.11 (5 s) to 0.24, and the fleet's whole capacity counts. The window is an exclusivity, not a delay: a proof that lands early is included early, so a longer window costs no latency when the assignee is fast. A 5-s window is the worst value in the table (score 0.592, worst day 92.9%).

6. Proposal

Proposed, not applied (spec 7.2 item 3 and 7.4; O-5.1 is the parameter's home):

1. Set the exclusive window from the shard-time distribution, not at 10 s. Rule: window = the 90th percentile of the eligible fleet's measured shard time plus one program swap, rounded up to 5 s; at today's targets that is 25 s (20 s on the 12 GB gate card plus 5 s). The phase 4 devnet test (O-5.1) already measures the shard-time distribution across three prover speeds; this makes the window a function of that measurement and keeps the acceptance test (the fastest prover wins under 25% of shards). Nothing in the proof protocol or the records changes; the parameter is a consensus constant either way. In the model the gain is 0 backlog and 15 points of hash at 100 shards per block, and no cost at launch traffic.
2. Tie B_p to the live proving fleet rather than a launch calibration. The design's formula (docs/design/execution-layer.md 4.3) sets B_p from cards_proving read on the testnet. The simulation says the system fails only above the fleet's capacity, and the fleet moves with price (scenario b: a third of cards change mode). The backlog rule halves B_p only after 600 s of age, which is 10 minutes of a growing queue. A candidate: B_p re-derived every difficulty window from the shards proved within the window in the trailing 24 h, bounded by the halving rule. This is a design question for the execution engineer and is listed here as a finding, not as a rule.
3. Leave the pool share, the burn and the claim timeout as designed. None of them moves the thresholds in either run. The pool share should not be raised to buy backlog relief (a 40% pool takes 10 to 19% of cards off the lottery); the window does the same job for free. The claim timeout is a market parameter for O-5.6: 120 s keeps jobs on 24 GB cards and the 3060 class on the lottery, which the hash figures favour (0.89 at day 30), and that is the value this study would start the devnet with.

7. Answer to the reviewer

At launch traffic, both roles stay filled in every scenario: every block is proven within 60 s in every hour of every run, no backlog forms, and hash never falls below 74% of its pre-event level (that floor is scenario d, by construction). The proving side is over-provisioned because the 20% pool is a fixed pot per block that cards compete for, not a capacity they fill, and because the dominant client strategy on 24 GB cards is to mine and answer assignments (half of all cards end there). The system oscillates between shortages only when traffic exceeds what the proving fleet can clear (100 to 300 shards per block in this fleet), and the 10-s sortition window is what wastes the slow half of that fleet first. Raising the window to the slowest eligible shard time plus a swap (25 s at today's targets) removes the backlog and 15 points of the hash loss at 100 shards per block and costs nothing at launch traffic.

8. What the model does not capture, and the three assumptions trusted least

1. Shard time and the hybrid swap (ledger P1, M11). The 20-s 3060 shard is the phase 2 target, unmeasured; the 5-s program swap on the prover side is a guess. Both set who wins the window race and the under-20-s share. If the swap is 30 s, HYBRID loses the race to PROVE cards and the mode split changes; the 60-s result survives unless shard times exceed 40 s.
2. Operator behaviour. Hourly observation, 12-minute decisions, 1-hour dwell, 5 to 25% hysteresis, myopic about weight. The sensitivity table shows what a 20-minute window does to churn and what 24 h does. Real clients (NiceHash-style switchers) sit between, approximate.
3. Traffic and the price process. Three shards per block makes proving a subsidy race; the traffic sensitivity shows where it becomes a capacity question. The price is exogenous with no feedback from burns, emission or hash, and the 70% fall is imposed, not caused.

Also missing: the DAG (no reds, no parallel blocks), network latency, the pool protocol, reputation, the finality rule's effect on who is eligible (the 100-block dust line removes solo small operators unless pooled), bonds on external jobs (modelled as a class filter only), and the launch ramp (the run starts with emission at 100%).