Remote Gaming Server

A remote gaming server built for the audit

Slotty Labs is the RGS behind its own five original titles — NIST-standard RNG, server-authoritative outcomes, four selectable RTP models per game, and a round log that reconstructs any bet on demand. Integrated with one TypeScript SDK.

Definition

What a remote gaming server actually is

A remote gaming server is the component that owns game logic. The client in the player's browser is presentation: reels, animation, sound. Every decision that touches money happens on the server — the random number is drawn there, the paytable is applied there, the win is calculated there, and the round is written to durable storage there.

That separation is not an architectural preference. It is the precondition for certification. A testing lab cannot certify a game whose outcome is computed in a client it does not control, and a regulator cannot adjudicate a player dispute against a round that was never persisted.

Slotty Labs operates as the RGS for its own catalog. There is no third-party studio behind the games and no aggregator between the operator and the engine.

Server-authoritative by construction
  • RNG runs server-side only — process-isolated, reachable through internal RPC, never exposed to the client.
  • Outcomes resolved before the animation — the client renders a result it has already been given; it never computes one.
  • Max win enforced server-side on every title.
  • Every round persisted and tied to the exact game build that produced it.
  • Deterministic replay from the event log for support, disputes and lab review.
The Engine

The four things a lab will actually test

Certification review concentrates on a small number of questions. The engine is built so each one has a document, a dataset, or a reproducible run behind it.

The RNG

NIST SP 800-90A Rev. 1 HMAC-DRBG (SHA-512, 256-bit security strength), seeded from multiple entropy sources, with continuous statistical self-tests modelled on NIST SP 800-22. Process-isolated with internal RPC access only.

The math

Every RTP variant is a separately calculated model, then verified with 10,000,000 fixed-seed Monte Carlo rounds — landing within ±0.5% of the theoretical figure. The written model and the simulation output ship together.

The fairness proof

SHA-256 commit-reveal on every real-money round: the seed is committed before the bet and revealed after, so a player can verify the outcome independently on a public verification page.

The evidence trail

Hash-chained audit logs with WORM storage and Merkle anchoring, plus a complete seven-dossier package built to GLI-19 (Interactive Gaming Systems) standards for accredited labs.

RTP Control

Four RTP models per title, chosen per market

The same game ships at 92%, 94%, 96% or 97% — each one an independently calculated and independently simulated math model, not a multiplier applied to a single base model.

TitleGenreVolatilityMax winRTP variants
Slotty SlotsOnline video slotMedium500× bet92 / 94 / 96 / 97%
Safe SmashMines-style instant gameHigh250× bet92 / 94 / 96 / 97%
Bit Key RushTower / ladder instant gameHigh500× bet92 / 94 / 96 / 97%
Fox'n FlockCrash-style cash-out gameMedium200× bet92 / 94 / 96 / 97%
KatapuuultArcade instant gameHigh300× bet92 / 94 / 96 / 97%
Integration

One SDK, one launch token, one webhook stream

Integration is a TypeScript SDK with zero runtime dependencies on Node 18+. The core path — single sign-on plus game embedding — is roughly twenty lines. Players are created automatically on first launch, keyed to the operator's own player IDs, so there is no user-migration project and no second identity system to reconcile.

Game launches are authorised with single-use RS256 tokens that expire in thirty seconds. Round outcomes, wallet movements and lifecycle events arrive as HMAC-SHA256-signed webhooks with retries and a dead-letter queue, so a brief outage on the operator side does not lose events.

A sandbox with forced outcomes lets QA drive specific results — a max win, a bust, a mid-round disconnect — without waiting for probability to cooperate.

Typical timeline
  • SDK integration — usually under a day for SSO and game embed.
  • Sandbox to live — typically one to two weeks including webhooks and review.
  • Certification — the evidence package is prepared in advance; formal lab certification is completed per market as part of the operator's own submission.
  • Docsdocs.slottylabs.com and @slottylabs/sdk on npm.
FAQ

Remote gaming server questions

What is a remote gaming server (RGS)?

A remote gaming server is the system that actually runs casino game logic. The player's browser only renders the game; the RGS holds the RNG, resolves every bet server-side, applies the configured RTP model, writes the round to a persistent log, and reports the result back to the operator's wallet. Because outcomes are decided server-side, an RGS is what makes a game auditable and certifiable.

What is the difference between an RGS and a game aggregator?

An RGS runs the games. An aggregator resells access to other studios' RGS platforms and takes a share of revenue for the routing. Slotty Labs is the RGS for its own five original titles, so operators integrate the source rather than a reseller layer on top of it.

Can we run our own front-end against your RGS?

Yes. Games are delivered as HTML5 clients embedded through a single-use, 30-second RS256 launch token, and the operator controls branding, lobby placement, and the surrounding experience.

How does the RGS integrate with our wallet?

Through a seamless-wallet model: the RGS calls the operator's balance, debit and credit endpoints — or uses the Slotty Labs double-entry wallet directly, if the operator would rather not run money infrastructure at all.

Is every round reproducible after the fact?

Yes. Rounds are event-sourced and deterministically replayable from their event log, and each round is tied to the exact game version that produced it — which is what dispute resolution and lab review both require.

Point your CTO at the round log.

Book a technical demo — RNG architecture, Monte Carlo evidence, round replay and the certification dossier, walked through live.

Book a Technical Demo