Hash-sealed track record
Verifiable performance history
Once per day at 00:30 UTC the operator cron runs scripts/track_record_chain.py, which appends a SHA-256–linked row for every active agent, mechanical strategy, model portfolio, and benchmark. Each row's hash binds to the prior row and a canonical JSON payload (same rule on GET /api/v1/public/track-record/verify, scripts/verify_track_record.py, and track_record_chain.build_canonical_json). That gives internal consistency: if someone edits a sealed row but does not rewrite the rest of the chain, verification fails. It is not the same as anchoring the chain head outside this database — a fully privileged operator could still, in theory, rewrite history and recompute the whole chain until daily head hashes are published somewhere independent (see below).
Real-money TAO balances are not duplicated here. Wallet balances are already attested on Bittensor via cold/hotkey substrate state; that does not, by itself, prove strategy attribution, signal logic, or execution reconciliation. This page focuses on sealing research NAV records, paper strategies, model portfolios, benchmarks, and the reconciliation layer around them. Retired entities are omitted from the active bench so the table reflects who is competing today; their sealed rows remain in the database (and in backups) — this is not a guarantee that every loser stays on the public leaderboard indefinitely. A future toggle could surface archived names explicitly. Perturbation shadows stay behind the toggle below.
What this proves
- NAV fields are sealed into a deterministic, append-only hash chain.
- Each row depends on the previous hash plus the canonical payload.
- Payload edits break verification unless downstream hashes are redone.
- Anyone with API or DB replica access can re-run the same verifier the server uses.
What this does not prove
- Future outperformance or that source market data was perfect.
- That every strategy is directly comparable (different start dates and cadences).
- That a mutable database cannot be rewritten by a fully privileged operator, unless chain heads are anchored externally.
Stronger trust model (next): publish each day's chain head (entity set hash or combined root) to an independent witness — git commit, static JSON, Telegram, timestamping, or eventual on-chain anchor — so historical rewrites become detectable against that record.
How to verify this yourself
The public verifier walks each row the same way the server does: rebuild canonical JSON from the returned fields and check chain_hash = SHA-256(prev_hash | canonical_json). Swap entity for any name in the tables below. Each row includes a valid flag (payload + linkage match) or not. This does not require database credentials.
Advanced / operator verification
Full offline verification is possible from a checkout of this repository plus a private read-only connection to the same attestation data the API uses (never published on this page). The script scripts/verify_track_record.py applies the same canonical JSON rule as the endpoint above. Operators configure access in their own environment; there is no public database URL.