Why preliminary scores get re-weighted
A 50%-real number shared at 100% confidence is worse than no number. Here is the rule we ship.
Two of six signals — creator and risk — currently return informative stubs while Bitquery and GoPlus API keys are provisioned. Any score that depends on those stubs carries a `confidence: preliminary` flag and is refused by the on-chain attestation pipeline.
The aggregate you see on `/score/:id` is re-weighted over live signals only. That means a 67/100 from four live signals is a 67/100 — not a 33/100 hiding behind two zeroed stubs. Leaderboards, percentile denominators, and attestations all exclude preliminary rows.
When the keys land, every preliminary row stays preliminary in its historical URL — the re-score button exists so creators can replay the submission against the full signal set without mutating shareable data.