For Casino Operators

WINR is the backend for onchain casinos, not a competing frontend. If you are an operator, studio, or platform, you plug into WINR to get:

  • shared bankroll

  • fast verifiable RNG

  • public proofs for every bet

All your games keep their own UX and brand. WINR runs the risk, liquidity, and proof logic in the background.


Bankroll access

To use the WINR Bankroll, an operator submits a simple access request.

We look at:

  • who you are and what you run

  • what type of product you have (casino, game studio, creator platform, prediction market)

  • which games you want to route through WINR

  • your expected volume and limits

  • RTP, volatility, and max multipliers for each game

This lets the protocol:

  • pick the right tranche for your risk profile

  • set safe max payouts and drawdown ceilings

  • plan long term liquidity for your product

Once this is in place, your games can start settling through the WINR Bankroll instead of your own internal balance sheet.


Risk fit and tranche assignment

Every game you connect to WINR is treated as a risk object, not just a UI.

For each game, WINR:

  • reads the game math and RTP model

  • runs Monte Carlo simulations over millions of rounds

  • tests worst streaks, tail events, and payout clusters

  • checks if the game can break a tranche under any realistic path

If the profile fits a tranche, the game is approved there. If not, it can move to a higher risk tranche or the math must be adjusted.

Typical mapping:

  • stable, high volume, low volatility games go to the senior tranche

  • mid volatility creator or studio games go to the medium tranche

  • high volatility, high multiplier, experimental games go to the high risk tranche

This keeps LP risk isolated while still giving operators enough room to run interesting games.


Settlement integration

Operators do not send funds to WINR. They send settlement calls.

Each game calls the bankroll with:

  • bet and round identifiers

  • the player wallet

  • wager amount

  • the RNG output used

  • outcome data from the game

  • the payout that should go to the player

The WINR contracts then verify:

  • does the RNG match the random seed for that block

  • does the outcome match the game_definition_hash

  • is the payout in line with the math model

  • is the payout below tranche max payout

  • do drawdown and stabilization rules still hold

  • is this operator allowed to use this tranche

If any of these checks fail, the whole transaction reverts and the bet does not settle. If they pass, the payout leaves the tranche and goes to the player.

You do not have to reimplement risk logic. You only have to send the proper fields.


Oracle and Proof integration

To keep fairness and risk aligned, operators must:

  • use WINR Oracle for all randomness for any game that uses the bankroll

  • derive outcomes only from the RNG output R provided by WINR

  • publish RNG and result data into the Proof Layer

In practice this means:

  • calling the Oracle in your game contract or using the SDK

  • not mixing in private randomness or offchain dice

  • linking to the Proof Explorer for each bet so players can check what happened

The goal is simple. There should be no part of the stack where an operator can silently tilt results without that tilt showing up in proofs or tranche behavior.


Activation and monitoring

After technical integration is complete and test runs look correct:

  • your operator address is whitelisted for a tranche

  • liquidity is made available

  • payout ceilings and drawdown limits go live in mainnet contracts

From that point, WINR monitors:

  • payout patterns

  • volatility compared to the approved model

  • volume versus expectations

  • how often risk boundaries are touched

If a product drifts too far from its modeled behavior, the protocol can slow routing, move it to a higher risk tranche, or put it in cooldown while you adjust the math.

This keeps the bankroll healthy while still letting operators ship and iterate.


Operator responsibilities

To keep access to the WINR Bankroll, operators are expected to:

  • keep game math aligned with the version that was approved

  • route all randomness for those games through WINR Oracle

  • not bypass payout caps or tranche rules

  • notify WINR when RTP, multipliers, or volatility change

  • expose proof links in the UI so players can verify games

Non compliance does not just break rules. It breaks the safety guarantees for LPs and other operators using the same liquidity network.


What operators get in return

By integrating with WINR, an operator:

  • does not need to raise a separate bankroll for each game

  • does not need to build their own RNG or proof system

  • gets a risk model that is already tested and monitored

  • can tell players and partners that every bet, payout, and outcome is publicly provable

You focus on product, games, creators, and users. WINR runs the liquidity, randomness, and transparency under the hood.

Last updated