How to verify the scorecard and the proofs: trust hashes, not us

The one-line conclusion: every scorecard number can be checked against its methodology, and every proof record against its hash. Neither layer requires trusting our character.

The scorecard's methodology

Every row on the public scorecard comes from the calibration API computed in real time; the page hard-codes nothing. Four fields to read per row:

• Hit rate: hits ÷ (hits + failures). Expired-but-unjudged entries are excluded from the denominator — undecided is neither win nor loss.
• Sample size n: the number of judged entries. With small samples the interval will be wide; never read the hit rate alone.
• Wilson 95% confidence interval: the uncertainty range of the hit rate at that sample size. Smaller samples, wider interval — that is statistics being honest.
• Window and era: sliced into 7-day, 30-day and all-time windows, then bucketed by engine era and prediction type. Every rule change opens a new era; old entries play out under the old rules and never mix buckets.

The "near-edge" warning additionally carries a random base rate and a lift multiple: how likely a randomly picked coin is to ignite within 5 days, and how many times that base rate the near-edge hit rate reaches. The multiple says far more about the layer's usefulness than the bare hit rate.

Proofs: the daily Merkle batch

Every day at 00:05 UTC, the system takes all signals opened or closed in the previous UTC day plus their lifecycle events, hashes each entry after normalization (the leaves), and builds a Merkle tree in lexicographic order; the root hash goes into the public proof batch. Merkle tree in plain terms: records are hashed pairwise and merged level by level into one root; change any single record and the root changes.

The root is then submitted to the OpenTimestamps public calendar and anchored to the Bitcoin blockchain — proving "this root existed before that moment". OTS is only a reinforcement layer: Merkle path verification does not depend on OTS being available.

Verify a record yourself

Open proof verification and enter a signal ID (with its batch day) or a 64-hex-character leaf hash. The API returns the record's Merkle path — every sibling hash and its left/right position from leaf to root. The server runs two checks:

1. rebuild the root from leaf and path, and compare it with the batch root;
2. for signal entries, additionally recompute the leaf from the current row: if the record was edited after being committed, the recomputed leaf will not match.

Anyone can recompute offline under the same rules. The batch roots are public, the algorithm is public, and the verification API is anonymous.

What this prevents — and what it does not

It prevents the industry's three most common cheats: editing entries after the fact, deleting losers, and cherry-picking time windows. What it cannot prevent is "the rule itself being weak": that is for the scorecard's historical statistics to prove or disprove — and historical statistics are not a promise of returns.