# 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)

| Solution | Trust model | Latency | Per-request cost | Arbitrum | Production readiness |
|---|---|---|---|---|---|
| **Chainlink VRF v2.5** | 1 oracle key, crypto-verifiable output (can't fake, can withhold) | ~2–60s (block confirmations + fulfillment) | gas (verification ~200k + callback) + 20–24% premium [VERIFIED model — https://docs.chain.link/vrf/v2-5/billing]; on Arbitrum typically ~$0.10–$0.50/request depending on gas [ESTIMATED] | Yes | Battle-tested, gold standard |
| **Pyth Entropy (v2)** | 2-party commit-reveal: random if *either* provider or user honest; provider can censor/withhold after seeing result; provider must keep hash chain secret [VERIFIED — https://docs.pyth.network/entropy/protocol-design] | "within a few blocks" [VERIFIED — https://docs.pyth.network/entropy] ⇒ ~1–4s on Arbitrum | provider fee + protocol fee in native token, per request; reveal free [VERIFIED fee structure — https://docs.pyth.network/entropy/fees]. Typical Arbitrum fee on the order of ~0.00001–0.0001 ETH (≈ cents) [UNVERIFIED exact number — read `getFee()` on the Arbitrum Entropy contract; fee page fetch failed] | Yes | Production, widely used by on-chain games |
| **Gelato VRF** | Built on **drand** beacon (League of Entropy threshold network); Gelato relayer delivers + proof [VERIFIED drand-based — https://docs.gelato.cloud/vrf/introduction/understanding-vrf.md] | tied to drand 3s rounds + relay + block ⇒ ~5–15s | Gelato subscription/1Balance gas model [UNVERIFIED exact pricing] | Yes (EVM-wide) | Production but thinner track record; latency too high for per-action |
| **drand / League of Entropy direct** | t-of-n threshold BLS across ~20 independent orgs — *no single party knows output beforehand*; strongest practical trust model | new round every **3s** (quicknet); but you must bind a bet to a *future* round → effective 3–6s+, plus someone must bring the beacon on-chain (BLS verification gas) | beacon itself is **free**; cost = gas for on-chain BLS verify (~hundreds of k gas) or a relayer | No native feed; DIY | Beacon is highly reliable. Honest analysis for per-action cards: bind bet to round R (future) → outcome = hash(beacon_R, betId). Risks: (a) **prediction window** — if bet tx isn't finalized before round R is published, anyone (incl. player) who sees beacon_R first can bet with known outcome ⇒ need strict "bet accepted only if included ≥1 round before R" logic; sequencer/MEV on Arbitrum matters here (centralized sequencer FCFS mitigates but you trust Offchain Labs); (b) liveness fine; (c) UX 3–6s per action — borderline acceptable for blackjack. tlock (timelock encryption to a future round) [VERIFIED drand supports timelock — drand.love] lets you encrypt the *deck* to round R: elegant for pre-shuffled decks, doesn't help per-action unless one round per action. Verdict: viable and free-ish, but engineering-heavy and latency-marginal. |
| **Supra dVRF** | Threshold BLS among Supra nodes (their claim) [VERIFIED description — https://docs.supra.com/dvrf/overview]; trust = Supra's node set (one company's network, not independent orgs) | few seconds [UNVERIFIED] | subscription model, customer wallet pays callback gas [VERIFIED model, not prices — same URL] | Yes (was JustBet's provider) | Production; used by real casinos; weaker decentralization story than drand |
| **API3 QRNG** | ANU quantum entropy source, delivered by a **single first-party Airnode** — you trust the ANU/API3 airnode operator not to substitute values; no threshold, no crypto proof of non-manipulation beyond signing | 1–2 blocks after request | was **free** (gas only) [UNVERIFIED current status — API3 has been deprecating QRNG; docs page 404'd this session — treat as possibly sunset] | Was on Arbitrum | Questionable ongoing support ⇒ not recommended for new builds |
| **Randcast / ARPA** | **Threshold BLS (t-of-n)** signature over request → verifiably random; no single node knows output beforehand [VERIFIED architecture — https://docs.arpanetwork.io/randcast] | ~1–2 blocks + BLS-TSS task, several seconds | per-request fee + callback gas [UNVERIFIED prices] | ARPA/Randcast has EVM deployments incl. L2s [UNVERIFIED current Arbitrum status] | Production but small adoption; team/network continuity risk |
| **Witnet** | Own oracle chain; witnesses produce randomness | slow (cross-chain attestation, ~minutes) | small fee | Bridge-based | Alive but low adoption; not suitable for per-action |
| **VDF-based (RANDAO+VDF, MinRoot)** | Beautiful theory: unbiasable via forced sequential computation | n/a | n/a | n/a | **Not practical today.** Ethereum's VDF/MinRoot effort was shelved (MinRoot was shown weaker than hoped in 2023 cryptanalysis by EF/CWI); no production VDF randomness service exists. [UNVERIFIED details, well-known status.] |
| **Optimistic reveal + bond slashing** | Provider commits, must reveal in window; failure ⇒ bond slashed, player compensated | 1–3s happy path | ~gas only + provider margin | DIY | This is essentially "Pyth Entropy + economic teeth." No off-the-shelf product; this is the Q4 proposal. |
| **TEE (SGX) randomness** | Hardware root of trust; caveats: SGX has a long history of side-channel breaks (SGAxe, Downfall...), attestation depends on Intel, operator can withhold | fast | cheap | DIY | Fine as *defense-in-depth*, unacceptable as sole trust anchor for a casino claiming trustlessness |
| **Band VRF** | Band oracle chain validators | cross-chain, slow-ish | fee | limited | Low adoption for gaming |
| **ORAO (Solana)** | Multi-node VRF on Solana, ~$0.001–0.002/request, sub-second — reference point for how cheap/fast this can be on a fast chain [UNVERIFIED prices] | <1s | ~$0.002 | No (Solana) | Production on Solana |

**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]