RAINRAINRISK MARKETS · PROTOCOL
v2.8 · RNG PRE-SUBMISSION PACKAGE v1.2
RAIN RNG · PRE-SUBMISSION PACKAGE v1.2 · DOCUMENT

DOCS/LAB-SUBMISSION-REQUIREMENTS — WHAT LABS ASK FOR; §7 CHECKLIST; §8 BUILD ORDER

Source sdk-v2/docs/LAB-SUBMISSION-REQUIREMENTS.md · commit 96368332 · GLI CSR §2.2: Requirements analysis · ← package index · raw on GitHub ↗

LAB SUBMISSION REQUIREMENTS — RAIN RNG (sdk-v2)

What an accredited test lab (GLI, BMM, eCOGRA, iTech Labs, Gaming Associates) actually asks for when you submit a software RNG for regulated online gaming; what the regulators behind them (UKGC, MGA, NJ DGE, Ontario AGCO/iGO, Isle of Man GSC, Curaçao CGA) require; how commit-reveal / blockchain RNGs have been certified so far; and a HAVE / PARTIAL / MISSING checklist against this repository.

Method and honesty notes. Everything marked [STD] is quoted or closely paraphrased from a public standard / regulation / law text that was downloaded and read for this document (URLs in §9). Everything marked [LAB] comes from a lab's own website — i.e. marketing, not a binding standard. Everything marked [REPO] is what was found by reading this repository (README.md, docs/RNG.md, docs/HOUSE-NODE.md, docs/HANDOFF.md, CHANGELOG.md, packages/*). Where a fact could not be verified from a primary source it is marked [UNVERIFIED] or explicitly "not public". Nothing below is invented; where standards are silent, that is stated. Research date: 2026-09-13. Web search engines were unreliable from this environment; most sources were fetched directly or via the Internet Archive (noted where used).

0. Executive summary (read this if nothing else)

  1. There is no "provably fair" certification category. Labs certify an RNG (the code that produces the number, plus every scaling / mapping / shuffling step to the final game outcome) against GLI-19 §3 / GLI-11 §3, UKGC RTS 7, NJ N.J.A.C. 13:69E-1.28G, AGCO Standard 4.26/4.27 etc. The two public precedents for blockchain-style randomness — BMM's GLI-19 certification of Chainlink VRF v2 (2 Sep 2022) and iTech Labs' UKGC-RTS RNG certificates for BC.Game (2019, 2020) and Hash Games (2024) — both certified the generator + scaling under the ordinary RNG standard. Neither public certificate states that the commit-reveal ceremony or the player's ability to verify was itself the object of certification (§4).
  2. The RAIN "RNG" the lab will look at is not one thing but a chain: r_k = keccak256(abi.encode(pRev_k, hRev_k, sessionSeed, channelId, k)) → (uint256(r) % N, or in v2.1 drbg(r, gameId) HMAC_DRBG/ChaCha20 with rejection sampling) → game rules. GLI-19 §3.2.1 requires source-code review of all of it, and §3.2.2 requires statistical testing of the final outcome output, after scaling — so per-game scaling code (dice, roulette, slots reels, craps, crash multiplier, Fisher-Yates decks) is in scope, not just rng-core.
  3. The submission package a lab wants is largely defined by GLI's public "Composite Submission Requirements v2.0" §2.2 [STD]: final source code + compiled binaries (lab recompiles and fingerprints), a data-collection tool with source that emits final outcomes in a computer-parsable format ("GLI may require hundreds of millions of draws"), a raw-output tool (≈96 million bits, binary), an RNG technical description, a source-code walkthrough document ("from the instantiation of the RNG to the generation of final outcome data"), game rules, and software signatures (SHA-256) of every file. iTech says the same in fewer words (source code required; scaling/shuffling code fragments required) [LAB].
  4. Against this repo the RNG core is in decent shape (HAVE: source, KATs, spec doc, threat model, 100 % coverage on rng-core); the evidence and process artifacts are mostly MISSING: no statistical test report with raw outputs, no lab-style collection tools, no runtime DRBG health tests, no build-reproducibility/fingerprint document, no formal change-control / SDLC document, no penetration-test report, no external contract audit, no incident procedure beyond a runbook paragraph. §7 has the full table; §8 has a build order.
  5. Two design points a lab will question, prepare answers now: (a) uint256(r) % N is a modulo reduction; GLI-11 says scaling must be "entirely free of bias" and GLI-19 "unbiased, as verified by source code review" — the bias is < N/2^256 but the words matter, so either document the bound as a formal argument or route all new games through drbg().intBelow (rejection sampling); (b) GLI-19 §3.3.2(c) "State Compromise Extension Attack: the RNG shall periodically modify its state through the use of external entropy" — the house hash chain is fixed at session open; the answer is that the player's reveal is fresh external entropy every round and that a session is bounded (4095 rounds), but that argument must be written down and accepted, not assumed.

1. GLI-19 v3.0 (Interactive Gaming Systems) — RNG requirements, point by point [STD]

Source: GLI-19 Standards for Interactive Gaming Systems v3.0 (©2020, PDF re-hosted June 2024), Chapter 3 "Random Number Generator (RNG) Requirements" pp. 26–30 and §4.5 "Game Outcome Using a Random Number Generator". Quotes are verbatim; RAIN mapping in italics.

1.1 Types (§3.1.1)

"a) Software-based RNGs do not use hardware devices and derive their randomness principally and primarily from a computer-based or software-driven algorithm… b) Hardware-based RNGs… c) Mechanical RNGs…"

RAIN is (a). Hardware-RNG dynamic monitoring (§3.3.3) does not apply, but the lab will still ask what the OS entropy source behind crypto.getRandomValues() is.

1.2 Source Code Review (§3.2.1)

"The independent test laboratory shall review the source code pertaining to any and all core randomness algorithms, scaling algorithms, shuffling algorithms, and other algorithms or functions that play a critical role in the final random outcome selected for use by a game. This review shall include comparison to published references, where applicable, and an examination for sources of bias, errors in implementation, malicious code, code with the potential to corrupt behavior, or undisclosed switches or parameters having a possible influence on randomness and fair play."

Scope for RAIN: rng-core/src/{keccak,sha256,rng,drbg}.ts, rng-session house/client state machines, rng-node/src/house.ts (StatelessHouse), every % N / intBelow / shuffle call in @rain/games vendor bundles and the Solidity verifiers, plus randomBytes32(). "Undisclosed switches" → the lab will ask about RAIN_CRASH_AT, seed32Compat() (deprecated), mechanism: "chacha20" | "hmac-drbg" selection, and any env flag that changes outcome derivation.

1.3 Statistical Analysis (§3.2.2)

"The independent test laboratory shall employ statistical tests to assess the outcomes produced by the RNG, after scaling, shuffling, or other mapping (hereafter referred to as 'final outcome output'). … The tests shall be selected to assure conformance to intended distribution of values, statistical independence between draws, and, if applicable, statistical independence between multiple values within a single draw. The applied tests shall be evaluated, collectively, at a 99% confidence level. The amount of data tested shall be such that significant deviations from applicable RNG testing criteria can be detected with high frequency. … Statistical tests may include any one or more of the following: a) Total Distribution or Chi-square test; b) Overlaps test; c) Coupon Collector's test; d) Runs test; e) Interplay Correlation test; f) Serial Correlation test; and g) Duplicates test."

Note "after scaling" and "99% confidence level". The lab picks the tests; you provide the data. GLI-19 does not name Diehard/NIST/TestU01 — those appear on lab websites (§2).

1.4 Distribution (§3.2.3)

"Each possible RNG selection shall be equally likely to be chosen. Where the game design specifies a non-uniform distribution, the final outcome shall conform to the intended distribution. a) All scaling, mapping, and shuffling algorithms used shall be unbiased, as verified by source code review. The discard of RNG values is permissible in this context and may be necessary to eliminate bias. b) The final outcome output shall be tested against intended distribution using appropriate statistical tests (e.g., Total Distribution test)."

→ The modulo question (§0 point 5a). GLI-19 says "unbiased"; GLI-11 §3.2.3(a) says "entirely free of bias". Rejection sampling ("discard of RNG values") is explicitly blessed. drbg().intBelow is rejection-based [REPO]; the canonical outcomeMod is % N [REPO].

1.5 Independence (§3.2.4)

"Knowledge of the numbers chosen in one draw shall not provide information on the numbers that may be chosen in a future draw. … a) As verified by source code review, the RNG shall not discard or modify selections based on previous selections, except where intended by game design (e.g., without-replacement functionality); b) The final outcome output shall be tested for independence between draws and, as applicable, independence within a draw, using appropriate statistical tests (e.g., Serial or Interplay Correlation tests, and Runs test)."

RAIN argument: r_{k+1} requires hRev_{k+1} (pre-image of hRev_k under keccak) and pRev_{k+1} (unknown to house). Write this as a formal one-page argument with the keccak pre-image assumption stated.

1.6 Available Outcomes / period (§3.2.5)

"As verified by source code review, the set of possible outcomes produced by the RNG solution (i.e., the RNG period), taken as a whole, shall be sufficiently large to ensure that all outcomes shall be available on every draw with the appropriate likelihood, independent of previously produced outcomes, except where specified by the game design."

RAIN: output space is 2^256 per round; "period" in the classic PRNG sense does not exist (no cycling state) — document this as "range = 2^256, no periodic state; each round's value is a fresh hash of ≥ 512 secret bits".

1.7 Cryptographic strength (§3.3.1) — mandatory in GLI-19 (optional in GLI-11)

"The RNG used in the determination of game outcomes in a Gaming Platform shall be cryptographically strong. 'Cryptographically strong' means that the RNG is resistant to attack or compromise by an intelligent attacker with modern computational resources, and who may have knowledge of the source code of the RNG."

1.8 Cryptographic RNG attacks (§3.3.2) — the three named attacks

"a) Direct Cryptanalytic Attack: Given a sequence of past values produced by the RNG, it shall be computationally infeasible to predict or estimate future RNG values. This shall be ensured through the appropriate use of a recognized cryptographic algorithm (RNG algorithm, hash, cipher, etc.). … b) Known Input Attack: It shall be infeasible to computationally determine or reasonably estimate the state of the RNG after initial seeding. In particular, the RNG shall not be seeded from a time value alone. The manufacturer shall ensure that games will not have the same initial seed. Seeding methods shall not compromise the cryptographic strength of the RNG; and c) State Compromise Extension Attack: The RNG shall periodically modify its state, through the use of external entropy, limiting the effective duration of any potential exploit by a successful attacker." "NOTE: Because of continuous computational improvements and advances in cryptographic research, compliance to this criterion shall be re-evaluated as required by the regulatory body."

RAIN mapping: (a) keccak-256 / HMAC-SHA-256 / ChaCha20 — recognized algorithms, but the lab compares to "published references": keep the FIPS 202 / FIPS 180-4 / RFC 2104 / RFC 8439 KATs (present [REPO]). (b) Seeds: houseSeed, chainSecret, playerSeed from crypto.getRandomValues() [REPO]; two sessions cannot share a seed unless the OS CSPRNG fails — say so, and say what happens if getRandomValues is absent (throws [REPO]). (c) Weak spot in wording: the house chain is fixed for the session. Argue: every round injects pRev_k (external to the house), sessionSeed mixes both parties' entropy, sessions are ≤ 4095 rounds and then fully re-seeded; a compromise of chainSecret alone cannot bias r_k (needs pRev_k) — this is in docs/RNG.md §3 and HOUSE-NODE §4 [REPO] but needs to be restated in GLI-19 §3.3.2 vocabulary in the RNG description document.

1.9 Game outcome rules (§4.5)

§4.5.1: every RNG and every distinct implementation of the same RNG "shall be separately evaluated". §4.5.2: the game "shall not limit the outcomes available for selection", "shall not modify or discard outcomes selected by the RNG due to adaptive behavior", no near-miss substitution, no adaptive RTP, and "(f) Events of chance shall not be affected by the effective bandwidth, link utilization, bit error rate or other characteristic of the communications channel".

RAIN: outcomes are used in order (k cursor). The client-side abort (RainRngClient.abort() burns k [REPO]) and the house-side selective-abort discussion in HOUSE-NODE §4 will be probed under 4.5.2(b): the lab will want to see that an aborted round is logged and visible and that no party can re-draw the same bet.

1.10 Related GLI-19 system requirements the RNG node inherits

  • §2.3.2 Control Program Self-Verification: "verifying that all critical control program components… are authentic copies of the approved components… at least once every twenty-four hours and on demand… Employ a cryptographic hash algorithm which produces a message digest of at least 128 bits". §2.3.3: independent third-party verification method, evaluated by the lab.
  • Appendix B.8.2 Program Change Control: version control for source and binaries; records of every install/modification (date, reason, component + CAR id, who installed, who authorised); rollback plan; emergency-change policy; segregation of duties; documentation updates.
  • Appendix B.8.3 SDLC: production logically and physically separated from dev/test; documented secure coding method; test methodology that prevents test software reaching production.
  • Appendix B.9 Technical Security Testing: annual third-party vulnerability assessment + penetration test (network + application layer, white-box and black-box), with a report containing scope, tester identity, date, findings, corrective action, operator response.

1.11 GLI-11 v3.0 (Gaming Devices) Chapter 3 — for comparison [STD]

GLI-11 (land-based) has the same §3.2.1–3.2.5 text (with "entirely free of bias" in §3.2.3a) plus items GLI-19 folds into "cryptographic":

  • §3.2.6 Unpredictability: "The state of the RNG must be modified between every game unless a 'cryptographic RNG' is implemented… a) The discard of an unpredictable number of RNG values (i.e., background cycling)… must be determined by a secondary RNG, independent and asynchronous to the primary RNG; and b) The overwriting (re-seeding) or mixing (entropy injection)… The external event or entropy source shall not be able to be predicted or estimated by a player."
  • §3.3.2 Seeding (software RNG): "The initial state, or seed, of a software-based RNG shall be randomly determined by an uncontrolled and unpredictable event. The manufacturer must ensure that games will not synchronize, even when powered-on or booted simultaneously. The set of available seeds shall be sufficiently large to ensure independence of outcomes."
  • §3.6 Cryptographic RNG is optional in GLI-11 ("introduced… as optional requirements. At its discretion, a regulatory body may elect to require…") and, when implemented, its three attack criteria "serve to replace the general RNG requirements for 'unpredictability'" — i.e. a cryptographic RNG is exempt from background-cycling.

Consequence: because RAIN is cryptographic, background cycling is not required under either standard; but "re-seeding / periodic state modification with external entropy" (GLI-19 §3.3.2c) still is.

1.12 What GLI wants in the package — Composite Submission Requirements v2.0 §2.2 [STD]

"The RNG analysis contains three primary items: source code review, statistical data analysis, and software verification. … The conclusion will only be applicable to the RNG that is identified through software verification. If this identification changes, then the conclusion will no longer be applicable unless the reasons for the changes are examined by GLI."

Required items (verbatim headings, condensed text):

  • RNG Source Code — "Source code shall be final and no longer in test or development. Source code shall be delivered in full along with the compiled binaries. Source code will be compiled by GLI and digital signatures will be taken during compile to ensure that the product being tested is the final release version."
  • RNG Final Outcome Collection Tool — "A data collection tool along with source code shall be available to allow GLI to collect data in a manner similar to the manner in which game data is produced in the final release version… This tool must utilize the same RNG and associated methods that are used to generate live game outcomes. The tool shall allow the user to specify, at a minimum… number of draws/games. The collection tool shall output data in a computer-parsable format. NOTE: GLI's data collection requirements are large. Please expect that GLI may require hundreds of millions of draws, depending on game format… Depending on the implementation, data may be collected in hours, days, weeks, or months."
  • Raw Output Collection Tool — "output from the RNG prior to scaling, shuffling, etc. … capable of generating approximately 96 million bits of data written in binary format. Alternatively… raw data (un-scaled) in ASCII format."
  • RNG Description and Documentation — "A technical description of the RNG shall be submitted… RNG design and construction, as well as details related to methods that manipulate the RNG output (i.e., algorithms related to scaling, shuffling, selection, etc.)."
  • Game Description and Documentation — game rules, help screens, pay tables.
  • Technical Source Code Description and Documentation — "sufficient documentation of the files and methods used so that one can follow the source code logic from the instantiation of the RNG to the generation of final outcome data."
  • Software verification — "GLI will record the key files and their respective signatures (SHA1, MD5, or SHA256) in the report… GLI will then compile the files independently. A digital signature is taken of the files compiled by the manufacturer and the ones compiled by GLI. If the signatures match, then it is assured that the supplied code was used to build the supplied compiled files. Alternatively, GLI can conduct a witnessed compile."
  • General software rules (§1.3, §1.5): every module carries name, description, edit history; code "commented in an informative and useful manner"; "correct, complete, and able to be compiled"; a list of official software signatures for everything provided.
  • Worked example in the text: for a 5-from-49 draw GLI asked for "a text file containing 51,000,000 records of 5 repeatable integers per record".
  • When an RNG must be (re)submitted (§2.2 "RNG Submission"): code or implementation changed; new hardware platform; "generating numbers that are outside scope of what was previously tested" (→ every new N / new game scaling extends scope); never certified before.
  • For platform submissions (§2.9, §2.11): functional description of all components, list of all games, Information Security Policy, production component inventory, network architecture diagram (topology, IPs, firewalls, VLANs), external systems list, encryption/key-management description (algorithm, key sizes, generation, storage, exchange, rotation, revocation), incident management, disaster recovery.

2. What labs actually run, and pass criteria

2.1 What the labs say publicly [LAB]

  • GLI (iGaming RNG page): "Source code review; Assessment for the RNG period; Determination of the RNG range; Investigation of the seeding/re-seeding; Inspection of the background cycling/activity; DIEHARD Battery of Tests; Outcome Distribution Tests." "An RNG Test Suite is applied for randomness testing" (custom in-house software).
  • iTech Labs (archived RNG page, 2019–2024): three stages — (1) source code examination & compilation: identify algorithm and research known weaknesses, verify internal state, unpredictability/non-repeatability, "seeding, background cycling and minimal re-seeding", scaling and shuffling usage, compile the code; (2) "Raw numbers generated by the RNG algorithm are subjected to 'diehard' tests"; (3) "Generating sample scaled output and applying 'Chi-square' tests e.g. if the RNG is used to shuffle a deck of cards, then we would apply Chi-square tests to a wide range of shuffled decks." Deliverables: certification report, "Test results for Diehard and Chi-square tests", seal, hot-linked certificate. Submission: "For a Pseudo RNG, the source code is required… In order to test the scaling/shuffling, code fragments that call the RNG or shuffle code are required (examples: scaling code for slot games, shuffling code for card games)." Recommended algorithms: Fortuna, SHA-1/SHA-2 PRNGs (Java SecureRandom), AES-CTR/OFB, ISAAC, Mersenne Twister ("not cryptographically secure, however… most widely used in gaming"). "RNG testing usually takes 1-3 weeks… we offer a firm, set price… Payment is required at the start… Our fixed price includes: consultations, unlimited retests after bug fixes, test results, detailed certification reports, hot linked certificates, and logos." (Price itself is not published.)
  • Gaming Associates: same five-item list as iTech ("Statistical randomness; Internal state of the RNG; Seeding, re-seeding and cycling; Unpredictability and non-repeatability; Usage of random numbers including scaling and shuffling") plus "Source Code Analysis; Period Assessment; Determining RNG Range; Examining Background Cycling/Activity; Comprehensive Battery of Tests; Outcome Distribution Analysis".
  • eCOGRA: source code review "based on well-established algorithms"; "extensive statistical analysis on the output of the RNG over many iterations"; seed generation evaluation; "algorithm's resistance to common attacks"; hardware/software environment; certification report; periodic re-testing.
  • BMM: RNG page is generic ("math & RNG testing"); the Chainlink VRF release (§4) is the only detail found.

2.2 Public statistical suites and their pass criteria (for your own pre-testing) [STD]

Labs do not publish their internal acceptance thresholds; these are the public suites they name or that engineers use to pre-qualify. Reproduce these yourself and ship the raw outputs (§7 item 4).

Suite What it is Sample size Pass criterion (as published)
NIST SP 800-22 Rev.1a (STS, April 2010; NIST announced in 2022 it will be revised) 15 tests on bit streams (frequency, block frequency, runs, longest run, rank, DFT, non-overlapping/overlapping templates, Maurer's universal, linear complexity, serial, approximate entropy, cumulative sums, random excursions ×2) Recommended ≥ 10^6 bits per sequence for the heavier tests; NIST's own runs use m sequences (typically 1000) §4.2: per test, α = 0.01; proportion of sequences passing must lie within p̂ ± 3·√(p̂(1−p̂)/m) (p̂ = 1−α; for m = 1000 → ≥ 0.9805… i.e. ≥ 980/1000), and p-values must be uniform: χ² over 10 bins, P-value_T ≥ 0.0001. SP 800-22 itself says "no set of statistical tests can absolutely certify a generator".
Diehard (Marsaglia, 1995) / Dieharder (R. G. Brown, Duke) Original 15 Diehard tests + STS + RGB tests, on 32-bit words Diehard: ~10–12 MB binary file; Dieharder: streams, hundreds of MB to GB for full -a Dieharder reports PASSED / WEAK / FAILED per test on the KS p-value of p-values; author's page: it is designed "to push a weak generator to unambiguous failure, not leave it in the 'limbo' of 1% or 5% maybe-failure". Occasional WEAK is expected on a good generator; FAILED reproducibly across seeds is a fail.
TestU01 (L'Ecuyer & Simard, ACM TOMS 2007) SmallCrush (10 tests / 15 statistics), Crush (96 / 144), BigCrush (106 / 160) on 32-bit outputs or doubles in [0,1) SmallCrush ≈ minutes; Crush ≈ 2^35 numbers; BigCrush ≈ 2^38 numbers (≈ 1 TB of 32-bit output), hours of CPU Summary flags p-values outside [10^-3, 1−10^-3] as suspicious and outside [10^-10, 1−10^-10] as clear failures; a "pass" is a summary with no flagged statistics (rare isolated suspicious values are re-run with a different seed).
Chi-square / Total Distribution on the scaled outcome (what GLI-19 §3.2.3b and iTech's stage 3 mean) Frequency of each of N outcomes vs expected n/N Rule of thumb: expected count per cell ≥ 5 → for dice N = 100 you want millions; for a 52-card deck position test 52×52 cells; GLI's example: 51 M records χ² with N−1 d.f. at the 99 % level (GLI-19 §3.2.2 "collectively, at a 99% confidence level"). Run many independent blocks and check the distribution of χ² p-values (KS), not a single p-value.
Serial correlation / Runs / Interplay Autocorrelation at lags 1..L; runs above/below median; correlation between fields within one multi-value draw (e.g. 5 reels) Same data as above Normal-approximation z-tests at 99 %; for interplay, a χ² on the joint 2-D table.
Shuffle tests (card games) Fisher-Yates output: each card equally likely in each position; pairwise adjacency independence iTech: "large enough samples to give the calculations sufficient statistical power" χ² on the 52×52 (or 312×312 for six decks) position table; p ≥ 0.01.

Practical reading of "how many samples": GLI's own text says hundreds of millions of draws for scaled data and ~96 Mbit raw; TestU01 BigCrush needs ~2^38 32-bit values (≈ 275 billion) — do not attempt BigCrush from a live ceremony; use the collection tool with fixed seeds (§7 item 3). Because RAIN is a hash-based construction, all these suites will pass if the implementation is correct — the point of the report is evidence, not discovery.

3. Regulator wording — exact quotes [STD]

3.1 UK Gambling Commission — RTS 7 (current text, "Last updated 7 May 2024", fetched from gamblingcommission.gov.uk/standards/…/rts-7-generation-of-random-outcomes)

RTS aim 7 "To ensure that games and other virtual events operate fairly." RTS requirement 7A "Random number generation and game results must be 'acceptably random'. Acceptably random here means that it is possible to demonstrate to a high degree of confidence that the output of the RNG, game, lottery and virtual event outcomes are random through, for example, statistical analysis using generally accepted tests and methods of analysis. Adaptive behaviour (that is, a compensated game) is not permitted. Where lotteries use the outcome of other events external to the lottery, to determine the result of the lottery the outcome must be unpredictable and externally verifiable." RTS implementation guidance 7A "RNGs should be capable of demonstrating the following qualities: the output from the RNG is uniformly distributed over the entire output range and game, lottery, or virtual event outcomes are distributed in accordance with the expected or theoretical probabilities; the output of the RNG, game, lottery, and virtual event outcomes should be unpredictable, for example, for a software RNG it should be computationally infeasible to predict what the next number will be without complete knowledge of the algorithm and seed value; random number generation does not reproduce the same output stream (cycle), and that two instances of a RNG do not produce the same stream as each other (synchronise); any forms of seeding and re-seeding used do not introduce predictability; any scaling applied to the output of the random number generator maintains the qualities as detailed." RTS requirement 7B "As far as is reasonably possible, games and events must be implemented fairly and in accordance with the rules and prevailing payouts, where applicable, as they are described to the customer." RTS implementation guidance 7B "Games should implement the rules as described in the rules available to the customer before play commenced. The mapping of the random inputs to game outcomes should be in accordance with prevailing probabilities, pay tables, etc. When random numbers, scaled or otherwise, are received, for example, following a game requesting a sequence of random numbers, they are to be used in the order in which they are received and they may not be discarded due to adaptive behaviour. Numbers or sequences of numbers are not to be discarded, unless they fall outside the expected range of numbers required by the virtual event – such an occurrence should result in an error being logged and investigated." RTS 7C prohibits near-miss substitution and simulations that do not match the real device's probabilities; 7D rules/payouts/probabilities may not change while a game is available, changes must be notified; 7E result display.

Other UKGC facts: Licence condition 2.3.1 — "Licensees must comply with the Commission's technical standards and with requirements set by the Commission relating to the timing and procedures for testing." The RTS security section (4.1–4.3) applies ISO/IEC 27001:2022 Annex A controls to "electronic systems that generate, transmit, or process random numbers used to determine the outcome of games or virtual events" and lists the controls (5.1, 5.15–5.28, 8.2, 8.5, 8.13, 8.15, 8.17, 8.24 Use of cryptography, 8.25 Secure development life cycle, 8.29 Security testing, 8.31 Separation of environments, 8.32 Change management, 8.33 Test information…). The Testing Strategy document (which defines "major/minor updates", that "products require external testing prior to release", and an "independent annual audit requirement") is referenced by iTech certificates ("Testing Strategy for Compliance with Remote Gambling and Software Technical Standards, February 2021"); the current PDF could not be fetched from this environment — obtain it from the Commission before submission. [UNVERIFIED current text]

3.2 Malta Gaming Authority — Gaming Authorisations and Compliance Directive (Directive 3 of 2018, V2 October 2021)

"'essential components' means (a) Components hosting Random Number Generators; (b) Components hosting jackpots; (c) Components hosting the games; (d) Gaming database; (e) Player database…" Art. 18(1): "Licensees shall ensure that essential components are subject to additional safeguards in order to minimise to the greatest possible extent the risk to such components. In conducting their risk assessment licensees shall take into account the risk factors listed in the First Schedule." 18(2): the risk assessment is filed with the system documentation and "continuously updated". Art. 19(1)(a)(ii) / 21(b): where a game "uses a random number generator and, or is based on a game engine which has not already been approved by the Authority, the prior written approval of the Authority shall be required". Art. 23(1): such an application "shall be made in such manner and be accompanied by such documents and certification as the Authority may require." 23(2): "the Authority reserves the right to require the licensee to undergo an audit in case of the addition of a new gaming vertical, or certification in case of a new random number generator and, or game engine." Art. 24: "Where a licensee wishes to update or change critical elements of a game, including the random number generator… the licensee shall seek prior approval from the Authority… which may include… re-certification of the random number generator and, or game engine should the Authority deem it necessary."

MGA in practice requires the RNG certificate to come from an MGA-approved (ISO/IEC 17025-accredited) test laboratory and the system audit to be performed by an approved Systems Auditor; the MGA's separate "Gaming Devices and Systems" technical document and the approved-laboratories list could not be fetched from this environment (site returned 404 for the legacy paths) — request them from the MGA or the chosen lab. [UNVERIFIED current text]

3.3 New Jersey DGE — N.J.A.C. 13:69E-1.28G (RNG standard; the task's "13:69D" reference is the controlled-computer-systems chapter, which 13:69O-1.5 incorporates for server-based/Internet gaming)

"(a) Random number generator (RNG) means a physical device or a mathematical algorithm that generates outcomes that cannot be predicted. (b) RNGs which utilize a mathematical algorithm to generate outcomes shall be: 1. Large enough to encompass all possible outcomes; 2. Available at the initiation of each and every game; 3. Statistically independent, conform to random distribution and pass variously recognized statistical tests such as the 'Chi-square' test, 'Mono-bit' test, and the 'Runs' test; 4. Designed to continually cycle in the background between games; 5. Designed to employ a random seed that is determined by an uncontrolled event to assure that the RNG does not begin from the same value every time; and 6. Designed in a manner where, if a number is required which is outside the provided RNG range, the RNG shall be rescaled using a method that ensures the occurrences of numbers within the shorter range are equally probable. (c) After the random selection of an outcome, gaming devices which utilize an RNG shall: 1. Only display the appropriate outcome as specifically determined by the RNG; 2. Not permit a secondary selection for the purpose of displaying the outcome; and 3. Not be misleading in any manner."

Note (b)4 "continually cycle in the background" is written for classic PRNGs; a cryptographic hash-based RNG has no background state to cycle. Labs certifying for NJ treat this on a case-by-case basis — obtain the DGE's position in writing (the Division approves products by letter, 13:69E-1.28(e)). [REGULATOR QUESTION] Related NJ text: 13:69E-1.28(c) "Electronic gaming equipment shall not be used… unless it is identical in all aspects to the prototype which was reviewed and approved". 13:69O-1.5: server-based gaming systems must "Comply with N.J.A.C. 13:69D-2", permit software validation "using a Gaming Authentication Tool (GAT) or other method approved by the Division", and "perform an authentication process on all control programs on demand and at least once every 24 hours"; a failed authentication → "immediately cease operation of the software and immediately notify the Division". 13:69O-1.8 mandatory gaming system logging.

3.4 Ontario — AGCO Registrar's Standards for Internet Gaming (amended May 2026)

4.26 "A mechanism shall be in place to randomly select game elements used to determine game outcomes… Requirements – At a minimum: Initial values and conditions shall be selected and used to seed the random selection process in a way that ensures the randomness of the resulting game outcomes and avoids any correlation of selected game elements with elements selected by any other instances of the mechanism. The selected game elements and their associated game outcomes shall not be influenced, affected or controlled by the amount wagered, or by the style or method of play… The mechanism… shall be impervious to outside influences (such as electro-magnetic interference, devices within or external to the gaming system; the characteristics of the communication channel between the system and the end player device, the player or the Operator)… shall not be altered, discarded or otherwise manipulated through a secondary decision by the game program and shall not be impacted by load on the gaming system. Any failure by the mechanism to randomly select game elements, including an interruption in the selection process, must be identified and responded to quickly and appropriately." 4.27 "Mechanisms used to select game elements and their associated game outcome must be capable of being monitored and inspected to ensure the integrity of the mechanisms and its component devices and the randomness of the generated outcomes." 4.25 "Bets shall be committed before the determination of game outcomes. Any wager received after the determination of game outcomes associated with the wager shall be voided and returned to the player."

AGCO "Registered Independent Testing Labs" (page fetched): BMM North America, Eclipse Compliance Testing, eCOGRA, Gaming Associates Europe, Gaming Laboratories International, Global Lab Ltd., Lean Lab Company Limited o/a Riskcherry, Quinel Ltd — "registered to test and certify key components of igaming systems such as games and random number generators."

RAIN note: 4.26 "impervious to… the player or the Operator" is the sentence to answer with the two-party argument — the player does contribute entropy, by design; you must show the player cannot influence the distribution, only contribute unpredictability. 4.25 is exactly RAIN's decision-before-reveal property.

3.5 Curaçao — LOK (Landsverordening op de kansspelen, in force 24 Dec 2024)

The CGA's public documents do not contain an RNG standard. The regime works through recognised test houses: the portal publishes a "Gaming Test House Application Form V250525" whose accreditation section says "Only accreditations issued by a national accreditation body for testing laboratories will be accepted… the Authority currently recognizes accreditations from the following jurisdictions: New Jersey (USA), Pennsylvania (USA), Ontario (Canada), British Columbia (Canada), United Kingdom, Malta", and asks each test house which facilities it offers ("Random Number Generator; Games (slots and virtual table games); Internet Gaming Systems…") and "Does the testing house publish its own technical standards / List all relevant technical standards used for testing online gaming". Supplier licences: "only suppliers of gaming-related critical services and goods established in Curaçao are required to obtain a supplier license… two years after the LOK entered into force" (portal FAQ). Practical meaning: a Curaçao operator will accept a GLI-19 or UKGC-RTS certificate from any of the recognised labs; there is no Curaçao-specific RNG text to comply with. iTech's 2024 certificates for "Hash Games CW B.V." (a Curaçao entity) were issued against the UK RTS, confirming the pattern.

3.6 Isle of Man GSC

Two regimes (Software Supplier Licence sheet, v10/25): "In the basic regime, no licence is required before supplying software to an Isle of Man operator. However, before that Isle of Man operator can deploy the software, it must supply test house certification to the GSC." Licensed regime: software supplier holds an OGRA licence, "provides the test house certification directly to the GSC and is responsible for the software"; covers "RNG/casino games, back-office platforms, live-dealer casino, betting platforms". Fees (public): Software Supplier Licence application £5,250, annual £36,750; Token/Blockchain-Based Software Supplier Licence application £5,250, annual £52,500 — "Products must be tested and approved by GSC-approved test houses". The GSC's technical RNG guidance document itself was not found on the new site (the old gamblingsupervision.im domain did not resolve). [PARTIAL]

4. How commit-reveal / provably-fair / blockchain RNGs have been certified so far — precisely

4.1 Chainlink VRF v2 — BMM Testlabs, GLI-19, announced 2 September 2022 (bmm.com press release; fetched). Exact wording: "Chainlink VRF, the blockchain standard for verifiable randomness in gaming and NFTs, has received the GLI-19 compliance certification through BMM Testlabs… VRF V2 launched in February 2022…" BMM's Maria Romero: "As one of the first certifications in the blockchain industry, BMM is paving the way for companies developing blockchain-based gaming solutions to become certified." What was certified: the VRF as an RNG under GLI-19 — i.e. the generator (elliptic-curve VRF proof + on-chain verification, whose output is a 256-bit hash) evaluated for source-code review, statistical output and unpredictability. The release does not say the request/fulfil economics, the oracle liveness model, or the consuming games' scaling were certified. No certificate PDF or scope statement is public.

4.2 BC.Game — iTech Labs, UK RTS, certificates 16 Aug 2019 and 12 Oct 2020 (ITL2002455, retrieved via Internet Archive). Verbatim scope: "The RNG uses a well-known algorithm to generate random numbers. The numbers generated by this RNG have passed Marsaglia's 'diehard' tests for statistical randomness. iTech Labs has evaluated shuffling of twelve decks without joker and single deck without joker for card games. iTech Labs has also conducted scaling tests for Crash, HashDice, Roulette, Plinko, Wheel, Dice, HiLo, Slots (…), Limbo and Keno games… iTech Labs has found that the card and number sequences are unpredictable, non-repeatable and uniformly distributed. The certified code for the RNG has been fingerprinted. * The RNG was tested according to the UK Remote Gambling and Software Technical Standards June 2017 and the Testing Strategy… November 2018. Disclaimer: …iTech Labs has conducted a level of testing appropriate for a component test of this type." BC.Game is a server-seed/client-seed/nonce "provably fair" casino: what iTech certified was the server-side generator and each game's scaling/shuffle code, with the code fingerprinted. The certificate does not mention the client seed, the commitment hash, or player-side verification.

4.3 Hash Games CW B.V. (Curaçao) — iTech Labs, UK RTS Feb 2021, certificates 20 Feb 2024 and 8 Apr 2024: identical template ("well-known algorithm… Marsaglia's diehard… shuffling for Single Deck and Six Decks… certified code… fingerprinted").

4.4 What this means for RAIN (inference, clearly labelled as such):

  • Labs have certified (i) an on-chain VRF as "the RNG" (BMM/GLI-19) and (ii) server-seed provably-fair systems as "the RNG + scaling" (iTech/UK RTS). Nobody has publicly certified a two-party commit-reveal where the player is an entropy source and the contract enforces the commitment — the closest analogue is VRF (unpredictable, verifiable, third-party) — so expect the lab to treat RAIN as a novel construction requiring an engineering-level review rather than a template job. iTech's page explicitly lists "Identification of RNG algorithm and researching known weaknesses" as stage 1; for RAIN, that is keccak-256 (FIPS 202) + the ceremony.
  • The lab will define "the RNG under test" as: entropy sources (getRandomValues() for houseSeed/chainSecret; the player's wallet-derived material keccak(personal_sign(...)) for playerSeed/chain) → mixing (sessionSeed, hash chains) → generator (outcome() / gameSeed() / drbg()) → scaling (% N or intBelow, shuffle) → game rules. Everything from outcome() onward is deterministic and can be fed to the collection tool with fixed inputs; the entropy stage is reviewed by code reading (GLI-19 §3.3.2b) — this is exactly how OS-seeded software PRNGs are handled today.
  • The ceremony's fairness properties (house cannot bias, player cannot bias, verifiable by anyone) are not a certification category. They are strong supporting evidence for §3.3.2 (a)–(c) and RTS 7A "unpredictable", and they are exactly what a regulator's systems audit (MGA Art. 18 risk assessment; AGCO 4.27 "capable of being monitored and inspected") will value — but write them up in the standards' vocabulary. Do not expect the certificate to say "provably fair".
  • Player-provided entropy will be the main discussion point. GLI-19 §4.5.2(e) "associated equipment… shall not influence or modify the behaviors of the game's RNG" and AGCO 4.26 "impervious to… the player" were written against a player steering outcomes. RAIN's defence is: the player commits playerChainRoot before the house seed is revealed and reveals pRev_k before seeing hRev_k; any choice of pRev_k yields a uniformly distributed r_k because hRev_k is unknown to the player and fixed — i.e. the player can add entropy but cannot bias. Have this as a one-page proof with the random-oracle assumption stated, and have the statistical report include a run where the player inputs are adversarially chosen (e.g. all-zero, repeated, grinding-style) to show the distribution of r_k is unchanged.

5. SP 800-90A DRBG requirements and whether labs accept HMAC-DRBG seeded from a protocol-derived 256-bit value

5.1 What SP 800-90A Rev.1 (June 2015) requires [STD]

  • Mechanisms: Hash_DRBG, HMAC_DRBG (§10.1.2), CTR_DRBG. Table 2 (hash-based, SHA-256): security strength up to 256; "Required minimum entropy for instantiate and reseed = security_strength"; min entropy input length = security_strength; max entropy input, personalization string and additional_input length 2^35 bits; max_number_of_bits_per_request 2^19; reseed_interval 2^48 requests.
  • Randomness source (§8.6.5): "A DRBG mechanism requires an approved randomness source during instantiation and reseeding… An approved randomness source is an entropy source that conforms to [SP 800-90B], or an RBG that conforms to [SP 800-90C] − either a DRBG or an NRBG."
  • Seed privacy (§8.6.6): "The security of the DRBG depends on the secrecy of the entropy input… the entropy input shall be treated as a critical security parameter."
  • Nonce (§8.6.7): "A nonce may be required in the construction of a seed during instantiation… shall be either: a. A value with at least (security_strength/2) bits of entropy, or b. A value that is expected to repeat no more often than a (security_strength/2)-bit random string." (For HMAC_DRBG, when the entropy input already carries ≥ security_strength bits and the derivation-function path is used, the nonce may be empty per §8.6.7's alternative construction — but state your choice.)
  • Health testing (§11.3): "A DRBG implementation shall perform self-tests to obtain assurance that the DRBG continues to operate as designed… Known-answer tests shall be conducted on each DRBG function within a boundary… prior to the first use of that DRBG (e.g., during the power-on self-testing sequence)… All data output from the DRBG mechanism boundary shall be inhibited while these tests are performed… Bits generated during health testing shall not be output as pseudorandom bits." Separate KATs for Instantiate (§11.3.2), Generate (§11.3.3), Reseed (§11.3.4); on failure "enter an error state and output an error indicator".
  • SP 800-90B (Jan 2018) governs entropy sources (min-entropy estimation, health tests: Repetition Count and Adaptive Proportion, restart tests); SP 800-90C (Sept 2025, final) defines RBG1/RBG2/RBG3/RBGC constructions combining 90A + 90B.

5.2 How RAIN v2.1 uses HMAC_DRBG [REPO]

packages/rng-core/src/drbg.ts: key = HMAC-SHA-256(r, "RAIN-RNG-v2.1|" + gameId); draw(i) = HMAC_DRBG.Instantiate(entropy_input = key, nonce = "", pers = "").Generate(32, additional_input = uint64be(i)) on a fresh instantiation per draw (stateless, index-addressable); reseed never called; reseed_interval never approached; n ≤ 65536 bytes enforced (= 2^19 bits); NIST CAVP HMAC_DRBG SHA-256 no-reseed vectors (32 cases) pass in tests. Alternative mechanism ChaCha20 block function (RFC 8439 §2.3) with counter = i.

5.3 Will a lab accept it? (assessment — clearly an inference from the standards' text, not a lab's statement)

  • As an "RNG" under GLI-19 §3.3 / RTS 7A: yes, in principle. Both standards demand a "recognized cryptographic algorithm"; HMAC-SHA-256 and ChaCha20 are recognized; the construction is a keyed PRF indexed by counter, which is textbook. The "seed" (r) has 256 bits derived from ≥ 512 secret bits; unpredictability rests on keccak/HMAC pre-image resistance.
  • As an SP 800-90A-conformant DRBG: only partially, and you should not claim conformance. (i) The entropy input is r, a protocol-derived value, not an SP 800-90B entropy source or 90C RBG — §8.6.5 requires an "approved randomness source". r is not "approved" in the NIST sense, even though it is unpredictable. (ii) Fresh Instantiate per draw with the index as additional_input is a legitimate use of the mechanism but is not the intended operational pattern; a lab's cryptographer will accept it as a PRF construction, not as "a DRBG instance". (iii) No runtime health tests (§11.3 KAT before first use) exist — the KATs live in the test suite, not in the node's startup path. Fix: run the CAVP KATs on startNode() and refuse to serve on mismatch (also satisfies GLI-19 §2.3.2-style self-verification for the RNG component).
  • Recommended positioning in the RNG description document: "The RAIN draw layer is a deterministic PRF built from the SP 800-90A HMAC_DRBG SHA-256 mechanism (CAVP-vector-verified) keyed by a 256-bit round value r produced by the two-party commit-reveal ceremony. It is not an SP 800-90C RBG: r is not an SP 800-90B entropy source but a cryptographic combination of two parties' CSPRNG outputs (crypto.getRandomValues(), OS-provided) and the on-chain channel identifier." Then answer §3.3.2 (a)–(c) explicitly. Labs routinely certify java.security.SecureRandom / OpenSSL / /dev/urandom-seeded generators without a 90B certificate; iTech even lists Mersenne Twister as acceptable. The OS CSPRNG as the ultimate entropy source is the industry norm.
  • If you want a NIST-flavoured claim you can defend: the seeds are produced by the platform's CSPRNG (Node: OpenSSL RAND_bytes; browser: WebCrypto) — cite the platform's FIPS/CAVP status if the deployment uses a FIPS-validated OpenSSL. That is a deployment property, not a code property; put it in the hosting document.

6. Security audit scope for the Solidity + node — what auditors expect as inputs

Sources: Trail of Bits / Crytic "Building Secure Contracts" (secure development workflow + blockchain maturity evaluation, github.com/crytic/building-secure-contracts), OpenZeppelin "Follow this quality checklist before an audit", Nascent "Audit Readiness Checklist" (github.com/nascentxyz/simple-security-toolkit). Cyfrin's checklist repository returned 404 at the checked path; Cyfrin's published guidance is consistent with the above but was not re-verified here. [LAB]-equivalent: auditor guidance, not a standard.

Inputs every serious auditor asks for (union of the three lists):

  1. Frozen commit hash of the scope; list of in-scope files with SLoC; out-of-scope list; external dependencies and their versions (OpenZeppelin etc.).
  2. Specification / protocol documentation that the code is checked against ("in an audit, we check that the implemented code works as intended by the specification" — OZ). For RAIN: docs/RNG.md, docs/CHANNEL-GAMES.md, the ChannelManagerAA.sol header spec, MATH.md.
  3. Threat model and explicit security assumptions ("Write down your extraneous security assumptions… 'We assume that the owner is not malicious…'" — Nascent). RAIN has a strong table in docs/RNG.md §3 and HOUSE-NODE §4 [REPO]; auditors want it as a stand-alone file with roles, assets, trust boundaries, and out-of-scope threats (e.g. malicious client, L2 sequencer censorship, chain reorgs on Arbitrum One, admin-key compromise).
  4. Invariants / security properties, ideally executable: Crytic "Define security properties in Solidity for use with Echidna… Focus on your state machine, access controls, arithmetic operations, external interactions"; Nascent: "Incorporate fuzz tests… Foundry Invariants… stateful fuzzing". RAIN's central invariant playerBal + houseBal + feeAccrued + grossAtRisk == deposit + allocation [REPO] and the chain-order invariants should be written as Foundry/Echidna properties.
  5. Test suite + coverage report, all passing, with happy-path and revert tests; static analysis (Slither) run and triaged, "Contracts compile without any errors or warnings".
  6. Deployment and upgrade scripts in scope ("Deployments and upgrades are as important as runtime code" — Nascent) plus the actual deployed addresses and verification status (Sourcify exact_match for ChannelManagerAA; the AUDIT.md notes some verifiers are not source-verified [REPO]).
  7. Known issues / prior review list — rain-risk-markets/AUDIT.md (internal, 2026-08-21: M1 bonus-claim signature, M2 operator liveness, L1–L3, I1–I3) [REPO]; the admin-key posture (setVerifier/setOperator/setPaused, CryptoRace owner EOA).
  8. NatSpec on all public/external functions; documented unchecked blocks and assembly; FREI-PI/CEI ordering.
  9. For the off-chain node (not covered by Solidity checklists): architecture diagram, data-flow, persistence guarantees (persist-before-reveal proof, test/crash.test.mjs), key management (operator ed25519 key, KMS hook interface-only, anchoring key), API surface (/v2/*, /verify, WS), rate-limiting/DoS posture, dependency SBOM, and the HA claims that "have NOT been executed here" (ha-test.sh, PgStore SQL) [REPO] — auditors will refuse to sign off on untested HA claims; run them first.
  10. Maturity self-assessment (Crytic ratings Missing/Weak/Moderate/Satisfactory/Strong across arithmetic, auditing, access control, complexity, decentralization, documentation, transaction ordering, low-level manipulation, testing). Doing this yourself before engagement shortens and cheapens the audit.

Scope to propose to the auditor for the RNG product (not the whole casino): RngAnchor.sol (currently not deployed [REPO]), the ChannelManagerAA seed-ceremony functions (openChannel, submitReveals, demandReveal, forceClose paths that reference reveals), EngineV2RulesVerifier.seedOf, @rain/rng-core, @rain/rng-session, @rain/rng-node. Money-path contracts are a second, larger scope.

7. CHECKLIST — artifacts for submission vs. sdk-v2 today

Legend: HAVE = exists in a form a lab could use with light editing; PARTIAL = exists but incomplete / wrong vocabulary / unexecuted; MISSING = not in the repo. Two statuses are given: before (2.1.0, commit 7f041cc4, 2026-09-13 morning) → after the lab/ package (same day; commit in lab/FINGERPRINTS.json).

# Artifact the lab / regulator expects Source of the requirement Before → After Evidence / remaining gap
1 RNG technical description in GLI-19 §3 vocabulary; §3.3.2 a/b/c explicit GLI CSR §2.2; GLI-19 §3.2.1 PARTIAL → HAVE lab/RNG-DESCRIPTION.md (§1–§11, App. A independence/unpredictability, App. B scaling proofs)
2 Source code, final, complete, compilable, commented, edit history, with binaries GLI CSR §1.3, §1.5, §2.2 PARTIAL → HAVE (vendored engines were found to be readable, not minified; edit history = git log) RngAnchor.sol still undeployed → anchoring path not "final"
3 Build reproducibility / software verification GLI CSR §2.2; GLI-19 §2.3.2–2.3.3 MISSING → HAVE lab/BUILD.md, lab/FINGERPRINTS.json (201 files), npm run lab:verify-build passes twice; no solc here → contract bytecode not fingerprinted
4 Statistical test report with raw outputs (Dieharder / STS / TestU01; scaled χ²/serial/runs per game; adversarial run; logs, seeds) GLI-19 §3.2.2–3.2.4; RTS 7A; iTech stages 2–3 MISSING → HAVE (self-run; Crush/BigCrush and the heaviest Dieharder ntuples not run — documented with runners) lab/REPORT-STATISTICAL.md + lab/results/**: Dieharder full battery on an unbounded stream per mechanism (chacha20 0 FAILED / 5 WEAK on 95 lines, rewinds impossible by construction; hmac partial, 0 FAILED), NIST STS 1000 × 10⁶ bits all 15 tests per mechanism (188/188 lines in CI, both), TestU01 SmallCrush 15/15 per mechanism, scaled outcomes 10⁸ (chacha) / 2 × 10⁷ (hmac) per game + 3 adversarial modes, Fisher–Yates 52 × 52 table; invalid rewound file runs quarantined and listed
5 Final-outcome + raw-output collection tools with source, production path GLI CSR §2.2 MISSING → HAVE lab/tools/collect-outcomes.mjs (checkpointed, adversarial modes), lab/tools/collect-raw.mjs (file / parallel / unbounded stream, bit-reproducible by seed), analyze-outcomes.mjs, suite runners run-dieharder-stream.sh, run-sts.sh, run-testu01-crush-stream.sh, run-outcomes.sh, report generator report-tables.sh
6 Scaling / mapping proof + inventory of every reduction GLI-19 §3.2.3(a); GLI-11 §3.2.3(a) PARTIAL → HAVE lab/SCALING-PROOF.md (stand-alone one page, R1 item 5); RNG-DESCRIPTION.md App. B; lab/SCALING-INVENTORY.md (certified / legacy / not-RNG). Policy fixed: certified = intBelow/shuffle; % N legacy out of scope
7 Seed / key management document GLI-19 §3.3.2(b),(c); GLI CSR §2.11; RTS 8.24 PARTIAL → HAVE lab/process/KEY-MANAGEMENT.md (leak-impact matrix, same-operator caveat)
8 Change control / version identification GLI-19 App. B.8.2; MGA Art. 24 MISSING → PARTIAL lab/process/CHANGE-CONTROL.md; CI in repo (.github/workflows/ci.yml), .github/CODEOWNERS (two maintainer teams — placeholder handles), PR template, docs/GOVERNANCE.md (branch protection: 2 approvals, required checks, signed tags). Still PARTIAL: protection not applied on GitHub, second maintainer not yet a real person (R1 item 4)
9 SDLC document GLI-19 App. B.8.3; RTS 8.25/8.29/8.31/8.33 MISSING → PARTIAL lab/process/SDLC.md + CI config now in repo (ci.yml: build, typecheck, unit, py, lab:verify-build drift, dependency review, audit) + lab/process/SECURITY-PROGRAM.md (cadence). PARTIAL because CI has not run on GitHub yet and the repo is single-maintainer
10 Runtime self-tests / health tests: KATs before first use, output inhibited on failure; daily artifact hash check SP 800-90A §11.3; GLI-19 §2.3.2; NJ 13:69O-1.5(c) MISSING → HAVE packages/rng-node/src/selftest.ts: 11 KATs (4 NIST CAVP HMAC_DRBG + FIPS/RFC vectors + RAIN stream vectors both mechanisms) at startup / 24 h / GET /selftest; /healthz.kat; 503 on RNG endpoints in error state; fingerprint check vs FINGERPRINTS.json; tests
11 Penetration test report GLI-19 App. B.9 MISSING → MISSING third party required — scope, annual cadence and status (not contracted) fixed in lab/process/SECURITY-PROGRAM.md §2 row 1
12 External contract + node audit §6 MISSING → MISSING third party required — cadence (per contract deployment / per major version) and status (not contracted) in SECURITY-PROGRAM.md §2 rows 2–3
13 Hosting / HA / DR document GLI CSR §2.11; MGA Art. 17(4) PARTIAL → PARTIAL lab/process/HOSTING-HA-DR.md; real-network deployment exercised (single node on Render, 4,000 rounds, 0 errors — lab/results/latency-real-network/); ha-test.sh (2 workers + Postgres + LB, SIGKILL) still not executed — no Docker/root in this environment, Render's LB offers no kill-one-instance control (R1 item 7b)
14 Incident procedure GLI CSR §2.11(h); RTS 5.24–5.28; NJ 13:69O-1.5(d) PARTIAL → HAVE lab/process/INCIDENT-RESPONSE.md (classes S1–S4, node auto-behaviour, notification, evidence, post-mortem)
15 Game description & rules / pay tables GLI CSR §2.2 PARTIAL → PARTIAL unchanged (out of RNG scope; configs vendored)
16 Independence / unpredictability argument (stand-alone) GLI-19 §3.2.4, §3.3.2(a),(c) PARTIAL → HAVE RNG-DESCRIPTION.md App. A (Claims 1–4 with stated assumptions); lab/STATE-MODIFICATION-3.3.2c.md (one page: per-round external entropy, rotation, per-round DRBG, attacker-with-snapshot table — R1 item 6)
17 Test vectors & cross-implementation evidence GLI-19 §3.2.1 HAVE → HAVE unchanged
18 Threat model §6; MGA Art. 18 HAVE → HAVE prose in docs/RNG.md §3; App. A + KEY-MANAGEMENT now give it in standards vocabulary
19 Public verifiability tooling AGCO 4.27 HAVE → HAVE unchanged
20 Licence / IP statement GLI CSR §1 HAVE → HAVE unchanged

Score: before HAVE 4 · PARTIAL 8 · MISSING 8 → after HAVE 13 · PARTIAL 5 · MISSING 2 (unchanged by review round 1: items 8, 9, 13 moved closer but stay PARTIAL until branch protection is applied by an org owner, a second maintainer exists and the HA test runs on a Docker host; 11, 12 need third parties). Index of the package: lab/README.md; one-screen artifact table: lab/EVIDENCE-INDEX.md; review-round-1 response: lab/REVIEW-RESPONSE-R1.md.

8. Recommended build order to reach "send to lab"

  1. Freeze scope: decide whether the certified RNG is (a) outcome() + % N (as live today) or (b) drbg() + intBelow (v2.1) — or both as two "implementations" (GLI-19 §4.5.1 evaluates each separately, doubling data collection). Recommendation: certify (b) as the forward path and (a) as the legacy path only if the live games must be covered now.
  2. Write docs/lab/RNG-DESCRIPTION.md in GLI-19 §3 order (types, entropy sources, seeding, mixing, generator, range/period, scaling per game, independence, cryptographic attacks a/b/c, state exposure, abort handling), with the assumption-explicit proofs (items 6, 16) as appendices.
  3. Build the two collection tools (item 5) and run the suites (item 4): Dieharder -a, SP 800-22 STS (≥ 1000 sequences × 10^6 bits), TestU01 Crush (BigCrush if budget), per-game chi-square/serial/runs at ≥ 10^8 outcomes for small N, shuffle position tables; adversarial-player-input run. Archive raw logs + seeds; write docs/lab/STATISTICAL-REPORT.md.
  4. Add runtime KATs and fingerprint self-check to rng-node startup (item 10); produce FINGERPRINTS.json + BUILD.md with pinned toolchain and a reproducibility check (item 3).
  5. De-minify / supply readable sources for every vendored engine reduction; inventory every % (item 2, 6).
  6. Execute the HA/Postgres/crash tests on real Docker and record results (item 13); deploy RngAnchor.sol on the target chain if anchoring is part of the certified configuration.
  7. Write the process documents: change control (with "RNG-affecting change" definition and re-cert trigger), SDLC, key management, incident response, hosting/DR template (items 7–9, 13, 14).
  8. Commission the external security audit on the RNG scope (§6) and a penetration test of a reference deployment (item 11, 12); attach reports.
  9. Pre-submission call with the lab (all labs offer it; iTech states "consultations" are included in the fixed price). Ask specifically: how they will classify player-supplied entropy under §4.5.2(e)/AGCO 4.26; whether % N with bias < N/2^256 passes their source review or must be rejection-sampled; what draw counts they want per game; whether they require the on-chain contracts in scope (for a UKGC/MGA component RNG certificate they usually will not; for a GLI-19 platform submission they will).

9. Labs — contact, process, cost/timeline (public facts only)

Lab Public process facts Cost / timeline Accreditation / recognition notes
GLI — Gaming Laboratories International (gaminglabs.com/contact) Publishes GLI-19, GLI-11, Composite Submission Requirements v2.0 (the package definition in §1.12) and a Change Management Program Guide; iGaming RNG page lists scope (§2.1). Submission via account manager; source review, data collection (hundreds of millions of draws), witnessed or in-lab compile. Not public. Pricing by quote. Their own text: data collection "hours, days, weeks, or months". Recognised essentially everywhere (NJ, PA, Ontario ITL list, UK, Malta…).
BMM Testlabs (bmm.com → "connect"; certification application form download on site) "math & RNG testing", product certification schemes published for Slovenia; issued the Chainlink VRF GLI-19 certificate (§4.1). Not public. Ontario ITL ("BMM North America"); NJ, PA, UK, MGA recognised.
iTech Labs (itechlabs.com/contact-us; Glen Waverley, VIC, Australia, +61 3 9561 9955 per certificates) Archived RNG page: source code required + scaling/shuffle code fragments; 3-stage method; deliverables = report, Diehard & chi-square results, seal, hot-linked certificate; "RNG testing usually takes 1-3 weeks"; "firm, set price… payment required at the start… unlimited retests after bug fixes". Has certified crypto-casino RNGs (BC.Game, Hash Games) under UK RTS (§4.2–4.3). Timeline public (1–3 weeks); price amount not public. UK, Malta, Isle of Man, Gibraltar, Alderney, Denmark, Italy, Spain, Portugal, Australia, Kahnawake listed on the archived page.
eCOGRA (ecogra.org, London) RNG page describes source review, statistical analysis, seed generation review, algorithm attack resistance, periodic re-testing; also offers ISO 27001, pen-testing, platform certification and "Change Management for iGaming Compliance". Not public. Ontario ITL; lists RNG certification in Alderney, Bahamas… Michigan, Netherlands, Ontario etc.
Gaming Associates (gamingassociates.com/contact-us) RNG page: same evaluation list as iTech; "Source Code Analysis; Period Assessment; Determining RNG Range; Examining Background Cycling/Activity; Comprehensive Battery of Tests; Outcome Distribution Analysis". Also "Transfer of Approvals" and "Source Code Reviews" as services. Not public. Ontario ITL ("Gaming Associates Europe"); Brazil recertification press release.
Others on the Ontario ITL list Eclipse Compliance Testing, Global Lab Ltd., Lean Lab Company (Riskcherry), Quinel Ltd. — Registered by AGCO for games and RNGs.

Regulator-side public fees found: Isle of Man Software Supplier Licence £5,250 application / £36,750 p.a.; Token/Blockchain Software Supplier Licence £5,250 / £52,500 p.a. (GSC sheets v10/25). MGA administrative fees for new RNG/game-engine approval are "due in advance" (Directive 3, Art. 19(1)(b)) — amounts are in the Gaming Licence Fees Regulations (S.L. 583.03), not checked here. No lab publishes RNG certification prices; industry anecdotes exist but are not reproduced here because they are not sourced.

10. Sources (all fetched 2026-09-13 unless noted)

Standards / regulations (primary):

Labs (marketing / precedents):

Audit-readiness guidance:

Repository files read [REPO]: README.md, CHANGELOG.md, PUBLISHING.md, package.json, docs/RNG.md, docs/HOUSE-NODE.md, docs/HANDOFF.md, packages/rng-core/{README.md,src/drbg.ts,src/rng.ts,test/*}, packages/rng-node/{src,test,scripts,docker}, packages/rng-session/contracts/RngAnchor.sol (listing), packages/rng-py/* (listing), ../AUDIT.md. docs/LAB-READINESS.md does not exist in the repo.

← Back to the package index · Rendered 2026-09-14 09:34 UTC from the repository copy; the markdown in the zip / repo is the document of record.