A provably fair hash check confirms that the operator honored a commitment — but it cannot detect manipulation of the commitment timing itself. Clash Watchdog AI's Rotation Analysis framework examines when server seeds rotate, whether those rotations correlate with user events, and whether pre-rotation and post-rotation distributions differ. This is an original contribution by the Clash Watchdog AI research team, and this article explains it.
What can hash verification actually prove?
Provably fair hash verification proves exactly one thing: the operator committed to a specific outcome before the player placed a bet, and the revealed outcome matches the commitment. This is a meaningful guarantee. It prevents the most basic form of cheating — changing the result after seeing the bet.
But hash verification is silent on several important questions:
- When was the commitment made? (Before one round? Before a thousand?)
- Why did the commitment change? (Routine rotation? Strategic timing?)
- Does the distribution of outcomes differ across commitment periods?
- Does the timing of commitment changes correlate with player behavior?
These questions are invisible to hash verification because hash checks operate at the round level — they test individual outcomes, not the system that generates them. Rotation analysis operates at the system level — it tests the patterns of how and when the commitment framework changes.
What is a rotation attack?
A rotation attack exploits the gap between per-round integrity and system-level integrity. Here is how it works:
The setup. In a provably fair crash game, the operator generates a server seed and commits its hash. All rounds under that seed produce outcomes derived from the seed via HMAC. The hash chain is honest — every round verifies correctly.
The attack. The operator monitors incoming bets in real time. When a large bet is detected (or a cluster of large bets), the operator triggers a server seed rotation. The new seed was pre-committed (its hash is already published), so the rotation itself is "honest" — the new seed's rounds will also verify correctly.
The manipulation. The operator has pre-computed the first several rounds of the new seed. They know that the new seed's first 3 rounds crash at 1.01×, 1.15×, and 1.03×. By rotating at the moment a large bet arrives, they ensure the large bet lands on a low-crash round. The player loses. The hash verifies. No per-round check detects the manipulation.
Why it works. The provably fair system guarantees that each round under a given seed is determined by the seed, client seed, and nonce. It does not guarantee that the operator cannot choose which seed is active at any given moment. The rotation is the degree of freedom.
The constraint. The operator cannot rotate infinitely — each rotation reveals the previous seed, allowing retroactive analysis. And the operator must pre-commit to each new seed before they know exactly when a large bet will arrive. The attack is not free — it requires predictive capability about when large bets will occur, and it generates observable traces in the rotation timing data.
How does Rotation Analysis detect it?
Rotation Analysis tests five hypotheses, each designed to detect a different aspect of rotation manipulation:
Test 1 — Rotation-bet correlation. We measure the correlation between seed rotation events and the total bet volume in the rounds immediately preceding the rotation. Under the null hypothesis (rotations are independent of bets), this correlation should be near zero. A significant positive correlation (rotations tend to follow large bets) is suspicious.
Test 2 — Pre-rotation vs. post-rotation distribution. We compare the distribution of crash multipliers in the last 50 rounds before each rotation to the first 50 rounds after each rotation. Under the null hypothesis, both distributions should be drawn from the same population. If post-rotation rounds crash significantly lower than pre-rotation rounds, the new seed may have been selected for unfavorable early outcomes.
Test 3 — Rotation frequency analysis. We measure the intervals between rotations and test them against an exponential distribution (the expected distribution for time-independent events). Clustering of rotations (many rotations in a short period followed by long gaps) could indicate strategic timing.
Test 4 — Player-initiated vs. system-initiated rotations. In most provably fair systems, players can trigger rotations by changing their client seed. We separately analyze player-initiated and system-initiated rotations. System-initiated rotations that correlate with bet-size spikes are more suspicious than player-initiated ones, because the system has access to bet data while individual players do not.
Test 5 — Cross-account rotation correlation. If the operator rotates seeds for multiple player accounts simultaneously in response to a single large bet, this is a strong signal. Legitimate rotation policies apply uniformly across time; manipulation is triggered by specific events.
Each test produces a p-value. A finding is flagged when p < 0.01 after Bonferroni correction for the five tests. Flagged findings trigger deeper investigation and potential Watchlist classification.
What are the five checks in Rotation Analysis?
The five tests are summarized here with their detection targets:
| Test | What It Detects | Data Required |
|---|---|---|
| Rotation-bet correlation | Rotations triggered by large bets | Bet volumes + rotation timestamps |
| Distribution shift | Unfavorable outcomes after rotation | Crash points + rotation boundaries |
| Frequency analysis | Non-random rotation timing | Rotation timestamps |
| Initiation source | System rotations correlated with bets | Rotation source tags + bet data |
| Cross-account correlation | Coordinated rotation across accounts | Multi-account rotation data |
Tests 1–3 can be performed with publicly available data (round outcomes and rotation timestamps). Tests 4–5 require data from multiple accounts, which is why they are part of our three-data-source approach.
What's a real-world example of rotation correlation?
No confirmed real-world case has been published as of 2026. We provide a hypothetical example to illustrate the detection method:
Hypothetical scenario: A crash game platform processes an average of $10,000 in bets per minute during normal hours. At 14:32, a single player places a $50,000 bet — 5× the typical per-minute volume. At 14:32:01, the server seed rotates. The first round under the new seed crashes at 1.02×. The player loses $50,000.
Analysis: Is this suspicious? A single instance proves nothing — rotations happen, and large bets coincide with rotations by chance. The question is whether this pattern recurs. If we observe 100 seed rotations and find that 30% of them occur within 2 seconds of a bet exceeding 5× the average, while the expected rate (under independence) is 2%, the correlation is highly significant.
The statistical test: We compute the proportion of rotations preceded by large bets within a defined window. We compare this to the expected proportion under independence (the proportion of all 2-second windows that contain large bets). If the rotation-conditioned rate significantly exceeds the baseline rate, the rotations are correlated with bet sizes.
This is a simplified description. The actual implementation accounts for time-of-day effects, bet-size distributions, rotation frequency, and multiple testing corrections. The full specification is in our methodology.
How does rotation analysis fit into the Gold Tier classification?
Rotation analysis is required for Gold Tier classification of provably fair games. This is a deliberate design choice: Gold represents our highest confidence level, and we do not award it without testing the most sophisticated known attack vector.
The logic: a game that passes Column A (RTP matches declared), Column B (distribution matches theory), and Column C (hash chain verifies) could still be running a rotation attack. Adding rotation analysis closes this gap. A game that passes all three columns plus rotation analysis has been tested against every known fairness threat.
For non-provably-fair games (like Aviator), rotation analysis does not apply because there is no hash chain to rotate. These games are evaluated on Columns A and B only, with the inherent limitation that per-round manipulation cannot be detected. This limitation is noted in the audit report.
The inclusion of rotation analysis in our methodology is, to our knowledge, unique. Standard provably fair verification guides do not test for rotation attacks. We believe this is a gap in existing practice, and we publish our methods openly so that other auditors can adopt and improve on them. The methodology documentation includes the full statistical specification, and the analysis notebooks are available in our GitHub repository for reproduction.