Proof DeskField Dispatch 09
Dispatch 09 the proof-market coordination gap

Over 40% of committed compute never proves a thing.

Supply, allocated, utilized are three different numbers. Most protocols report one and call it capacity. The distance between them is not a hardware problem, it is a coordination problem, and this is a working model of it. Every figure below is computed in your browser by the open-source engine, not read from a slide.

Capacity flow · one horizon, 48 Prover Nodes runs in your browser
supply committed and proving, left to right39.4% utilized
0total Prover Node supply over the horizon100%
Utilized 39.4%
capacity that produced a proof
Committed, then stalled 36.4%
allocated but stranded by scheduling
Never allocated 24.2%
supply stranded by fragmented matching
39.4%
utilization
Supply
345,600
Allocated
258,003
Utilized
136,031
Drive the model
Same supply in every regime. Move a control and every number above recomputes from the model.
Section 01 / The distinction

Three numbers most protocols collapse into one.

A proof market has a supply of machines. It commits some of that supply to work. Some of what it commits actually runs. Report only the first number and the market looks full. Report all three and the coordination loss becomes visible. The vocabulary here is Fermah's own: Seekers submit Proof Requests, the Matchmaker assigns them to Prover Nodes.

Utilized
Capacity that actually produced a proof. The only number that ships work. Everything else is potential.
Allocated
Capacity the Matchmaker committed to a request. Committed is not the same as running. A committed Prover Node can still sit stalled.
Supply
Everything the Prover Nodes made available. The headline figure. On its own it says nothing about what got used.
Matching gap. Supply that never got committed. 1 - allocated / supply. Fragmented matching strands it: a request reserves a whole node it does not fill, or an operator on the critical path holds it until the Seeker gives up, and nodes sit idle.
Scheduling gap. Committed capacity that never ran. 1 - utilized / allocated. This is the one Fermah keeps naming: over 40% of allocated capacity goes unutilized before a single proof executes.
Consensus was solved a decade ago. The operational layer never moved.
The gap between committed compute and usable compute is where execution capacity dies. Closing it, in the model and in Fermah's own framing, requires no new machines.
Section 02 / The horizon

Watch utilization build, tick by tick.

The instrument at the top settles on the horizon average. This plays the same run out over time, for the regime and load you set above. Coordinated runs climb and hold near the top. Operator-gated runs stall below the line and stay there.

Utilization over the horizon · operator on path
Section 03 / The payoff

Same machines. Coordination is the only variable.

These three regimes run over an identical supply. Nothing is added between them. Removing the operator from the critical path and placing work on the guarantee spectrum lifts utilization from the low forties to the low nineties, and the number of proofs produced roughly doubles.

Operator on path, guarantees maxed39.4%
supply 345,600 · proofs produced 3,808
Operator removed, matching still coarse44.5%
supply 345,600 · proofs produced 4,282
Operator removed, work on the guarantee spectrum91.4%
supply 345,600 · proofs produced 9,360

Supply is byte-for-byte identical in all three rows. The only thing that changes is how the market coordinates. That is the whole claim: the ceiling is coordination, not compute.

Section 04 / Method

The engine is open. Run it yourself.

This is a model, not Fermah's live telemetry. It is small enough to read in one sitting and deterministic, so every figure on this page is reproducible from a seed. The page embeds the exact engine published in the repository, so what you see here is what the code produces.

proofmarket-sim
A deterministic model of where proving capacity is lost between supply, allocated and utilized. The two loss mechanisms it reproduces, supply stranded by fragmented matching and committed capacity stranded by scheduling stalls, are real coordination phenomena. Parameters are illustrative and documented in src/engine.js.
# compare all three regimes over the same supply
node bin/cli.js

# drive it: override load, seed, node count
node bin/cli.js --load 24 --seed 7

# invariants and stability
npm test

Alongside this dispatch I opened a pull request to Fermah's own documentation, filling the empty components diagram in their architecture page with a Seekers, Core and Prover Nodes schematic that matches the workflow their docs describe. Vocabulary on this page was checked against that same documentation.

Sources and method

  1. Fermah on the operational layer, human latency, and autonomous composition as the opening condition of era two. @fermah_xyz, July 2026.
  2. Fermah on resolution windows as a resolution constraint, and on over 40% of allocated capacity going unutilized before a single proof executes. @fermah_xyz, July 2026.
  3. Fermah network architecture: Seekers, Matchmaker, Prover Nodes, Core. docs.fermah.xyz
  4. The model that produces every figure on this page. github.com/Zhekinmaksim/proofmarket-sim

The simulation is an independent model built by this desk, not published by Fermah and not a source of live network data. It reproduces the coordination dynamics Fermah describes so they can be inspected and driven, and every number is generated in your browser by the embedded engine. Fermah's counters and the 40% figure are theirs; the model is calibrated to sit in that range, not to assert it.