iGaming

How to Build a Provably-Fair Crypto iGaming Game

8 min readAbsolute Foundry

A crypto iGaming game is a casino game whose every outcome can be verified on-chain — players don't have to trust the house isn't cheating, they can check. That single property is the whole pitch. Get it wrong and you've built an ordinary casino with extra steps; get it right and "provably fair" becomes the reason people choose you.

To keep this concrete we'll build one simple, classic game end to end: In-Between (also called Acey-Deucey) — two cards are dealt, you bet whether a third lands between them in rank. It's the perfect teaching case: trivial rules, real house edge, and every fairness and money decision an iGaming product has to make.

01 "Provably fair" is the product — design it first

The temptation is to build the game, then bolt on fairness. We do the opposite, because the verification scheme shapes everything else.

The trade-off we weighedCommit-reveal vs. an on-chain VRF (verifiable random function). Commit-reveal is cheap and classic: the house commits to a hashed seed, the player adds their own seed, the result is derived from both and revealed — neither side can rig it alone. But it needs a reveal step and careful handling if a player walks away mid-round. A VRF (Chainlink-style) gives tamper-proof randomness in one flow at the cost of fees and a dependency. We default to commit-reveal with the player's seed mixed in for card games like this — it's fully auditable, has no oracle dependency, and the math is simple enough for a player to verify themselves. We reach for a VRF when a single trusted random draw (a jackpot, a raffle) matters more than per-round cost.

02 The house edge is the business — make it explicit and honest

A casino game that's truly 50/50 makes no money and won't survive. In-Between has a natural edge: the bigger the gap between the two cards, the more likely you win, so payouts scale with the odds — and a tie or hitting a posted card pays the house. We model the exact edge before writing a line of contract code, because:

It sets the payout table — the numbers that decide whether the game is profitable and still feels fair to play.
It drives the bankroll math — how much float the contract needs to cover a hot streak without going insolvent.
It's a disclosure — a credible iGaming product publishes its edge, it doesn't hide it.

03 The contract: custody, payouts and the bankroll

The smart contract is a tiny bank. It takes the bet, derives the verified outcome, pays winners and keeps the rest. The decisions that actually bite:

Bankroll solvency — the contract must never promise a payout it can't cover. We cap the max bet as a fraction of the bankroll so one lucky round can't drain it.
Pull-over-push payouts — credit winnings to a balance the player withdraws, rather than pushing transfers that can fail and wedge the round.
Reentrancy and rounding — the classic ways on-chain money contracts get drained. Checks-effects-interactions, audited math, no shortcuts.
House liquidity — who funds the bankroll, how the edge accrues to it, and how operators withdraw profit without touching player funds.

This is the same discipline as an escrow contract — it just happens to pay out on a card draw instead of a milestone.

04 Speed and feel — without giving up trust

Players expect a slot-machine cadence; blockchains confirm in blocks. We bridge the gap with an optimistic UI — deal and animate instantly off the verified seed, then settle on-chain underneath — and by choosing a fast, cheap chain so a $1 bet isn't eaten by gas. The animation sells the moment; the contract guarantees it was honest.

Where we'd landCommit-reveal fairness with the player's seed mixed in, a modelled and published house edge, a bankroll-safe contract with capped bets and pull-payments, and an optimistic UI on a low-fee chain. Auditable by anyone, fast enough to be fun.

05 The part most projects skip: guardrails

This is where an iGaming build is won or lost as a real business. Real-money gaming is regulated, jurisdiction by jurisdiction, and "it's on-chain" is not a legal shield. We build in geofencing, age and eligibility checks, deposit/loss limits and self-exclusion from day one — and we're frank with clients about licensing and which markets are off-limits. A provably-fair game that ignores responsible-gaming and compliance isn't clever; it's a liability. Fairness and compliance by design are the same instinct applied to two different risks.

Key takeaways

Provable fairness is the product — design the verification scheme before the game.
Commit-reveal (player seed mixed in) fits card games; VRF fits single trusted draws.
Model and publish the house edge; size the bankroll and cap bets so the contract stays solvent.
Use an optimistic UI on a cheap chain for feel — and build compliance and responsible-gaming guardrails in from day one.

FAQ

What makes a crypto game "provably fair"?

The outcome is derived from seeds neither side can control alone (commit-reveal) or from verifiable on-chain randomness (a VRF), so any player can independently check that a result wasn't rigged.

Doesn't on-chain mean no house edge?

No — provable fairness verifies the randomness, not the odds. The house edge is built into the payout table and is fully compatible with being provably fair; the best products publish it openly.

Is launching an on-chain casino legal?

Real-money gaming is regulated per jurisdiction and being on-chain doesn't change that. We build geofencing, eligibility checks and responsible-gaming limits in, and advise clients on licensing and restricted markets.

We build provably-fair games end to end — contract, math and the guardrails that keep them legitimate.

Build my game