Plinko Audit | Provably Fair Audits

✓ CertifiedPlinkoLast Updated: June 2026

8,100Live Bets Verified

100%Parity Rate

27MSimulated Rounds

99.9%Theoretical RTP

20/20

Tests Passed

Verification Pipeline

Outcome Generation — Duel Plinko (10 rows · HIGH)

Seeds + Nonce + Rows

HMAC-SHA256

Direction bit per row

L/R Bounce → Slot

Payout Applied

77×

10×

3×

0.9×

0.3×

0.2×

0.3×

0.9×

3×

10×

77×

Slot: 8/10·Multiplier: 3.0254×·Payout: $0.0303

Bet Captured by ProvablyFair.org

Now independently verifying every step...

Seed

RNG

Parity

RTP

Integrity

Test Suite — 20 Steps

1—Seed Hash Integrity

8—Multiplier Table Provenance

15—Dataset Hash

2—Next-Seed Promotion

9—Phase C Code-Path Equivalence

16—Scaling Edge Analysis

3—Hash Consistency Within Epoch

10—Zero Edge Audit

17—Probability Independence

4—Nonce Audit

11—Config Completeness

18—Phase D — Client Seed Variation

5—Slot Recomputation (RNG + drand absent)

12—Epoch Size

19—Simulation Results — Pass 1 Integrity

6—Client Seed Influence

13—Multiplier Table + Symmetry

20—Simulation Results — Pass 2 Cherry-Pick Test

7—Payout Math

14—Phase Labels

PROVABLY FAIR — Full Pass20/20 · 0 failsRecap only — full audit in S7

Result

Audit Verdict

Overall Status

Pass

RTP Verified

Pass

99.9% theoretical · 99.917% simulated (27M) · 0.1% house edge

Live ↔︎ Verifier Parity

Pass

100% — 8,100 / 8,100 bets matched

Commit-Reveal System

Pass

SHA-256 verified, 162 / 162 seeds — commitment chain intact across all rotations

Client Seed

Pass

Browser-generated + player customizable — server commits before client seed is known

RNG Analysis

Pass

HMAC-SHA256 per-row — each bounce is an unbiased 50/50, no hidden inputs

Payout Logic

Pass

All 8,100 payouts verified — win_amount = bet × multiplier, exact to 8 decimal places

Scaling House Edge

Info

0.1% house edge at bracket 0, scaling to 2.0% at extreme bet sizes. Thresholds vary by config — see S4.7

Anti-Circularity

Pass

Binomial P(slot) × observed multipliers = 99.9% for all 27 configs — derivation uses no operator RTP figure

Integrity Checks

Pass

15 standard fairness integrity tests — 14 pass, 1 N/A

Determinism

Pass

Full reproducibility confirmed

Open SourceReproduce This Audit

The repo is the credential. You don't have to trust us — every finding ships as code. Run npm test to re-run the full audit: 20 verification steps, 27M simulated rounds, 8,100 live bets re-verified.

Repository:github.com/ProvablyFair-org/duel-plinko

Commit Audited:5bb2cd4a0ea159af118c3000b74298a16b2f89ad

View reproduction commands

reproduce-audit.shVerified

# Clone and setup
git clone https://github.com/ProvablyFair-org/duel-plinko.git
cd duel-plinko
git checkout 5bb2cd4a0ea159af118c3000b74298a16b2f89ad
npm install
# Run full audit (15 unit tests + 27M simulation + 20 verification steps)
npm test
# Or run individual components
npm run verify    # 20-step verification pipeline
npm run simulate  # 27M-round simulation
# View generated reports
cat outputs/verification-results.json
cat outputs/simulation-results.json

Overview

Plinko Audit Overview

This audit independently validates the Plinko game operated by Duel.com across five domains: deterministic outcome generation, entropy integrity, live-to-verifier parity, RTP mathematical accuracy, and fairness integrity testing. We placed 8,100 real bets across 162 seed pairs and independently verified every single outcome using our own implementation of the algorithm.

Scope

What Was Audited

The RNG algorithm is deterministic and verifiable
Server seeds are cryptographically committed via SHA-256 before play
Client seed is browser-generated and players can customize it
Nonces increment correctly and are never reused
Slot outcomes are computed via HMAC-SHA256 with one call per row
Slot positions are reproducible from server seed, client seed, nonce, and row count
Payout logic matches the published multiplier tables for all 27 configurations
Theoretical RTP is 99.9% across all configurations (0.1% house edge at bracket 0)
Bet amount does not influence the RNG or slot outcome
Players can independently verify every bet

What Audit Covers

Area	Description
Commit-Reveal System	SHA-256 server seed hashing, pre-bet commitment, reveal on rotation
Client Seed Origin	Player-controlled seed, browser-generated — server commits before your seed is known
Seed Handling	Client seed control, nonce lifecycle, seed pair rotation
RNG Analysis	HMAC-SHA256 per-row algorithm verification, bias analysis, external entropy assessment
Payout Logic	Multiplier table accuracy, house edge verification, bet-size invariance (Phase C)
Live Parity	Independent slot recomputation vs live game results
RTP Validation	Anti-circularity proof, simulated RTP (27M rounds), cherry-pick detection (Pass 2)
Fairness Integrity	Standard integrity matrix — 15 tests across commit-reveal, determinism, payout, isolation, and parameter enforcement

What Audit Guarantees

Outcomes are deterministic and reproducible from the recorded inputs
Live game results match independent recomputation for the verified sample (8,100 / 8,100)
Slot distribution follows binomial B(rows, 0.5) for all 27 configurations
RTP is proven analytically: binomial P(slot) × multiplier = 99.9% for all 27 configurations
Client seed is a genuine, browser-generated input that materially influences results (84.2% slot change rate)
The house edge is 0.1% at bracket 0 as documented
All standard fairness integrity checks passed at audit time
Progressive house edge is disclosed and documented — 191 bet-size brackets per config, scaling from 0.1% to 2.0%

What Audit Excludes

Infrastructure or server security
Wallet, payments, or operational systems outside game logic
Rakeback layer — 99.9% is the certified RTP; rakeback is operator-side
Scaling house edge at bet amounts above bracket 0 — see S4.7 for full analysis
Cross-account sampling
Max win cap enforcement — not embedded in game logic

References

Plinko — Game Rules7 sections▶

Plinko is a ball-drop game on a triangular peg board. You pick the number of rows (8–16) and a risk level (low, medium, or high). The ball bounces left or right at each row — a fair 50/50 each time — and lands in one of the slots at the bottom. The slot it lands in decides your payout multiplier.

How to Play

1. Choose row count — Select between 8 and 16 rows. More rows means more bounces and more possible slot positions.
2. Choose risk level — Select low, medium, or high. Higher risk shifts payout weight toward edge slots.
3. Enter bet amount — Choose how much to wager.
4. Drop the ball — The ball bounces through the peg board and lands in a slot.
5. Outcome — Payout = bet amount × multiplier for the landing slot.

Slot outcomes are determined cryptographically before the ball animation plays. The visual drop is cosmetic — the result is fixed at the moment the bet is placed.

Win Conditions

The win condition in Plinko depends on which slot the ball lands in.

Outcome	Condition	Example (16r/high)
Jackpot (edge slot)	Ball lands in slot 0 or 16	1009.33× — ~1 in 65,536 chance
Win (outer slots)	Ball lands near edges	Slot 4 → 4.04×
Partial return	Ball lands near center	Slot 8 → 0.20×

Every Plinko bet returns something — there is no bust/zero outcome. Center slots return less than the bet amount; edge slots return large multiples.

Risk vs Reward

The core mechanic of Plinko is the tradeoff between row count, risk level, and payout shape.

Row count controls granularity — more rows means more possible slots and higher maximum multipliers at the edges
Risk level controls payout shape — low risk has flatter payouts; high risk concentrates value at edge slots with a 0.2× center floor
RTP is constant — all 27 configurations have the same theoretical RTP (99.9% at bracket 0) regardless of rows or risk

Parameters

Parameter	Value	Notes
Row Count	8–16	Player selects; determines slot count
Risk Levels	Low, Medium, High	Affects multiplier table, not slot probabilities
House Edge	0.1% (bracket 0)	Progressive — increases at higher bet amounts
Theoretical RTP	99.9%	Verified across all 27 configurations
Configurations	27	9 row counts × 3 risk levels
RNG Algorithm	HMAC-SHA256	One HMAC call per row; key = hex-decoded server seed

Seed Formats

Every Plinko bet uses three cryptographic inputs to generate the result.

Seed Type	Format	Example	Purpose
Server Seed	64-char hex (32 bytes)	5de225f630d2de83…	Casino-provided randomness
Client Seed	Alphanumeric string	MAAxNnpj1uB4AobA	Player-contributed entropy
Nonce	Integer (0, 1, 2…)	23	Ensures uniqueness per bet within epoch

The server seed is hex-decoded to 32 raw bytes before use as the HMAC key. Passing the hex string as UTF-8 would produce completely different results. This is confirmed by 8,100-bet recomputation.

Multiplier Tables & Payout

Payouts in Plinko are determined by the landing slot, row count, and risk level. The multiplier is calibrated so that the expected return is approximately 99.9% across all 27 configurations at bracket 0.

win_amount = bet_amount × multiplier_table[risk][rows][slot]

Rows	Risk	Edge Multiplier (slot 0/N)	Center Multiplier	RTP
8	Low	5.65×	0.50×	99.9%
8	High	29.25×	0.20×	99.9%
16	Low	16.15×	0.50×	99.9%
16	High	1009.33×	0.20×	99.9%

Multiplier tables are symmetric — slot k and slot (rows − k) always carry the same multiplier. All 27 configurations produce exactly 99.9% RTP at bracket 0. Higher bet amounts fall into progressively higher brackets with lower multipliers.

Why Provably Fair Matters▶

Traditional online casinos require players to trust that games are fair. Provably fair systems eliminate this trust requirement by allowing players to mathematically verify that outcomes were not manipulated. In a Provably Fair system:

The casino commits to a result before the player bets
The player contributes randomness that the casino cannot predict
Anyone can verify the outcome after the fact

High-Level Overview8 sections▶

Checklist Reference

Based on the ProvablyFair.org Audit Execution Checklist, here are the tests covered under this audit document.

1. Commit-Reveal System & Seed Handling

Test	Description
Server seed commit exists before play	SHA-256 hash shown to player before betting
Server seed reveal matches commit	SHA-256(hexDecode(revealed)) = committed hash
Client seed control	Player can set/change client seed via rotation UI
Nonce increments correctly	Starts at 0, +1 per bet, resets at epoch boundary
Full determinism	Same inputs → same result

2. Randomness & Entropy Model

Test	Description
RNG depends only on seeds + nonce	No external inputs — slot is a pure function of (server seed, client seed, nonce)
No mixed entropy sources	No timestamps, Math.random, etc.
Unbiased mapping	int % 2 on uint32 has zero modulo bias
No state leakage	RNG isolated per round — each row uses unique cursor

3. Verifier ↔︎ Live Parity

Test	Description
Live outcomes match verifier	8,100 / 8,100 slots recomputed with 0 mismatches
Multi-phase verification	Phases A (all configs), B (deep sample), C (bet-size check), D (client seed)
Bet-size invariance	$10 bets produce same slots as $0.01 bets

4. Game Logic & RTP Validation

Test	Description
Anti-circularity proof	Binomial P(slot) × observed multipliers = 99.9%
House edge audit	0.1% confirmed across all 27 configs at bracket 0
Payout rules correctness	Win amount matches multiplier × bet within 1e-8
Simulated RTP convergence	27M rounds converge on theoretical 99.9%
Cherry-pick detection	10 flags, binomial p = 0.773 (not significant)

5. Fairness Integrity & Player Verification

Test	Description
Player can reproduce results offline	Using seeds + nonce + row count
Verifier logic matches live logic	Same HMAC-SHA256 per-row algorithm
Verifier publicly accessible	ProvablyFair.org verifier — no login required
No reliance on private APIs	Fully client-side verification
20 fairness integrity tests	Commit-reveal, determinism, payout, distribution, anti-manipulation

High-Level Flow

To get an overview of how the process works, here is a high-level breakdown:

1. Player Bets — Selects row count (8–16), risk level, and bet amount
2. Seeds Combined — HMAC-SHA256(hexDecode(serverSeed), clientSeed:nonce:cursor) for each row
3. RNG Output — Each row produces a uint32; int % 2 determines left (0) or right (+1)
4. Slot Accumulation — Sum of right-bounces across all rows = final slot (0 to rows)
5. Multiplier Lookup — final_slot maps to multiplier via scaling_edge[0].multipliers[rows][risk]
6. Payout Result — win_amount = bet_amount × payout_multiplier

Provably Fair Model

Provably fair gambling systems use cryptographic primitives to guarantee the integrity of outcomes. The model relies on three components: a server seed committed via hash before play, a player-controlled client seed, and an incrementing nonce. These inputs are combined using HMAC-SHA256 to produce deterministic, verifiable results. This section documents the global provably fair architecture used by almost all casinos and all relevant games.

Commit-Reveal Model

The Commit-Reveal model is integral to ensuring fairness and transparency in online gambling. This model involves several key phases:

Commit Phase:
Before any bets are placed, the casino generates a random server seed. To prove its authenticity and prevent later manipulation, only the SHA-256 hash of the hex-decoded seed is sent to the player. This ensures that while the player cannot know the seed initially, they can verify it later.

Bet Phase:
The player places their bet. The server combines the server seed with the player's client seed via HMAC-SHA256 to compute each row's outcome. Each epoch uses the same server seed and client seed pair.

Reveal Phase:
After the epoch ends, the server rotates seeds and reveals the plaintext server seed. The player can now independently verify SHA-256(hexDecode(serverSeed)) = committedHash.

Verify Phase:
Anyone can recompute every bet's slot from the revealed server seed, client seed, and nonce using the published HMAC-SHA256 algorithm.

Player-Controlled Client Seed

The player's client seed is generated by the browser and submitted to the server via the seed rotation UI. Players can set their own client seed at any time. This ensures:

The casino cannot predict the full RNG input
Players contribute entropy that they control
Results depend on both parties' inputs

Nonce Lifecycle

The nonce is a counter that increments with each bet within an epoch:

Starts at 0 for each new server seed
Increments by exactly 1 per bet
Never reused within the same seed epoch
Resets to 0 when the server rotates to a new server seed

Seed Epoch: (serverSeed, clientSeed)

Bet 1:  nonce = 0  → Slot A
Bet 2:  nonce = 1  → Slot B
Bet 3:  nonce = 2  → Slot C

...
[Player rotates seed — epoch complete]
Next bet: nonce = 0  → Slot X (new seed pair)

Determinism Guarantee

Given identical inputs, the output is always identical:

HMAC-SHA256(hexDecode(serverSeed), clientSeed:nonce:cursor) → Always same hash
Same hash per row → Always same left/right bounce
Same bounces across all rows → Always same final slot
Same slot + same config → Always same payout

Technical Glossary7 categories▶

Core Concepts

Term	Definition
Provably Fair	A cryptographic system that allows players to mathematically verify that game outcomes were not altered. Relies on commit-reveal schemes and deterministic algorithms.
Commit-Reveal Protocol	A two-phase process in which the casino commits to a result (by showing its hash) before the player bets, then reveals the actual value after the bet.
Determinism	The property that identical inputs always produce identical outputs. Same server seed, client seed, nonce, and row count must always generate the same slot position.
Client Seed Origin	The method by which the client seed is generated. Full Pass: browser-generated default + player customizable seed. Conditional Pass: server-assigned default + player customizable seed. Hard Fail: player cannot set own seed.

Seed System

Term	Definition
Server Seed	A random 32-byte value generated by Duel.com, transmitted as a 64-character hex string. Hashed and shown to players before betting, revealed after epoch rotation.
Client Seed	A random value controlled by the player, generated by the browser. Players can change it at any time via the seed rotation UI.
Nonce	A sequential counter that increments per bet within an epoch. Resets to 0 when the server rotates to a new server seed.
Hashed Server Seed	SHA-256(hexDecode(serverSeed)) — the commitment hash shown before betting. After rotation, players verify the revealed seed produces this hash.
Cursor	Zero-based row index (0 to rows−1) used in the HMAC message. Each cursor value produces one row's left/right bounce.

Cryptographic Functions

Term	Definition
HMAC-SHA256	Hash-based Message Authentication Code using SHA-256. Duel Plinko uses HMAC-SHA256 with the hex-decoded server seed as key and clientSeed:nonce:cursor as message. One call per row.
SHA-256	Secure Hash Algorithm 256-bit. Used for server seed commitment: SHA-256(hexDecode(serverSeed)) = serverSeedHashed.
Hex Decoding	Converting a 64-character hex string to 32 raw bytes. Critical for the HMAC key — using the hex string as UTF-8 produces wrong outputs.

Verification Terms

Term	Definition
Verifier	A tool that independently calculates slot outcomes using provided seeds, nonce, and row count. The ProvablyFair.org verifier is built from the audit codebase.
Parity	Degree of matching between verifier and live game results. 100% parity = every slot matches. This audit: 8,100/8,100 exact match.
Anti-Circularity	Proof that the RTP derivation uses no operator-supplied RTP figure. Independently-computed binomial B(rows, 0.5) probabilities × the published payout table = 99.9%.

Game Mechanics

Term	Definition
Slot	The ball's final landing position (0 to rows). Slot = count of right-bounces across all rows. Each slot has a corresponding payout multiplier.
Row Count	Player-selected parameter (8–16) determining the number of peg rows and HMAC calls per bet. More rows = more possible slots.
Risk Level	Player-selected parameter (low, medium, high) that determines the multiplier table. Higher risk = more value at edge slots, less at center.
Binomial Distribution	B(rows, 0.5) — the probability distribution for slot outcomes. P(slot = k) = C(rows, k) × 0.5^rows. Each row is an independent 50/50 event.
Progressive House Edge	Duel.com applies higher house edges at larger bet amounts via 191 bet-size brackets per config. Bracket 0 (0.1% edge) covers bets up to ~$336 for the most restrictive config.

Audit Terms

Term	Definition
Epoch	A sequence of bets using the same server seed and client seed pair. Ends when the player rotates seeds.
Phase	A structured data collection segment. Phase A: all 27 configs. Phase B: deep 16r/high sample. Phase C: $10 bet-size check. Phase D: client seed verification.
Cherry-Pick Detection	Test for selective seed deployment. Pass 2 simulation runs 162 revealed seeds × 10,000 nonces, comparing early vs late distributions to detect biased seed selection.
Master Dataset	data/plinko-master-8100bets.json — the primary dataset containing all 8,100 bets and 166 seed entries across four phases.

Data Formats

Term	Definition
plinko-master-8100bets.json	The 8,100-bet dataset used throughout this audit. SHA-256: 3cf9359d88220bc800bb32edfe04399f55b909302262928ee3a0582715635267.
plinkoConfig.json	Duel.com's game configuration file containing all 27 multiplier tables, 191 bet-size brackets per config, and probability arrays. Captured from https://duel.com/api/v2/games/plinko/config during the April 2026 audit window. SHA-256: 78f0a39201a8c24fd1577143732e004f77e27d4d36efeedc6b3f7b93b2078fed.
verification-results.json	Output of the 20-step verification suite. Contains all step results, seed hash checks, slot recomputation logs, and simulation artifact verification.
simulation-results.json	Two-pass simulation output: Pass 1 (27M rounds, fresh seeds) and Pass 2 (162 casino seeds × 10K nonces, cherry-pick detection).

Seed, Nonce & Determinism

Can the casino change your outcome after you bet?

Every Plinko game on Duel.com is generated from four inputs: server seed, client seed, nonce, and row count. The casino commits to its server seed by publishing a SHA-256 hash before you place any bets. After you rotate your seed, the server reveals the actual seed — and anyone can verify that the hash matches. This cryptographic commitment makes it impossible for the casino to secretly change your outcome after you bet.

Commit-Reveal Cryptographic Guarantee

162 / 162seeds verified

🔍What We Verified

Casino commits to the server seed hash before any bet is placed
Client seed is browser-generated — server cannot know it at commitment time (Full Pass origin)
Players can set or change their client seed at any time via the rotation UI
Nonce increments by 1 per bet with no gaps or duplicates across 162 seed pairs
Slot positions are fully determined by the seed inputs before the ball drops
Identical inputs always produce the same slot — confirmed across all 8,100 bets
Your client seed is a genuine input — changing it changes the outcome

👤What This Means for You

The casino cannot change where the ball lands after you bet
You contribute randomness the server cannot predict or pre-select against
Every bet is unique — the nonce ensures no two bets share an outcome
Any result can be independently verified using the public tools and repo
Outcomes are tamper-proof and verifiable even months later
Cherry-picking favourable seeds is structurally impossible

Test	Status	Finding
Server seed committed before bet	Pass	SHA-256 hash of server seed published before play — casino cannot change randomness after betting
Client seed origin	Pass	Browser-generated (Full Pass) — server commits before client seed is known
Client seed control	Pass	Player can set/change client seed via rotation UI at any time
Nonce sequencing	Pass	Sequential within each seed pair, 0 gaps, 0 duplicates across 162 seed pairs
Hash consistency within seed pair	Pass	server_seed_hashed constant across all bets within each of 162 seed pairs
Seed hash integrity	Pass	162 / 162 revealed seeds hash-verified — commitment chain intact
Deterministic output	Pass	Same (serverSeed, clientSeed, nonce, rows) always produces same slot — 8,100/8,100 confirmed
Client seed participation	Pass	Client seed is a genuine input — changing it changes the slot outcome

✓ Commit-reveal verified

All 162 revealed seeds hash-verified. Every seed rotation was verified — the next seed the casino pre-committed always matched what was actually used. Outcomes are fully deterministic — the same server seed, client seed, nonce, and row count always produce the same slot. The casino cannot change your result after you bet.

How It Works — Seed, Nonce & Determinism7 sections

1.1Server Seed Commitment

Before any bet is placed, the casino generates a secret server seed and publicly commits to it by displaying its SHA-256 hash. The server seed is a 64-character hex string (32 bytes), and the commitment hash is computed as SHA-256(hexDecode(serverSeed)). This cryptographic commitment locks the server's randomness before the player acts. After the epoch ends, the actual server seed is revealed — and anyone can verify that the hash matches.

src/rng.ts· verifyHashVerified

export function verifyHash(serverSeed: string, serverSeedHashed: string): boolean {
  const hash = crypto
    .createHash('sha256')
    .update(Buffer.from(serverSeed, 'hex'))
    .digest('hex');
  return hash === serverSeedHashed;
}

Result: 162/162 revealed seeds hash-verified. Zero mismatches. The 3 skipped entries are phase-boundary marker rotations — the capture script forces a clean seed rotation at each phase transition (A→B→C→D), and these rotations carry valid commitments but no bets reference them.

Real Example from Live Data:

plinko-master-8100bets.json· seed entry

{
  "clientSeed": "MAAxNnpj1uB4AobA",
  "serverSeedHashed": "9fae5bb7897874cb71d7bd1be6dca522ddcd8f0c8f18ecaab9c5474d63b9be5a",
  "serverSeed": "5de225f630d2de838265252752ab4ba050a3f20a53711e23a0a43979abf755bd",
  "nonce": 0
}

Verification:

verify-seed.jsVERIFIED

const crypto = require('crypto');
const serverSeed = "5de225f630d2de838265252752ab4ba050a3f20a53711e23a0a43979abf755bd";
const hashedServerSeed = crypto
  .createHash("sha256")
  .update(Buffer.from(serverSeed, 'hex'))
  .digest("hex");
console.log(hashedServerSeed);
// Output: 9fae5bb7897874cb71d7bd1be6dca522ddcd8f0c8f18ecaab9c5474d63b9be5a ✅

1.2Commitment Linkage (Next-Seed Promotion)

At every seed rotation, the nextServerSeedHash pre-committed before rotation must match the serverSeedHashed that becomes active after rotation. This chain ensures the server cannot generate seeds at rotation time after seeing the player's client seed — the next seed was already locked before the previous epoch began.

tests/steps/commitment.ts· Step 2: EC-2Verified

// Step 2: Next-Seed Promotion (Commitment Linkage)
for (const s of seeds) {
  if (!s.nextSeedPromotion) continue;
  checked++;
  // recompute linkage — don't trust a captured flag:
  const { previousNextHash, newActiveHash } = s.nextSeedPromotion;
  if (previousNextHash !== newActiveHash) {
    promoFails++;
  }
}

Result: 166/166 next-seed promotions verified across all four phases. The pre-committed next server seed hash matched the promoted active hash at every rotation boundary.

1.3Hash Consistency Within Epoch

For each of the 162 epochs, the server_seed_hashed field was extracted from every bet response and checked for uniqueness. More than one distinct hash within a single epoch would indicate a mid-epoch seed substitution — a critical commit-reveal violation.

tests/steps/commitment.ts· Step 3: EC-26Verified

// Step 3: Hash Consistency Within Epoch
for (const [hash, epochBets] of byHash) {
  const hashes = new Set(epochBets.map(b => b.response.server_seed_hashed));
  if (hashes.size !== 1) {
    failures.push(`Epoch ${hash.substring(0, 16)}: ${hashes.size} distinct hashes among ${epochBets.length} bets`);
  }
}

Result: 162/162 epochs — server_seed_hashed constant within every epoch. Zero mid-epoch changes detected.

1.4Client Seed Origin & Control

Players have full control over their client seed through the Duel.com fairness UI, allowing them to view, modify, or randomize it at any time before placing bets. The client seed is an input to every HMAC-SHA256 computation — changing it produces a completely different slot outcome. The client seed is browser-generated (Full Pass origin) — the server commits to its seed before the client seed for that epoch is known, making cherry-picking structurally impossible. Phase D specifically tested 10 distinct pfaudit-prefixed client seeds to confirm each is actively used.

0fFB4mFVNIQOSDzR
3FfHxJWEayg31gaN
KWooaSzlek9LYZzc
LPzKd5K1ULzrG2Xc
MAAxNnpj1uB4AobA

Result: 162 unique client seeds observed across the dataset. Client seeds are player-controlled and vary across all phases and epochs. Full Pass origin confirmed. Evidence: plinko-master-8100bets.json

1.5Nonce Incrementation

The nonce begins at 0 and increments by 1 for each bet under the same server seed. In Plinko, the nonce advances once per bet — each bet uses one nonce value. The nonce resets to 0 when the player rotates their seed, starting a new epoch. In two epochs our capture script dropped a single bet response (a network blip on our side, not the casino's). The platform's nonce sequence on either side of the drop was perfectly intact, and we recomputed the missing slot from the revealed server seed to confirm it.

tests/steps/commitment.ts· Step 4: EC-3, EC-4, EC-5Verified

// Step 4: Nonce Audit
for (const [hash, epochBets] of byHash) {
  const sorted = [...epochBets].sort((a, b) => a.response.nonce - b.response.nonce);
  const nonces = sorted.map(b => b.response.nonce);
  const clientSeeds = new Set(sorted.map(b => b.response.client_seed));
  if (clientSeeds.size !== 1) {
    hardFailures.push(`Epoch ${shortHash}: ${clientSeeds.size} distinct client seeds`);
  }
  if (nonces[0] !== 0) {
    hardFailures.push(`Epoch ${shortHash}: first nonce is ${nonces[0]} (expected 0)`);
  }
  // Check for capture-retry pattern (nonce 50 present, one missed)
  const hasNonce50 = nonces.includes(50);
  const missingNonces = Array.from({ length: 51 }, (_, i) => i).filter(i => !nonces.includes(i));
  const isRetryPattern = hasNonce50 && missingNonces.length === 1 && nonces.length === 50;
}

Result: 0 gaps, 0 duplicates in the platform's nonce sequence across all 162 epochs. Two bets were dropped by our capture script and recomputed from the revealed seed.

1.6Deterministic Mapping

The RNG algorithm is fully deterministic: given the same server seed, client seed, nonce, and row count, it always produces the exact same slot position. The hash function is HMAC-SHA256 with one call per row. The server seed is hex-decoded to 32 raw bytes before use as the HMAC key. HMAC message format: clientSeed:nonce:cursor where cursor is the zero-based row index. Each row produces a uint32 from the first 4 bytes of the HMAC output; int % 2 determines left (0) or right (+1). The final slot is the sum of right-bounces across all rows.

src/rng.ts· computeSlotVerified

export function computeSlot(
  serverSeed: string,
  clientSeed: string,
  nonce: number,
  rows: number
): number {
  return computeSlotFromBuffer(Buffer.from(serverSeed, 'hex'), clientSeed, nonce, rows);
}
export function computeSlotFromBuffer(
  key: Buffer,
  clientSeed: string,
  nonce: number,
  rows: number
): number {
  let slot = 0;
  for (let cursor = 0; cursor < rows; cursor++) {
    const message = `${clientSeed}:${nonce}:${cursor}`;
    const hmac = crypto.createHmac('sha256', key).update(message).digest('hex');
    slot += parseInt(hmac.substring(0, 8), 16) % 2;
  }
  return slot;
}

Result: All 8,100 bets with revealed seeds: HMAC-SHA256 recompute matches final_slot. Zero mismatches.

Real Bet Verified:

plinko-master-8100bets.json· Bet #71591629VERIFIED

// Source: data/plinko-master-8100bets.json
// Bet ID: 71591629 (Phase A, 8 rows, high risk, nonce 0)
// ✅ VERIFIED — slot recomputed from revealed server seed
{
  "serverSeed": "5de225f630d2de838265252752ab4ba050a3f20a53711e23a0a43979abf755bd",
  "serverSeedHashed": "9fae5bb7897874cb71d7bd1be6dca522ddcd8f0c8f18ecaab9c5474d63b9be5a",
  "clientSeed": "MAAxNnpj1uB4AobA",
  "nonce": 0,
  "rows": 8,
  "risk_level": "high",
  "final_slot": 3,
  "payout_multiplier": "0.30253628",
  "win_amount": "0.0030253628"
}

Verification:

verify-slot.jsVERIFIED

// computeSlot("5de225f6...", "MAAxNnpj1uB4AobA", 0, 8)
// For each cursor 0..7:
//   message = "MAAxNnpj1uB4AobA:0:{cursor}"
//   hmac = HMAC-SHA256(hexDecode("5de225f6..."), message)
//   slot += parseInt(hmac[0..7], 16) % 2
// Final slot: 3 ✅
// Multiplier (high/8, slot 3): 0.30253628× ✅
// Payout: 0.01 × 0.30253628 = 0.0030253628 ✅

1.7Client Seed Influence

To confirm the client seed is a genuine input to the HMAC-SHA256 computation, all 8,100 bets across 162 epochs were recomputed using a deliberately incorrect client seed (WRONG_CLIENT_SEED_FOR_AUDIT_TEST). 6,819 of 8,100 slots (84.2%) changed. No epoch produced identical outcomes with the wrong seed. The unchanged slots are expected: for any given row, there is a 50% probability the HMAC bit coincidentally matches under a different key input. Phase D additionally verified 500 bets across 10 distinct pfaudit-prefixed client seeds — 434/500 slots changed (86.8%).

tests/steps/determinism.ts· Step 6: EC-27Verified

// Step 6: Client Seed Influence
const wrongClientSeed = 'WRONG_CLIENT_SEED_FOR_AUDIT_TEST';
for (const [hash, epochBets] of byHash) {
  const seedEntry = revealedMap.get(hash);
  if (!seedEntry || epochBets.length !== 50) continue;
  const serverSeed = seedEntry.seed.serverSeed!;
  let changed = 0;
  for (const bet of epochBets) {
    const { client_seed, nonce } = bet.response;
    const { rows } = bet.request;
    const correctSlot = computeSlot(serverSeed, client_seed, nonce, rows);
    const wrongSlot = computeSlot(serverSeed, wrongClientSeed, nonce, rows);
    if (wrongSlot !== correctSlot) changed++;
  }
  totalChanged += changed;
}

Result: 6,819/8,100 bets (84.2%) across 162 epochs produce different slots with an alternate client seed. Phase D: 434/500 changed (86.8%) across 10 custom seeds. Client seed is a genuine, material input.

Technical Evidence & Verification5 sections

1.8Evidence Coverage Summary

Verification Area	Coverage	Result
Seed hash integrity (Step 1)	162/162 revealed	Pass
Commitment linkage (Step 2)	166/166 next-seed promotions	Pass
Hash consistency (Step 3)	162/162 epochs	Pass
Nonce audit (Step 4)	0 gaps, 0 duplicates, 2 capture-retry verified	Pass
Slot recomputation (Step 5)	8,100/8,100	Pass
Client seed influence (Step 6)	6,819/8,100 (84.2%)	Pass

1.9Code References

File	Purpose
`tests/verify.ts`	20-step verification pipeline (Steps 1–6 cover S1)
`tests/steps/commitment.ts`	Steps 1–4: Commit-reveal integrity checks
`tests/steps/determinism.ts`	Steps 5–6: Slot recomputation and client seed influence
`src/rng.ts`	HMAC-SHA256 slot computation (computeSlot, verifyHash)
`src/loader.ts`	Dataset loading + seed/bet parsing
`capture/plinko-capture.reference.js`	Browser-based data collection script

1.10Datasets Used

Primary: data/plinko-master-8100bets.json

Property	Value
Source	Live Plinko game data from Duel.com
Total Records	8,100 bets across 162 epochs (166 seed entries)
SHA-256	3cf9359d88220bc800bb32edfe04399f55b909302262928ee3a0582715635267

Fields used: serverSeed, serverSeedHashed, clientSeed, nonce, rows, risk_level, final_slot, payout_multiplier

1.11Verified Invariants

Invariant	Result
SHA-256(hexDecode(serverSeed)) = serverSeedHashed for all 162 revealed seeds	Pass
Next-seed promotion chain intact for all 166 transitions	Pass
server_seed_hashed constant within epoch for all 162 epochs	Pass
Zero nonce gaps within any epoch	Pass
Zero nonce duplicates within any epoch	Pass
Same inputs produce same slot for all 8,100 bets	Pass
Wrong client seed changes slot in 84.2% of tests (6,819/8,100)	Pass
Client seed is browser-generated (Full Pass origin)	Pass

1.12Reproduction Instructions

Clone the repository, install dependencies, and run the verification suite:

reproduce-s1.sh· 4 linesVerified

git clone https://github.com/ProvablyFair-org/duel-plinko.git
cd duel-plinko && npm install
npm run verify
# Expected output: Steps 1–6 all PASS

Steps 1–6 cover all Seed, Nonce & Determinism checks. Expected output:

[PASS] Step 1 — Seed Hash Integrity
[PASS] Step 2 — Next-Seed Promotion (Commitment Linkage)
[PASS] Step 3 — Hash Consistency Within Epoch
[PASS] Step 4 — Nonce Audit
[PASS] Step 5 — Slot Recomputation (RNG determinism)
[PASS] Step 6 — Client Seed Influence

RNG & Entropy Model

Is the randomness genuinely random, or could it be rigged?

This section verifies that Duel.com's Plinko random number generation produces cryptographically sound, unbiased outputs using only the disclosed inputs. The RNG uses HMAC-SHA256 with one call per row — each row's bounce direction is derived from the first 4 bytes of the HMAC output, reduced to a binary left/right decision via int % 2. We independently implemented this algorithm, verified it produces the same results as the live game, and confirmed no hidden inputs can influence outcomes.

Cryptographic Randomness Verification

27 / 27configs verified

🔍What We Verified

HMAC-SHA256 produces cryptographically sound, unpredictable output for each row
Only disclosed inputs affect outcomes — no timestamps, no server-side state, no hidden entropy
`int % 2` on a uint32 has mathematically zero modulo bias — exact 50/50 per row
Slot distribution follows binomial B(rows, 0.5) for all 27 configurations (confirmed over 27M simulated rounds)
Consecutive outcomes are statistically independent — no patterns, no streaks
84.2% of outcomes change with a different client seed (6,819/8,100 tested bets)

👤What This Means for You

Each row's bounce is generated fairly and cannot be skewed
Left and right bounces are equally likely — no directional bias
No hidden randomness or server-side tricks influence the ball's path
Consecutive bets are not correlated — past results don't affect future outcomes
The algorithm depends only on seeds you can verify

Test	Status	Finding
RNG derived only from disclosed inputs	Pass	HMAC-SHA256(hexDecode(serverSeed), clientSeed:nonce:cursor) — no hidden entropy
Entropy purity	Pass	No timestamps, external APIs, Math.random, or server-side state
Algorithm independently implemented	Pass	Independent implementation produces identical results for all 8,100 bets
Modulo bias	Pass	`int % 2` on uint32 has zero bias — 2^32 is exactly divisible by 2
Key encoding verified	Pass	Server seed hex-decoded to bytes (not UTF-8) — confirmed via 8,100-bet recomputation
Serial independence	Pass	Lag-1 autocorrelation near zero and runs tests pass across all 27 configs at 1M rounds each
Client seed influence	Pass	84.2% of outcomes change with an alternate client seed — confirmed across all 8,100 bets

✓ Unbiased and Cryptographically Sound

The Plinko RNG uses only the disclosed inputs, produces uniform slot distribution across all 27 configurations, and shows no serial dependence across 27M simulated rounds. The client seed is a genuine input — 84.2% of outcomes change with a different seed.

How It Works — RNG & Entropy Model7 sections

2.1RNG Function Implementation

Each Plinko bet resolves one row at a time. For a game with rows rows, the algorithm runs rows HMAC-SHA256 computations and accumulates a slot value. The HMAC key is the server seed hex-decoded to 32 raw bytes. The message for each row is clientSeed:nonce:cursor where cursor is the zero-based row index. The first 8 hex characters (4 bytes) of each HMAC output are parsed as a big-endian uint32, and int % 2 determines the bounce direction: 1 = right (slot increments), 0 = left (slot unchanged).

Component	Detail
Hash function	HMAC-SHA256
Key	`Buffer.from(serverSeed, 'hex')` — 32 bytes
Message	`clientSeed:nonce:cursor`
Extraction	First 8 hex chars → `parseInt(hex, 16)` → uint32
Reduction	`uint32 % 2` → 0 (left) or 1 (right)
Accumulation	`slot += bit` for each cursor 0 to rows−1
Output range	0 to rows (inclusive)

src/rng.ts· computeSlotFromBufferVerified

export function computeSlotFromBuffer(
  key: Buffer,
  clientSeed: string,
  nonce: number,
  rows: number
): number {
  let slot = 0;
  for (let cursor = 0; cursor < rows; cursor++) {
    const message = `${clientSeed}:${nonce}:${cursor}`;
    const hmac = crypto.createHmac('sha256', key).update(message).digest('hex');
    slot += parseInt(hmac.substring(0, 8), 16) % 2;
  }
  return slot;
}

Result: Independent implementation matches all 8,100 live bets with zero mismatches. Algorithm coded from the cryptographic specification, not copied from any casino source code.

2.2Entropy Sources

All randomness derives exclusively from the deterministic HMAC-SHA256 function combining four cleanly separated inputs:

Source	Controlled By	Purpose
Server Seed	Casino	Base randomness (committed via SHA-256 hash before betting)
Client Seed	Player	Player-contributed entropy
Nonce	System	Uniqueness per bet (increments automatically)
Cursor	System	Per-row isolation (0 to rows-1)

No mixed entropy sources detected. Run the same inputs multiple times — results are always identical. Pure HMAC-SHA256 must always produce identical outputs. 8,100/8,100 confirmed.

How we know: 8,100/8,100 bets were recomputed using only the four declared inputs. If any hidden entropy source existed, recomputation would fail. It does not.

Verified absent: No timestamps, no Math.random(), no external APIs, no server-side mutable state. Only: HMAC-SHA256(hexDecode(serverSeed), clientSeed:nonce:cursor)

2.3Modulo Bias Analysis

Each row's bounce direction is determined by parseInt(hmac[0..7], 16) % 2 — a uint32 modulo 2 operation. Modulo bias occurs when 2^32 is not evenly divisible by the modulus. For modulus 2, there is mathematically zero bias: 2^32 = 4,294,967,296 divides evenly by 2, producing exactly 2,147,483,648 even values and 2,147,483,648 odd values. No rejection sampling is needed.

2^32 = 4,294,967,296
4,294,967,296 / 2 = 2,147,483,648  (exact, no remainder)

Even values in [0, 2^32 - 1]: 2,147,483,648  → left  (50.000%)
Odd  values in [0, 2^32 - 1]: 2,147,483,648  → right (50.000%)

Bias: 0.000%

Result: Zero modulo bias confirmed. Each row is an independent, unbiased coin flip.

This contrasts with moduli that are not powers of 2 — for example, int % 37 on a 32-bit integer would have a non-uniform residue distribution requiring rejection sampling. int % 2 requires none. Each HMAC-SHA256 output is uniform over the uint32 range (HMAC-SHA256 is a pseudorandom function), so each row produces an exact 50/50 left/right decision.

2.4RNG Isolation

Each row within a single bet uses a unique cursor value in the HMAC message (clientSeed:nonce:cursor), ensuring per-row outputs are cryptographically independent. Each bet uses a unique nonce, ensuring per-bet outputs are independent. HMAC-SHA256 is a pseudorandom function — knowing one row's output gives zero information about other rows' outputs. There is no shared state between rows, between bets, or between epochs.

Result: RNG isolation confirmed. No state leakage between rows, bets, or epochs. Each HMAC call is independently keyed and messaged.

Evidence: The computeSlot implementation in 2.1 confirms this — it is a pure function with no class state, no external calls, and no cross-bet memory. The function takes (serverSeed, clientSeed, nonce, rows) explicitly and returns a slot. Same inputs always produce the same output.

2.5Monte Carlo Simulation (27M Rounds)

A 27,000,000-round Monte Carlo simulation (1,000,000 rounds per config, all 27 configurations) verified that the algorithm produces the expected slot distribution at scale.

Metric	Value
Average simulated RTP	99.917%
Average theoretical RTP	99.900%
Chi-squared (α=0.01)	27/27 configs pass
Bonferroni-corrected (α/27)	27/27 pass
Serial independence	27/27 pass

src/simulate.ts· simulation parametersVerified

// Simulation parameters
// Per-config pinned seeds via crypto.randomBytes
// Rounds: 1,000,000 per config × 27 configs = 27,000,000
// Slot distribution tested against binomial B(rows, 0.5)

Result: 27M rounds simulated. All 27 configs pass chi-squared and serial independence. Slot distribution matches binomial expectations.

All 27 configurations pass individual chi-squared tests. Serial independence: 0 failures at Bonferroni-corrected threshold across 27M rounds.

Methodology: Per-config pinned seeds for reproducibility. Chi-squared goodness-of-fit on slot distribution vs independent binomial B(rows, 0.5). Serial independence tested via lag-1 autocorrelation and Wald-Wolfowitz runs test.

2.6Serial Independence

Serial independence ensures consecutive bet outcomes are not correlated — winning or losing on one bet does not affect the next. Two tests were applied to each configuration in the Pass 1 simulation (1,000,000 rounds per config):

Lag-1 autocorrelation: Measures correlation between consecutive slot values. Expected r ≈ 0 for independent sequences. Threshold: |z| > 3 (where z = r × √n).

Wald-Wolfowitz runs test: Tests whether the sequence of above/below-median outcomes has the expected number of runs. p < 0.01 indicates non-random structure.

src/stats.ts· lag1AutocorrelationVerified

export function lag1Autocorrelation(values: number[]): number {
  const N = values.length;
  if (N < 3) return 0;
  const mu = values.reduce((a, b) => a + b, 0) / N;
  const variance = values.reduce((acc, x) => acc + Math.pow(x - mu, 2), 0) / N;
  if (variance === 0) return 0;
  let cov = 0;
  for (let i = 0; i < N - 1; i++) {
    cov += (values[i] - mu) * (values[i + 1] - mu);
  }
  return cov / ((N - 1) * variance);
}

Result: 0/27 configurations fail serial independence. All lag-1 autocorrelation values are near zero, all runs test p-values are above 0.01. Consecutive outcomes are statistically independent.

2.7Worked Example — Full RNG Trace

Real bet from dataset — Bet ID 71596330, 16 rows, high risk, nonce 0. Verified from plinko-master-8100bets.json:

serverSeed  = b22261c6dc661d17db31417fb4a2dd1e58eb351ae7d8c77c6f51a2cd81dc84b9
clientSeed  = 9sysyk9uhCw09FzD
nonce       = 0
rows        = 16
risk        = high

cursor	HMAC[:8]	uint32	% 2	direction	slot
0	`a9c2f13f`	2,848,125,247	1	right	1
1	`14895bdb`	344,546,267	1	right	2
2	`4739337b`	1,194,931,067	1	right	3
3	`d74021d8`	3,611,304,408	0	left	3
4	`54078d16`	1,409,781,014	0	left	3
5	`6074bdba`	1,618,263,482	0	left	3
6	`09ba0b81`	163,187,585	1	right	4
7	`a0b6ea00`	2,696,342,016	0	left	4
8	`ef0695f6`	4,010,186,230	0	left	4
9	`9a93d48e`	2,593,379,470	0	left	4
10	`3ff81328`	1,073,222,440	0	left	4
11	`0ea47ffb`	245,661,691	1	right	5
12	`869a92ab`	2,258,277,035	1	right	6
13	`87a5194b`	2,275,744,075	1	right	7
14	`fab89728`	4,206,401,320	0	left	7
15	`32fcaf56`	855,420,758	0	left	7

Parity verified: Bet #71596330 — final_slot = 7 matches HMAC-SHA256 recomputation exactly. Multiplier (16r/high, slot 7): 0.20186622×. Payout: 0.01 × 0.20186622 = 0.0020186622.

Live Game

slot = 7

Verifier

slot = 7

Technical Evidence & Verification5 sections

2.8Evidence Coverage Summary

Verification Area	Coverage	Result
Algorithm implementation (Step 5)	8,100/8,100 bets	Pass
Key encoding (hex vs UTF-8)	Confirmed via recomputation	Pass
Modulo bias analysis	Mathematical proof: 2^32 % 2 = 0	Pass
External entropy non-participation (Step 5)	8,100/8,100 reproduced from disclosed inputs alone	Pass
Simulation chi-squared (Step 19)	0/27 configs fail at α=0.01	Pass
Serial independence (Step 19)	0/27 configs fail (lag-1 + runs test)	Pass

2.9Code References

File	Purpose
`src/rng.ts`	HMAC-SHA256 implementation (computeSlot, computeSlotFromBuffer)
`src/simulate.ts`	Monte Carlo simulation (27M rounds, two-pass)
`src/stats.ts`	Chi-squared, lag-1 autocorrelation, Wald-Wolfowitz runs test
`tests/steps/determinism.ts`	Steps 5–6: Slot recomputation and client seed influence
`tests/steps/simulation.ts`	Steps 19–20: Simulation integrity verification

2.10Verified Invariants

Invariant	Result
HMAC-SHA256 output matches live game for all 8,100 bets	Pass
Key is hex-decoded (not UTF-8) — wrong encoding produces wrong slots	Pass
int % 2 has zero modulo bias (2^32 exactly divisible by 2)	Pass
No external entropy sources required for slot computation	Pass
Slot distribution matches binomial B(rows, 0.5) for all 27 configs (1M rounds each)	Pass
Lag-1 autocorrelation near zero for all 27 configs	Pass
Runs test p > 0.01 for all 27 configs	Pass
Per-config simulated RTP converges to 99.9% theoretical	Pass
Client seed change produces different slot in 84.2% of bets (6,819/8,100)	Pass

2.11Datasets Used

Simulation: outputs/simulation-results.json — 27M rounds across 27 configs

Primary dataset: data/plinko-master-8100bets.json — 8,100 live bets for slot recomputation verification

Simulation output: outputs/simulation-results.json — Pass 1 (27M rounds, per-config chi-squared and serial tests) + Pass 2 (162 casino seeds × 10K nonces)

Determinism log: outputs/determinism-log.json — per-bet slot verification log (8,100 entries)

2.12Reproduction Instructions

Clone the repository, install dependencies, and run the simulation and verification:

reproduce-s2.sh· 4 linesVerified

git clone https://github.com/ProvablyFair-org/duel-plinko.git
cd duel-plinko && npm install
npm run simulate  # 27M-round simulation (~6 min)
npm run verify    # Steps 5, 19 cover S2

S2-related steps:

[PASS] Step 5  — Slot Recomputation (RNG determinism)
[PASS] Step 19 — Simulation Results — Pass 1 Integrity

Verifier Parity

Does the live game actually follow its own rules?

This section validates that the independent verifier produces the exact same slot position as the live game for every single bet. It also confirms the payout math and that every multiplier matches Duel's published tables. Any mismatch would invalidate the fairness guarantee.

Live ↔︎ Verifier Parity

8,100 / 8,100bets matched

🔍What We Verified

Every bet independently recomputed from seeds — full slot position verified, not just the payout
Payout correctness: win_amount = bet × multiplier, exact to 8 decimal places for all 8,100 bets
Multiplier table produces the correct value for all 27 row/risk configurations
Bet amount is not an input to the RNG — slot position depends only on seeds, nonce, and row count
All four capture phases recomputed identically (config coverage, stress test, elevated stake, client seed variation)

👤What This Means for You

The verifier isn’t a simulation — it produces the exact same slot as the live game
Every bet you play can be independently recomputed by anyone
No hidden logic alters outcomes based on how much you bet or how you play
The game engine in production matches the published algorithm exactly

8,100Live Bets Tested

100%Parity Rate

$0.01 & $10Bet Sizes Tested

0Mismatches

Test	Status	Finding
Slot recomputation	Pass	8,100/8,100 exact match — slot position verified for every bet
Payout correctness	Pass	All 8,100 bets: win_amount = bet × multiplier, exact to 8 decimal places
Multiplier table integrity	Pass	All observed multipliers match the published table for all 27 configurations
Bet-size independence	Pass	Bet amount is absent from the RNG input — slot position depends only on seeds, nonce, and row count
Config completeness	Pass	All 27 row/risk configurations (8–16 rows × low/medium/high) covered in live data
Multi-phase coverage	Pass	4 structured phases: config coverage (A), stress test (B), elevated stake (C), client seed variation (D)

✓ Live game and verifier fully aligned

All 8,100 bets matched the independent verifier exactly — slot positions verified across all four capture phases. Payout math correct. Multiplier table confirmed across all 27 configurations.

How It Works — Verifier Parity8 sections

3.1Why Parity Matters

If the verifier produces results that differ from the live game, players cannot trust the verification — the entire provably fair system becomes meaningless. 100% parity is required because even a single discrepancy would indicate either a bug in the verification logic, manipulation in the live game, or inconsistent RNG implementation. Players must be able to take the revealed seeds after gameplay, input them into the independent verifier, and receive the exact same slot position they experienced during live play.

3.2Four-Phase Collection Design

Data was collected across four structured phases, each designed to test a specific fairness property. The phases are complementary — together they cover configuration breadth, statistical depth, bet-size invariance, and client seed verification.

Phase	Bets	Config	Bet Amount	Purpose
A — Configuration coverage	5,400	All 27 configs	$0.01	Verify every config behaves correctly
B — High-variance sampling	2,000	16r/high	$0.01	Deep binomial distribution test on highest-variance config
C — Code-path equivalence	200	16r/high	$10.00	Confirm bet amount is not in the RNG
D — Client seed verification	500	10 configs	$0.01	Confirm client seed is genuinely used in HMAC computation

Total: 8,100 bets across 162 epochs. Total wagered: $2,079.00 ($54.00 Phase A + $20.00 Phase B + $2,000.00 Phase C + $5.00 Phase D).

3.3Slot Recomputation (Step 5)

For every bet belonging to an epoch with a revealed server seed, the verifier independently computed the slot using computeSlot(serverSeed, clientSeed, nonce, rows) and compared it to the server-reported final_slot. The computation uses HMAC-SHA256 with the hex-decoded server seed as key and clientSeed:nonce:cursor as message for each row.

tests/steps/determinism.ts· Step 5: EC-6, EC-7Verified

// Step 5: Slot Recomputation
for (const [hash, epochBets] of byHash) {
  const seedEntry = revealedMap.get(hash);
  if (!seedEntry) { skipped += epochBets.length; continue; }
  const serverSeed = seedEntry.seed.serverSeed!;
  for (const bet of epochBets) {
    const { client_seed, nonce, final_slot } = bet.response;
    const { rows } = bet.request;
    const computed = computeSlot(serverSeed, client_seed, nonce, rows);
    if (computed !== final_slot) {
      failures.push(`bet ${bet.response.id}: computed=${computed} actual=${final_slot}`);
    }
    checked++;
  }
}

Result: 8,100/8,100 bets verified. 0 skipped. Zero mismatches. Every computed slot matches final_slot in the dataset.

3.4Payout Math (Step 7)

For each of the 8,100 bets, the verifier computed amount_currency × payout_multiplier and compared the result to the server-reported win_amount. The tolerance is 1×10⁻⁸ — any difference larger than this would indicate the server is applying hidden fees, rounding errors, or incorrect multipliers.

tests/steps/payouts.ts· Step 7: EC-11, EC-18Verified

// Step 7: Payout Math
const TOLERANCE = 1e-8;
for (const bet of bets) {
  const amount = parseFloat(bet.response.amount_currency);
  const mult = parseFloat(bet.response.payout_multiplier);
  const win = parseFloat(bet.response.win_amount);
  const expected = amount * mult;
  const diff = Math.abs(win - expected);
  if (diff > TOLERANCE) {
    failures.push(`bet ${bet.response.id}: win=${win} expected=${expected} diff=${diff.toExponential(2)}`);
  }
}

Result: All 8,100 bets: win_amount = amount_currency × payout_multiplier within tolerance 1e-8. Zero mismatches. Payout math is exact.

3.5Multiplier Table Provenance (Step 8)

For each of the 8,100 bets, the observed payout_multiplier was compared against both multiplier sources in plinkoConfig.json: the compact payout_tables and the per-bracket scaling_edge[0].multipliers. Both sources agree within 1.49×10⁻⁶ (floating-point rounding). The server uses scaling_edge[0].multipliers as the reference table — confirmed by 8,100/8,100 exact matches.

Metric	Count
Total bets checked	8,100
Matching scaling_edge[0]	8,100
Matching payout_tables	8,100
Matching neither	0

Result: Reference table: scaling_edge[0].multipliers. Every live payout multiplier matches plinkoConfig.json. Theoretical RTP from this table: 99.900% across all 27 configurations.

3.6Multiplier Symmetry & Floor (Step 13)

For all 27 configurations, the multiplier table was verified to be symmetric: multiplier[k] = multiplier[rows − k] for every slot k. This follows from the symmetric binomial distribution — slots k and (rows − k) have identical probabilities, so their multipliers must match. Additionally, the 16r/high configuration was verified to have a 0.2× floor at center slots (slots 6–10).

tests/steps/dataset.ts· Step 13: EC-10, EC-12, EC-13, EC-14Verified

// Step 13: Multiplier Table + Symmetry
for (const { rows, risk } of cfg.allConfigs()) {
  // EC-14: Symmetry check
  for (let k = 0; k <= rows; k++) {
    const mk = cfg.scalingEdgeMultiplier(rows, risk as RiskLevel, k);
    const mk_mirror = cfg.scalingEdgeMultiplier(rows, risk as RiskLevel, rows - k);
    if (Math.abs(mk - mk_mirror) > TOLERANCE) {
      failures.push(`EC-14: ${rows}r/${risk} slot ${k} vs ${rows - k}: ${mk} ≠ ${mk_mirror}`);
    }
  }
  // EC-13: 16r/high center floor
  if (rows === 16 && risk === 'high') {
    const center = cfg.scalingEdgeMultiplier(16, 'high', 8);
    if (center < 0.2) {
      failures.push(`EC-13: 16r/high center slot multiplier=${center} < 0.2`);
    }
  }
}

Result: All 27 configurations: multipliers symmetric, all positive, 16r/high center floor = 0.2×. Zero violations.

3.7Phase C — Bet-Size Equivalence (Step 9)

Phase C placed 200 bets at $10 on the same 16r/high configuration as Phase B's $0.01 bets. All 200 slots were recomputed correctly from revealed seeds. All 200 payout multipliers matched the same scaling_edge[0].multipliers table as Phase B. Equivalence is proven deterministically — 200/200 exact slot and multiplier matches. No distributional test is applied: at n=200, statistical comparisons have near-zero power and add nothing over the deterministic proof.

tests/steps/payouts.ts· Step 9: EC-15, EC-16, EC-17Verified

// Step 9: Phase C Code-Path Equivalence
for (const bet of phaseC) {
  const seedEntry = revealedMap.get(bet.response.server_seed_hashed);
  if (!seedEntry) { slotSkipped++; continue; }
  const computed = computeSlot(
    seedEntry.seed.serverSeed!,
    bet.response.client_seed,
    bet.response.nonce,
    bet.request.rows
  );
  if (computed !== bet.response.final_slot) {
    failures.push(`bet ${bet.response.id} slot mismatch`);
  }
}

Result: Phase C: 200/200 slots recomputed correctly at $10. All multipliers match Phase B table. Bet amount is not an input to the RNG.

Variance context: Phase C empirical RTP was 74.993% in the 200-bet sample. This is within expected range — the 16r/high configuration has extreme per-bet variance due to the 1009× jackpot at 1/65,536 probability. At N=200, the 95% confidence interval spans roughly 8% to 192% RTP.

3.8Worked Example — Full Parity Verification

Real bet from Phase B — Bet ID 71644262, 16 rows, high risk, nonce 5. Verified from plinko-master-8100bets.json:

serverSeed  = 7b8c38d84c6d187c472c4e3f1e668222d64cfca099ca6127ad0e1cd198faf5b6
clientSeed  = S8Wfb9k9Uyie6M9D
nonce       = 5
rows        = 16
risk        = high

Step	Process	Output
1	HMAC-SHA256(hexDecode(serverSeed), "S8Wfb9k9Uyie6M9D:5:0") through cursor 15	16 uint32 values
2	Each uint32 % 2 → left/right bounce	9 right bounces
3	final_slot = 9	Matches live game ✅
4	Multiplier lookup: 16r/high slot 9	0.20186622×
5	Payout: 0.01 × 0.20186622	0.0020186622 ✅

HMAC-SHA256 recomputationVERIFIED

// computeSlot("7b8c38d8...", "S8Wfb9k9Uyie6M9D", 5, 16)
// 16 HMAC calls → slot = 9
//
// Multiplier lookup: scaling_edge[0].multipliers["16"]["high"][9]
// = 0.20186622
//
// Payout: 0.01 × 0.20186622 = 0.0020186622
// Live win_amount: 0.0020186622 ✅

Parity verified: Bet #71644262 — slot, multiplier, and payout all match exactly between live game and independent verifier.

Live Game

slot = 9, payout = 0.0020186622

Verifier

slot = 9, payout = 0.0020186622

Technical Evidence & Verification5 sections

3.9Evidence Coverage Summary

Verification Area	Coverage	Result
Slot recomputation	8,100 / 8,100 bets — full slot position verified	Pass
Payout math	8,100 / 8,100 bets (exact to 8 decimal places)	Pass
Multiplier table integrity	All 27 configs — observed multipliers match published table	Pass
Multiplier symmetry	27/27 configs — slot k = slot (rows − k)	Pass
Phase C slot recomputation	200 / 200 at $10	Pass
Phase C multiplier match	200 / 200 bets — identical to $0.01 table	Pass
Config completeness	All 27 configs (8–16 × low/medium/high) covered in live data	Pass
Multi-phase coverage	4 phases: A (5,400) + B (2,000) + C (200) + D (500)	Pass

3.10Code References

File	Purpose
`tests/steps/determinism.ts`	Step 5: Slot recomputation
`tests/steps/payouts.ts`	Steps 7–9: Payout math, multiplier provenance, Phase C equivalence
`tests/steps/dataset.ts`	Steps 10–16: Config completeness, epoch size, multiplier symmetry, scaling edge
`src/rng.ts`	HMAC-SHA256 slot computation
`src/config.ts`	PlinkoConfig multiplier lookup and RTP calculation

3.11Datasets Used

Primary dataset: data/plinko-master-8100bets.json — 8,100 live bets across 162 epochs

Game config: plinkoConfig.json — 27 multiplier tables, 191 bet-size brackets per config; captured from https://duel.com/api/v2/games/plinko/config, SHA-256 78f0a39201a8c24fd1577143732e004f77e27d4d36efeedc6b3f7b93b2078fed

Verification output: outputs/verification-results.json — Steps 5, 7–9, 11, 13

3.12Verified Invariants

Invariant	Result
Computed slot matches live final_slot for all 8,100 bets	Pass
win_amount = bet × multiplier, exact to 8 decimal places for all 8,100 bets	Pass
Every payout_multiplier matches the published table for all 27 configurations	Pass
Multiplier tables are symmetric for all 27 configs: slot k = slot (rows − k)	Pass
Phase C ($10) produces identical slot positions to $0.01 bets	Pass
Phase C multipliers match Phase B table (same config, different bet size)	Pass
No hidden inputs beyond (serverSeed, clientSeed, nonce, rows)	Pass
All 27 row/risk configurations (8–16 × low/medium/high) present in live data	Pass
Phase D: 500/500 slots verified across 10 custom client seeds	Pass

3.13Reproduction Instructions

reproduce-s3.sh· 4 linesVerified

git clone https://github.com/ProvablyFair-org/duel-plinko.git
cd duel-plinko && npm install
npm run verify
# Expected output: Steps 5, 7–9, 11, 13 all PASS

S3-related steps:

[PASS] Step 5  — Slot Recomputation (RNG determinism)
[PASS] Step 7  — Payout Math
[PASS] Step 8  — Multiplier Table Provenance
[PASS] Step 9  — Phase C Code-Path Equivalence
[PASS] Step 11 — Config Completeness
[PASS] Step 13 — Multiplier Table + Symmetry

RTP & Payout Logic

Is the house edge what the casino claims?

This section mathematically verifies that the 0.1% house edge is exactly what's advertised across all 27 configurations. The key test is anti-circularity: we confirm the RTP by applying independently-computed binomial probabilities to the published payout table — the derivation uses no operator-supplied RTP figure. We then confirm it against 27 million simulated rounds and test whether the casino pre-selected favourable seeds.

Return to Player Verification

99.9%theoretical RTP

🔍What We Verified

House edge is exactly 0.1% at bracket 0 — confirmed from the published configuration and independently derived
RTP confirmed against the published payout table: independent binomial P(slot) × multiplier = 99.9% for every configuration
27M-round simulation converges on theoretical RTP (mean 99.917%)
Cherry-pick detection: 162 casino seeds tested — no evidence of seed pre-selection
Bet amount does not influence slot position — confirmed at $0.01 and $10

👤What This Means for You

Within bracket 0, the game-engine house edge is a flat 0.1%
The RTP is confirmed using independently-computed probabilities applied to the published payout table — it doesn't rely on the casino's own RTP claim
The casino's seeds show no evidence of being chosen to produce favourable early outcomes
Your bet amount doesn't affect where the ball lands
Higher bet amounts face a scaling house edge — see S4.7 for full analysis

99.9%

Theoretical RTP (all 27 configs)

99.917%

Simulated (27M rounds)

0.1%

House Edge

27/27

Configs pass

Test	Status	Finding
Anti-circularity	Pass	Binomial P(slot) × multiplier = 99.9% for all 27 configs — binomial P from B(rows, 0.5) computed independently; multipliers are the published table
House edge audit	Info	0.1% house edge at bracket 0, scaling to 2.0% at extreme bet sizes. Thresholds vary by config — see S4.7
Simulated RTP (Pass 1)	Pass	27M rounds, avg RTP = 99.917%, 0/27 chi-squared failures, 0/27 serial independence failures
Cherry-pick detection (Pass 2)	Pass	162 casino seeds tested — no evidence of seed pre-selection
Bet-size invariance	Pass	Bet amount is not an input to the RNG — same slot distribution at $0.01 and $10. Tested in Phase C (200/200)
Multiplier formula	Pass	Binomial B(rows, 0.5) × scaling_edge[0].multipliers = 99.9% independently verified for all 27 configs
Config completeness	Pass	All 27 row/risk configurations covered
Zero Edge audit	Pass	Zero Edge bets use identical multiplier tables — no separate payout structure

✓ RTP Behaves as Advertised

The 99.9% RTP is proven mathematically from binomial probabilities — P(slot) × multiplier = 0.999 for all 27 configurations, using independently-computed probabilities and the published payout table — an exact identity, not a statistical estimate. 27M simulated rounds and cherry-pick detection confirm no anomalies.

How It Works — RTP & Payout Logic9 sections

4.1Anti-Circularity Proof (Step 17)

The anti-circularity proof establishes the 99.9% RTP by applying independently-computed binomial probabilities to the published payout table, using no operator-supplied RTP figure. This is what separates a mathematical proof from a statistical estimate. The proof has two components — each derived independently:

Component	Formula	Source
Slot probability	P(slot=k) = C(rows,k) × 0.5^rows	Binomial distribution — pure math, not from casino
Multiplier	scaling_edge[0].multipliers[rows][risk][k]	Casino-supplied — observed from plinkoConfig.json
RTP computation	Σ P(k) × multiplier(k) for k = 0 to rows	Independent probability × observed multiplier
Result	= 0.999 for all 27 configurations	Exact identity from independent probabilities × published table — not a statistical estimate

Rows	Risk	P(slot=0)	Multiplier(slot=0)	Σ P×M	RTP
8	low	0.00391	5.65180×	0.99900	99.9%
8	high	0.00391	29.24517×	0.99900	99.9%
16	low	0.00002	16.15×	0.99900	99.9%
16	high	0.00002	1009.33×	0.99900	99.9%

Result: All 351 config×slot probabilities exactly equal independent binomial. 27/27 RTP cross-checks match. Theoretical RTP proof is non-circular.

Anti-Circularity Verification:

tests/steps/anti-circularity.ts· Step 17: EC-33Verified

// Step 17: Probability Independence — Anti-Circularity
for (const { rows, risk } of cfg.allConfigs()) {
  const configProbs = cfg.probabilities(rows, risk);
  const slotCount = rows + 1;
  for (let k = 0; k < slotCount; k++) {
    const independent = binomProb(rows, k);
    const fromConfig = configProbs[k];
    if (fromConfig !== independent) {
      failures.push(
        `${rows}r/${risk} slot ${k}: config=${fromConfig} independent=${independent}`
      );
    }
  }
}

Why this proof is non-circular: P(slot) comes from the binomial distribution B(rows, 0.5) — a mathematical property of fair coin flips, not from casino data. The multiplier table is the only casino-sourced input. When we multiply independent probabilities by observed multipliers and get exactly 0.999 for every configuration, the RTP is proven — not estimated.

4.2House Edge Audit (Step 10, Step 16)

The game-engine house edge at bracket 0 is 0.1% (RTP = 99.9%), implemented by the multiplier table values themselves — the payout_multiplier returned for each (rows, risk, slot) combination is drawn from a table constructed to yield 99.9% RTP. This is the audit's primary RTP finding and is confirmed by the anti-circularity proof in Step 17.

The captured dataset also exposes an effective_edge field on every bet response. Per the operator's published mechanism, this field represents the player's net edge after Zero Edge rakeback is applied. Bets under $1,000 placed while the account is within its $50,000 daily Zero Edge allowance are eligible for a 0.1% instant rakeback, applied asynchronously after settlement via an operator-side rewards queue. The field updates from 0.1 to 0 once the queue processes the bet.

At capture time, 537 of 8,100 bets (6.6%) carried effective_edge: 0 and 7,563 carried 0.1. A sample re-fetch of bets initially captured as 0.1 showed the field had since been updated to 0 — consistent with the operator's description of the rewards mechanism as asynchronous post-settlement. We did not re-fetch every bet, and the audit's scope does not include verifying the rewards transaction layer itself — we audit the game-engine RTP from the multiplier tables, which both effective_edge values draw from identically.

Step 10 tested whether the two effective_edge groups receive different multipliers — they do not. Across all 8,100 bets, a Zero Edge-tagged bet and a 0.1%-tagged bet on the same (rows, risk, slot) receive the exact same payout_multiplier. All test bets settled within the operator's $50,000 daily Zero Edge allowance; post-cap behaviour was not empirically exercised by this audit.

tests/steps/dataset.ts· Step 10: EC-23Verified

// Step 10: Zero Edge Audit
const edgeGroups = new Map<number, typeof bets>();
for (const bet of bets) {
  const e = bet.response.effective_edge;
  if (!edgeGroups.has(e)) edgeGroups.set(e, []);
  edgeGroups.get(e)!.push(bet);
}
// Both edge groups use identical multiplier tables — 0 mismatches

Result: Within the empirical scope (8,100 captured bets, all settling within the $50,000 daily Zero Edge allowance): the two effective_edge groups resolve through identical multiplier tables, with zero mismatches. The game-engine 0.1% house edge is confirmed by the multiplier table values themselves (verified by Step 17 anti-circularity). The rewards transaction layer that brings net edge to 0% via rakeback is operator settlement-side and outside this audit's scope.

Scaling house edge: plinkoConfig.json contains 191 bet-size brackets per configuration. House edge scales from 0.1% at bracket 0 upward at larger bet sizes, applied per-bet via bracket lookup at multiplier time. All test bets ($0.01 and $10) fall within bracket 0 — see subsection 4.7 for full bracket analysis.

4.3Full RTP Table — All 27 Configurations

All 27 configurations produce the same theoretical RTP of 99.900% at bracket 0. The simulated RTP varies per config due to sampling variance, particularly for high-risk configurations where jackpot multipliers (up to 1009×) create large per-bet variance.

Config	Theoretical RTP	Simulated RTP	Deviation
8r/low	99.900%	99.894%	−0.006%
8r/medium	99.900%	99.677%	−0.223%
8r/high	99.900%	99.997%	+0.097%
9r/low	99.900%	99.900%	−0.000%
9r/medium	99.900%	99.994%	+0.094%
9r/high	99.900%	99.566%	−0.334%
10r/low	99.900%	99.902%	+0.002%
10r/medium	99.900%	99.815%	−0.085%
10r/high	99.900%	99.460%	−0.440%
11r/low	99.900%	99.876%	−0.024%
11r/medium	99.900%	99.921%	+0.021%
11r/high	99.900%	100.093%	+0.193%
12r/low	99.900%	99.916%	+0.016%
12r/medium	99.900%	99.895%	−0.005%
12r/high	99.900%	99.852%	−0.048%
13r/low	99.900%	99.912%	+0.012%
13r/medium	99.900%	99.748%	−0.152%
13r/high	99.900%	100.361%	+0.461%
14r/low	99.900%	99.872%	−0.028%
14r/medium	99.900%	99.945%	+0.045%
14r/high	99.900%	99.908%	+0.008%
15r/low	99.900%	99.917%	+0.017%
15r/medium	99.900%	99.923%	+0.023%
15r/high	99.900%	100.003%	+0.103%
16r/low	99.900%	99.881%	−0.019%
16r/medium	99.900%	99.786%	−0.114%
16r/high	99.900%	100.736%	+0.836%

Result: Mean simulated RTP: 99.917%. All 27 configurations pass chi-squared and serial independence. No anomalies detected.

Variance note: High-risk configs (especially 16r/high with its 1009× jackpot at 1/65,536 probability) show larger per-config deviations because jackpot hits dominate the RTP calculation at 1M rounds per config.

4.4Simulation Pass 1 — Fresh Seeds (Step 19)

Section 4.1 proves RTP = 99.9% mathematically. But does the game engine actually produce that in practice? To find out, we simulated 27 million rounds locally using the same RNG algorithm and independent auditor-generated seeds. If the simulated payouts converge on 99.9%, the implementation matches the math.

Chi-squared test: Compares observed slot frequencies to expected binomial frequencies. 0/27 fail at uncorrected α=0.01. 0/27 fail at Bonferroni α/27 ≈ 0.00037.

Serial independence: Lag-1 autocorrelation measures correlation between consecutive slots. Runs test checks for non-random run structure. 0/27 configs fail either test.

RTP convergence: Avg simulated RTP = 99.917% vs 99.900% theoretical. Deviation of +0.017% is within expected sampling variance.

src/simulate.ts· Pass 1 summaryVerified

// Pass 1 — Fresh random seeds
// 1,000,000 rounds × 27 configs = 27,000,000 total
// Per-config pinned seeds for reproducibility (S7)
const { server: simServer, client: simClient } = SIM_SEEDS[ci];
for (let nonce = 0; nonce < ROUNDS_PER_CONFIG; nonce++) {
  const slot = computeSlot(simServer, simClient, nonce, rows);
  slotCounts[slot]++;
  totalPayout += cfg.scalingEdgeMultiplier(rows, risk, slot);
}

Result: 27M rounds. Avg simulated RTP: 99.917%. 0/27 chi-squared failures. 0/27 serial independence failures. Slot distribution is consistent with binomial expectations.

What is a Monte Carlo simulation? Instead of proving fairness with algebra alone, we simulate millions of real game rounds. Each round computes a slot position from scratch using the same HMAC-SHA256 pipeline as the live game. We record payouts, then compare the aggregate return to the theoretical 99.9%. If they match, the math holds in practice — not just on paper.

4.5Cherry-Pick Detection — Pass 2 (Step 20)

Could the casino have chosen server seeds that produce worse outcomes for players? Pass 2 takes every server seed the casino actually used and simulates thousands of rounds to check whether any of them are statistically biased against players.

Test A — Overall RTP: Does any individual seed produce lower-than-expected RTP across all 10,000 nonces? A cherry-picked seed would show a statistically significant RTP deficit.

Test B — Early vs late window: Does any seed produce worse outcomes in the early nonces (where real players bet) compared to later nonces? A sophisticated cherry-pick could target only the first few hundred rounds.

Test	Result
Seeds tested	162
Seed × row combinations	242
Test A fails (p<0.01)	1 / 242 — binomial p = 0.912
Early-window statistical flags (Test B)	10 / 242 — binomial p = 0.773
Multi-window analysis	8 isolated-early, 2 multi-window — consistent with H₀

src/simulate.ts· Pass 2 cherry-pick detectionVerified

// Pass 2 — Casino seeds
for (const [seedHash, info] of seedEntries) {
  for (const rows of rowList) {
    for (let nonce = 0; nonce < NONCES_PER_SEED; nonce++) {
      const slot = computeSlotFromBuffer(keyBuffer, info.clientSeed, nonce, rows);
      fullCounts[slot]++;
      if (nonce < EPOCH_LENGTH) { earlyCounts[slot]++; }
      else { lateCounts[slot]++; }
    }
    // Cherry-picking signature: early deviates from binomial, late does not
    const cherryPickFlag = earlyTest.pValue < 0.05 && lateTest.pValue >= 0.05;
  }
}

Result: Pass 2 (artifact verdicts: Test A=PASS, Test B=PASS): 10 early-window statistical flags out of 242 combinations, within expected false-positive range. Binomial p = 0.773 — not significant. Multi-window analysis confirms distributional noiseing.

Why is this included? Cherry-pick detection is a standard part of our audit methodology, designed primarily for casinos where the default client seed is server-assigned (Conditional Pass origin) — meaning the casino generates the initial client seed on behalf of the player. In those cases, the casino knows both seeds before any bets are placed and could theoretically pre-select favourable server seeds. Duel.com generates the default client seed in the player's browser (Full Pass origin), and players can set their own custom client seed at any time. The server cannot know either value at commitment time. Cherry-picking is structurally impossible here. Pass 2 is included as a confirmatory check to provide empirical evidence alongside the structural guarantee.

4.6Bet-Size Invariance (Step 9)

Phase C placed 200 bets at $10 on 16r/high — the same configuration as Phase B's $0.01 bets. All 200 slots were recomputed correctly from revealed seeds using the same HMAC-SHA256 path. All 200 multipliers matched the same scaling_edge[0].multipliers table. Bet amount is not an input to the RNG and does not affect the slot distribution.

Metric	Phase B ($0.01)	Phase C ($10)
Bets	2,000	200
Config	16r/high	16r/high
Slots recomputed	2,000/2,000	200/200
Multiplier table	scaling_edge[0]	scaling_edge[0]
RNG path	HMAC-SHA256	HMAC-SHA256

Result: Equivalence proven deterministically. Same RNG, same multiplier table, same slot distribution regardless of bet amount.

4.7Progressive House Edge — Scaling Edge Analysis (Step 16)

plinkoConfig.json contains a scaling_edge structure with 191 bet-size brackets per configuration. As bet amounts increase, the game-engine house edge scales from 0.1% (bracket 0) up to 2.0% (bracket 190). Higher brackets apply lower multipliers — the slot distribution is unchanged, but the payout per slot decreases. For example, the 16r/high jackpot multiplier drops from 1009.33× at bracket 0 to 990.13× at the highest bracket. This is a static, disclosed structure embedded in the game configuration, not a dynamic adjustment.

The brackets describe the game-engine edge — the edge before rakeback. Per the operator's disclosed Zero Edge mechanism (see 4.2), the bracket tier is selected on the total bet amount, and rakeback rebates the edge to 0% net on the portion of a bet up to the lesser of a $1,000 per-bet cap or the account's remaining $50,000 daily Zero Edge allowance; any portion above that retains the bracket's game-engine edge. This audit verifies the game-engine multiplier tables; it does not verify the operator-side rewards layer that applies the rakeback, so the figures below should be read as game-engine edge, not guaranteed net edge.

How it works: The server selects the bracket based on amount_currency. Each bracket contains a complete multiplier table for all slots. Higher brackets reduce every multiplier proportionally, increasing the effective house edge.

Impact on players: A player betting $500 on 16r/high lands in a bracket above 0, carrying a higher game-engine house edge than the 0.1% at bracket 0. Per the operator's disclosed Zero Edge rakeback (see 4.2), that edge is rebated to 0% net on the portion of a bet up to the lesser of a $1,000 per-bet cap or the remaining daily allowance — so the bracket determines the game-engine edge, not necessarily the edge the player ultimately pays. The game UI does not prominently surface the bracket thresholds themselves — but when an entered bet size triggers a higher bracket, the multiplier shown on the game board updates to the scaled multiplier, so the payout displayed always reflects the bracket actually in effect for that bet. The audit did not test post-allowance behaviour or the rewards layer that applies the rakeback.

Audit scope: All test bets ($0.01 and $10) fall within bracket 0. The RTP figures in this audit apply to bracket 0 only.

Config	Bracket 0 Ceiling	Notes
8r/low	$46,898.81	Highest ceiling among 8-row configs
8r/high	$2,061.27
12r/medium	$8,809.34
16r/low	$99,038.25	Highest ceiling among 16-row configs
16r/medium	$6,731.19
16r/high	$335.95	Most restrictive — lowest ceiling across all 27 configs

Bet Range	House Edge	RTP	Jackpot Multiplier (slot 0)
$0 – $335.95	0.1%	99.9%	1009.33×
$335.95 – $662.00	0.1% – 0.2%	99.9% – 99.8%	1009.33× – 1008.32×
$662.00 – $1,493.44	0.2% – 0.5%	99.8% – 99.5%	1008.32× – 1004.28×
$1,493.44 – $1,500.99	0.5% – 1.0%	99.5% – 99.0%	1004.28× – 999.23×
$1,500.99 – $1,516.48	1.0% – 2.0%	99.0% – 98.0%	999.23× – 990.13×

Risk	Bracket 0 Ceiling	Bracket 190 Max Bet	Edge Range
Low	$99,038.25	$101,087.78	0.1% – 2.0%
Medium	$6,731.19	$13,901.54	0.1% – 2.0%
High	$335.95	$1,516.48	0.1% – 2.0%

Classification: Informational finding. The bracket structure is static and embedded in plinkoConfig.json. It is not evidence of manipulation — the multiplier tables are consistent with the declared algorithm. However, it materially affects effective RTP for higher-stakes players.

Key takeaway for players: The bracket structure sets the game-engine edge: 99.9% RTP applies at bet amounts within bracket 0, and higher-risk configurations have significantly lower bracket 0 ceilings — 16r/high reaches a higher bracket above ~$336. The operator discloses that Zero Edge rakeback rebates this to 0% net on the portion of a bet up to the lesser of a $1,000 per-bet cap or the remaining $50,000 daily Zero Edge allowance (see 4.2) — but this audit did not verify the rewards layer, and post-allowance behaviour was not tested. The multipliers displayed directly on the slot tiles update with your bet size and show the game-engine payout for that bet — the most reliable indicator of the bracket in effect. Low-risk configurations reach higher brackets far later: 16r/low stays in bracket 0 up to ~$99,000.

4.8Informational Items (Not Scored)

These items are reported for transparency but are not scored audit steps. They provide context on the empirical RTP observed during data collection.

Item	Value	Context
Phase A empirical RTP	99.303%	5,400 bets at $0.01 — within expected variance
Phase B empirical RTP	92.313%	2,000 bets at $0.01 (16r/high) — high jackpot variance
Phase C empirical RTP	74.993%	200 bets at $10 (16r/high) — expected at N=200
Phase D empirical RTP	104.636%	500 bets at $0.01 — within expected variance

4.9Worked Example — Payout Verification

Real bet from Phase A — Bet ID 71602647, 12 rows, medium risk, nonce 3. Verified from plinko-master-8100bets.json:

serverSeed  = a7775148ccf4ba93bbaba4605c9b055bf6d0971ca1328777d69407fa52584ff6
clientSeed  = OFsDIaHWohCPjh0t
nonce       = 3
rows        = 12
risk        = medium

Step 1 — Slot computation: computeSlot(serverSeed, clientSeed, 3, 12) → 12 HMAC calls → final_slot = 8

Step 2 — Multiplier lookup: scaling_edge[0].multipliers["12"]["medium"][8] = 1.11012046

Step 3 — Payout: 0.01 × 1.11012046 = 0.0111012046

Step	Process	Output
1	HMAC-SHA256 × 12 rows	slot = 8 ✅
2	Multiplier: 12r/medium slot 8	1.11012046×
3	RTP check: P(slot=8) × 1.11012046	Contributes to 99.9%
4	Payout: 0.01 × 1.11012046	0.0111012046 ✅

RTP proof for this bet's configVERIFIED

// 12 rows, medium risk — anti-circularity proof
// P(slot=k) = C(12,k) × 0.5^12 for k = 0..12
//
// Σ binomProb(12, k) × scalingEdgeMultiplier(12, "medium", k)
// = 0.999000 (99.9%)
//
// This is a mathematical identity, not a measurement.
// Casino supplies multipliers; probabilities are independently computed.

Parity verified: Bet #71602647 — slot, multiplier, and payout all match. RTP for 12r/medium = 99.900% proven from independent binomial probabilities.

Live Game

slot = 8, payout = 0.0111012046

Verifier

slot = 8, payout = 0.0111012046

Technical Evidence & Verification5 sections

4.10Evidence Coverage Summary

Verification Area	Coverage	Result
Anti-circularity (Step 17)	351 probabilities, 27/27 RTP cross-checks	Pass
Zero Edge audit (Step 10)	Both edge groups, 0 mismatches	Pass
Scaling edge (Step 16)	All 27 configs, bracket 0 confirmed	Pass
Simulation Pass 1 (Step 19)	27M rounds, 0/27 chi-squared, 0/27 serial	Pass
Simulation Pass 2 (Step 20)	162 seeds × 10K nonces, 10 flags (p=0.773)	Pass
Bet-size invariance (Step 9)	200/200 Phase C at $10	Pass

4.11Code References

File	Purpose
`tests/steps/anti-circularity.ts`	Step 17: Probability independence and RTP cross-check
`tests/steps/dataset.ts`	Steps 10, 16: Zero Edge audit, scaling edge analysis
`tests/steps/simulation.ts`	Steps 19–20: Simulation integrity and cherry-pick detection
`src/simulate.ts`	Monte Carlo simulation (27M rounds, two-pass)
`src/stats.ts`	binomProb, chiSquaredTest, lag1Autocorrelation, runsTest
`src/config.ts`	theoreticalRTP, scalingEdgeMultiplier, payoutTableMultiplier

4.12Datasets Used

Simulation output: outputs/simulation-results.json — Pass 1 (27M rounds) + Pass 2 (162 seeds × 10K nonces)

Primary dataset: data/plinko-master-8100bets.json — Phase C bet-size invariance verification

4.13Verified Invariants

Invariant	Result
P(slot) × multiplier = 0.999 for all 27 configs (non-circular)	Pass
HOUSE_EDGE = 0.001 confirmed from plinkoConfig.json for all 27 configs	Pass
Binomial B(rows, 0.5) probabilities match plinkoConfig.json for all 351 config×slot pairs	Pass
Simulated RTP average = 99.917% across 27M rounds	Pass
0/27 configs reject at Bonferroni α/27	Pass
0 serial independence failures at Bonferroni-corrected threshold	Pass
No evidence of seed pre-selection across 162 casino seeds (Pass 2)	Pass
Phase C ($10) slot positions match Phase B ($0.01) algorithm	Pass
Bet amount absent from RNG input by construction	Pass
Zero Edge and standard bets use identical multiplier tables	Pass

4.14Reproduction Instructions

reproduce-s4.sh· 5 linesVerified

git clone https://github.com/ProvablyFair-org/duel-plinko.git
cd duel-plinko && npm install
npm run simulate  # 27M simulation + cherry-pick test (~6 min)
npm run verify    # Steps 9, 10, 16, 17, 19, 20 cover S4
cat outputs/simulation-results.json

S4-related steps:

[PASS] Step 9  — Phase C Code-Path Equivalence
[PASS] Step 10 — Zero Edge Audit
[PASS] Step 16 — Scaling Edge Analysis
[PASS] Step 17 — Probability Independence (Anti-Circularity)
[PASS] Step 19 — Simulation Results — Pass 1 Integrity
[PASS] Step 20 — Simulation Results — Pass 2 Cherry-Pick Test

Fairness Integrity Testing

Does the implementation maintain fairness under non-standard conditions?

Sections 1–4 prove the game is mathematically fair. Section 5 proves the implementation maintains integrity under non-standard conditions. We applied 15 standard fairness integrity tests covering nonce integrity, seed commitment, outcome determinism, cross-player isolation, and payout integrity. 14 tests passed and 1 is not applicable to this game type.

Fairness Integrity Testing

14pass·1N/A

🔍What We Verified

Nonce tampering — can the sequence be forced, replayed, or skipped?
Seed injection — can server or client seed fields be overridden via API?
Outcome replay — can a completed bet be replayed for duplicate payouts?
Cross-player isolation — can one player's seeds or outcomes affect another's?
Payout tampering — can multiplier or payout values be injected client-side?
Parameter limits — can invalid row counts or risk levels be submitted?

👤What This Means for You

Across the 15 tests we ran, no API path allowed outcomes to be altered, replayed, or injected — by player or casino
Once a bet is placed, the result cannot be changed or replayed
Each bet is cryptographically unique and isolated
Your results are independent of every other player
The server rejects malformed, out-of-range, and duplicate requests

Category Coverage

Nonce Integrity

4/4

Seed Commitment

5/5

Outcome Determinism

1/1

Player Isolation

2/2

Payout Integrity

2/2

Test	Status	Finding
Nonce integrity	Pass	Sequential, server-controlled, no gaps or duplicates across 162 seed pairs
Seed commitment integrity	Pass	Locked at bet acceptance, unique per seed pair — 162/162 verified
Outcome determinism	Pass	Identical inputs produce identical outcomes — 8,100/8,100 confirmed
Round & player isolation	Pass	Per-user seeds, serial independence confirmed (0/27 fail in simulation)
Payout integrity	Pass	Parameter limits (rows 8–16, risk 1–3) enforced; client-injected payout fields ignored — server computes outcome from seeds only

✓ All Fairness Guarantees Verified

15 standard fairness integrity tests: 14 pass, 1 N/A (single-step game). All API probe tests completed.

How It Works — Fairness Integrity Testing2 sections

5.1Framework Overview

Testing follows the ProvablyFair.org Fairness Integrity Framework — a structured methodology derived from real, historically observed failures in provably fair systems. Five categories target specific fairness properties. Scope boundary: S5 tests whether fairness guarantees hold under non-standard API interaction. Platform-level implementation testing falls outside standard certification.

Category	Tests	What It Catches
Nonce Integrity	4	Sequence gaps, server-side nonce manipulation, session continuity
Seed Commitment	5	Mid-epoch seed changes, seed reuse, predictable seed generation
Outcome Determinism	2	Non-deterministic outputs, outcome replay
Player Isolation	2	Cross-round correlation, cross-user outcome dependence
Payout Integrity	2	Parameter enforcement, server-side computation verification

5.2Severity Framework & Hard Fail Criteria

Findings are classified by severity. Hard fail criteria — any one triggers a NOT PROVABLY FAIR verdict.

Severity	Meaning	Action
PASS	Test passed — no issue detected	None
N/A	Test not applicable to this game type	None
FLAG	Anomaly detected, documented for transparency	Disclosed
HARD FAIL	Fairness guarantee cannot be confirmed	Certification blocked until remediated

Condition	Consequence
Nonce gap or duplicate within epoch	Outcome sequence integrity broken
Server seed changed mid-epoch	Commit-reveal guarantee broken
Slot recomputation mismatch	Undisclosed inputs affecting outcomes
Client seed not used in HMAC	Player has no influence on outcomes

Hard fail criteria: Any single hard fail = NOT PROVABLY FAIR. The audit cannot proceed past a hard fail without operator remediation and re-verification.

15 tests·14 pass·1 N/A

Each bet increments the nonce sequentially with no gaps, repeats, or resets — preventing the server from skipping unfavourable outcomes

▸Evidence

Nonce progression is server-controlled — the client cannot inject, skip, or replay a nonce value via the API

▸Evidence

Submitting an invalid or out-of-sequence nonce does not produce a game outcome — the server rejects the request

▸Evidence

Nonce sequence continues correctly after disconnect/reconnect — no reset to zero mid-epoch

▸Evidence

Empty, null, or invalid client seeds are handled deterministically — the server enforces input requirements

▸Evidence

Once a bet is accepted, the seed pair is locked for the epoch — no mid-epoch mutation of server or client seed is possible

▸Evidence

Each epoch uses a unique server seed — no seed is reused across epochs or sessions

▸Evidence

No shared seed pool across users — each player's seeds are independently generated and isolated

▸Evidence

Server seeds show no correlation with timestamps, sequential patterns, or other predictable inputs

▸Evidence

Given identical inputs (serverSeed, clientSeed, nonce, rows), the game always produces the same slot — verified across all 8,100 live bets

▸Evidence

A completed bet cannot be replayed via the API to generate a duplicate payout

▸Evidence

RNG state is fully independent across rounds — no carry-over from one bet to the next. Each nonce produces a fresh HMAC-SHA256 computation

▸Evidence

One player's seeds, nonces, and outcomes cannot be observed or influenced by another player — complete cross-user isolation

▸Evidence

Game parameters cannot exceed defined limits — only valid row counts (8–16) and risk levels (low, medium, high) are accepted

▸Evidence

Multiplier and payout fields in the API request are ignored — the server computes all values from its own formula, not from client-supplied values

▸Evidence

Technical Evidence & Verification4 sections

5.3Coverage Summary

Test ID	Category	Verification Source	Status
FI-NONCE-001	Nonce	S1, Step 4 (data-driven)	Pass
FI-NONCE-002	Nonce	S1, Step 4 (data-driven)	Pass
FI-NONCE-003	Nonce	API probe	Pass
FI-NONCE-004	Nonce	S1, Step 4 (data-driven)	Pass
FI-SEED-001	Seed	API probe	Pass
FI-SEED-002	Seed	S1, Steps 3 & 6 (data-driven)	Pass
FI-SEED-003	Seed	S1, Step 1 (data-driven)	Pass
FI-SEED-004	Seed	API probe	Pass
FI-SEED-005	Seed	API probe	Pass
FI-OUTCOME-001	Determinism	S3, Step 5 (data-driven)	Pass
FI-OUTCOME-002	Determinism	Structural — single-step game	N/A
FI-ISO-001	Isolation	S2, Step 19 (simulation)	Pass
FI-ISO-002	Isolation	Structural — seed uniqueness	Pass
FI-PAYOUT-001	Payout	API probe	Pass
FI-PAYOUT-002	Payout	API probe	Pass

Method breakdown: 8 tests verified via verification suite steps and structural analysis, 6 tests verified via API probes, 1 test N/A (single-step game). No game-state integrity tests required — Plinko is a single-step auto-resolving game with no multi-step state.

5.4Additional Integrity Evidence (S1–S4)

Property	Source	Finding
162/162 seed hashes verified	S1, Step 1	Commit-reveal chain intact
166/166 next-seed promotions	S1, Step 2	Seed rotation chain intact
8,100/8,100 exact parity	S3, Step 5	No post-RNG conditional logic
Anti-circularity proven	S4, Step 17	0.1% house edge (bracket 0) via independent probabilities × published table
10 early-window flags, p=0.773 (within expected range)	S4, Step 20	No seed pre-selection bias
84.2% client seed influence	S1, Step 6	Player entropy is genuine

5.5Scope & Limitations

This certification covers the 15 standard fairness integrity tests listed above — the minimum required to verify that the provably fair implementation holds up under non-standard conditions. This is not a penetration test. It focuses specifically on the provably fair implementation — not the operator's broader platform security.

Standard scope: The integrity matrix is largely consistent across every game we audit — the core nonce, seed, determinism, and isolation checks are identical. A small number of tests are tailored to each game (e.g. parameter ranges and payout fields specific to Plinko's rows and risk levels). Additional private testing may be conducted as a paid add-on — results are shared with the operator under responsible disclosure.

No infrastructure testing: Server security, network-level protections, and operational controls are not tested. These fall under platform-level security, not game-level fairness.

Point-in-time: Results apply to the game configuration and codebase at the time of audit. Post-audit changes require re-certification.

5.6Reproduction Instructions

Data-driven tests (8 of 15): Fully reproducible from the open-source audit repo. These tests run against the captured dataset and produce deterministic results.

API probe tests (6 of 15): Live API probes against duel.com captured at audit time. Per-test evidence (requests, responses, server-assigned values, timing) is retained in our private adversarial-testing archive and summarised in the integrity test review document. The testing harness itself is kept private to avoid handing exploit primitives to players.

reproduce-s5-data.sh· 4 linesVerified

git clone https://github.com/ProvablyFair-org/duel-plinko.git
cd duel-plinko
npm install
npm run verify

Expected output (S5-related steps):

[PASS] Step 1  — Seed Hash Integrity       → FI-SEED-003
[PASS] Step 3  — Hash Consistency           → FI-SEED-002
[PASS] Step 4  — Nonce Audit                → FI-NONCE-001, 002, 004
[PASS] Step 5  — Slot Recomputation         → FI-OUTCOME-001
[PASS] Step 6  — Client Seed Influence      → FI-SEED-002
[PASS] Step 19 — Simulation Pass 1          → FI-ISO-001

API Probe Tests (completed):

fi-api-probes.sh

[PASS] FI-NONCE-003  — Invalid nonce handling      → 7/7 invalid nonces ignored
[PASS] FI-SEED-001   — Invalid client seed handling → 6/7 rejected (1 active-game blocked)
[PASS] FI-SEED-004   — Cross-user seed pool check  → 0/20 collisions across 2 accounts
[PASS] FI-SEED-005   — Seed timing analysis        → 10 distinct hashes, no time correlation
[PASS] FI-PAYOUT-001 — Invalid parameter handling  → 6/6 boundary violations rejected (HTTP 422)
[PASS] FI-PAYOUT-002 — Multiplier field handling   → 0 injections honoured

API probes: All 6 API probe tests completed. Per-test evidence — requests, server responses, HTTP status codes, server-assigned nonces and seed hashes — is retained in our private adversarial-testing archive and summarised in the integrity test review document. The testing harness itself is kept private to avoid publishing exploit primitives; per-test evidence is available to operators and regulators on request.

Player Verification

Can a player verify their own bets without trusting anyone?

Every Plinko outcome can be independently reproduced using publicly disclosed inputs. No hidden variables, no private backend data. If your calculated slot position matches the game result, the bet was provably fair. This section walks you through the process — and provides an independent verification tool built from the same code used in this audit.

Independent Result Verification

4 Stepsto verify any bet

🔍Key Principles

Every Plinko outcome can be independently reproduced
No hidden variables — no private backend data
If your computed slot matches the game result, the bet was provably fair
Most players can verify directly through the Duel.com fairness UI

👤What You Need

Server Seed — revealed after seed rotation (casino entropy)
Client Seed — your player-controlled seed
Nonce — the bet number in sequence (ensures uniqueness)
Row Count — the configuration you played (8–16)

Verification Walkthrough

Place a Plinko Bet — Choose your row count, risk level, and bet amount. The game generates a result using the provably fair algorithm.

Open the Fairness Modal — Open the Provably Fair modal on the game page. You'll see the active client seed, the hashed server seed, and your current nonce. Rotate the seed pair to unlock the revealed plaintext server seed for your previous bets.

Open Past Bet to Reveal Seed — Open Transactions and click a past Plinko round. The per-bet modal shows the revealed plaintext server seed alongside the bet ID, client seed, and nonce.

Recompute & Confirm — Click Verify in the per-bet modal to open the Provably Fair page with the seeds pre-populated. The page recomputes the slot position inline — if it matches your live game result, the bet was provably fair.

ProvablyFair.org Plinko Verifier

Independent verification tool — built from the audit codebase, not controlled by the casino

Open →

Duel.com Built-in Verifier

Casino's own verification page — convenient but casino-controlled

Open →

✓ Any Player Can Reproduce Plinko Results

Only disclosed inputs are used. Identical inputs always produce identical output.

Visual Walkthroughstep-by-step

6.1Step 1: Place a Plinko Bet

Select your row count and risk level, then place a bet. The ball drops through the peg board and lands in a slot. The server has already committed to the outcome before you clicked.

Duel.com Plinko — ball-drop game with row and risk selector. Slot outcome is locked before the ball drops.

6.2Step 2: Open the Fairness Modal

Open the Provably Fair modal on the game page. You'll see the active client seed, the hashed server seed (the casino's pre-commitment), and your current nonce. Below those, you can set the new client seed that will become active after rotation. Click 'Rotate seed' to retire the active seed pair and start a new one — this is what unlocks the revealed plaintext server seed for your previous bets in Step 3.

Provably Fair modal — active client seed, hashed server seed, nonce, customisable new client seed, next pair pre-commitment, and Rotate seed action.

6.3Step 3: Open Past Bet to Reveal Seed

Open Transactions and click a past Plinko round. The per-bet modal shows the revealed plaintext server seed alongside the bet ID, client seed, and nonce. The pre-committed hash from Step 2 must match SHA-256 of this revealed seed:

Server Seed (revealed) — plaintext value the casino committed to before your bet. Hash it to confirm it matches the pre-commitment.

Client Seed — your player-controlled entropy input.

Nonce — the sequential bet counter for this seed pair.

Per-bet transaction modal — revealed plaintext server seed, client seed, and nonce for the round.

6.4Step 4: Recompute & Confirm

Click Verify in the per-bet modal to open the Provably Fair page with the seeds pre-populated. The page recomputes the slot position from the disclosed inputs and renders the Game Result inline. If the recomputed slot matches your live game result, the bet was provably fair — the casino committed to the outcome before you bet, you contributed entropy via your client seed, and the result is mathematically reproducible by anyone.

Provably Fair page — seeds populated from the per-bet modal, recomputed slot rendered inline matching the live game result.

Manual Verification (Advanced)6 sections

6.6Why Manual Verification Matters

True provably fair verification means you don't trust any casino-provided tool. Manual verification allows you to run calculations on your own machine, eliminate any possibility of a tampered verifier, and understand exactly how results are generated.

6.7How the Algorithm Works (Plain English)

Before you play, the server locks the slot outcome using three ingredients:

The server's secret seed — committed by publishing its hash before you bet
Your client seed — generated by your browser, unknown to the server
The nonce — a counter that makes each bet unique

These three ingredients are combined with HMAC-SHA256 (a cryptographic function) to produce a bounce direction at each row of the peg board. The ball bounces left or right at each row — the final slot is the count of right-bounces. Because the server committed to its seed before you bet, and your client seed is generated in your browser, neither party can predict or influence the outcome.

6.8Casino Verifier vs ProvablyFair.org Verifier

Two verification tools are available. Both should produce identical results — if they don't, something has changed.

	Duel.com Verifier	ProvablyFair.org Verifier
Source	Casino-controlled	Independent (audit codebase)
Access	duel.com/fairness/verify	audit.provablyfair.org/casino/duel/tools/verify-bets
Trust model	Requires trusting the casino	Open-source, version-controlled
Monitoring	No change detection	Mismatches detected if casino changes logic

6.9JavaScript Verification Script

Copy and run this in Node.js to verify any Plinko bet:

verify-plinko.js· Standalone Node.js

const crypto = require('crypto');
function computeSlot(serverSeed, clientSeed, nonce, rows) {
  const key = Buffer.from(serverSeed, 'hex');
  let slot = 0;
  for (let cursor = 0; cursor < rows; cursor++) {
    const message = `${clientSeed}:${nonce}:${cursor}`;
    const hmac = crypto.createHmac('sha256', key).update(message).digest('hex');
    slot += parseInt(hmac.substring(0, 8), 16) % 2;
  }
  return slot;
}
function verifyHash(serverSeed, serverSeedHashed) {
  const hash = crypto
    .createHash('sha256')
    .update(Buffer.from(serverSeed, 'hex'))
    .digest('hex');
  return hash === serverSeedHashed;
}
// Replace with your values
const serverSeed = 'YOUR_SERVER_SEED';
const serverSeedHashed = 'YOUR_SERVER_SEED_HASH';
const clientSeed = 'YOUR_CLIENT_SEED';
const nonce = 0;
const rows = 16;
console.log('Hash check:', verifyHash(serverSeed, serverSeedHashed) ? 'PASS' : 'FAIL');
console.log('Computed slot:', computeSlot(serverSeed, clientSeed, nonce, rows));

6.10Python Verification Script

The same verification in Python (standard library only):

verify-plinko.py· Standalone Python

import hashlib, hmac
def compute_slot(server_seed, client_seed, nonce, rows):
    key = bytes.fromhex(server_seed)
    slot = 0
    for cursor in range(rows):
        message = f'{client_seed}:{nonce}:{cursor}'.encode()
        h = hmac.new(key, message, hashlib.sha256).hexdigest()
        slot += int(h[:8], 16) % 2
    return slot
def verify_hash(server_seed, server_seed_hashed):
    computed = hashlib.sha256(bytes.fromhex(server_seed)).hexdigest()
    return computed == server_seed_hashed
# Replace with your values
server_seed = 'YOUR_SERVER_SEED'
server_seed_hashed = 'YOUR_SERVER_SEED_HASH'
client_seed = 'YOUR_CLIENT_SEED'
nonce = 0
rows = 16
print('Hash check:', 'PASS' if verify_hash(server_seed, server_seed_hashed) else 'FAIL')
print('Computed slot:', compute_slot(server_seed, client_seed, nonce, rows))

6.11Evidence Screenshots

Evidence	Description
S08	Fairness page overview — "What is Provably Fair?" and "How it works" sections
S09	Fairness verification tool — Plinko selected, showing Rows and Risk Level inputs
S10	Fairness page Plinko source code — full validatePlinkoResult and generateHMAC_SHA256 implementation
S11	Client seed rotation response — server echoes client-submitted seed, does not assign

Reproducibility & Artifacts

Can anyone independently reproduce every finding in this audit?

This section consolidates the open-source repository, datasets, output artifacts, and reproducibility posture of the audit. Every finding, every statistic, every pass/fail result can be independently reproduced by anyone with a computer and an internet connection. The repository is the credential — not this report.

Open-Source Audit Repository

5bb2cd4commit audited

Repository Details

GitHub: ProvablyFair-org/duel-plinko
Commit: 5bb2cd4a0ea159af118c3000b74298a16b2f89ad
Game: Plinko (duel-plinko)
Public Verifier: audit.provablyfair.org/casino/duel/tools/verify-bets

Prerequisites

Node.js 18+
npm 8+
Git
TypeScript (installed via npm)

Repository Structure

duel-plinko/
├── src/
│   ├── rng.ts                  → HMAC-SHA256 slot computation
│   ├── config.ts               → PlinkoConfig multiplier lookup + RTP
│   ├── simulate.ts             → Monte Carlo — 1M rounds/config × 27
│   ├── stats.ts                → Chi-squared, autocorrelation, runs test
│   ├── loader.ts               → Dataset loader + SHA-256 hash guard
│   └── types.ts                → Type definitions
├── tests/
│   ├── verify.ts               → 20-step verification pipeline
│   ├── steps/
│   │   ├── commitment.ts       → Steps 1–4: Commit-reveal integrity
│   │   ├── determinism.ts      → Steps 5–6: Slot recomputation + client seed
│   │   ├── payouts.ts          → Steps 7–9: Payout math + Phase C
│   │   ├── dataset.ts          → Steps 10–16: Dataset integrity checks
│   │   ├── anti-circularity.ts → Step 17: Probability independence
│   │   ├── phase-d.ts          → Step 18: Client seed variation
│   │   ├── simulation.ts       → Steps 19–20: Simulation integrity
│   │   ├── statistical.ts      → Informational: RTP, serial, chi-squared
│   │   └── context.ts          → Shared context + pass/fail helpers
│   └── plinko/
│       └── PlinkoTests.ts      → 15 unit tests (Mocha)
├── data/
│   └── plinko-master-8100bets.json → 8,100 live bets (4 phases, 166 seeds)
├── outputs/                    → Generated by npm test
│   ├── verification-results.json → Steps 1–20 pass/fail
│   ├── simulation-results.json  → 27M rounds, per-config RTP + cherry-pick
│   ├── determinism-log.json     → Per-bet slot recomputation log
│   ├── chi-squared-results.json → Distribution test results
│   └── rtp-convergence.html     → Interactive RTP convergence chart
├── evidence/
│   ├── S01–S11 *.png            → UI, fairness page, seed rotation evidence
│   └── client-seed-origin.png   → Client seed origin evidence
├── capture/
│   ├── plinko-capture.reference.js → Browser bet capture script
│   └── capture-auto.reference.js   → Capture automation
├── results/                    → Merged capture working directory
├── plinkoConfig.json            → Duel.com game configuration (27 configs)
├── README.md
├── MANIFEST.md
├── package.json
├── tsconfig.json
└── .mocharc.yml

Commands to Reproduce

git clone https://github.com/ProvablyFair-org/duel-plinko.git
cd duel-plinko
npm install

# Run entire audit end-to-end (15 unit tests + simulation + verification)
npm test

Installs TypeScript, ts-node, and cryptographic dependencies. npm test runs mocha (15 unit tests), then the 27M-round simulation, then the 20-step verification pipeline.

Output Artifacts5 files generated

▶

Audit Reproducibility Pinning

Git Commit

5bb2cd4a0ea159af118c3000b74298a16b2f89ad

Node Version

v18+ (tested on v22.x)

Dataset

data/plinko-master-8100bets.json (8,100 bets, 162 active seeds + 4 boundary)

Dataset Hash (SHA-256)

3cf9359d88220bc800bb32edfe04399f55b909302262928ee3a0582715635267

Audit Date

April 2026

Audit ID

PF-2026-DL01

Step-to-Section Cross-Reference20 verification steps mapped

▶

✓ Fully Reproducible

All audit results can be independently reproduced using the pinned commit, dataset, and commands above. The dataset hash ensures you're running against the same 8,100 bets.