Stake Engine Explained: How Studios Build, Submit and Launch Games on Stake’s RGS

Stake Engine is the remote gaming server (RGS) that Stake opened to independent studios in 2025. Instead of integrating through an aggregator, a studio builds its game against Stake’s own toolkit, submits it for review, and — if approved — goes live in front of one of the largest crypto-casino audiences in the world. Three Giro Games titles run on it, two of them with the maximum three-star rating, so this is a description from the inside rather than a press release retold.

What Stake Engine actually is

Technically it is three things bundled together: a remote gaming server that handles bets, balances and round history; a Math SDK that produces the game’s outcomes; and a Frontend SDK for the client. The unusual part — and the one that changes how you design — is that outcomes are not calculated in real time. The Math SDK simulates the game in advance and ships every possible result as data. At play time the RGS simply picks one of the pre-computed results according to its weight.

Stake’s own launch material described the offer as “build, launch, earn”: studios keep the IP, publish under their name and share revenue. The catalogue that has grown around it is visible on the Stake Engine provider page, and it is where the “Only on Stake” label comes from for many recent titles.

The Math SDK, in plain terms

The Math SDK is Python with a Rust optimiser. A game is described by three objects:

• GameConfig — reel strips, paytable, special symbols, RTP targets and the list of bet modes (base game, bonus buy and so on, each with its cost multiplier and its own RTP target).
• GameState — the code that plays one round: spin, evaluate wins, run features.
• BetMode — the description of each purchasable mode.

You run the simulation for a large number of rounds; each round is written to a books file (JSON lines, optionally compressed) together with a lookup table that maps every simulation ID to its payout and weight. Then the optimiser adjusts the weights so that the weighted average payout lands on the configured RTP within tolerance. The publish folder that comes out — books, lookup tables and the game config — is what both the client and the RGS consume.

Two consequences follow. First, the game is fully deterministic and reproducible: every result that can ever happen already exists in the books, which makes verification straightforward. Second, design decisions become budget decisions. A feature with a long chain of random events produces a huge number of distinct outcomes, and the file that has to represent them grows with it. Designing for Stake Engine means thinking about the space of outcomes, not just their average.

The Frontend SDK

The client kit is built on PixiJS with Svelte. It gives you the plumbing — bet controls, balance, round flow, the messaging with the RGS — and leaves the presentation to the studio. This is where the art, animation and sound live, and where a game either feels like a 2026 release or like a template. Our own titles use custom reel, win and feature scenes on top of the SDK; the framework does not limit the visual ambition, but it does reward a clean separation between game logic (which is already decided in the books) and presentation.

Submission and the three-star rating

Every game goes through a pre-release review. The review is not a certification in the regulatory sense; it is Stake’s quality gate. Games receive a rating from one to three stars, and the rating affects placement — three-star titles are the ones that end up in Recommended Slots. The criteria are the ones you would expect from a platform that lives on player engagement: maths that behaves as documented, a client that performs on mobile, presentation quality, and a feature set that holds attention.

From our experience across three submissions: the maths is checked first, the front end second, and the difference between two and three stars is almost always polish — win presentation, anticipation, load times, the small things a player feels without naming.

What is different about designing for a pre-computed RGS

1. No live RNG on the server. Fairness verification is done against the books rather than against an RNG certificate.
2. Bet modes are first-class. Bonus buy is not a hack added to the base game; it is a separate mode with its own simulation and RTP.
3. Outcome count is a design constraint. A cascade with unbounded multipliers has to be capped somewhere, and the cap is a maths decision, not a UI one.
4. Iteration is cheap. Changing a paytable and re-running the optimiser is minutes, not a new lab submission.

Who Stake Engine is for

Small and mid-size studios that want distribution without an aggregator, and operators or brands that want an exclusive title in front of Stake’s audience. The barrier is not access — the SDKs are public — but execution: a game that passes review and earns three stars needs a working maths model, a client that holds 60 fps on a phone, and art that reads at reel size.

That execution is what we offer as a service. Stake Engine development at Giro Games covers the maths in the SDK format, the client on the Frontend SDK, the submission and the review — and the studio’s own titles are the reference: Midas Golden Era and Sugar Space were built exactly this way.

Sources: Stake Engine Math SDK documentation (stakeengine-math-sdk.mintlify.app), the Math SDK repository on GitHub, and Stake’s Stake Engine announcement; ratings and review details from our own submissions.