Engine-Opaque Config

Anything stored in a config field is opaque to the platform. The engine package defines the shape and the validation rules; the platform stores, transports, and returns the blob without inspecting it.

This is what lets a new game ship without any platform code change: the platform does not need to understand a game’s tuning knobs to carry them.

Where it lives

Engine config travels on the runtime profile, fetched at engine startup via GET /internal/runtime-profiles/:id (see Config + Ledger):

{
  "id": 42,
  "engineType": "wp9dvdgp4wfqmxq4",
  "name": "Hi-Lo Classic",
  "rtp": 0.96,
  "config": {
    "deckSize": 13,
    "payoutMultiplier": 1.95,
    "bettingWindowSeconds": 5
  },
  "createdAt": "2026-01-15T10:30:00Z",
  "updatedAt": "2026-05-01T14:22:00Z"
}

The config field

The config object is the schema the engine package defines. The platform stores it as JSON and returns it verbatim. Its contents are entirely up to the game:

Game	Example config
Hi-Lo	{ deckSize, payoutMultiplier, bettingWindowSeconds }
Crash	{ maxMultiplier, growthRate, houseEdge }
Slot	{ reels, paylines, symbols, payTable }

The platform guarantees one thing only: whatever is saved is returned unchanged at runtime. Validation is the service’s responsibility, in the engine package.

Why opaque

• Zero platform coupling — a game adds, removes, or renames a tuning knob with no platform deploy.
• Independent validation — the engine package owns its own schema and is the single place that validates it.
• Forward compatibility — reserved and unknown fields pass through untouched, so new fields never break an older service.