ZOOT (https://getzoot.us) launched in January 2024 as a US sweepstakes arcade platform. Users purchase digital coins (SC), use SC as entry fees to participate in online games, and may redeem winnings for USD.

Revenue is driven by coin purchases. Sustaining the platform requires predictable economic behavior, where expected winnings remain below total entry fees collected. This is expressed through RTP (Return to Player), typically around 96%, with the remaining margin retained by the platform.

Scaling the business required expanding the game catalogue rapidly while ensuring that every round affecting a user’s balance could be validated deterministically. At launch, there was no centralized engine capable of processing millions of rounds with consistent auditability, provider normalization, and financial safeguards.

The Remote Game Server (RGS) was designed and built to serve as that transaction backbone.

The Initial Risk Surface

Without a centralized transaction layer, each game would integrate directly with the Wallet service. This created structural risk.

External providers exposed heterogeneous APIs with inconsistent payload schemas, retry semantics, and round lifecycle definitions. Wallet updates could not be validated uniformly, and RTP monitoring would depend on provider-specific assumptions.

Direct wallet exposure increased the blast radius of integration defects. Duplicate requests, malformed payloads, or unclear idempotency rules could result in inconsistent balances.

Auditability was also limited. Without a canonical, immutable record of round progression, reconciliation and dispute resolution required cross-system investigation.

Finally, integration velocity would scale linearly with provider complexity. Each new catalogue expansion would introduce new transaction semantics into core systems.

These constraints limited growth and increased operational risk.

Design Objectives

RGS was designed around four requirements:

  • Deterministic round progression
  • Idempotent balance mutations
  • Immutable auditability
  • Provider normalization at the boundary

The objective was to isolate external variability from internal economic invariants.

Architectural Model

RGS operates as an event-sourced transaction system, modeling each game round as an aggregate reconstructed from an append-only event stream.

For each provider interaction, RGS:

  • Translates provider payloads into canonical domain commands
  • Rehydrates round state from the event store
  • Validates round invariants
  • Delegates debit or credit operations to the Wallet using idempotency keys
  • Appends resulting events to the round stream
  • Returns a provider-specific response

A typical round consists of:

  • BET_REGISTER (entry fee debit)
  • Optional FREE_BET_REGISTER
  • BET_RESULT or FREE_BET_RESULT (credit winnings and finalize the round)

Each state transition is recorded. Round state can be reconstructed deterministically from its event history.

Wallet Coordination

The Wallet service functions as an immutable ledger supporting multi-currency balances. Debits and credits are appended as ledger events and protected by idempotency keys.

RGS does not mutate balances directly. Instead, it issues debit or credit commands scoped to a round event. Retries and timeouts are safe because wallet operations are idempotent.

This separation ensures financial correctness even when provider behavior is inconsistent or network conditions are unreliable.

Internal and External Integrations

RGS supports both internally developed and externally sourced games.

More than 60 original games were built directly against the RGS API, relying on deterministic round progression and explicit debit and credit contracts.

Externally, 1,740+ games were integrated from 16 providers. Each provider required an adapter layer that normalized:

  • Payload structure
  • Idempotency rules
  • Currency formats
  • Error semantics

These adapters translate provider variability into a stable internal event model. Core transaction logic remains unchanged as catalogue size grows.

Integration cycles were reduced from months to days.

Expansion into a Supplier Platform

As ZOOT Studios matured, RGS evolved into a multi-tenant supplier system distributing original games to external operators via aggregator networks.

This required introducing tenant isolation into routing, configuration, logging, and reporting. Support was added for multiple currencies, languages, configurable play limits, and variable RTP.

A headless external client wrapper was developed to manage authentication, session lifecycle, iframe routing, and state restoration while remaining operator-agnostic.

Despite these expansions, the underlying round model and ledger coordination remained unchanged.

Operational Impact

RGS established a single transaction contract across all games on the platform. Provider-specific differences are contained within adapter boundaries, while balance mutations are executed through idempotent wallet operations and recorded in an immutable event stream.

As the catalogue expanded and the platform evolved into a multi-tenant supplier model, the core round semantics did not require redesign. Growth in integrations and operators did not alter the transaction guarantees.

Scale increased, but the economic model and ledger invariants remained stable.