«Provably fair» sits on a lot of casino front pages and is almost never tested, which wastes the entire point of it. The scheme exists so that nobody has to be trusted: an outcome is a deterministic function of values committed before the bet was placed, and reproducing it needs a hash calculator and a couple of minutes.
What it replaces
A conventional online slot draws its numbers server-side. The player sees an outcome and nothing else, and the assurance behind it is a laboratory report on a generator tested once, on a test rig, at some point in the past. That audit is a snapshot; your rounds number in the thousands.
Provably fair reverses the order of events. The server commits to its share of the randomness before the button is pressed and reveals it afterwards. Swapping an outcome mid-round would break the link between the commitment and the reveal, and the mismatch is visible to anyone holding a SHA-256 tool.
Three inputs make a round
- Server seed — a random string held server-side. Before play you are shown its SHA-256 hash rather than the string. Hashing runs one way: the hash gives nothing away, yet it lets you confirm afterwards that the revealed string is the same one.
- Client seed — a string you choose. It is the piece that stops the server from hunting in advance for a seed that lands badly on your particular bet.
- Nonce — a bet counter inside the current seed pair. It steps up every round, which is why one pair never returns the same outcome twice in a row.
From seeds to an outcome
The standard construction is HMAC-SHA256, keyed with the server seed, with the client seed, the nonce and the index of the number being drawn concatenated into the message. That index matters wherever one number is not enough: several mine positions, a dealt hand, a ball bouncing down rows of pegs. The output is 32 deterministic bytes — identical inputs, identical result, every time.
The bytes then become a fraction between zero and one, the leading ones read as digits in base 256. Each game maps that fraction onto its own outcome space: a coin side, a roulette pocket, a Plinko bucket. The per-game formula is published on the provably fair page, and without it there is nothing to check a result against.
Verifying a round, step by step
- Before playing, save the hash of the active server seed shown in the fairness settings.
- Set your own client seed. Any string does; what counts is that the choice was yours.
- Play, then note the nonce of the round you intend to examine.
- Rotate the seed pair. An active server seed is deliberately withheld, since knowing it would let anyone compute the next rounds in advance; the reveal follows once that seed is retired.
- Push the revealed string through SHA-256 and compare it with the hash you saved. A match places the seed before your bets rather than after them.
- Compute HMAC-SHA256 over the same three values and apply the game's conversion rule. The number has to match the entry in your bet history.
No dedicated software is involved — an online hash calculator or five lines of Python covers it.
What verification does not prove
The scheme establishes one thing: the result was not altered after the bet. It says nothing about how much the game takes on average, because the house edge lives in the payout table, where a win pays slightly less than true odds. A round can be flawlessly verifiable and still unprofitable over distance. Two separate properties, routinely mistaken for one.
Coverage is the other limit. Tonza Originals — Coin Flip, Mines, Roulette, Plinko, Blackjack — derive each round from seeds and can be recomputed by hand. Third-party slots and table games run on the provider's own generator with its own verification model, and the seeds in your profile have no bearing on them.
One practical closing note: a scheme nobody exercises protects nobody. Change the client seed on your own initiative instead of waiting for a system rotation, particularly during a long session on a single pair. Check winning rounds as well — a calm spot-check reveals more about the mechanics than a frantic recount after a losing run, when the search is for someone to blame rather than for an error.
