How We're Measuring Crypto
Surges — What We Know So Far
This article doesn't contain a conclusion that "this signal works." Instead, it shows exactly why we don't have one yet, and what we're actually measuring.
Why 100K+ Rows Become Just 1,463 Episodes
The crypto_universe_snapshot table holds 105,796 rows (as of
2026-08-28, of which 71,273 have a matured/settled label). But you can't treat those
105,796 rows as "105,796 independent observations."
Scans run hourly. When a surge-warning signal fires on a coin, that same signal often keeps firing for several consecutive hours while the setup persists. Counting all of those as "105,796 independent observations" is pseudo-replication — you're really counting one underlying event many times, and a statistical test that doesn't know that will report inflated significance.
To prevent this, we apply a dedup rule that merges the same coin/signal into one episode if it re-fires within 72 hours. What's left after that is the real count of independent events: 1,463 (as of 2026-08-28, from a raw 105,796 rows, with a 72-hour episode dedup applied, source: crypto_universe_snapshot). That gap — "we collected 100K+ rows" versus "we measured 1,463" — is itself the trap you have to name when working with crypto data.
The 168-Hour Label Bug — a Defect Row Counts Couldn't Catch
This is a real case, found and fixed on 2026-08-05. A label called
fwd_ret_168h, which scores the return 168 hours (7 days) after a surge
signal, was entirely NULL due to a boundary bug in the data-collection
window. It didn't stop there — the missing values were incorrectly counted as
"target not reached" (False) instead of "not yet determinable," which
made that label's measured base rate come out to 0%. The real value was
19.2%.
What We Use to Judge — No Reimplementation
Confidence intervals on rates reuse services/signal_stats._wilson
(a Wilson 95% confidence interval) directly. The stratified verdict that
screens for whether a signal is really predictive versus just firing more often on
already-volatile coins reuses services/stratify.stratified_verdicts
directly (logic already validated on the stock side — without controlling for volatility
confounding, "the signal predicted it" can really mean "the signal just fires more on
high-volatility coins"; see
why crypto volatility differs from
stocks for background). Because a mismatch between the diagnostic tool and the public
verdict would itself be a trust problem, crypto signals call
the exact same functions as stocks — nothing is reimplemented.
Where Things Stand — All 6 Pending
As of 2026-08-28, all 6 signals under stratified verdict are "pending (insufficient sample)." Zero have been adopted. Data collection started on 2026-07-28, so it's only about a month's worth so far, and 1,463 independent episodes isn't enough to finish stratification (splitting into volatility quartiles shrinks the sample in each cell further) and reach a statistically meaningful conclusion. We expect verdicts to become possible around late September to October 2026.
We keep publishing progress on the crypto base-rate proof page. The scanner itself runs at /en/crypto/scanner with a "weight0, measurement stage — not a buy recommendation" notice attached.