Randomness Architectures for On-Chain & Online Casinos — Research Report

Date: 2026-07-28 · Author: Dario (research subagent) · Scope: research only, no code changes. Labeling convention: [VERIFIED] = confirmed from a primary source fetched during this research (URL given). [PARTIAL] = primary source confirms part of the claim. [UNVERIFIED] = from prior knowledge / secondary sources; could not be confirmed from primary docs during this session (several sites block bots or 404'd).

Q1 — How crypto casinos source randomness

1.1 Stake.com — "Provably Fair" (commit-reveal, centralized)

[PARTIAL — stake.com blocks bot fetches (Cloudflare 403); the scheme below matches Stake's published docs and is the industry-standard scheme used almost verbatim by Stake, BC.Game, Shuffle, Roobet, etc.]

Mechanism:

1. Server seed: casino generates a random server seed; publishes only SHA-256(serverSeed) to the player before betting (the commitment).
2. Client seed: player supplies (or can edit) a client seed.
3. Nonce: an incrementing counter per (serverSeed, clientSeed) pair — one increment per bet, so one seed pair covers thousands of bets.
4. Outcome: HMAC-SHA256(serverSeed, clientSeed:nonce[:cursor]) → bytes → mapped to cards/rolls/multipliers deterministically per game.
5. Reveal: the server seed is revealed only when the player rotates to a new seed; the player can then recompute every past bet and check the hash matches the pre-published commitment.

Trust assumptions (important — this is NOT trustless):

• The operator is centralized; the commitment prevents retroactive changing of outcomes, but:
• The casino knows all outcomes in advance for the current seed pair (it holds the server seed). It cannot change a given bet's result, but it could in principle profile players, or adaptively influence behavior (bonuses, disconnects, bet limits) knowing future outcomes.
• The player must trust that the client seed is actually incorporated as documented and that the revealed seed corresponds to what was actually used for their account (no per-player selective implementation) — auditable only after the fact, and only if the player bothers.
• No third party enforces anything; the guarantee is reputational + verifiable-after-the-fact math.
• Marginal cost per random number ≈ zero (one HMAC computation).

Rollbit, BC.Game, Shuffle: all use the same server-seed-hash + client-seed + nonce commit-reveal pattern for their in-house "originals" games; third-party slots on these sites use the game studio's certified RNG (see Q2). [UNVERIFIED for exact per-site parameter details; scheme itself is uniformly documented across these operators' "provably fair" pages.] Note: none of these are "on-chain casinos" — they are custodial web casinos that accept crypto.

1.2 On-chain casinos and their randomness sources

• WINR Protocol / JustBet (just.bet, Arbitrum): [VERIFIED that WINR is a live on-chain casino protocol with shared on-chain bankroll and on-chain settlement — https://docs.winr.games/]. Historically JustBet/WINR used Supra dVRF on Arbitrum (announced partnership in 2023). [UNVERIFIED in current docs — the current docs.winr.games pages I could fetch do not name the randomness provider; treat "Supra dVRF" as historical/likely.]
• Pyth Entropy users: Pyth's own case studies list on-chain gaming/gambling users on Arbitrum/Blast/Berachain (e.g., degen games and casino protocols); Entropy is explicitly marketed for "blockchain game, NFT mint, lottery" [VERIFIED marketing claim — https://docs.pyth.network/entropy]. Specific casino names not verified this session.
• Chainlink VRF users: PoolTogether (lottery, historically), many lotteries/loot-box games; per-request cost model verified below (Q5). Full-table casino games on VRF are rare because of latency (multi-block confirmation) and cost.
• Randomizer.ai (Arbitrum): site is still up and serves integration docs/sample code [VERIFIED alive as a website — https://randomizer.ai/]. It was the randomness supplier for several 2022–2023 Arbitrum degen casinos. Whether the oracle network is still actively fulfilling requests could not be verified on-chain this session [UNVERIFIED — check the Randomizer contract's recent tx activity on Arbiscan before depending on it; activity reportedly dwindled after 2023].
• ZKasino: notorious — marketed as an on-chain casino, but in April 2024 moved ~$33M of user bridge deposits to staked ETH instead of returning them; widely reported as a rug. Lesson: "on-chain casino" branding ≠ trustless randomness or trustless custody. [UNVERIFIED this session; extensively reported at the time.]
• Decentral Games (Polygon/Decentraland): used Chainlink VRF for some games in its ICE Poker / casino era [UNVERIFIED this session]; the project has since pivoted away from casino games.
• Edgeless (2017, Ethereum): early "0% house edge" casino; used a commit-reveal scheme between player and house on-chain. Effectively dead. [UNVERIFIED this session.]

1.3 FunFair "Fate Channels"

[UNVERIFIED from primary source this session — funfair.io docs are largely offline; description from the FunFair whitepaper and technical blog posts (2017–2020).]

• FunFair ran casino games inside state channels between player and operator. Each random draw used a mutual commit-reveal inside the channel: both parties committed to seeds; XOR/hash of both reveals produced each card/roll. Because it was a 2-party channel, reveals were instant (no block confirmation) → sub-second latency at near-zero cost, with on-chain settlement only at channel open/close, and on-chain dispute resolution if a party stalled.
• Why relevant: it is the existence proof that per-action, low-latency, 2-party-trustless casino randomness works — the exact property a per-action blackjack game needs. Its trust model equals Pyth Entropy's 2-party commit-reveal (random if either party is honest), with the same caveat: the house sees the outcome before finalizing and could stall/censor; Fate Channels handled that with on-chain timeout/dispute logic that penalized the staller. FunFair shut down its B2C/B2B casino operations (~2022) for business/regulatory reasons, not because the crypto broke.

Q2 — Traditional (non-crypto) iGaming randomness

2.1 How it works

• Game studios (Evolution, Pragmatic Play, NetEnt, Microgaming/Games Global, Playtech) run a certified software RNG on their own game servers — typically a CSPRNG (e.g., Fortuna, SHA/AES-CTR-based DRBGs, or a well-seeded Mersenne Twister variant reseeded from hardware entropy; exact algorithms are lab-audited, rarely public). Live-dealer games (Evolution) use physical cards/wheels plus certified shufflers, with software RNG only for side features. [UNVERIFIED per-studio algorithm details — studios publish certificates, not algorithms; the pattern itself is standard and documented in lab standards.]
• The RNG is certified against standards such as GLI-19 (interactive gaming systems) and jurisdiction rules (MGA, UKGC, NJ DGE, etc.). Labs: GLI, iTech Labs, BMM Testlabs, eCOGRA (eCOGRA also does ongoing RTP/payout audits). Certification covers: statistical quality (diehard/NIST-style suites), seeding/reseeding, scaling to game outcomes without bias, non-predictability, and change control on the binary.
• Costs: labs don't publish price lists. Industry-cited ballparks: RNG certification per platform ≈ $10k–$40k, per-game math/RTP certification ≈ $2k–$10k per game per jurisdiction, plus annual audits. [UNVERIFIED — estimates only; no public primary figures found.] Licensing (MGA/UKGC) adds tens to hundreds of thousands per year.

2.2 The key economic point — CONFIRMED as a matter of architecture

A local CSPRNG produces a random number for effectively zero marginal cost (microseconds of CPU). The entire cost structure is fixed: certification + licensing + compliance. Players do not verify anything mathematically; they trust the regulator and the test lab (and the operator's license being at stake). This is the exact inverse of the on-chain model, where trust is bought per-request (oracle fee + gas) and verification is mathematical/public. Any on-chain casino design should be judged against this benchmark: incumbents pay ~$0 per random number.

Q3 — Trustless/verifiable randomness landscape (per-action casino on Arbitrum)

Bottom line for Q3: on Arbitrum today, for per-action 1–3s randomness, the realistic shortlist is Pyth Entropy (fast, cheap, but single-provider commit-reveal trust), Chainlink VRF v2.5 (strongest brand, too slow/expensive per action), and drand-derived designs (best trust model, latency-marginal, DIY engineering). Nothing off-the-shelf is strictly "better than Pyth Entropy" for this use case; the improvements available are economic (slashing) or threshold (t-of-n), both DIY.

Q4 — Evaluation: RAIN Protocol's own permissionless entropy network (Pyth-Entropy-style + staking/slashing)

4.1 Economic soundness — yes, and the math is favorable

The only attack a commit-reveal provider has is selective censorship: compute r off-chain, and if r is bad for the provider, refuse to reveal [VERIFIED this is the attack — Pyth's own docs list it: https://docs.pyth.network/entropy/protocol-design].

Quantify for blackjack: censoring a reveal ≈ voiding a hand (bet refunded, per protocol rule). The provider's gain from voiding is at most the player's expected win on that hand — for a bet B, the EV difference between "hand plays out" and "hand voided" is bounded by ~B (and on average is ~house-edge × B, i.e. cents). So:

• Max extractable value per censorship ≈ B (worst case: player had a made blackjack, ~1.5B).
• Required deterrent: slash ≥ k×maxBet with automatic compensation to the player of, say, maxBet×2. If maxBet = $1,000 and bond = $250k, cheating once costs 250,000 to save ≤1,500 — a >150:1 deterrence ratio, plus permanent ejection. Economically airtight provided (a) reveal-failure is objectively attributable on-chain (it is: commitment exists, deadline passed, no reveal tx), and (b) bond ≫ maxBet always enforced by capping table limits to bond/k.
• Residual honest-failure risk (server crash) is handled the same way: player compensated from bond, provider loses a small liveness penalty rather than full slash for first offenses — standard liveness-vs-safety fault distinction.

4.2 Who sees what — foundation-blind design is straightforward

• Each provider generates its own hash chain locally; only the head (commitment) goes on-chain. The foundation never holds any secret [this mirrors Pyth's design where the provider holds the chain — VERIFIED, protocol-design doc above].
• The only party who "knows the future" is the specific provider, and only for requests routed to them. Mitigations: player chooses provider, or round-robin/random assignment; multiple independent providers means no single insider (including anyone at the foundation) has global foresight.
• Foundation revenue = protocol fee per request, independent of game outcomes ⇒ no incentive alignment problem. This is a real, communicable trust advantage over Stake-style casinos where the seed-holder IS the counterparty.

4.3 Precedents

• Pyth Entropy: exactly this architecture minus permissionless staking — providers are allowlisted, trust is reputational; Pyth docs explicitly acknowledge the censorship/front-running/leak trust assumptions [VERIFIED]. RAIN's proposal = Entropy + economic enforcement. Reasonable and novel-ish but incremental.
• drand/League of Entropy: liveness via t-of-n threshold — no slashing needed because no single node can censor or predict [VERIFIED architecture claims — drand.love].
• Randcast/ARPA: BLS-TSS node network with staking; nodes stake ARPA and can be penalized for non-participation [VERIFIED threshold architecture — docs.arpanetwork.io/randcast; staking/slashing parameters UNVERIFIED].

4.4 The threshold variant is the real upgrade

Single-provider commit-reveal (Pyth-style, even with slashing) still means someone knows the outcome before the player acts — slashing makes exploiting it irrational, but the headline "nobody knows your next card, not even us" is false. A t-of-n threshold BLS design (drand/ARPA-style): the random value is the threshold signature over (betId, round), which does not exist until t nodes cooperate — no single insider, foundation included, ever knows it in advance. This converts the trust story from "cheating is unprofitable" to "cheating is cryptographically impossible below t collusion." For a casino brand, that's the difference worth building. Cost: DKG ceremonies, node software, membership churn handling — this is what drand spent years hardening.

4.5 Build cost / recommendation

• Phase 1 (weeks, 1–2 engineers): single/multi-provider commit-reveal contracts + keeper — essentially reimplementing Pyth Entropy; low risk, but you gain little over just using Pyth Entropy and paying cents.
• Phase 2 (months, 3–5 engineers + audit ≥ $100k–$300k): permissionless staking/slashing + auto-compensation. Justified once volume makes external oracle fees material or once "our entropy network" is a marketing asset.
• Phase 3 (6–12+ months): threshold BLS network (or: contribute/partner with drand/ARPA instead of rebuilding).
• Honest verdict: at launch, use an external oracle (Pyth Entropy) with the protocol-level slashing wrapper (RAIN contracts refund/compensate the player if the oracle fails to reveal in time — you can bolt the economics on without running the network). Build the own-network only when scale or narrative demands it.

Q5 — Synthesis: blackjack on Arbitrum, per-action, 1–3s

Reference costs:

• Pyth Entropy on Arbitrum: fee structure = provider fee + protocol fee, native token, per request, reveal free [VERIFIED — https://docs.pyth.network/entropy/fees]. Exact current Arbitrum number not retrievable this session (fee page 404'd via fetch); action item: call getFee(provider) on the Arbitrum Entropy contract. Order of magnitude from ecosystem reports: fractions of a cent to a few cents per request [ESTIMATED].
• Chainlink VRF v2.5 on Arbitrum: cost = gas × (≈200k verification + callback) × (1 + 20–24% premium) [VERIFIED formula — https://docs.chain.link/vrf/v2-5/billing]. At Arbitrum gas ~0.01–0.1 gwei this is roughly $0.05–$0.50 per request [ESTIMATED], plus multi-block latency (worse: seconds to tens of seconds).

Ranking for per-action blackjack (hit/stand/double each need a fresh card):

1. Pyth Entropy (+ RAIN economic wrapper) — 🥇 practical winner. (a) trust-minimization: medium (2-party commit-reveal; provider can censor but wrapper compensates player automatically); (b) cost: ~cents/action (best-in-class among oracles); (c) latency: ~1–4s ✅ fits requirement; (d) effort: low — SDK integration + a compensation/void module.
2. Session-seed commit-reveal channels (FunFair-style), settled on Arbitrum — 🥈 best UX/cost, more engineering. One oracle-grade seed (Entropy or drand) per session, then per-action randomness via instant player↔house commit-reveal in a state channel or signed-message flow, disputes on-chain. (a) trust: medium-high (random if either party honest, house staller slashed); (b) cost: ~zero per action, one oracle call per session; (c) latency: <1s ✅✅; (d) effort: high (channel/dispute logic). This is what competing with Web2 UX actually requires at scale.
3. drand-bound outcomes (bet binds to future beacon round) — 🥉 best trust model available today. (a) trust: highest (League of Entropy threshold — nobody knows in advance); (b) cost: free beacon + verification/relay gas (cents); (c) latency: 3–6s ⚠️ slightly above target, and needs careful ordering rules vs the prediction window; (d) effort: medium-high (BLS verify on-chain or trusted relayer — the latter reintroduces trust; Gelato VRF packages this but at ~5–15s latency).

Chainlink VRF v2.5 ranks below all three for per-action use purely on latency and cost; it remains the right choice for low-frequency high-value draws (jackpots, tournament seeds).

Final recommendation

For RAIN's Arbitrum blackjack, launch on Pyth Entropy for per-action randomness — it is the only production service that actually hits 1–3s at cents-per-request on Arbitrum — and wrap it in RAIN's own contracts implementing the proposed economics: reveal deadline, automatic hand-void + player compensation funded by a protocol-held bond, so the player-facing guarantee ("censorship can only ever refund-and-pay-you, never hurt you") exists from day one without operating any infrastructure. In parallel, design the game so each session could instead consume one seed and derive per-action cards via a FunFair-style two-party commit-reveal channel (near-zero marginal cost, sub-second UX) — that path is what makes unit economics competitive with Web2 casinos whose RNG costs are zero. Defer the own permissionless entropy network to a later phase, and when built, build it as threshold BLS (t-of-n) rather than single-provider commit-reveal with slashing, because only the threshold variant delivers the true headline — that nobody, including any insider or the foundation, can know the next card — while slashing-only merely makes knowing it unprofitable.

Source list (fetched this session)

• Pyth Entropy overview: https://docs.pyth.network/entropy [VERIFIED]
• Pyth Entropy protocol design & trust assumptions: https://docs.pyth.network/entropy/protocol-design [VERIFIED]
• Pyth Entropy fee structure: https://docs.pyth.network/entropy/fees [VERIFIED]
• Chainlink VRF v2.5 billing: https://docs.chain.link/vrf/v2-5/billing [VERIFIED]
• Gelato VRF (drand-based): https://docs.gelato.cloud/vrf/introduction/understanding-vrf.md [VERIFIED]
• drand / League of Entropy: https://drand.love/ [VERIFIED existence/claims; round timing from prior knowledge]
• Supra dVRF overview: https://docs.supra.com/dvrf/overview [VERIFIED]
• Randcast/ARPA (threshold BLS): https://docs.arpanetwork.io/randcast [VERIFIED]
• WINR Protocol: https://docs.winr.games/ [VERIFIED]
• Randomizer.ai (site alive): https://randomizer.ai/ [VERIFIED alive; activity unverified]
• Stake.com provably-fair page: fetch blocked (403) — scheme documented from standard industry sources [PARTIAL]
• API3 QRNG docs: 404 on fetched path — status uncertain [UNVERIFIED]