Provably fair explained, and what it does not prove

The scheme

Provably fair systems are a commit-reveal protocol. The mechanics vary between operators, but the skeleton is consistent:

1. 01The server generates a secret seed for the round and publishes a hash of it before you bet. A hash is a one-way fingerprint: it identifies the seed without revealing it.
2. 02You supply a client seed, which you can change at any time, and which the server cannot predict.
3. 03The round outcome is computed from both seeds together, usually with a nonce that increments per bet.
4. 04Afterwards the server reveals its seed. You hash it, check it matches the commitment published beforehand, and re-run the same derivation to confirm the result you were given.

The guarantee is genuine. Because the server committed to its seed before seeing your bet, and because your seed is mixed in, the operator cannot pick a result after the fact. Retroactive tampering is detectable, and that is a real class of cheating eliminated.

What it does not cover

Verification confirms one thing: that the published result is what the published algorithm produces from the two seeds. It is silent on everything upstream of that.

• The mapping from random number to outcome. The seeds produce a uniform value; the game turns that value into a crash point, a bucket, or a roll. That conversion is where the house edge lives, and it is code, not cryptography.
• The paytable. Nothing in a commit-reveal scheme certifies that the multiplier printed beside a bet is the one that actually gets applied.
• Whether you verify at all. Almost nobody does. A verifiable system that goes unverified is functionally an unverified one.
• Everything around the game. Bonus terms, wagering requirements, withdrawal limits and account closures are untouched by the protocol, and they are where most real disputes actually happen.

A worked example: honest payouts, dishonest rolls

The cleanest way to see the gap is a dice game, because the whole thing fits in one line of arithmetic.

You roll a number from 0.00 to 100.00 and bet on whether it lands over or under a target. Multiplier, target and win chance are three views of one number: pick any one and the other two follow. At a 50% win chance the fair multiplier is 2.00×; at 25% it is 4.00×; at 2% it is 50.00×.

Now suppose the payouts are perfectly fair — no edge in the multiplier at all — but the roll is quietly biased so that numbers land under the target slightly less often than uniform chance says they should. The printed multiplier does not change. The stated win chance does not change. The verification page still checks out, because the seeds really did produce that number under the published algorithm.

The real RTP has moved anyway, and none of the things a player is invited to check will show it. The only way to detect it is statistical: play a very large number of rounds and compare the observed win rate against the stated one.

So what should you actually check?

Verification is worth something, but it is the last line of defence rather than the first. In rough order of how much protection each provides:

1. 01A published RTP or house edge, per game. If the cut is not stated, nothing else you check matters much.
2. 02Independent testing. A lab that models the game and runs large simulations against the production build is testing the mapping and the paytable, which is exactly what commit-reveal does not cover.
3. 03Large-sample empirical results. Aggregate win rate against stated win rate, over tens of thousands of rounds. This is the only test that catches a biased mapping.
4. 04Commit-reveal verification. Genuinely useful, and narrow. It closes the retroactive-tampering hole and no other.

What LarpCasino claims instead

LarpCasino is a simulated casino for iPhone, and it deliberately does not claim to be provably fair. There is no server, no seeds and no verification page, because there is no network involved at all — every round is generated on the device, and no money exists in the app to protect.

The claim it does make is different in kind: the odds are local, inspectable and set by you. The house edge is a slider from −100% to +100%. Every game prints the odds it is running at. And the RTP simulator runs 10,000, 100,000 or 1,000,000 rounds against your live configuration, reporting empirical RTP beside theoretical RTP, win rate, house profit and longest losing streak.

There is one more feature that exists purely to make the point of this article. Most games carry a bias dial that moves real RTP away from the printed table — precisely the attack described above. Dice is the clearest demonstration: its payouts are locked fair, and biasing it moves the roll instead, leaving every printed number untouched. When bias is on, the lobby badge reads "Biased," and the RTP simulator will show you the damage in the empirical column while the theoretical column keeps insisting everything is fine.

That divergence between the two columns is the thing worth internalising. It is what an unverifiable game looks like from the inside, reproduced somewhere it cannot cost you anything.

The short version

• Provably fair is commit-reveal: the server commits to a hashed seed before you bet, then reveals it so you can re-derive the result.
• It rules out changing an outcome after the fact. That is a real guarantee and a narrow one.
• It does not certify the odds-to-outcome mapping, the paytable, or the actual RTP.
• A game can pass every verification check while running a biased roll behind an honest-looking multiplier.
• Only large-sample statistics catch that, which is why a simulator that runs a million rounds is a more useful tool than a hash.