SFreedom Logo
Gaming / Real-moneyArchitecture record

Multi-Tenant Slot Game Provider

This is the supply side of a casino rather than the casino itself. Operators plug in over a provider API, and each game is delivered as an embedded runtime that hosts presentation but decides nothing. The architectural line that matters runs between the math packages — which own outcomes, return-to-player behaviour and money — and the game client, which only draws. That separation means the rendering layer can be rewritten without any risk to fairness or settlement.

6
Workspace packages
core, games, builder, runtime, sdk, conformance
2
Deployable apps
provider API + iframe runtime
20+
Documented specs
in the docs tree
3
Operator surfaces
admin, casino web, operator demo
Repository shape

Monorepo: provider API, iframe runtime, six game packages, admin and operator web surfaces, infrastructure and compliance docs

How this is presented

Documented as an architecture record. A provider API with real money callbacks is not something to expose publicly; the embedding contract and the outcome/presentation split are the substance.

Who decides the spin

Follow a spin from the operator's page through the sandbox to the math packages and back. The game client is never in the decision path.

Game clientClient surface

Pure presentation — layered renderer and symbol state machines.

ExternalClient surfaceServiceData storeWorker / job
Executing a spin

The decision path, and who is excluded from it.

Highlights

Outcome and money logic live in renderer-agnostic packages — the presentation layer cannot influence a result.
Games are embedded through a sandboxed iframe with a versioned postMessage contract, so operators integrate against a stable boundary.
A dedicated conformance package validates that a game implementation behaves the way the provider contract requires.
Return-to-player and win-frequency behaviour are properties of the math packages, making them auditable in isolation.
Operational documentation is treated as deliverable: runbooks, disaster-recovery plan, status page and a responsive testing matrix.
A builder package generates game definitions, so adding a title is configuration rather than a rewrite.

Outcomes in packages, pixels in the iframe

The provider API owns sessions, spins and settlement. Game math sits in packages that know nothing about rendering. The iframe runtime hosts the visual game and talks to the host page through a fixed message contract. Each boundary exists so one side can change without endangering the other.

Provider API

Sessions, spins, game configuration, operator setup and the authoritative settlement path.

  • Owns the money path end to end.
  • Publishes an OpenAPI contract that operators integrate against.
  • Wallet callbacks let an operator keep custody of player balances.

Game math packages

Outcome generation, game definitions, combination logic and return-to-player behaviour.

  • Deliberately renderer-agnostic — no dependency on any drawing code.
  • Outcomes are replayable from stored data, which makes disputes resolvable.
  • A conformance package tests implementations against the contract.

iframe runtime

The secure embedding shell: bootstrap, session context, preload, audio unlock and theme handoff.

  • Hosts the game but never decides an outcome.
  • Versioned postMessage contract so operator integrations do not break silently.
  • Sandboxing keeps operator pages and game code separated.

Game client

Presentation: reels, clusters, scatter mechanics and instant-game variants.

  • Layered renderer model separating background, board, effects, UI and overlays.
  • Symbol state machines drive idle, spinning, landing, winning and clearing states.
  • Theme configuration allows reskinning without touching mechanics.

Operator tooling

Administration, catalogue management and an operator-facing demo surface.

  • Tenant and game configuration for onboarding new operators.
  • A demo surface operators can evaluate before integrating.

Applications, packages and documentation

Six packages carry the game logic, two applications carry the runtime, and the operational documentation is treated as a deliverable rather than an afterthought. 28 units across 4 groups.

Applications

5
provider-apiiframe-runtimeadmin-webcasino-weboperator-demo

Game packages

6
coregamesbuilderruntimesdk-tsconformance

Documentation set

10
postmessage-v1.mdgame-rendering-architecture.mdper-game-ui-module-architecture.mdanimation-pipeline.mdembedding-security.mdfull-flow.mdgames.mdanalytics.mdresponsive-testing-matrix.mdquickstart.md

Operations

7
runbooksdr-planstatus-pagecomplianceobservabilityinfrastructureeslint-rules

Stack by layer

Provider surface
NestJS provider APIOpenAPI specOperator bootstrapWallet callbacks
Embedding
Sandboxed iframe runtimeVersioned postMessage contractSession bootstrap
Game packages
Core mathGame definitionsBuilderRuntimeConformance suiteClient SDK
Presentation
Layered rendererSymbol state machinesTheme configurationAudio pipeline
Operations
DockerRunbooksDR planStatus pageObservability

Delivered work

Provider platform

  • Provider API covering sessions, spins, operator bootstrap, wallet callbacks and game execution.
  • OpenAPI contract and a Postman collection for integrators.
  • Game catalogue and per-operator configuration.
  • Conformance package validating implementations against the contract.

Embedding and rendering

  • Sandboxed iframe runtime with bootstrap, session context, preload and audio unlock.
  • Versioned postMessage contract with documented embedding-security expectations.
  • Layered renderer model and symbol state machines.
  • Theme configuration for reskinning without touching mechanics.

Operations

  • Runbooks, disaster-recovery plan and status-page documentation.
  • Responsive testing matrix and analytics specification.
  • Containerised local and provider-style environments.
  • Compliance documentation kept in-tree.

Modules and demo strategy

Outcome/presentation split

The reason the rendering layer can be rewritten safely.

  • Math packages carry no rendering dependency.
  • The game client animates a result it did not choose.

Embedding contract

A stable boundary between provider and operator.

  • Versioned messages so integrations do not break silently.
  • Sandboxing separates operator pages from game code.

Conformance suite

Turns the provider contract into something testable.

  • Catches integration drift before it reaches production.

Frontend documentation format

How this project is presented

The outcome/presentation boundary explained, since it is the fairness argument.
Embedding contract described rather than exposed.
Verified package and document counts.
No public instance — the API carries real money callbacks.