Rotator's scoring engine is not fixed. When it changes, the numbers it produces change with it — and sometimes the published accuracy counter has to restart, because an old score and a new one are not measuring the same thing. This page lists every change, what it moved, and what it did not.
The counter on the track record page has restarted twice in one week. Without an explanation that looks like a tool hiding a bad run, so here is the explanation.
Rotator publishes a running accuracy figure. That figure is only meaningful if every call inside it was produced the same way. Change how the model scores, and the calls before and after are two different measurements — averaging them into one number would report something that was never true of either.
So the record restarts instead. It costs the history, and it is still the honest option. The retired engine's final figure is kept and shown separately rather than quietly folded in.
Two things force a restart. Nothing else does.
1. A score changed meaning. The same number now describes something different, so old and new calls cannot share an average.
2. The published selection changed. The scores are identical, but a different set of assets reaches the shortlist — so the calls being graded are drawn from a different population.
Of the four releases below, two moved a score and two did not. The two that did not were built that way deliberately: a change that only adds information, without touching any existing number, leaves the record intact and comparable. That is worth designing for, and it is why 2.2.0 was built as a separate classification rather than as another term inside the score.
A redesigned scoring model was built alongside the live one and tested against 771 days of price history, measuring whether its scores actually related to what assets did next.
They did not — no better than the existing model, and on one measure worse. So it was not shipped. It still runs alongside the live model on every update and is recorded, unpublished, in case later evidence changes the answer. The live scoring was left untouched.
Smaller assets carried a size adjustment meant to dampen their scores. Because of how it was applied, on assets already scoring negatively it raised the score instead of lowering it — moving exactly the assets it was meant to hold back toward the top of the shortlist.
It affected 145 of 191 tracked assets, so this was the normal case, not an edge case. Rewriting it changed 93 scores and moved 4 assets between bands. Assets in the mid-cap range were unaffected, exactly as expected — that zero is what confirmed the fix behaved as designed.
A 2.1.0 score is a different quantity from the one before it, so the counter restarted here.
Until this release, an asset reached the rotation shortlist by scoring low and having fallen over the past month. Nothing checked whether the fall had stopped, whether the weakness was confirmed by anything other than past performance, or whether the asset had already moved sharply in the other direction.
On one recorded day the shortlist included an asset that had risen 46.8% in 24 hours. Every other component scored it well, and nothing was watching the one number that mattered.
Five checks now run before anything is presented as a new rotation candidate: an extreme recent move, whether a pullback exists at all, whether the decline is accelerating, whether RSI confirms the weakness, and whether prices have steadied. Assets that fail are still shown and still scored — they are labelled rather than promoted.
No score, ranking or band changed. The shortlist narrowed: on live data it went from nine candidates to three. Two of those removed had actually risen over the previous week and were on the list purely because their 30-day figure was negative.
Part of the model still ran in your browser rather than on the server. That had two consequences worth stating plainly. The number was not the same for every visitor — it was calculated on a different scale depending on which assets you happened to be tracking. And where real RSI was unavailable, it substituted a stand-in derived from an asset's ranking against the others, which is not the same measurement and should not have carried the same name.
All of it now runs once, on the server, from real indicator data. Every visitor sees the same number, and the stand-in has been removed rather than kept as a fallback.
No score and no band changed in production — checked against live data before and after the update. The counter restarted here for 2.2.0's reason, not this one: the shortlist is now drawn from a stricter selection than the calls recorded the day before.
| Since | Unchanged across all four releases |
|---|---|
| momentum | The 7 / 14 / 30-day ranking blend at the core of the score. Re-weighting it was tested and moved the ordering so little it was left alone. |
| eligibility | Liquidity floor, market-cap sanity and delisted-pair exclusion. An asset can score well and still be untradeable; that has been filtered since before this log begins. |
| grading | How a published call is judged: price clearing a market-cap-aware threshold within 7–14 days. Unchanged, so accuracy figures are comparable between engines even when scores are not. |
| data | Prices and market data from CoinGecko; exchange and indicator data from Binance. No change in sources. |
Every figure quoted here was measured, not estimated. Model changes are tested against a frozen day of real market data before release, then checked again on live data afterwards — comparing the update before against the update after, so what moved is observed rather than assumed.
One correction worth recording. The retired engine's final accuracy was published as 66%. Re-grading the stored calls under the same rules gives 76.2% across 863 calls. The difference was a fault in how the page loaded price history, not in the calls themselves — it had been under-reporting. The figure now shown is the re-graded one.
Accuracy is graded on the best price reached inside the 7–14 day window, so read it as an upper bound rather than a typical outcome.