crypto_momentum_anchor

1. Every threshold this site recommends was shut all week — and we deleted the evidence that would tell you whether that's normal

Three places on this site suggest a setting for this signal. The builder's number field defaults to 2. The builder's one-click crypto recipe, "Risk-on momentum", is {"above": 2}. The starter bot "Crypto Momentum (Up-Day)" ships with {"above": 0} and tells you in its own blurb to "raise it to +3% for a stronger breakout filter, or flip it to a dip-buy that only fires when the market is down more than 5%". The module's docstring gives the same two examples, {"above": 2} and {"below": -5}.

Counted against all 1,595 readings we hold:

The full range of the week was −1.79% to +1.67%, standard deviation 0.64. Not one reading came within a third of a percentage point of the builder's default. Counting by day rather than by reading, so the units match a daily statistic: on 0 of the 8 calendar days in the table did the number ever touch +2% at any moment. The best any single day managed was +1.67%, on 4 August.

Now the part that stops this being a dunk. Over the last 365 days a day moving more than +2% happened 12.6% of the time — but that is measured on Bitcoin, which swings wider than the index this signal reads, so it flatters the threshold. Scaled by the 0.752 beta in catch #3, clearing +2% on the total is closer to 6.3% of days, about one day in sixteen. It is a real, recurring condition. The thresholds are defensible.

What is not defensible is that our own records cannot tell you any of that, because the poller deletes everything older than seven days, and the seven days it happens to be holding rank 12th of 359 seven-day windows by volatility — the calmest 3% of the year. A user reading their own bot's history would conclude the +2% gate is broken. It isn't. Our memory is.

The one recommendation that does not survive the same defence is the starter bot's suggested dip-buy. Scaled the same way, a −5% day on the total works out at roughly 0.5% of days — about one day in two hundred. Told to "flip it to a dip-buy", a user would be building a bot that expects to trade on one or two days a year, and nothing on the page says so.

2. It is 91.6% Bitcoin, and we sell it as something only we compute

Our own copy, in the builder and the starter both, calls this "a cap-weighted, broad-market momentum read most bettors never compute". Measured against our own table: across 1,578 timestamps where we stored both, the correlation between the total-market 24h change and Bitcoin's own 24h change is 0.957, an r² of 0.916. Nine-tenths of this signal's movement is explained by a number printed at the top of CoinGecko's homepage and every other crypto site on the internet.

We are not presenting that as a shock. It is close to what you would predict: Bitcoin is 56.6% of the index by weight, and most of the rest trades like Bitcoin, so a high correlation is arithmetic before it is evidence. The residual 8% is real but small. The finding isn't "we discovered it's Bitcoin" — it's that the number is a damped Bitcoin, and our copy sells it as a distinct broad-market factor.

Two claims are bundled in that sentence and they deserve separating. Distinct is the one the correlation refutes. "Most bettors never compute it" is probably fair as far as it goes — most people betting on prediction markets are not pulling CoinGecko's global endpoint — but the phrasing implies proprietary work, and this is one HTTP request to a free, keyless URL. The honest version is that most bettors never gate a bot on it, which is true and much smaller. We should fix that copy; this page is where we admit it first.

3. The number is systematically damped, so a threshold that feels right is about a third too demanding

Total market cap moves less than the coins in it. Our measured beta of the total-market reading against Bitcoin's is 0.752 — when Bitcoin moves 1%, the headline total moves about ¾ of a percent. Across the same week: Bitcoin's own 24h reading ranged ±2.2%, Ethereum's ±3.0%, Solana's −2.5% to +4.4%, Ripple's ±3.6% — and the total ranged only −1.79% to +1.67%. The aggregate is the calmest series on the board.

The main mechanical reason is in our own data: stablecoins are 11.16% of the total market cap on average across the week (we store this, for stablecoin_share_anchor). A ninth of "the crypto market" is pinned to a dollar and cannot move. Even if every non-stablecoin coin moved in perfect lockstep with Bitcoin, that ballast alone would cap the beta at 0.888; the rest of the gap is imperfect co-movement between coins.

The consequence is practical: if you have "Bitcoin up 2%" in your head and you type 2 into this field, you have asked for something meaningfully rarer than you think. To fire on the same days, scale your instinct down — multiply by about 0.75, so a "+2% Bitcoin day" is roughly {"above": 1.5} here. In our week even that was open on just 12 of the 1,595 readings.

This is also, we think, the honest explanation for catch #1. The recommended settings are round numbers that feel right for Bitcoin — 2%, 3%, 5% — pointed at an index that moves a quarter less than Bitcoin does. That is a better description of what went wrong than "the defaults never fire": nobody picked absurd numbers, they picked Bitcoin-shaped numbers for a quieter series, and then had no history to check them against.

4. The signal is blind for a quarter of the clock, and it is designed to be the first thing dropped

Over the window we hold, 2,151 five-minute cycles should have produced a reading. We have 1,595 — 74.2% coverage, blind 25.8% of the time. The gap splits two ways. On 252 cycles the poller finished and wrote all five coin rows but no total-market row — the reading was lost on its own. The remaining ~304 produced no rows at all: a run that crashed, or a cycle that never completed.

The reason is a design decision that is defensible and still bites. The /global fetch and its write sit inside their own try/except, explicitly so that a problem there "can never break the core price polling". It works — but it means that when predictive.db is contended, the coin prices survive and this signal's row is the one thrown overboard. Lifetime, the poller's log shows 869 dominance-step failures with database is locked (plus 2 with database or disk is full), and separately 1,042 runs that died outright on the same lock at the price insert, with a further 190 crashing elsewhere in the same job — 1,230 OperationalErrors in all.

This is the seventh job we have found on the same shared-predictive.db write contention, after resolution_buckets, sentiment_poller, eia_poller, tropical_poller, space_launch_poller and this poller's own price step. On top of that, the vendor side has its own losses: 250 read timeouts, 111 HTTP 429 "Too Many Requests", 31 HTTP 400 and 21 assorted gateway errors.

A fair challenge to catch #1 lives here: if the dropped cycles were the volatile ones, we deleted the evidence and then mocked the threshold. It is a real worry — vendors rate-limit hardest when everyone is hitting them, which is when the market is moving. We can rule it out for this particular week, because the five coin rows survive the cycles the total-market row doesn't. Bitcoin has 253 readings the momentum row is missing, and across all of them Bitcoin's own 24h change never exceeded +2.22% — which at the 0.752 beta in catch #3 implies a total of +1.67%, precisely the highest total we recorded. Nothing was hiding in the gaps. That check works only because a better-covered series sits in the same table; it is not a general defence.

Those 429s are worth a line of their own, because the poller's docstring asserts the opposite: "CoinGecko's free tier allows ~10-30 calls/min — we hit it every 5 min, so 12 calls/hour. Well under any limit." The arithmetic is wrong (we make two CoinGecko calls per cycle, so 24/hour, not 12) and the conclusion is wrong: we have been rate-limited 111 times. Nothing retries, and a rate-limited cycle simply has no reading.

5. The backtester cannot replay it — and it isn't even on the list of things that can't be replayed

A backtest that includes this signal is not testing this signal. The replay loop has no historical total-market series to look up, so it runs the strategy without the gate and still returns a curve. The result is flagged as unsupported_rules, but the curve is still a curve, and a curve is what people look at.

There is a small twist here worth knowing. quants/backtest.py keeps a hand- maintained list, _UNSUPPORTED_ENTRY, of anchors it can't replay — crypto_momentum_anchor is not in it; it was added to the library after that list was last curated and nobody went back. What saves it is that the real check was rewritten to flag every entry key not on the supported list, so a forgotten anchor gets caught anyway. The safety net did its job. The list, though, is now documentation that is quietly out of date.

Unlike energy_anchor, where the vendor happily serves decades of history we simply never ask for, the excuse here is half fair. CoinGecko does not give away the total-market-cap history: its /global/market_cap_chart endpoint returned HTTP 401 Unauthorized to us today for every window we tried. But the half that isn't fair is worse than an excuse — we have been generating this series ourselves, every five minutes, since 17 June, and deleting it. See catch #6.

6. We throw away exactly the history that would make the signal usable

The poller ends every run with a prune: delete everything in crypto_prices older than seven days. That is sensible for five coin prices nobody needs a year of. It is destructive for this signal, because the whole question a user has — "how often would my threshold actually fire?" — is a question about history, and seven days of it is not enough to answer anything. Our table holds eight calendar dates.

Two smaller notes on the same statement. It compares an ISO-8601 timestamp against SQLite's datetime() format as text, and because 'T' > ' ' no row from the cut-off day itself is ever removed — so real retention is seven days plus a partial eighth, which is why our window is 179 hours rather than 168. And a row costs roughly nothing: keeping a year of this one series would be about 105,000 rows.

Nothing on this page proposes changing the poller — that is outside what this loop is allowed to touch, and it is a live job. But it is the single change that would move this signal from undecidable to testable.

7. Two configs that validate and shouldn't, and one that works while the English lies about it

{"above": 2, "below": -5} passes validation and can never be satisfied — it asks for a market that is simultaneously up more than 2% and down more than 5%. It renders in the builder's plain-English preview as a sentence joined by "and", with no warning. This is the same class of defect as the {"^VIX", above: 20, below: 10} case on finance_anchor; the builder's own controls can't produce it, but the JSON path can.

More interesting is the config that does work. {"above": -1, "below": 1} is a genuinely useful "quiet market" band, and the gate handles it correctly. But to_english hard-codes a label onto each clause, so it reads: "only when the total crypto market cap's 24h move is above −1% (risk-on momentum) and the total crypto market cap's 24h move is below 1% (risk-off / capitulation)" — describing a flat, boring market as a rally and a crash at the same time. The rule is right; the sentence explaining it to the user is nonsense.

Also permitted: {"above": 100}. The validator's range is −100 to 100, so "only when all of crypto doubles in a day" is a legal setting.

8. "Momentum" is a 24-hour return, and market cap isn't price

Two smaller honesty points about the name and the number.

Momentum, in the research sense, is persistence measured over weeks or months. This is a single day's return. Calling it momentum is a marketing choice, and a one-day return is much closer to noise than to a trend — which matters, because "trade with the trend" is the reason the starter bot gives for using it.

Market cap is price × supply, across a changing list of coins. The denominator moves: 18,374 coins are tracked today, new listings enter, tokens unlock, stablecoins are minted and redeemed. So a move in this field is not purely a move in prices. We have not measured how large that contamination is on any given day and we are not going to guess at it — but it is a real difference between this number and "the price of crypto went up", and anyone gating money on it should know the difference exists.