Kether Fast Ribbon
What it is — and what it is not
The classic Hash Ribbons signal compares a 30-day and a 60-day moving average of network hashrate. The Kether Fast Ribbon runs the same crossover mechanic on 5-day and 14-day windows — the windows our trading engine has run live on Bitcoin since April 2026. Its windows are 4–6× shorter (5d vs 30d, 14d vs 60d), so crossovers arrive correspondingly sooner and it flips more often. It is not a substitute for the canonical signal, and we never display one as the other: the dashboard's health badge is always the canonical 30d/60d definition; this page is the fast instrument, labeled as itself.
| chain | 5-day window | 14-day window | per-block target |
|---|---|---|---|
| BTC | 720 blocks | 2,016 blocks | 600 s |
| LTC | 2,880 blocks | 8,064 blocks | 150 s |
| DOGE | 7,200 blocks | 20,160 blocks | 60 s |
The exact recipe
per-block hashrate = difficulty × 2³² / interval_seconds
(interval floored at 1 s; out-of-order timestamps fall back to the chain's target)
MA_fast = simple mean of last 5-days-worth of per-block hashrates
MA_slow = simple mean of last 14-days-worth
state = CAPITULATION when MA_fast < MA_slow, else EXPANSION
(EXPANSION younger than 2 days is shown as RECOVERY)
streak = consecutive blocks in the current state
days = streak_blocks × target_seconds ÷ 86,400 (block-time days, not wall-clock;
the 2-day RECOVERY cutoff uses the same unit; streaks are measured within our
stored ~90-day header window)
Estimator note, for the checkers: the per-block hashrate estimator is upward-biased as an absolute number (Jensen's inequality on 1/interval, floored at 1 s; non-increasing timestamps fall back to the chain's target). Inside this signal the bias carries into both averages roughly equally, so it largely cancels at the crossover — which is the part that matters here. The absolute hashrate figures elsewhere on this site use the unbiased aggregate estimator (total work ÷ elapsed time). Both recipes ship inside the API response itself.
How it relates to the canonical signal — measured, not asserted
We benchmarked the two definitions against each other on 306 days of Bitcoin daily hashrate (run 2026-09-18, one year of mempool.space daily data; at daily resolution 720/2016 blocks equals exactly 5/14 days):
| comparison | result |
|---|---|
| day-by-day state agreement, Kether 5d/14d vs canonical 30d/60d | 52.0% (Wilson 95% CI 46.4% – 57.5%) |
| state on the benchmark day | both EXPANSION |
Read that number honestly: the two instruments agree barely more than a coin flip day-to-day, because the fast ribbon lives inside shorter cycles the slow one smooths away. We have not yet published a lead/lag analysis of the disagreement days — until we do, the number in the table is the whole claim. It is the point of publishing both, and the reason we will never quietly swap one for the other.
Lineage & validation status — plainly
The crossover core is the deployed engine's loop, unchanged — the hash-ribbon stage that has run live inside our Bitcoin trading pipeline since April 2026. Exactly two modifications were made for publication: the two window lengths were lifted into per-chain parameters, and the internal hash seals were swapped for public SHA-256. No formula changes. The math is machine-checked on every pipeline start, and the pipeline refuses to publish if any invariant fails.
What is not claimed: the fast ribbon has not been independently backtested as a predictor of price or profitability. We publish it as a faster state-detector of the same physical quantity Hash Ribbons watches — hashrate leaving or entering the network — with its full recipe above so anyone can recompute it.