Proof Layer

The WINR Proof Layer is the transparency system of the protocol. It publishes cryptographic proofs for every RNG value, game outcome, and settlement, so anyone can check how the system behaves in practice.

It turns the casino backend into public data. Operators do not host or manage this. They only push structured data. WINR indexes it, verifies it, and exposes it through the Proof Explorer and APIs.


What the Proof Layer provides

For every bet, the Proof Layer records:

  • how randomness was created

  • how that randomness produced the outcome

  • how the payout was checked against bankroll rules

This lets:

  • players verify fairness

  • LPs verify risk controls

  • auditors verify full history

  • operators prove they are not cheating

Traditional casinos hide this logic. Even many onchain casinos still hide randomness or settlement behind backend services. WINR makes it public, cryptographically linked, and immutable.


Proofs per bet

Each bet generates three proof objects that the Proof Layer stores and exposes:

  • RNG proof

  • Result proof

  • Settlement proof

These three together show:

  • the RNG was fair

  • the math was followed

  • the bankroll rules were respected

Operators do not have to build this logic themselves. The WINR settlement flow emits the required data.


RNG proof

RNG proofs describe how the random value for a bet was created.

Each RNG proof includes at least:

  • block_randomness

  • rng_output (R)

  • rng_hash or rng_derivation_hash

  • proof_of_randomness (VRF or chain entropy proof)

  • betId

  • gameId

  • blockNumber

  • timestamp

The derivation hash links everything:

R = H(block_randomness || operator_request_hash || seed_mix)

This prevents:

  • miner and proposer bias

  • operator-level manipulation

  • RNG reuse across multiple bets

  • hidden backend randomness

Anyone can recompute R and confirm that the randomness was produced exactly from the recorded inputs.


Result proof

Result proofs link RNG to the game math and the final outcome.

Each result proof includes:

  • rng_output

  • game_definition_hash

  • outcome_values (symbols, multiplier, dice result, roulette number, line wins, bonus triggers, and similar)

  • outcome_derivation_hash

  • payout_amount

  • payout_validation and settlement_status

The key relation is:

outcome = GameEngine(rng_output, game_definition)

and

payout = PayoutModel(outcome)

The game_definition_hash is a hash of the full math model: paytable, reels, symbol weights, RTP target, multiplier curves, bonus logic, jackpot rules, and so on.

If a studio changes the math, the hash must change and the game must be re-approved. They cannot silently change RTP or symbol weights without creating a new definition.

Result proofs close the gap where a game could use fair RNG but cheat in the way it interprets that RNG. If math or payouts deviate from the game definition, the proof fails.


Settlement proof

Settlement proofs show how the bankroll rules were applied.

For each bet, the settlement proof confirms that:

  • payout is below the tranche max payout

  • payout respects stabilization caps if active

  • drawdown limits were not broken

  • the correct operator and tranche were used

  • RNG matches the stored RNG proof

  • the outcome matches the math model

  • no anomaly or pattern trigger was hit

If any of these checks fail, the bet reverts. There is no way to bypass payout validation or drawdown rules at the contract level.

This gives LPs a clear view of how risk is enforced over time.


Proof Explorer

The Proof Explorer is the public frontend for the Proof Layer, hosted by WINR at explorer.winr.games.

Users can search by:

  • bet ID or round ID

  • transaction hash or block hash

  • operator address or player wallet

  • game ID or tranche ID

  • time ranges

The explorer provides different views:

  • RNG proof view

    • block randomness

    • VRF or entropy proof

    • RNG output and linking hashes

  • Result proof view

    • RNG used

    • Game_definition_hash

    • outcome derivation and payout logic

    • max payout validation and settlement result

  • LP safety view

    • payouts from each bet

    • max payout checks

    • drawdown impact

    • tranche state

  • Operator view

    • RNG distribution

    • outcome distribution

    • payout curve behavior

    • compliance with tranche limits

Operators do not maintain this. They only provide proof links in their UI.


UI integration for operators

Every completed bet in an operator UI must expose proof links. Typical actions are:

  • “View RNG Proof”

  • “View Game Result Proof”

  • “View Settlement Proof”

These links point to:

https://explorer.winr.games/bet/{betId}

This is mandatory for any game using WINR. It makes fairness a visible part of the product, not just a backend promise.


Player and LP verification flow

A normal verification flow looks like:

  • player hits “View Proof” next to a bet

  • explorer opens with RNG, result, and settlement tabs

  • player can see what RNG was used, how it turned into symbols or numbers, and how the payout was capped or paid

  • LP can see how that payout affected tranche drawdown and health

No special tools are needed beyond a browser.


Developer tools and APIs

Developers and auditors can access the same data by API.

The Proof Layer exposes:

  • REST endpoints

    • /api/rng/{betId} for RNG proofs

    • /api/result/{betId} for result proofs

    • /api/settlement/{betId} for settlement proofs

  • Websocket stream

    • real time rng_proof, result_proof, settlement_proof, and tranche health events

  • Verification SDK

    • JS/TS helpers to verify RNG hash and entropy

    • functions to recompute outcomes from RNG and game_definition_hash

    • payout logic checks

These tools make it simple to add proof checks into operator backends, analytics, or external monitoring.

Last updated