Investigation: Moonroll Fake Verifier

Moonroll.io markets its Plinko game as provably fair. Following multiple player reports about the verification flow, we conducted an independent technical review of the live game and the on-site “Plinko Fairness Checker.” The review covered the user interface, the bet API, network traffic, cookies, and the source code of the public verifier tool.

The conclusion is that none of the components required for a cryptographically verifiable provably fair system are present in the live game. The verifier tool published on Moonroll’s site exists, but it does not match the live game’s logic and cannot be used to reproduce a real bet.

Across seven core requirements of a provably fair system, Moonroll’s Plinko implementation does not satisfy any.

What a provably fair game requires

A provably fair game makes a cryptographic commitment to its outcome before the player bets, then reveals the underlying randomness afterwards so the player can independently reproduce the result. In practice, that means five components must be present and accessible to the player:

• A server seed hash published before the bet (the commitment).
• A client seed chosen or set by the player.
• A per-bet nonce that ensures each bet is uniquely indexed.
• A deterministic RNG formula the player can run themselves, typically HMAC_SHA256(serverSeed, clientSeed + nonce).
• A server seed reveal after the round, so any past bet can be reproduced.

If all five are present and the reveal matches the original commitment, a third party can recompute the outcome and confirm it was not manipulated. If any of these components are missing, the chain breaks and the player has no way to verify the result.

A proper provably fair flow (left) chains the player’s seed, the server commitment, and the deterministic RNG into a reproducible outcome. Moonroll’s implementation (right) skips the commitment and player input entirely.

Where Moonroll’s implementation falls short

Across the live game, the bet API, and the response payloads, none of the required components appear.

The bet request submits only a bet amount, risk level, and number of rows. There is no field for a client seed and no nonce. The bet response returns the final path, the bucket index, and the multiplier — all already computed. The player is never shown a server seed hash before betting; only a raw server seed appears in the bet history afterwards, with no prior commitment to compare it against.

Without a pre-bet hash commitment, a player has no way to confirm that the server seed shown afterwards is the one that produced the outcome — rather than one selected from a range of possible seeds after the bet was resolved. Without a client seed or nonce, even if the server seed were honest, the outcome cannot be independently recomputed.

A Plinko bet record in Moonroll’s history view. A server seed is shown after the fact, with no prior commitment hash, no client seed, and no nonce.

Why the on-site fairness checker doesn’t fix this

Moonroll publishes a “Plinko Fairness Checker” on its site, presented as a verification tool. Source-code analysis of the checker shows that it does not match the live game in three measurable ways.

The checker calculates outcomes using a different RNG construction:

This concatenates the two seeds and hashes the result with the bet index appended as a string. The live game’s RNG, whatever it is, is not exposed; the bet API never asks for these inputs and never returns them. The two systems use different randomness pipelines.

The checker also targets a different RTP:

The live game advertises approximately 99% RTP. The checker hardcodes 95%. Multipliers are scaled internally to produce that 95% expected value, which is mathematically incompatible with the multipliers the live game returns. The checker generates a smoothed multiplier curve with smaller extreme payouts; the live game uses fixed extreme multipliers such as 110× and 1000×.

Moonroll’s on-site Plinko verifier tool. It runs a self-contained simulation and cannot reproduce a real bet from the live game.

Because the checker accepts inputs (client seed, server seed) that the live game does not produce, and uses different RTP and multiplier logic, it cannot be used to verify any real bet. It is a self-contained simulation displayed alongside the game, not a verifier of it. It presents the full interface of a verification tool while being structurally incapable of reproducing a single live bet.

What this means for players

The practical consequence is that players betting on Moonroll Plinko have no cryptographic guarantee about the outcomes. The RTP cannot be independently confirmed, the distribution of multipliers cannot be checked, and historical bets cannot be replayed against published seeds. The system relies entirely on trust in the operator — which is the condition that provably fair gaming was originally designed to eliminate.

Side-by-side comparison of the core components of a provably fair system against Moonroll’s implementation.

This is an instance of what we have described elsewhere as partial provable fairness — a category of implementations where the label is applied to a game whose underlying mechanisms do not deliver the property the term implies. Moonroll’s case sits at the extreme end of that category: the components are not partially implemented, they are absent.

A working fix would require Moonroll to implement a real commit-reveal flow, accept a client seed, expose a per-bet nonce, and replace the standalone fairness checker with a verifier that reproduces actual bet outcomes from real seed material. Until those changes are in place, the “provably fair” claim on Moonroll Plinko is not supported by what the game actually does.