RNG as a Service (WINR Oracle)
WINR Oracle is the randomness layer of the protocol. It gives games single transaction, verifiable RNG directly inside the same block as the bet, with no callbacks and no waiting.
Every bet gets one random value, one proof, and one outcome. RNG, game logic, payout, and validation all happen in a single atomic transaction.
What WINR Oracle does
WINR Oracle gives operators a shared RNG service that is:
onchain
Synchronous
provable
Instead of running their own backend RNG or using slow commit reveal oracles, operators call WINR Oracle through the standard settlement flow and receive:
a random value R
the block randomness that produced it
a proof that links R to that block
a hash that lets anyone recompute and verify the RNG path
This model works for high frequency games where users expect instant results.
Single transaction RNG
WINR Oracle follows a simple rule: one bet, one block, one RNG.
When an operator settles a bet:
the transaction enters the block
the chain produces block level randomness
WINR Oracle mixes this entropy with betId, gameId, and an operator nonce
a unique RNG value R is derived
game logic uses R to compute the outcome
payout is validated and paid from the bankroll
RNG and result proofs are logged
There is no commit reveal cycle, no multi step callbacks, and no second transaction.
This has a few clear effects:
players see instant results
there is no MEV window to peek at RNG before execution
operators cannot hold or reorder RNG responses
RNG and settlement cannot be separated or delayed
RNG derivation and proof
RNG is derived from block entropy and bet data in a deterministic way.
At a high level, WINR computes:
R = H(block_randomness || bet_id || game_id || operator_nonce)
This gives:
one RNG per bet
no RNG reuse across spins
no way to guess R before the block is produced
no way for the operator to bias the output without changing the inputs
For each bet, the system emits an RNG proof with:
block_randomness
rng_output R
rng_derivation_hash
proof of randomness at block level
block number and timestamp
Anyone can verify that R is correct for that block and request.
Anti manipulation properties
Because RNG and settlement live in the same transaction, the oracle closes many common attack paths:
no miner or proposer can condition on seeing RNG first
no front running or back running flow that targets specific seeds
no delayed reveals that let an operator choose when to settle
no backend RNG that overrides the chain source
If RNG verification fails, or if the block randomness does not match the stored proof, the transaction reverts automatically.
This keeps randomness usage clean and visible for players, LPs, and auditors.
How games use RNG
Game logic must be deterministic and fully driven by R.
Typical patterns:
slots: index = R % reel_length
roulette: number = R % 37
dice: value = R % 6
cards: card_index = R % deck_size or bit slicing from R
multipliers: lookup in a weighted table based on R
Rules for operators:
no extra hidden RNG
no backend randomness
no changing payout logic after R is known
outcomes must depend only on R and the approved game definition
If outcome derivation does not match the game definition or R, the Proof Layer flags it and settlement reverts.
Each bet must have exactly one RNG and one outcome.
Integration flow for operators
From an operator view, integration is simple.
For each bet, the operator:
calls the game contract and passes wager and params
uses the standard WINR settlement call with outcome data and payout
reads R and proof from the context if needed for UI or offchain checks
Inside that call, WINR Oracle:
derives R from block randomness and bet data
validates that R and the proof are correct
passes R into the approved game math
checks payout against tranche limits and stabilization caps
settles the bet and updates LP and operator state
From the user view this is a single click and a single confirmation.
Oracle fees and economics
Oracle cost is tied to how much money the operator makes, not how many RNG calls they do.
WINR charges a flat 5 percent fee on Net Gaming Revenue (NGR) per operator:
Oracle_Fee = NGR × 0.05
Where NGR is:
total bets
minus player payouts
minus creator and affiliate shares
minus bonus payouts
There are no:
per RNG call charges
subscription fees
extra API or RPC fees
If an operator does not make money over a period, there is no Oracle fee.
Supported game types
WINR Oracle supports any game that needs randomness and can be mapped to deterministic logic.
Examples include:
slots, single line and multi line, including bonus buy and cascading reels
table games like blackjack, roulette, baccarat, hi lo, and dice
crash and multiplier games
jackpot systems such as progressive and pooled jackpots
custom creator games with their own payout curves and bonus logic
If a game can be written as a pure function of R and a game definition, it can use WINR Oracle.
Developer tools
To make integration easier, WINR provides:
onchain helpers to derive and verify RNG
TypeScript and JavaScript SDKs for verification and testing
REST endpoints and a Proof Explorer to fetch RNG and result proofs
example patterns for slots, table games, crash, and custom modes
These tools let studios plug into the oracle without building their own cryptography or proof systems.
Last updated