The engine — under the hood

A sealed room where a verdict is decided and no hand reaches inside.

Every anti-overfitting statistic in quantitative finance divides by one input — how many strategies were tried before the one being shown. For a century that number has been typed in by the person being judged. MIZAN makes it the leaf count of a committed Merkle tree, recomputed inside a zero-knowledge proof. What comes out is a 225 KB receipt any allocator checks offline in ~81 milliseconds — while the strategy never leaves its maker's machine.

~81 ms
To verify a receipt —
offline, trusting no one
225 KB
Receipt size —
the whole proof, portable
~200
Lines of Python that recompute
every statistic to the digit
12,870
Balanced splits the gate
runs — C(16,8) at S=16
§ 01The one number

The last self-reported number in finance, made structural.

A deflated Sharpe ratio asks: given how many strategies you tried, how surprised should I be that this one looks good? Answer honestly and most edges evaporate. So the number of tries — N — has always been the one input nobody could check, and the one input everyone rounds down.

In MIZAN, N is a Merkle leaf count. Each strategy you evaluate is a committed leaf; the tree is fixed before the gate runs; the proof reads the leaf count and cannot be handed a smaller one. You cannot try a thousand and report three. The deflation is computed against what you actually did — and this is enforced maximally: the statistic uses the full committed count, not a subset. The number that was always a confession is now a fact the proof carries.

Why this is the whole thing. GIPS verified the presentation of a track record. Nothing had ever verified the mathematics — because the mathematics depended on a number only the claimant knew. Commit the tree, and the last soft input in the discipline goes hard.
§ 02The sealed room

Fingerprint first. Then no hands reach in.

The gate runs inside a RISC Zero zero-knowledge virtual machine — the sealed room. The order of operations is the guarantee: the strategy and its data are committed first, as a cryptographic fingerprint, and only then does anything run. You cannot see the result, dislike it, and change the inputs — the inputs were sealed before the result existed.

The zkVM guest — execution order is the proof
STEP 01 — COMMIT
Fingerprint
Strategy, data, the out-of-sample split, and the cost model are hashed into a commitment. This is locked before evaluation.
STEP 02 — RUN
Backtest
The committed strategy runs on the committed data, inside the room. Net of the committed costs. On the committed split.
STEP 03 — JUDGE
Statistics
The anti-overfitting battery runs on the result — against the committed trial count. No input can be swapped now.
The verdict is decided with no hands inside the room.
Nobody — not the maker, not MIZAN — can reach in and move a number once the fingerprint is set. The proof attests that the code that ran is the code that was committed.
OUT → a 225 KB receipt: the verdict, the committed hashes, and the statistics — not the strategy.
§ 03The statistical seals

One committed strategy. A battery of independent seals.

Each seal is its own credential on the same committed strategy, so an allocator reads exactly which tests a record passed and which it did not. This is the live v11 battery — the both-schools composite, in-circuit.

Deflated Sharpe (DSR)In-circuit
The Sharpe ratio corrected for the number of trials and the higher moments of the return stream — the Bailey–López de Prado / Harvey–Liu multiple-testing deflation. The seal the trial count feeds directly.recomputed in proof
PBOIn-circuit
Probability of backtest overfitting, computed across all 12,870 balanced splits — C(16,8) at S=16 — not a single favourable partition.recomputed in proof
Purged CPCVIn-circuit
Combinatorial purged cross-validation — leakage between train and test folds is purged, so a record can't borrow information across the split.recomputed in proof
PSR · SPAIn-circuit · guest v11
Probabilistic Sharpe and Hansen's superior-predictive-ability test — is the edge distinguishable from the best of many lucky draws? Run over the committed ledger; the SPA seed is derived in-arm from the data and trial-stream, so it can't be shopped.recomputed in proof
MinBTLVerifier-side
Minimum backtest length — is the track long enough that the Sharpe could be trusted at all, given the trial count? Currently consistency-checked verifier-side on read, not claimed in-circuit. We label what runs where.checked on verify
Annualization basisVerifier-side
A window / annualization-basis sanity check the verifier applies to the receipt on read — stated plainly as verifier-side, not claimed to run in-circuit. We label what runs where, and this one runs on verify.checked on verify
The gate refuses most of what it sees. It refused Apple's +272,548% buy-and-hold, a neural net that returned +895% on NVDA, and its own maker's flagship — deflated Sharpe 0.68, not significant, published on the wall beside everything else. A gate that passes everything certifies nothing.
§ 04The receipt

Trust no one. Recompute it yourself.

A credential is a 225 KB receipt. Verifying it is a local cryptographic check — ~81 milliseconds, offline, no server call to us, no account. The verifier confirms the proof is valid and the committed hashes match; it never needs the strategy, and neither do you.

If checking the proof isn't enough, reproduce the numbers. About two hundred lines of dependency-free Python recompute every committed statistic to the digit from the public inputs. The standard that lets you do this — VTR-1 — is frozen and published on SSRN, free for anyone to implement, including competitors. The verifier is not something you have to trust us to run; it is something you run.

The asymmetry is the security. Verifying is cheap — ~81 ms on a laptop, trusting no one. Minting is not: each credential is a real STARK proved on an NVIDIA H100 or comparable GPU — minutes of GPU work per mint, not milliseconds. That gap is deliberate and it cannot be closed: a forger gets no shortcut, because to fake a verdict they must run the same heavy, honest proving the wall demands, on the same locked circuit, against the same committed inputs. The check is trivial for everyone; the forgery is expensive for the claimant. That is the trade the cryptography buys — and the reason a credential means something. The adversarial review of the whole construction is public: the security model, in full →

Not a description — the live machine. Verify any line yourself.
Engine era · image id3ac3b10b7930…v11 · dated 2026-07-25 · status LIVE · the circuit that ran, hashed
Registration root88298a2e…c6825aone Merkle root over all 77 registry entries · sha256 binary merkle, sorted hex leaves
A credential that PASSEDd40c1140… · track-btc-trend-4hSharpe≥1.20 · CAGR≥20% · MDD≤25% — all in-circuit
A credential it REFUSED6b767764… · zkml11-verifiable-ai-nvdaa net that returned +895% on NVDA — FAIL, 38% drawdown, published on the wall anyway
Every hash above resolves on the public registry. A valid proof whose leaf is not under this root is a real STARK but an unregistered mint — sound, and second-class. Check inclusion yourself →
§ 05The wall & the chain

Committed forever. Anchored in Bitcoin.

The registry is append-only. Every credential is a permanent, ordered entry; nothing is ever deleted or reordered; earlier is senior. The whole registry commits to a single registration root — one Merkle root over every entry — so the state of the wall itself is a number you can check.

The record is anchored in time. Anchor state is printed per credential — Bitcoin via OpenTimestamps, plus RFC-3161 where stamped. The rule is stated on the face of it: no anchor shown, no claim made. A record chained forward extends past each anchor, so it reads LIVE — a pulse that can only have been built forward, never backfilled.

§ 06Eras

The engine is a hash.

A version of the gate is identified by its image id — the cryptographic hash of the exact circuit that ran. That is what an era is: a specific image id. When the gate improves, a new era begins, but the old one is never revoked. A credential minted under an earlier era verifies against that era's image id forever — the rules it was judged under are pinned to it and cannot be quietly changed after the fact.

Eleven engine eras of production Rust stand behind the current one. Superseded is not the same as wrong: a credential means exactly what the era that minted it said it meant, permanently, because the era is a hash and the hash is on the receipt.
§ 07The sealed path

For the strategy the rules can't express.

Some strategies don't fit a declarative rule language — bracket exits, a machine-learning model, a black box. The sealed path handles them: your bot emits its committed positions, and the proof runs the gate over that committed position stream. Your code, your model, your parameters — none of it enters the room. What the strategy did becomes checkable; what it is stays sealed. This is also how a trading AI proves conduct: a compact model can be recomputed in-circuit, and any model can prove its behaviour through the sealed path. Verifiable AI →

§ 08Honest boundaries

What the proof does not claim.

A referee that overstates its reach is worth nothing. Here is the line, drawn plainly — because the honesty is the product.

The proof does not prove
What it does prove
Future returns. A verdict is about a committed record, not a forecast. Backtested performance is hypothetical.
That the record is real — computed honestly, net of committed costs, on a split fixed before evaluation, against the true trial count.
Capacity or liquidity. Whether the edge survives at size is off the gate entirely — it stays a human judgement.
That the maths wasn't gamed — no swapped inputs, no shrunk N, no leaked split, no cherry-picked partition.
Real-money fills from a backtest alone. Simulated execution is simulated.
Live conduct, once chained — a record extended forward past Bitcoin anchors can only have accrued in real time.
Things a sealed model isn't using. A sealed strategy can prove what it did, not the absence of a given input.
Exactly which seals passed — and, plainly labelled, which checks are in-circuit versus verifier-side.
§ 09The stack

The specification, in one table.

Proof systemRISC Zero zkVM — STARK-based zero-knowledge proof of correct execution of the committed guest program.
ProvingNVIDIA H100 (sm_90) or comparable GPU, minutes of GPU work per mint — the heavy, unshortcuttable side of the asymmetry; concurrency is cost-guarded. Verifying the result stays ~81 ms on any laptop.
Trial count (N)Merkle leaf count, committed before evaluation; deflation computed against the full committed count (enforced maximally).
Statistical batteryDSR, PBO (12,870 splits, C(16,8) at S=16), purged CPCV, PSR, SPA in-circuit (DSR carries the Harvey–Liu / Bailey–López de Prado deflation); MinBTL and the window/annualization-basis check verifier-side.
Receipt~225 KB, verified in ~81 ms offline — no server call, no account.
Independent reproduction~200 lines of dependency-free Python recompute every committed statistic to the digit.
RegistryAppend-only, ordered by seniority, committing to one registration root (Merkle root over all entries).
Time anchorBitcoin via OpenTimestamps, plus RFC-3161 where stamped — no anchor shown, no claim made.
VersioningEach era is an image id (circuit hash); superseded eras are never revoked; credentials pin to their era forever.
StandardVTR-1 — frozen, published on SSRN, CC BY. Verifier open; the prover is the private part.
§ 10See it run

Don't take the description on faith. Verify a real one.

Every credential on the public wall came out of the room above — including the refusals. Reproduce any of them to the digit, read the frozen standard, or bring your own strategy and watch the gate decide. Free while open testing lasts.

ENGINE v11 · 3ac3b10b… ● LIVE REGISTRY 77 CREDENTIALS · APPEND-ONLY VERIFY ~81 MS · OFFLINE · TRUSTING NO ONE ANCHOR BITCOIN #962,013 SPEC VTR-1 · FROZEN · CC BY ROOT 88298a2e…c6825a · MERKLE-COMMITTED