Four ways to prove a random number: commit-reveal, beacons, VRF, certified hardware

What “proving random” even means

Strictly, you cannot prove one number is random — randomness is a property of a process, not an output. Every scheme below therefore proves something narrower and more useful: that a specific party could not have chosen or changed the outcome after a specific moment. The schemes differ in who that party is, when the moment falls, and who gets to check.

The four schemes, side by side

1 · Commit-reveal seed pairs

The provably-fair standard, and what Betkyo’s originals run. The house hashes a secret server seed and shows you the hash before you bet; your own client seed is mixed into every outcome via HMAC; a counter makes each round unique. Rotate the pair and the old seed is revealed — now every past round recomputes on your side of the table. The full walkthrough takes about a minute to perform.

• Proves: no result was altered after commitment; your seed co-authored every outcome.
• Assumes: the hash is sound (SHA-256), and the outcome mapping is published — which is why we print paytables next to the scheme.
• Fits: solo instant games — dice, limbo, cards — where each player deserves a private, free, immediate proof.

2 · Public randomness beacons

A beacon publishes one random value on a fixed schedule, generated so that no single operator can steer it — drand does this with threshold cryptography across independent organizations (universities, infrastructure companies), NIST with a government-run pulse chain. Everyone on Earth sees the same value at the same time, which is exactly what shared events want: one round of Crash, one lottery draw, one tournament seeding.

• Proves: the raw number was outside everyone’s control, including the house’s.
• Assumes: the honest-threshold of operators — and, crucially, that the house committed its mapping (how the pulse becomes a result) before the pulse landed. A beacon does not save a house that picks the formula afterward.
• Fits: shared rounds, raffles, anything where many players must trust one draw.

3 · Verifiable random functions

A VRF is a keyed function whose output arrives with a proof: anyone holding the public key can check that this exact output is the unique correct one for this input — no reveal step, no waiting. On-chain implementations let a smart contract verify the proof mechanically before using the number, which is why VRFs dominate blockchain gaming and NFT mints.

• Proves: the number is the deterministic, unforgeable output of a committed key on a known input.
• Assumes: the key holder keeps the key safe, and the input (the “request”) was itself not gameable.
• Fits: on-chain settlement, where the verifier must be a program and gas is worth paying.

4 · Certified hardware, audited

The incumbent model of the licensed industry: a hardware or certified software RNG, examined by an accredited testing laboratory, operating under a regulator. It is a real assurance — labs run serious statistical batteries — but it is institutional assurance. The player verifies nothing; the player reads a certificate. When the certificate is real and the regulator has teeth, this works. The player simply has no way to tell from the outside.

• Proves (to you): that someone else says it is fine.
• Fits: the licensed mainstream — and any setting where players do not want to verify anything themselves.

What none of them prove

A perfectly verified random number can still feed a terrible game. No scheme above constrains the odds — a provably-fair game paying half of fair value verifies flawlessly. Randomness proofs answer “was the draw honest?”; only a published paytable answers “was the deal honest?”. That is why every Betkyo game shows its multipliers and house edge next to the fairness scheme, and why our journal articles quote them from engine source.