Verify · Zero Trust Required

Don't trust us.
Verify it yourself.

A MIZAN credential is not a PDF you take on faith. It's a cryptographic receipt anyone can independently re-check — without trusting MIZAN, the manager, or the data provider. Run the source-available verifier on a real credential below. Twelve conditions checked independently — sixteen when the credential discloses exposures and regimes. The strategy stays hidden.

The Fastest Way

In your browser — no install.

The live engine verifies a real STARK credential end-to-end, in front of you, in about seconds. Watch all sixteen conditions clear while the strategy is never revealed.

A

Run it in the studio

Universal · nothing to install · the exact same verifier, client-side in your browser — no server involved. The honest demo behind everything on this site.

Open the live engine ↗
The Full-Reproducibility Way

From the command line — trust nothing.

Download a real credential, the canonical data it was bound to, and the source-available verifier. Run one command on your own machine. This is the whole point of MIZAN: the proof is portable and the issuer is irrelevant.

$ chmod +x mizan-verifier-macos-arm64 $ ./mizan-verifier-macos-arm64 mizan_sample_credential.bundle btc_4h.csv
════════════════════════════════════════════════ MIZAN · INDEPENDENT VERIFIER (PASS/FAIL only · zero trust) ════════════════════════════════════════════════ [✓] guest image id matches the program we trust [✓] zk receipt verifies (proof is real) [✓] committed journal matches credential (no swap) [✓] data root recomputed from canonical CSV matches [✓] data root pinned to canonical allowlist: BTC 4h (OHLC) [✓] gate policy is the canonical MIZAN policy [✓] dataset was canonical in-proof [✓] credential format v4 (disclosing) [✓] annualization basis bound to the committed 12917-bar window (C1) [✓] GATE VERDICT is PASS (zk-attested) [✓] a strategy commitment is present [✓] credential digest intact (tamper-evident) [✓] exposure card internally consistent (bands · leverage rail · instruments) [✓] regime policy is the pinned canonical policy [✓] regime panel internally consistent (bar accounting · return rail) [✓] regime bar counts re-derive from the canonical CSV ──────────────────────────────────────────────── Issuer : MIZAN Gate policy : Sharpe≥1.20 · CAGR≥20% · MaxDD≤25% · no bar<-12% GATE VERDICT : PASS ✓ Metrics : Sharpe 1.63 · CAGR 26.6% · net 301.61% · MaxDD 20.76% Strategy : ***NEVER REVEALED*** ════════════════════════════════════════════════ ✅ INDEPENDENTLY VERIFIED — a hidden strategy cleared the MIZAN gate on bound real data. Zero trust in the issuer.

Tamper test: change a single byte of the bundle and re-run, the digest and receipt checks fail instantly. The proof cannot be forged or edited.  ·  Other platforms: the verifier is source-available Rust — Linux/Windows builds and full source on request for any allocator or reviewer; full public source release is planned.  ·  macOS may quarantine an unsigned binary — clear it with xattr -d com.apple.quarantine mizan-verifier-macos-arm64.

New · Chained Tracks

One sealed strategy. A window that only grows.

A chained credential re-proves the same committed strategy over a strictly longer data window, the backtest becomes a growing live track, and every link is cryptographically bound: same spec commitment, same guest, the old window a Merkle prefix of the new. Re-verify the first real chain yourself — parent (800 bars) → extension (1,096 bars, +296 new).

$ chmod +x mizan-verifier-v3-macos-arm64 $ ./mizan-verifier-v3-macos-arm64 mizan_chain_extended.bundle btc_daily.csv --chain mizan_chain_parent.bundle
════════════════════════════════════════════════ MIZAN · INDEPENDENT VERIFIER (zero trust) ════════════════════════════════════════════════ [✓] guest image id matches the program we trust [✓] zk receipt verifies (proof is real) [✓] committed journal matches credential (no swap) [✓] data root recomputed from canonical CSV matches [✓] data root pinned to canonical allowlist: daily OHLC [✓] gate policy is the canonical MIZAN policy [✓] credential format v4 · exposure card · regime panel consistent [✓] annualization bound to the committed 1096-bar window [✓] committed cost model read from the journal: 7+3 bps per side [✓] GATE VERDICT is PASS (zk-attested) [✓] credential digest intact (tamper-evident) [✓] parent zk receipt verifies against the SAME trusted guest [✓] parent committed journal matches parent credential (no swap) [✓] CHAINED: same committed spec · window strictly extends parent (Merkle prefix) · parent digest matches 🔗 track: parent 800 bars → this credential 1096 bars (+296) · parent digest a4e4730816bcc442… ──────────────────────────────────────────────── GATE VERDICT : PASS ✓ (extended window) Metrics : Sharpe 1.41 · CAGR 36.5% · net 154.32% · MaxDD 17.36% Strategy : ***NEVER REVEALED*** ════════════════════════════════════════════════ ✅ INDEPENDENTLY VERIFIED, the same hidden strategy, re-proven over a strictly extended window, chained to its parent. Sixteen core conditions plus four chain checks, all green.

What the chain proves, and what it doesn't: the chain check proves the same committed spec was honestly computed over the extended window (same guest, same gate, same costs; old window a Merkle prefix of the new). Provenance of the newly appended bars still rests on the canonical-data allowlist, not an exchange-signed feed — that boundary is printed by the verifier itself, not hidden.  ·  Break test: swap the spec, shrink the window, or forge the parent digest, the verifier refuses with the exact reason.  ·  Every credential minted in the app is chain-ready: one click re-proves it as data accrues.  ·  Verifier eras, honestly: a verifier binary trusts exactly the engine it was built with — verifier v3 (above) verifies everything minted from 2026-07-17; the original binary verifies the sample credential of its own era. Cross-era verification fails by design, not by accident.

New · Black-box models, proven: the gate ran inside the circuit.

Two credential families, both minted as real STARKs on 2026-07-17. Black-box FULL: a hidden model commits its positions forward into an append-only track, and the gate is computed in-circuit over that committed position stream, the credential attests these exact pre-committed positions cleared the gate on this exact data. zkML proven inference: a committed compact model runs its own decisions inside the circuit — every position provably came from that one hidden model. Tampering, curation and re-tuning are refused by construction — alter or drop any period and the sealed track head changes, so the credential fails. Forward-commitment timing: that positions were fixed before each period's outcome — rests on the track head being published or timestamp-anchored ahead of time, not on the circuit alone; anchoring it (OpenTimestamps / RFC-3161) is the honest completion of that claim. The model is never revealed.

$ ./mizan-verifier-v3-macos-arm64 mizan_blackbox_full.bundle btc_daily.csv --aux mizan_blackbox_full_parts.json --track mizan_blackbox_full_track_head.json

Since guest v10 · Fractional positions, a sealed model's sizing is now provable. Positions are no longer just long/flat/short: the committed stream carries a signed leverage per bar (×0.01 steps), a declared cap is enforced inside the circuit, and the parity and fractional commitment formats live in separate hash domains, a track committed one way can never replay as the other. The sample below is a hidden model whose dynamic sizing (avg 0.22×, peaks 1.24×) clears the full institutional gate — Sharpe 1.50 · CAGR 28.8% · MaxDD 20.8% · net +345%, all computed in-circuit. Minted as a real STARK on GPU, 2026-07-22.

$ ./mizan-verifier-v10-macos-arm64 mizan_blackbox_fractional.bundle btc_4h.csv --aux mizan_blackbox_fractional_parts.json --track mizan_blackbox_fractional_track_head.json
$ ./mizan-verifier-v3-macos-arm64 mizan_zkml.bundle btc_daily.csv --aux mizan_zkml_parts.json

Break test: change one byte of the parts file and re-run, the aux binding check fails and the verifier refuses the credential.  ·  Honest scope: the gate-in-circuit and compact-model inference above are proven — their receipts exist. Large-net zkML (proving inference of a big neural net in-STARK) remains a research frontier industry-wide; we don't relabel it.  ·  The original forward-track rail credential (verifies with the era -v2- binary) is kept as the historical artifact.

New · Deflated Sharpe · Unfakeable N

Every backtest ever run, counted against the winner.

Try enough strategies and one will look brilliant by pure luck, and no ordinary track record shows you how many were tried. The DSR credential closes that hole: all N candidate trials are committed in a Merkle ledger, every trial's Sharpe is re-derived inside the circuit, and the winner's Sharpe is deflated for the luck of the best-of-N (Bailey & López de Prado's Deflated Sharpe Ratio — here made cryptographic). N is read from the ledger, never declared — understate it and verification fails. Minted as a real STARK on GPU, 2026-07-20. Since guest v10, significance is tested at an autocorrelation-corrected effective sample size: serially correlated returns can only make the test harder, never easier.

And it doesn't flatter its own maker. The credential below is real and verifies, but at the honest significance bar (DSR ≥ 0.95, Bailey–López de Prado's standard, not a coin flip), this particular strategy's edge does not survive the best-of-N correction. Our own verifier says so, out loud. A tool that stamped everything "significant" would be worthless; the whole value is that it tells you the truth, including when the truth is no.

$ chmod +x mizan-verifier-v10-macos-arm64 $ ./mizan-verifier-v10-macos-arm64 mizan_dsr.bundle btc_4h.csv --dsr --aux mizan_dsr_parts.json
════════════════════════════════════════════════ MIZAN · DSR VERIFIER (deflated Sharpe · N committed · trials proven) ════════════════════════════════════════════════ [✓] guest image id matches the program we trust [✓] zk receipt verifies (proof is real) [✓] committed gate journal matches the credential (no swap) [✓] gate policy is the canonical MIZAN policy [✓] the winning strategy cleared the gate (zk-attested) [✓] EVERY trial's Sharpe re-derived + bound in-circuit — V[SR] is proof-grade [✓] N == committed trial-ledger leaf count [✓] credential digest intact (tamper-evident) [✓] winner data root recomputed from YOUR CSV matches the committed root [✓] data root pinned to canonical allowlist: BTC 4h (OHLC) ──────────────────────────────────────────────── Trials committed (N) : 10 Observed Sharpe : 0.031 (per-obs) SR₀ (N-deflation) : 0.027 DEFLATED SHARPE (DSR): 0.6779 Significance bar : DSR ≥ 0.95 (Bailey–López de Prado) Verdict : NOT significant at 95% (DSR 0.68) — this edge does not survive multiple testing across N=10 trials Strategy : ***NEVER REVEALED*** ════════════════════════════════════════════════ ✅ DSR INDEPENDENTLY VERIFIED — N committed, every trial proven, deflation honest. (Verified = the deflation is computed honestly. The verdict above is what that honest computation returns.)

"Verified" is not "significant", and that distinction is the product. The green line certifies the deflation was computed honestly: N is real, every trial's Sharpe is proven, the math is right. What that honest math returns for this strategy is not significant at 95%: and the verifier says so plainly. A DSR of 0.68 means "more likely than not, but below the bar." Most edges land here; that is the entire reason the correction exists.  ·  What this proves, and what it can't: N counts the trials committed to this ledger from the moment it opened; no cryptography can recover experiments run before a ledger existed. The honest claim is "from here on, every trial is counted": never "we fixed history." That forward-only boundary is why the ledger is timestamp-anchored (Bitcoin + RFC-3161, files above): the commitment provably predates the outcomes.  ·  Break test: drop a losing trial from the ledger, fabricate a Sharpe, or restate N, each is refused with the exact reason; under-resolving trials fails closed.  ·  Verifier eras: the -v7- binary verifies engine-v7 credentials (this DSR one); the current era is -v10- (composed PBO · n_eff DSR · fractional sizing); the DSR and PBO credentials below are v10 mints, CPCV remains a v9-era mint and verifies with -v9- — its era's binary, forever; earlier eras keep their own binaries above — cross-era failure is by design.

New · PBO · Backtest Overfitting

Was the winner skill, or a lucky fit?

Even with N honestly counted, the selection itself can overfit: pick the in-sample best and it may sit below median out of sample, a backtest dressed as alpha. The Probability of Backtest Overfitting (Bailey–Borwein–López de Prado–Zhu, via combinatorially-symmetric cross-validation) prices exactly that: split the history into 16 sub-periods, and over every one of the 12,870 balanced train/test partitions — López de Prado’s own published setting — check whether the in-sample best stays above median out of sample. All committed trials are re-derived inside the circuit; PBO is the fraction of partitions where the selection was luck. Bar: PBO ≤ 0.5. Minted as a real STARK on GPU, 2026-07-22.

This one passes, and it's now composed. Since guest v10 each committed trial is its own STARK, and the credential's aggregator proof cryptographically verifies every trial receipt inside itself before running the partition test on committed return moments — proofs checking proofs. That unlock is what pays for the full 12,870 partitions. The flagship trend selection reads PBO 0.0759: the in-sample-best config stays above the median out-of-sample, so the selection is skill, not overfitting. And the padding attacks stay closed — every committed trial must clear the institutional gate, the winner is bound to the maximum-Sharpe trial, the split is canonical, and (new, found by our own red-team before this mint) a ledger padded with clones of the winner is refused outright. Tracked openly as D7 and D9 on the security ledger.

$ chmod +x mizan-verifier-v10-macos-arm64 $ ./mizan-verifier-v10-macos-arm64 mizan_pbo.bundle btc_4h.csv --pbo
New · CPCV · Leak-Free Cross-Validation

Was the out-of-sample actually out of sample?

Cross-validation leaks when train and test overlap in time — serial correlation bleeds one into the other and flatters the result. Purged, embargoed combinatorial cross-validation (López de Prado, Advances in Financial ML, ch. 7 & 12) removes it: split into groups, hold out combinations as test, purge the label-overlap bars and embargo the boundary bars — in the circuit, with the purge count committed so a prover can't quietly skip it — then score the strategy across every recombined path for a distribution of OOS Sharpe, not one fragile split. The headline is the honest tail: the 5th-percentile path. Minted as a real STARK on GPU, 2026-07-22.

And this one holds. Across 15 recombined paths with 160 boundary bars purged+embargoed in-circuit, the flagship's 5th-percentile path Sharpe stays positive: the edge survives leak-free cross-validation, not just one lucky split.

$ ./mizan-verifier-v9-macos-arm64 mizan_cpcv.bundle btc_4h.csv --cpcv

All three sins, credentialed, and hardened. DSR (selection bias), PBO (overfitting) and CPCV (leakage) are each real STARK credentials you can re-verify here, the complete López de Prado framework — every correction a re-verifiable STARK credential. We red-teamed PBO and CPCV the same day we shipped them and found two real gaming vectors (D7, D8 on the security ledger): a paddable PBO ledger and an unenforced CPCV purge floor with a prover-chosen schema. Both are closed in guest v9: every PBO trial must clear the gate with the winner bound to the max, and the CPCV purge/embargo schema is a canonical constant with a per-path purge floor the verifier re-checks. We'd rather show you a credential, its holes, and the fix than a clean demo that hides them.

What The Math Guarantees

Sixteen conditions. All checked.

The verifier doesn't take MIZAN's word for anything, it recomputes and re-checks each of these from the raw bundle and your copy of the data. Twelve conditions checked independently — sixteen when the credential discloses its exposures and regimes, as this sample does.

1The program is the exact one we trust (guest image id)
2The zero-knowledge receipt is real and verifies
3The journal matches the credential — no swap
4The data root recomputes from your CSV
5The data root is a pinned canonical dataset — substituted history fails
6The gate policy is the canonical MIZAN policy
7The dataset was canonical inside the proof
8The credential declares the current format (v4 · disclosing · OHLC · intrabar-marked risk)
9The annualization basis is bound to the committed window — Sharpe can't be inflated
10The verdict is PASS, zk-attested
11A strategy commitment is present (but hidden)
12The credential digest is intact — tamper-evident
13The exposure card is internally consistent (bands · leverage rail · instrument count)
14The regime policy is the pinned one — the prover cannot choose the buckets
15The regime panel is internally consistent (bar accounting · return rail)
16The regime bar counts re-derive from OUR own copy of the public data

Verifying is milliseconds; minting is not. Generating a proof is heavy, one-time work, a simple strategy on a daily dataset takes roughly 20–30 minutes on our single machine, and a multi-sleeve book on 4h data runs for hours. The Studio measures your exact proof cost up front and tells you before anything is queued; heavy books are minted offline. Verification stays seconds forever — that asymmetry is the whole point.

Sixteen pass. The strategy never leaves the proof. No trust in MIZAN required.

Try the live engine ↗ The Retraction Ledger View the Deck