How to Verify a Dice Roll Was Fair, Step by Step
A provably-fair dice roll is a checkable claim, not a marketing line. On Llamabet, a hash of the server seed is committed to the Sui blockchain before you bet, you contribute your own client seed, and the roll is derived deterministically from both. After the seed rotates and is revealed, anyone — you, a rival, a skeptic on a forum — can re-run the math and confirm every roll. Here is exactly how.
Roll verifiable dice →Commit-reveal in one paragraph
The scheme rests on a property of cryptographic hashes: they are one-way. Given a server seed, computing its SHA-256 hash is trivial; given the hash, recovering the seed is computationally infeasible — and any change to the seed produces a completely different hash. So the casino generates a secret server seed, publishes its hash on Sui before any bets are placed, and keeps the seed itself hidden while the seed is live. Publishing the hash is a binding commitment: the house has locked in its randomness without exposing it. You then supply a client seed of your own choosing, and each roll is derived deterministically from the combination of server seed and client seed. Since the house committed first and you contributed second, neither side could have engineered the outcome — the house could not pick a seed to beat your bet it had not seen, and you could not pick a client seed to beat a server seed you cannot read.
Why the commitment lives on-chain
A hash on the casino's own website is a weak commitment — a dishonest operator could quietly swap it and few players would ever notice. Llamabet instead publishes each server-seed hash in a transaction on the Sui blockchain, where it is timestamped, immutable and independently readable on any Sui explorer. That closes the last loophole in the scheme: the operator cannot rewrite history, cannot show different hashes to different players, and cannot claim after the fact that a different seed was in play. The blockchain acts as a neutral notary that neither party controls. This is the piece that separates on-chain provable fairness from the off-chain variety — the commitment is anchored somewhere the house cannot edit, before the first bet against that seed is ever placed.
Your half of the randomness: the client seed
The client seed is your defense against a subtler attack: a house that pre-computes outcomes. If rolls depended only on the server seed, an operator could generate seeds, simulate the resulting rolls in advance, and discard any seed that produced a player-favorable sequence — technically honoring its commitments while curating them. Mixing in a client seed the house cannot predict destroys that strategy: the roll sequence is unknowable until you choose your input, and you can change that input whenever you like. Practical advice: set your own client seed rather than accepting a default, change it when a new server seed goes live, and record the values you used alongside the on-chain commitment. Those three data points — committed hash, client seed, revealed seed — are the complete evidence file for auditing your session later.
The verification steps, one by one
After the server seed rotates and the old seed is revealed, run four checks. Step one: collect the revealed server seed from the fairness panel, plus the client seed you used. Step two: recompute the hash — run the revealed seed through SHA-256 using any tool you trust (a local script, your terminal, an independent online hasher). Step three: compare that output to the commitment published on Sui before your bets, by looking up the commitment transaction on a Sui explorer. If the recomputed hash matches the on-chain hash, the seed you were just shown is provably the seed that existed before you bet. Step four: re-derive the rolls — feed the server seed and your client seed through the published derivation formula and confirm the outputs match the results you were paid on. Every step uses public data and independent tooling; at no point do you need to trust Llamabet's own interface to grade its own homework.
What each check actually proves
It pays to be precise about what you have established. The hash match (step three) proves temporal integrity: the server seed was fixed before your bets, because the odds of finding a second seed with the same SHA-256 hash are astronomically negligible. The roll re-derivation (step four) proves computational integrity: each result follows mechanically from the two seeds, so the house did not fudge an outcome or misreport a roll after seeing your stake. Together they prove the property that matters: at no point between commitment and payout did the operator have both the knowledge of your bet and the freedom to change the result. That is a stronger statement than any fairness audit can make, because it is proven per roll, from public data, by you.
What verification cannot tell you
Honest limits, stated plainly. Verification proves past rolls were untampered; it says nothing about future rolls — those depend on a server seed that is still secret, which is exactly why the scheme works. It does not predict or improve your luck: a verified roll is still a random roll, and Llamabet dice still carries its flat 1% house edge (payout = 99 divided by win chance) at every setting. Losing streaks happen in provably-fair games at precisely the frequency probability dictates — verification lets you confirm a brutal streak was legitimate randomness, which is genuinely useful for peace of mind, but it will not shorten the streak. And it cannot audit anything outside the roll itself, such as whether a given game's posted edge suits you. Fairness and favorable odds are different questions; this scheme nails the first and merely makes the second transparent.
Why this beats a certificate that says trust us
Traditional online casinos answer the fairness question with an RNG certificate: a testing lab sampled the operator's random number generator at some point and found its output statistically sound. That model has three structural gaps — it is a snapshot (the code that runs tonight is not necessarily the code that was tested), it is third-party (you trust the lab instead of the casino, but you still trust someone), and it is aggregate (a certificate cannot tell you anything about the specific roll that just took your stake). Commit-reveal on a public chain inverts all three: verification is continuous rather than periodic, self-serve rather than delegated, and per-roll rather than statistical. You do not need to believe anyone. You check. That is the whole difference between provably fair and probably fair — and once you have verified a roll yourself, end to end, the certificate model starts to look like what it always was: a promise.
Frequently asked questions
How do I verify a dice roll was fair?
Wait for the server seed to rotate and be revealed, then: recompute the SHA-256 hash of the revealed seed, compare it to the commitment published on Sui before your bet (via any Sui explorer), and re-derive your rolls from the server seed plus your client seed using the published formula. If both checks match, the rolls were provably untampered.
What does the server seed hash on the blockchain prove?
It proves the house locked in its randomness before you bet. Because SHA-256 is one-way and collision-resistant, the operator cannot find a different seed matching the committed hash — so when the seed is revealed and hashes to the on-chain commitment, you know outcomes were fixed by that seed all along, on a timestamped record the house cannot edit.
Can a provably fair casino still cheat?
Not on the rolls themselves, if you verify — the on-chain commitment plus your client seed remove the freedom to alter results after seeing bets. What provable fairness does not cover is everything outside the roll: posted odds, payout terms, withdrawal behavior. Verify the math, and judge the rest the way you would judge any counterparty.