Economics

The short version

Figures in this box use the defaults (an H100 at $4.00 an hour, FlashProve's vendor-reported speed, 24 contracts of about 600 words) and update with the calculator.

Why proofs need packing

Anthropic's FlashProve can prove that a specific model produced a specific answer. It proves at most 1,024 tokens, about 750 words, per request: question, evidence and answer together. Each proof takes about 9 seconds of H100 time, produces an 18.78 MB proof and takes 17 seconds to verify on a CPU (vendor-reported). It proves one model today, Llama 4 Maverick.

The limit comes from the prover, not the model: a proof has to keep and check every intermediate value, for every token, on one machine. So proving one request per proof wastes most of every window and pays for every proof in full. And because only one model is provable, five jurors running it on the same input get the same answer: five proofs of one computation.

Two fixed costs decide whether proving pays. Warm-up: loading a 400-billion-parameter model before proving starts, two thirds of a small unpacked block's bill. And idle time: a rented GPU that isn't proving still costs money. That is why blocks wait until enough funded work is queued.

Calculator

Proof packing

A proof covers one request of up to 1,024 tokens, about 750 words. That limit comes from today's prover, not the model: it has to keep and check every intermediate value for every token. Proof packing fills those requests as tightly as possible and stops paying for the same proof twice. It has four parts.

1. Atomize. Each contract is broken into atoms: small questions that ask one thing (yes or no, a choice, or a bounded integer) and carry only the facts that decide it, each citing a pinned source. An exact composition rule turns the atoms' answers back into the contract's outcome. That rule is code, integer math only, and any UNKNOWN atom sends the contract to its declared fallback instead of a guess. Plain dense English, never invented shorthand: models read English tokens best.
2. Dedupe. The same atomic question over the same pinned facts has the same hash. Thirty markets that all hinge on "did the Fed cut rates on December 10?" share one slot and one proof.
3. Pack. Atoms are packed first-fit by size into 1,024-token requests, about 16 to 18 per request in our tests, each in a numbered slot with its own answer line. The slot order is shuffled by the block hash, so nobody chooses their neighbors. A reply that misses or mangles any slot is rejected whole. Contracts that must stand alone opt out.
4. Prove once, verify many. Today only one model can be proven, and with integer weights and greedy decoding, every juror running it on the same input gets the same answer. So each packed request is proven once, by a prover drawn from the block hash, and the other jurors become verifiers. Lab diversity returns as soon as a second model is provable: one proof per distinct model.

What packing does not change

• Warm-up is paid per proving session, not per block. A proving service that stays warm across blocks pays for idle hours instead, which the utilization input models.
• A long document still has to be briefed; a proven juror never reads more than 1,024 tokens at once. Long-document judgment is better run unproven (L1) with a diverse jury and auditors, or by proving only the deciding excerpts.
• Prove once trades jury diversity for proof while one model is provable. Say so on any contract that uses it.

Unpacked and packed

On your inputs

Cost per contract as blocks grow

Both lines use your current inputs. The marker is your block size. The curve falls because warm-up is a fixed cost shared by every contract in the block.

Fast screens (Jev)

A System 1 model such as TypeSafe's Jev returns a typed answer with a probability in 70 to 500 ms for about $0.0004 a decision (vendor-reported, not reproduced). A jury of models from several labs takes 5.9 to 30.1 seconds per contract (measured, Nov 6, 2026). Atoms are exactly the shape a screen reads. It can do four jobs, all before or around the real jury and never instead of it:

1. Screen the fidelity checks, the biggest cost once proofs are packed. Clear plans pass on the screen; unclear ones go to the multi-lab panel.
2. Triage atoms. Where it is confident, the stakes are low and the contract allows it, its answer stands: roughly 10 to 400 times faster than a jury. Never for L2: a closed model can't carry a proof.
3. Size the jury. Its probability is a cheap read on difficulty: easy questions get the contract's minimum panel, hard ones get more jurors and labs.
4. Run a fast lane for what it settles, under a second instead of seconds to minutes.

What it might save, on your inputs at 1,000 contracts

The cutoff

A screen's answer may stand only when all three hold: its probability clears the calibrated cutoff for that question type (the lowest confidence where its accuracy, as a Wilson lower bound on labeled examples, matches the jury it replaces); its chance of being wrong times the stakes is under the contract's allowed loss; and the contract allows a screen. Random audits, drawn from the block hash, keep re-checking it on live traffic and withdraw a cutoff whose accuracy drops. This is built in packages/route and tested with scripted screens.

It can't be the court. It is one closed model, so it adds no lab diversity and can't carry a proof, and calibrated isn't the same as correct.

Difficulty sorting

Don't send every question to your biggest jury. Start each one at the cheapest tier that can answer it safely, and move up only when needed: a fast screen, then panels of small, mid-size and frontier models, each spanning labs. A unanimous, confident panel stops there; a split one moves up. The screen's probability, juror disagreement and the stakes decide where each question goes, and contracts that require proof go straight to the proven lane. Set the tiers and how often questions stop at each:

Defaults: shares 30, 35, 20 and 15 percent (illustrative); the mid tier is close to the measured Nov 6 run ($0.0163 for five contracts, 5.9 to 30.1 s each); Jev figures vendor-reported. The catch: a genuinely hard question pays for every tier on the way up, so route high-stakes questions straight to the top. The router is built in packages/route; real tier shares need live traffic.

Reasoning and storage

Each juror's reasoning is committed with its vote, so it can't be rewritten after the outcome is known, and a challenge can point at the step where the logic broke. Proving reasoning is possible (FlashProve proves it like any output), but every reasoning token uses the 1,024-token window.

Proven reasoning, on your inputs at 1,000 contracts

So proven jurors give short, structured reasons; unproven tiers keep full reasoning. Storing reasoning is cheap: on chain it is a 32-byte hash per juror; the full text lives next to the chain, fetched by hash. At one ruling a second with full reasoning (about 8 KB per juror), that is about 3.5 GB a day, and one proof is bigger than about 2,300 full reasoning traces (modeled).

Settling on Solana

Under the three draft SIMDs, all of this can settle on Solana as ordinary programs, with no validator changes. What lives on chain is small: commitments and hashes (32 bytes each), attestations (about half a KB), rulings with a 512-byte summary (about 4 KB). Rent is 6,960 lamports a byte at current parameters, refunded when an account closes; five certification standards, 22,712 bytes of text, compress to 5,246 bytes, about 0.0377 SOL (from the SIMD drafts). Proofs and full reasoning stay off chain by hash.

The proving machine

In the diagram, the light client is built, TinySVM phase 1 is built as an optional prototype beside runtime.js (which stays the default), and the packer is built as a library but not yet wired into a harness run. A harness can also buy proofs from a proving service through its API router and verify them before counting the answer, so it never trusts the service.

Who earns what

Roles priced at cost plus your margin on the work they do. A proving operator only profits if the GPU is busy enough: the break-even utilization is where revenue meets the hourly rent.

Jurors are paid per counted vote from the contract's escrow, dissent included; the contract's author sets the escrow. Under prove once, the drawn prover also holds a jury seat.

Assumptions and sources

The math lives in packages/economics, with tests that pin every vector on this page. Nothing here is measured on a running network; there isn't one.