Two records, one honest split.
Below are two distinct things, kept rigorously separate. First, the backtested history — what the L3-verified strategy families produced in real-fill simulation. Second, the live-verified chain — every signal hash-chained at the instant it fires, before the outcome is known, so nothing can be altered, inserted, or back-dated. Download the chain and verify it with 30 lines of code. The split itself is the product.
Section 1
Backtested Performance — Hypothetical
Real-fill simulated · loading…
| Family | Events | Mean ticks/event | Win | Worst trade | Note |
|---|---|---|---|---|---|
| Loading backtested family results… | |||||
L3 order-book simulated fills incl. fees & latency — NOT live trading. Full Rule 4.41 disclosure below.
This table is the headline. For the unfiltered two-year history — the last 60 sessions per family, every year (including the losing ones), the dispersion and the equity curves — see the Full Research Record → (also hypothetical).
How these two records differ. The table above is a backtest — simulated history, replayed against recorded order-book data with realistic fees and latency. It is hindsight-bounded by construction. The chain below is a provable emission-time record: each signal is hash-chained the instant it fires, before its outcome is known, and the log grows by one record every trading day. The backtest tells you what the edge looked like; the chain proves we are not editing the story after the fact. Keeping them apart — and never blending them into one number — is the whole point.
Section 2
Live-Verified Record — Cryptographic Chain
Every entry below was hash-chained at emission time. Verify it yourself.
Chain head
The current rolling head hash. It is posted publicly (X / git) so a third party timestamps it — the history cannot be back-dated.
…
How to verify (anyone can run this)
Download the chain
record/track_record.jsonl — the full append-only log.
Re-walk it
Run the public verifier. It checks seq is contiguous from 0, every
prev_chain_hashequals the prior record'schain_hash, and eachchain_hash == sha256(prev_chain_hash + event_payload_sha256).$ python3 commercial/verify_record.py commercial/record/track_record.jsonl OK: chain verified — N record(s), no tampering detected. chain_head = <64-hex>Confirm the head
Match the printed
chain_headagainst the publicly-posted head. Equal head + exit code 0 = the record you're reading is exactly the record we committed, in order, with nothing inserted.
The chain (most recent first)
| seq | chained at (UTC) | event payload sha256 | chain hash |
|---|---|---|---|
| Loading chain… | |||
Each row is one emitted signal event, frozen. The payload hash commits to the exact bytes we published; the chain hash links it to all prior records. What the events mean →
Required Disclosures
CFTC RULE 4.41 — SIMULATED PERFORMANCE
HYPOTHETICAL OR SIMULATED PERFORMANCE RESULTS HAVE CERTAIN LIMITATIONS. UNLIKE AN ACTUAL PERFORMANCE RECORD, SIMULATED RESULTS DO NOT REPRESENT ACTUAL TRADING. ALSO, SINCE THE TRADES HAVE NOT BEEN EXECUTED, THE RESULTS MAY HAVE UNDER-OR-OVER COMPENSATED FOR THE IMPACT, IF ANY, OF CERTAIN MARKET FACTORS, SUCH AS LACK OF LIQUIDITY. SIMULATED TRADING PROGRAMS IN GENERAL ARE ALSO SUBJECT TO THE FACT THAT THEY ARE DESIGNED WITH THE BENEFIT OF HINDSIGHT. NO REPRESENTATION IS BEING MADE THAT ANY ACCOUNT WILL OR IS LIKELY TO ACHIEVE PROFIT OR LOSSES SIMILAR TO THOSE SHOWN.
Trading futures involves substantial risk of loss and is not suitable for all investors. Past or hypothetical performance is not indicative of future results.
Read the complete required disclosures — Rule 4.41, full futures & options risk, the impersonal-publisher statement, and data/simulation limitations — on the Disclosures & Risk Disclosure page.