For Developers

WINR is built so you can plug in your games without building your own bankroll, RNG, or proof system.

You keep full control over your game logic and UI. The protocol handles randomness, risk checks, payouts, and public proofs in one flow.


What you integrate

As a developer or operator you connect three parts:

  • WINR Oracle for randomness

  • WINR Bankroll for settlement and payouts

  • Proof Layer for transparency and links in your UI

Your game contract stays your own. WINR sits under it as infra.


High level game flow

For a typical casino game round:

  • player sends a bet through your frontend

  • your game contract calls WINR Oracle and Bankroll in the same transaction

  • randomness is derived from block entropy and your bet identifiers

  • your game logic uses that randomness to compute the outcome and payout

  • WINR Bankroll validates payout and tranche limits

  • Proof Layer records RNG proof, result proof, and settlement proof

  • player can click through and verify everything in the explorer

From the user side it feels like a normal instant bet. Onchain it is a full audit trail.


Oracle integration

WINR Oracle gives you single transaction randomness. There is no commit reveal and no second transaction.

The core idea is: randomness comes from block_randomness plus your own bet identifiers and nonce.

In Solidity you use the derivation helper:

bytes32 R = deriveRNG(

blockRandomness,

betId,

gameId,

operatorNonce

);

You then use R inside your game code to pick reels, cards, dice, multipliers, and bonuses.

If you want to verify onchain you can also call:

bool ok = verifyRNG(

R,

blockRandomness,

betId,

gameId,

operatorNonce

);

On the client or backend side you can mirror the same logic with the JS SDK:

import { deriveRNG, verifyRNG } from "@winr/oracle-sdk";

const R = deriveRNG(blockRandomness, betId, gameId, operatorNonce);

verifyRNG(R, blockRandomness, betId, gameId, operatorNonce); // true or false

Every bet emits RNG proof data in an event so you and your users can inspect it later.


Bankroll and settlement integration

The Bankroll contract pays the player and enforces all risk limits. You do not keep a private balance sheet. You send a settlement request and the protocol checks everything.

Typical settlement call:

settleBet(

gameId,

roundId,

betId,

wager,

outcomeData,

payout,

player

);

When you call this, WINR validates in the same transaction:

  • RNG matches the block randomness and your identifiers

  • outcome matches your approved game definition

  • payout matches the game math

  • payout is under max payout for that tranche

  • drawdown and stabilization limits are respected

  • the operator is allowed to use this tranche

If all checks pass, the Bankroll releases funds to the player and records the result. If any rule is broken, the transaction reverts. There is no hidden override.


Proof Layer integration

The Proof Layer is the public view of how your games behave.

For every bet WINR logs:

  • RNG proof

  • result proof

  • settlement proof

These are exposed through an explorer and simple APIs.

Your job as a developer is to link to them from your UI.

Typical REST endpoints:

GET /api/rng/{betId}

GET /api/result/{betId}

GET /api/settlement/{betId}

And inside the casino UI each completed bet should show links like:

  • View RNG Proof

  • View Game Result Proof

  • View Settlement Proof

All pointing to the same betId in the Proof Explorer.

This is what lets players, LPs, and auditors click and verify how the outcome was produced and whether payouts respected tranche rules.


Game definition and determinism

For fairness and compatibility your game must be deterministic.

You publish a game_definition_hash which commits to your math:

  • reels and symbol weights

  • paytable and multiplier mapping

  • RTP target and volatility curve

  • bonus and jackpot rules

In every settlement the result proof shows that:

  • the same RNG output was used

  • the same game definition hash was referenced

  • the outcome is the output of GameEngine(R, game_definition)

  • the payout is derived from that outcome

If you change math, you produce a new game_definition_hash and go through risk approval again.


Operator responsibilities in code

To stay compatible with WINR infra you should:

  • use WINR Oracle as the only randomness source for games on the protocol

  • keep settlement logic deterministic and reproducible from RNG and game_definition_hash

  • respect tranche payout and drawdown limits

  • report outcome data correctly in settlement calls

  • embed proof links into your frontend so users can check fairness

If you break rules the protocol can throttle your access, move you to a different tranche, or block settlement until issues are fixed.


Tools and contract references

To integrate faster you get:

  • Solidity interfaces for Oracle, Bankroll, and Proof registry

  • JS and TS SDKs for RNG and proof verification

  • REST and websocket APIs from the Proof Explorer

  • contract addresses and ABIs for each supported chain

You bring the game idea, UI, and distribution. WINR gives you a shared bankroll, instant randomness, and transparent proofs under one protocol.

Last updated