Verification

What the signature proves

Every record in the store is signed with the organiser's ed25519 key over the record as canonical JSON — sorted keys, no whitespace. This site verifies each one in Node before it renders it and says so on the page. It verifies against the organiser's key when the deployment pins one; otherwise against the key the store's own index names, which shows the records are unaltered since that key signed them but not whose key it is. The home page and the dashboard say which. A record that does not verify is shown as unverified rather than hidden.

That check is about authorship, not truth: it says the competition published these numbers and that nobody has altered them since.

Canonical JSON

The bytes that are signed are the record serialised with sorted keys and no whitespace — what the competition's own store._canonical produces, json.dumps(sort_keys=True, separators=(",", ":")).

This site re-derives those bytes by keeping every scalar's source text rather than re-encoding it, because a JSON encoder writes 2 where Python wrote 2.0 and would fail every signature. That is the one piece of this site with no margin for approximation, and it is held to the real published record in the test suite.

The epoch directory

An epoch directory carries no signature. What makes the numbers checkable is the revealed secret and the bundles, and neither is in any record: the units, bundles and results of an epoch live in that directory, so the site shows them only when it agrees with the record on its secret commitment, its config's sha256 and its units.

A directory that disagrees is not quietly dropped: the epoch's table says what disagreed, in place of the episodes it would have shown, and nothing from it is shown as the epoch's.

Digests

From version 2 a record also signs their digests — each bundle's in pool_manifest, each result's and its rollout's in results_manifest — and this site hashes every bundle, result and clip it shows and compares it with them, marking a file that differs or that the record does not sign. A record from before version 2 signs none, and its files are shown unsigned.

A result carries one check no digest can make for it: which bundle it ran against. Every result names one, and the pool froze exactly one bundle per unit, so a result naming another is marked wherever it is shown beside the unit's own — a rollout against a different demonstration is not a result on that unit, however well its own digest checks out.

Check it yourself

The same verification runs from the command line, and is worth most with the organiser's key taken from somewhere other than the store being checked.

horizon-competition store verify --store store/

The per-epoch checks — re-deriving an epoch's units from its revealed secret, and hashing that secret against the commitment the epoch opened on — are epoch derive and a sha256 of the derivation and the secret, run against the published record. No page prints them: a command built from a record this site does not hold every field of could not be trusted to run as printed.

What this site does not do

It computes nothing. The axis scores, the score that is their mean and the rank are read from the record as the organiser published them; the only things this site works out for itself are whether the signatures hold and whether an epoch directory matches its record. It never writes to the store.

It holds no key, no token and no credential either. The only key it touches is a public one — the organiser's, when a deployment pins it — and the only secret it shows is the epoch secret, which is public by the time an epoch closes.