Akash Interactive - Creative Developer Portfolio

1. What Is a Math Model in RGS Context

A math model is the complete mathematical specification of how a game behaves. It is server-side only — the frontend (client) never has access to the raw math tables; it only receives the already-computed outcome.

1.1 What a Math Model Contains

Component	Description	Example Value
RTP	Return to Player — theoretical long-run payout %	96.50%
Volatility Index	Statistical variance of win distribution	HIGH / 7.2
Hit Frequency	Probability of any win per round	1 in 4.8 spins
Max Win Multiplier	Highest possible win relative to bet	5,000×
Reel Strip Weights	Weighted symbol probability table per reel position	`[12, 8, 3, 1, ...]`
Paytable	Win multiplier per symbol combination per line	3× Wild = 500×
Bet Modes	Named game modes with cost multipliers	BASE=1.0×, BONUS_BUY=100×
Bonus Trigger Probability	Odds of entering free spins or bonus game	1 in 140 spins
Jackpot Contribution Rate	% of each bet contributed to jackpot pool	0.5%
Feature Probabilities	Multiplier wilds, sticky wilds, cascades	per-feature tables
Jurisdiction Overrides	Jurisdiction-specific constraints on any above field	SE: max_bet=100 SEK

1.2 The Non-Negotiable Rule — Math Is Server-Side Only

┌────────────────────────────────────────────────────────────────┐
│ CLIENT (Browser / App)        │ RGS (Server)                   │
│                               │                                │
│ • Renders reel animation      │ • Holds reel strip tables      │
│ • Plays win sound             │ • Executes RNG                 │
│ • Shows win amount            │ • Applies math model           │
│ • Sends: bet amount + session │ • Returns: outcome + payout    │
│                               │                                │
│ ✗ NEVER has symbol weights    │ ✓ ONLY source of truth         │
│ ✗ NEVER knows next outcome    │ ✓ Produces SHA-256 round hash  │
└────────────────────────────────────────────────────────────────┘

Certification Rule: Any change to the server-side math model — even a single reel weight value — requires re-submission to the test lab before going live in regulated markets.

2. Industry Analysis — How Major Studios Handle Math Configs

2.1 Stake Engine (Stake.com) — Published SDK Approach

Stake Engine publicly documents their math file format. Their approach is the clearest example of static JSON files + compressed lookup tables as the source of truth.

Their math publication format involves three mandatory files per game:

index.json: Mode index (names, cost multipliers, file references).
lookUpTable_base.csv: Probability-weighted outcome lookup table.
books_base.jsonl.zst: Compressed round event data (all pre-computed outcomes).

At game launch, the RNG picks a simulation ID from the weighted CSV table; the matching .jsonl.zst record delivers the pre-verified outcome. No live math calculation happens at runtime.

2.2 Hacksaw Gaming — OpenRGS Math Configuration

Hacksaw separates the studio-owned math from the platform math:

Studio-owned math: Studio uploads certified math tables in Hacksaw's format.
Platform math: Hacksaw's mathematicians design and store the math model centrally.

Jurisdiction constraints (min/max bet, turbo availability) are delivered dynamically during the session initialization, keeping the core math tables clean and static.

2.3 IGT / Land-Based + Online Component Certification Model

GT stores math parameters as pre-certified software components that can be dynamically linked at runtime. A pre-certified base game combined with a pre-certified bonus module creates a certifiable combination without requiring a complete re-test of the entire game stack.

2.4 Multi-RTP Variant Pattern (Industry Wide)

Most studios release games with multiple RTP variants (e.g., 96.5%, 94.5%, and 92.0%). Each variant has its own certified math document, lab certification number, version tag, and paytable/reel strip configuration. Operators choose which variant to deploy based on their market strategy.

3. Storage Architecture — DB vs JSON vs Hybrid

Production-grade RGS systems implement a Hybrid Storage Architecture:

Git & S3 (Immutable Math Artifacts): Files submitted to the test lab (reel strips, weight CSVs, math documents, SHA-256 hashes) are stored as read-only assets. Once certified, they are never edited.
PostgreSQL / MongoDB (Mutable Config Layer): Manages operator assignments, active game variants, jurisdiction rules, bet limits, and version mapping.
Redis (Resolved Cache): Resolves the session math context at player login and caches it in memory with a 24h TTL to eliminate database lookups during game rounds.

4. Math Config Schema Design

4.1 Core JSON Schema — The Master Math Document

This is the canonical JSON layout for a single certified math variant (fortune-tiger-v2.3.0-rtp96):

{
  "math_config": {
    "schema_version": "2.1",
    "game_id": "fortune-tiger",
    "variant_id": "fortune-tiger-v2.3.0-rtp96",
    "game_version": "2.3.0",
    "rtp_variant": "96.50",
    "certification": {
      "lab": "GLI",
      "certificate_number": "GLI-000-2025-XYZ",
      "certified_date": "2025-03-15",
      "certified_rtp": 96.50,
      "certified_rtp_tolerance": 0.5,
      "jurisdiction_approvals": ["UKGC", "MGA", "AGCO"],
      "math_doc_hash": "sha256:a3f4b5c6d7e8f9...",
      "source_code_hash": "sha256:1a2b3c4d5e6f7a..."
    },
    "math_parameters": {
      "rtp_theoretical": 96.50,
      "volatility_index": 7.2,
      "volatility_label": "HIGH",
      "hit_frequency": 0.2083,
      "max_win_multiplier": 5000,
      "max_win_value_eur": 500000
    },
    "bet_config": {
      "min_bet_units": 100000,
      "max_bet_units": 1000000000,
      "step_bet_units": 100000,
      "default_bet_level": 1000000,
      "currency_precision": 6,
      "bet_levels": [100000, 200000, 500000, 1000000, 5000000]
    },
    "modes": [
      {
        "name": "BASE",
        "cost_multiplier": 1.0,
        "enabled": true,
        "weights_file": "s3://math-artifacts/fortune-tiger/v2.3.0/base_weights.csv",
        "weights_hash": "sha256:c1d2e3f4a5b6..."
      }
    ]
  }
}

4.2 Jurisdiction Override Layer Schema

Stored in the database and applied dynamically based on the player's regulatory region:

{
  "jurisdiction_override": {
    "jurisdiction_code": "SE",
    "game_id": "fortune-tiger",
    "base_variant_id": "fortune-tiger-v2.3.0-rtp96",
    "overrides": {
      "bet_config": {
        "max_bet_units": 10000000,
        "max_bet_eur_equivalent": 10.00
      },
      "features": {
        "bonus_buy_enabled": false,
        "turbo_spin_enabled": false,
        "auto_spin_max_rounds": 50
      },
      "session_rules": {
        "mandatory_break_minutes_after": 60,
        "reality_check_interval_minutes": 15,
        "display_session_time": true
      }
    }
  }
}

4.3 Operator Config Layer Schema

Per-operator configurations that layer on top of jurisdiction defaults:

{
  "operator_config": {
    "operator_id": "op-casino-uk-001",
    "game_id": "fortune-tiger",
    "jurisdiction": "UKGC",
    "active_math_variant_id": "fortune-tiger-v2.3.0-rtp96",
    "operator_overrides": {
      "rtp_variant_selected": "96.50",
      "bet_config": {
        "min_bet_units": 200000,
        "max_bet_units": 50000000,
        "default_bet_level": 1000000
      },
      "features": {
        "bonus_buy_enabled": false,
        "jackpot_pool_id": "op-001-jackpot-pool"
      },
      "launch_parameters": {
        "lobby_url": "https://casino-uk-001.com/lobby",
        "cashier_url": "https://casino-uk-001.com/cashier",
        "home_url": "https://casino-uk-001.com"
      },
      "status": "active"
    }
  }
}

5. Multi-Dimensional Config Resolution

When a player launches a game session, the RGS must resolve a single, flattened configuration layout. This config governs the active round rules, bet levels, and feature access.

┌────────────────────────┐
│  Base Math Config      │ (v2.3.0 Base Settings)
└───────────┬────────────┘
            │
            ▼ deep-merge
┌────────────────────────┐
│  Jurisdiction Override │ (e.g. UKGC restrictions)
└───────────┬────────────┘
            │
            ▼ deep-merge
┌────────────────────────┐
│  Operator Settings     │ (Custom bet levels & URLs)
└───────────┬────────────┘
            │
            ▼ validate
┌────────────────────────┐
│  Resolved Config       │ -> Cached in Redis for sub-1ms lookup
└────────────────────────┘

Below is a TypeScript implementation of the dynamic merge and resolution process:

import { merge } from 'lodash';

interface BetConfig {
  min_bet_units: number;
  max_bet_units: number;
  bet_levels: number[];
}

interface MathConfig {
  game_id: string;
  variant_id: string;
  bet_config: BetConfig;
  features: Record<string, boolean>;
}

export function resolveSessionConfig(
  baseConfig: MathConfig,
  jurisdictionOverride: Partial<MathConfig> = {},
  operatorOverride: Partial<MathConfig> = {}
): MathConfig {
  // Deep-merge: Base <- Jurisdiction Override <- Operator Override
  const resolved = merge({}, baseConfig, jurisdictionOverride, operatorOverride);

  // Guard Rails Validation
  if (resolved.bet_config.min_bet_units < baseConfig.bet_config.min_bet_units) {
    resolved.bet_config.min_bet_units = baseConfig.bet_config.min_bet_units;
  }
  if (resolved.bet_config.max_bet_units > baseConfig.bet_config.max_bet_units) {
    resolved.bet_config.max_bet_units = baseConfig.bet_config.max_bet_units;
  }
  
  return resolved;
}

6. Version Management Strategy

iGaming configurations use a strict semantic versioning (SemVer) framework:

MAJOR (vX.0.0): Changes that modify math weights, paytables, symbol distributions, or core logic that alter the certified theoretical RTP. Requires laboratory re-certification.
MINOR (vx.Y.0): Updates introducing secondary components (e.g. localized graphics, text, support for additional currencies) that do not impact the certified mathematical output.
PATCH (vx.y.Z): Cosmetic configurations, operator-specific links, lobby navigation URLs, or non-functional modifications.

Each certified release maps directly to a Git release tag and is deployed as an immutable artifact with checksum matching to prevent files from being modified post-certification.

7. Certification Lifecycle & What Triggers Re-Cert

Math verification is the longest gate in game deployment. Understanding what actions trigger a re-audit reduces overhead:

┌──────────────────────────────────────┐
│       Mathematical Modifiers         │ -> Modifies Reel Strips / Paytables / RNG Seeding
└──────────────────┬───────────────────┘
                   │
                   ▼ Triggers
┌──────────────────────────────────────┐
│  Independent Test Lab Re-audit       │ -> 4-6 Weeks testing (GLI / BMM / iTech)
└──────────────────────────────────────┘

┌──────────────────────────────────────┐
│       Operational Modifiers          │ -> Adjusts default currency / lobby redirect / bet levels
└──────────────────┬───────────────────┘
                   │
                   ▼ Safe
┌──────────────────────────────────────┐
│  Dynamic Update (No Audit Needed)    │ -> 10-Minute deployment window
└──────────────────────────────────────┘

8. Multi-Operator / Multi-Jurisdiction Deployment Matrix

The table below illustrates how different operators utilize base variants and apply custom parameters at runtime:

Operator ID	Jurisdiction	Base Math Variant	Applied Overrides	Status
`spin-casino-uk`	UKGC	`fortune-tiger-v2.3.0-rtp96`	Max Bet £50, No Auto-spin, Reality Check	Deployed
`nordic-win-se`	Sweden (SE)	`fortune-tiger-v2.3.0-rtp94`	Max Bet 100 SEK, Swedish break rules, No Turbo	Active
`ontario-slots-ca`	AGCO	`fortune-tiger-v2.3.0-rtp96`	Localized CAD currency, GameSense display	Active
`crypto-dice-global`	Curacao	`fortune-tiger-v2.3.0-rtp96`	High limits, multi-currency crypto active	Active

9. Implementation Recommendation for Your RGS

Strict Schema Validation: Implement JSON Schema validation at the gateway level. If an operator requests a configuration update that violates the certified limits of the base schema, it must be rejected immediately.
Immutable Artifact Registry: Host math lookup tables (JSON/CSV) in an object storage container with object locking enabled (WORM — Write Once, Read Many).
Pre-warmed Session Resolution: Perform configuration resolution at user login and persist the state in a local Redis instance. Do not compute configurations mid-round.

iGaming Math Config Architecture