AI Oracles: Why Now, In Numbers

AI oracles are not new. People have used language models to decide things for smart contracts for a few years, and a lot of money has been raised on the idea. Most people have tuned it out, and fair enough: "an AI decides" is not an argument.

So this post makes a different kind of case. Not that AI oracles are exciting, but that a handful of things that did not exist a year ago change the engineering and the economics enough to make them worth building now. Every number below is labeled: measured on our own runs, vendor-reported by the people who built a tool, modeled from those, or illustrative where we had to assume.

What changed

1. Provable inference. Anthropic's FlashProve can produce a zero-knowledge proof that a specific model produced a specific answer. It is a research prototype, it proves one model today, and it is expensive. But it exists.
2. Fast typed-answer models. "System 1" models like TypeSafe's Jev return a typed answer with a calibrated probability in under a second, by their maker's figures.
3. Open agent harnesses. DeepSeek Harness is an MIT-licensed agent harness built so that everything is a plugin. Ours, Verafy Harness, is built on it.
4. Strong open-weight models. Models you can run and pin yourself are now good enough to sit on a jury.
5. Difficulty routing. Sending easy questions to small, cheap models and hard ones to big juries is an old idea. Cheap calibrated screens and juror disagreement make it practical.
6. Auditable reasoning. Models can write down their chain of thought, and we can record it, so a bad ruling can be traced to the step where the logic broke.

None of these is enough alone. Together, they open room to rethink what an oracle can be. Here is how they fit.

Proof packing

A familiar problem shows up when you build an AI validator on FlashProve. We call it proof packing: combining many incoming requests into each proof.

FlashProve can prove only 1,024 tokens, about 750 words, at a time. 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). Prove one request per proof and you waste most of every window, and pay for every proof in full.

The limit comes from the prover, not the model. A proof has to keep and check every intermediate value the model computes, for every token, so the work grows with every token and has to fit on one machine.

The fix is to compile requests before the AI sees them:

• Atomize. Break each contract into small, self-contained questions: yes or no, a choice, or a bounded number, each carrying only the facts that decide it, each fact citing a pinned source. An exact rule, written as code, turns the answers back into the contract's outcome. Any question answered UNKNOWN sends the contract to its declared fallback rather than a guess.
• Dedupe. The same question over the same evidence has the same fingerprint. Thirty markets that all hinge on "did the Fed cut rates on December 10?" share one slot.
• Pack. Fit as many questions as possible into each 1,024-token window.

This is working code, not just a model. In our packer's tests, 60 contracts became 120 small questions, 61 after dedupe, and fit in 4 proven requests of about 18 questions each, at 85% fill (measured on the packer, with mock models).

There is a second saving. Today only one model can be proven, and with integer weights and greedy decoding it gives the same answer every time. So five jurors proving the same request means paying five times for one proof. Instead, prove each window once, and let the other jurors verify it. Packing alone takes a block of 24 contracts from 120 proofs to 15. Proving once takes it to 3 (modeled).

One catch keeps this honest. The proof covers the small questions, not whether they faithfully capture the contract. So every breakdown is checked against the original before it is used, either agreed by the contract's parties or checked by a cheap panel from several labs. A breakdown that drops the deciding fact fails the check, and that contract runs unpacked.

What a prover costs

The proving machine is one H100 80 GB with about 290 GB of RAM and 24 cores (vendor-reported). One caveat: many single-H100 cloud rentals come with far less RAM, so meeting that may mean renting a bigger node.

At a typical $4.00 an hour for an H100 (on-demand rates, Nov 2026, from about $2.87 to $4.50, and up to $12.29 at the biggest clouds):

	Value	Label
One proof	about $0.0103 of GPU time	modeled
Proofs one GPU makes per hour	about 387	modeled from vendor-reported speed
Per decision, unpacked, 5 jurors	$0.1043	modeled
Per decision, atomized and proven once	$0.0059, about 18 times cheaper	modeled
Break-even for a proving operator at a 30% margin	77% of hours busy	modeled

Two things decide whether proving pays. First, warm-up: loading a 400-billion-parameter model before proving starts. In a 24-contract block, warm-up is two thirds of the bill, which is why blocks should wait until enough funded work is queued. Second, the checks: once proofs are packed, they stop being the expensive part. At 1,000 contracts, proving costs about $1.29 and the breakdown checks about $3.26 (modeled). The next big saving is cheaper checks, not cheaper proofs.

The full calculator, with every input and its source, is at harness.verafy.ai/economics.

Where a fast screen fits

A fast System 1 model like Jev can pre-screen incoming questions in 70 to 500 ms for about $0.0004 each (vendor-reported). A jury of models from several labs takes 5.9 to 30.1 seconds per contract (measured, Nov 6, 2026). A proven ruling takes about 4 minutes per batch of proofs, plus the wait for the block to fill (modeled).

Where Jev is confident, the stakes are low and the contract allows it, it can answer on the spot: roughly 10 to 400 times faster than a jury. Everything else goes to the jury, or to the prover where the contract requires proof. Its confidence also helps decide how big each jury should be.

How much it saves depends on how much it can safely settle, and that has not been tested on real questions yet. On its maker's own benchmark it scored 67.8%, against 73 to 74% for frontier models (vendor-reported). In our model, 1,000 packed contracts proven once cost $0.0069 per contract without a screen:

If Jev settles	Per contract	Change
Half the questions	$0.0068	1% saved
70% of the breakdown checks	$0.0058	16% saved
Both	$0.0045	35% saved
Nothing	$0.0081	17% more

The settle rates are assumptions, not measurements. The pattern is the useful part: once proofs are packed, a screen's money is in the checks, not the proofs, and its real gift is speed. It cannot be the court. It is one closed model, so it adds no lab diversity and cannot carry a proof. Until its confidence is calibrated on our own questions, it should settle nothing, and only size juries and log what it would have decided.

Difficulty sorting

Don't send every question to your biggest AI jury. Start each one at the cheapest tier: a fast screen, then small models, then mid-size, then frontier. A confident, unanimous panel stops there. A split one moves up. The screen's confidence, juror disagreement and the stakes decide where each question goes, and contracts that require proof go straight to the proven lane.

Compared with sending everything to a frontier jury, the cascade comes out about 4 times cheaper and 3 times faster on average, and about 15 times faster for the typical question. These are illustrative: the tier shares are assumed, and only the mid tier is grounded in our measured run.

The catch: a genuinely hard question pays for every tier on the way up, about $0.035 and 47 seconds, which is slower than going straight to the frontier. Route high-stakes questions straight to the top.

Chain of thought, disclosed

Each juror records its reasoning step by step, with the evidence each step cites, and commits a fingerprint of it with the vote, so it cannot be rewritten later. When a ruling looks wrong, you can find the exact step where the logic broke, and a challenge can cite that step instead of just the outcome.

Storing it is cheap. On chain, each juror's reasoning is a 32-byte hash. The full text lives next to the chain and is fetched by that hash. Even at one ruling a second with full reasoning, that is about 3.5 GB a day, and a single proof is bigger than about 2,300 full reasoning traces (modeled).

Proving it is not cheap. FlashProve proves reasoning like any other output, so you would know the committed model wrote exactly that reasoning. But every reasoning token uses the 1,024-token window. At 1,000 packed contracts:

Reasoning per question	Questions per proof	Cost per contract
None	16	$0.0069
Short reasons, about 40 tokens	9	$0.0089
Full reasoning, about 150 tokens	4	$0.0147
Long reasoning, about 400 tokens	2	$0.0251

All modeled. So proven jurors give short, structured reasons, and the unproven tiers keep full reasoning. And written reasoning is not always what actually drove an answer: it is evidence to check, not a guarantee.

Why a chain

Each ruling stores the hash of the one before it, plus hashes of every vote and every juror's reasoning. Edit one word after the fact and every later block breaks, on every copy.

That matters for an oracle because:

• Nothing can change after the fact. Auditing reasoning means nothing if it can be edited once the outcome is known.
• Order and time are provable. You can show a juror committed before the others revealed, and before the outcome was known.
• No single owner. Jurors run different labs' models for different operators. Nobody can quietly delete an embarrassing ruling.
• Money acts on it. Escrow is released from these records, so everyone has to agree on exactly one version.

A chain proves integrity, not truth. Juries, auditors, challenges and proofs handle correctness. Records are permanent, so personal data never goes on chain. And if one party ran everything, a signed log would do. A chain earns its cost when many independent parties write the record and money moves on what it says.

It can all settle on Solana

Here is the finding we did not expect. In theory, we would not need a separate chain at all. Our three draft SIMDs describe how to build every part of this on Solana as ordinary programs, with no changes to Solana itself. They use only Solana's existing signature check.

• Inference Programs: contracts written in words, stored on chain and versioned.
• Attestations: evaluators commit to a model, commit and reveal their votes, and record hashes of their full output and any proof.
• Rulings: the outcome, a short summary, the reasoning hash, sources, dissents, and challenges that append rather than edit.

Solana provides the ordered, shared, tamper-evident record. The jurors, proof packing and difficulty routing run off chain in the harness either way, and proofs and full reasoning stay off chain by hash. Storage is affordable: by the SIMD drafts' own numbers, five certification standards, 22,712 bytes of text, compress to 5,246 bytes, about 0.0377 SOL of rent, refunded when the account closes.

Two pieces would still need adding: a fair way to draw jurors, since recent block data alone can be nudged, and somewhere to keep the off-chain data available through the challenge window. Proof packing also needs a small amendment to the drafts, so many attestations can point at one shared proof.

A dedicated Verafy Chain only becomes worth building if the Solana version runs into real limits. That turns the ask from "back a new chain" into "these programs make Solana the natural home for AI oracles."

What is measured, and what is next

Measured so far: five labs' models ruled live and sealed a block, at 5.9 to 30.1 seconds and $0.0163 for five contracts; five DeepSeek Harness jurors on five labs' models sealed a block from their reveals; and the packer fits 60 contracts into 4 requests. Most of the rest is modeled from vendor figures, and labeled that way.

The next steps turn modeled into measured:

1. A real packed proof, with DeepProve on a few packed questions, recording the actual time, cost and proof size.
2. A Solana devnet slice: a minimal program implementing commit, reveal and the Ruling account from the SIMDs, with one harness-produced ruling settled on devnet.
3. A calibration test for fast screens, on labeled questions, to replace our assumed settle rates with real ones.

The code is open: Verafy Harness, the economics, the SIMDs, and the discussion on the Solana forum. There is no token, and there will not be one.