Complete Technical Specification

Jackpot System

Multi-level progressive jackpot engine. Operator-owned. Cross-provider. All contributions and all drops stay within our player base.

Curaçao Romania Mode 1–4 Dev Ready March 2026

"You are present in a place where luck might appear."

Part 1

Vision & Design Rules

The principles that govern every design decision in the system.

The Core Design Test"Does this make the player feel they are present in a place where luck might appear?" — Every developer, designer, and copywriter must test every decision against this question. If the answer is no, the design fails.

A proprietary jackpot platform replacing provider-controlled jackpots with operator-owned jackpots. Games from any provider feed our pools. Every drop goes to our players. Every contribution stays in our ecosystem.

The system creates a Jackpot Universe — a destination with 20+ differently-themed, differently-configured jackpots that collectively feel like a live environment where luck lives. Players choose between jackpots like they choose between games. Each jackpot has its own identity, mechanics, and personality.

The system must deliver three things simultaneously: operational flexibility for the operator (unlimited configuration, manual overrides, multi-brand management), mathematical integrity for compliance (auditable, fair, provable), and visceral excitement for the player (real-time tickers, urgency animations, social proof, celebration experiences).

The Ten Implementation Rules

PRESENCE — Always show live player counts and activity signals. "2,418 players chasing tonight's jackpots."
SOCIAL PROOF — Always show recent winners with masked names, amounts, games, and timestamps.
NARRATIVE PROGRESSION — Jackpots move through Calm → Heating → On Fire → Must Drop with escalating visual intensity.
PLAYER JOURNEY — Show the player their personal contribution amount, qualifying spins, time invested, leaderboard rank.
SHARED LUCK — When a jackpot drops, Chain Reaction distributes bonus prizes to other active players. Luck touches the room, not just one person.
URGENCY WINDOWS — Timed jackpots show countdowns. Must-drop jackpots show proximity to guaranteed drop.
VARIETY — 20+ jackpots with different themes, mechanics, and personalities. Each feels like a different product.
STORY MOMENTS — Every win is a dramatic event with animations, broadcasts, and cascading celebrations that create memories.
ALWAYS ALIVE — Tickers always increment smoothly. Counters always update. Nothing is ever static on any jackpot component.
NEVER MECHANICAL — Copy says "luck touched the room" not "consolation prize distributed." Design feels organic, not robotic.

💡Rule 5 in Practice: Chain Reaction Event

Player A wins Crown Fortune GRAND — €47,000 System selects 8 other active eligible players for Chain Reaction: Player B: €500 | Player C: €250 | Players D-H: €100 each WHAT EACH PERSON SEES: Winner (A): Full-screen celebration. Amount reveal animation. "Congratulations!" Chain Recipients (B-H): Toast — "✨ Luck touched the room! You received €500!" All other players: Toast — "🏆 Pl***rA won GRAND €47,000! +8 bonus prizes awarded!" Activity Feed: Win pinned at top for 5 minutes. All pools reseed with animation.

▶ WHY The psychology behind these rules

Every human alive already beat odds of roughly 1 in 400 trillion just to be born. That's not a statistic people consciously think about, but it's wired into the operating system. You ARE the winner of the most improbable lottery ever run.

When a player sits at a slot and sees a jackpot ticker, they're not calculating probability. Deep down they think: "Why not me? I'm already here against all odds. The universe already picked me once."

The Chain Reaction isn't a "consolation prize." It's the universe saying "I see you too. You weren't the one this time, but I noticed you were here." It validates the player's presence.

The "Must Drop" mechanic tells the player: "Luck is GUARANTEED to visit this room before midnight." That transforms passive hope into urgent presence. The question becomes: "Will I still be here when luck arrives?"

The jackpot engine is not just an RNG system. It is a probability theater. Players are not watching math. They are watching the moment when luck chooses someone.

Extensibility Principle

The jackpot engine is designed as a standalone service with an event-driven architecture. The same event bus, pool mechanics, eligibility engine, and widget system will later support Cash Drops, Raffles, Wagering Leaderboards, and Multiplier Challenges. All interfaces and event schemas must be designed with this expansion in mind. No jackpot-specific assumptions should be hardcoded where a generic engagement-event model would work.

Target Markets

	Curaçao (Priority 1)	Romania / ONJN (Priority 2)
Distribution	Mode 2 (Behavior-Weighted) + Mode 3 (Operator-Directed) for promotional jackpots	Mode 2 (conservative weights). Mode 1 (Pure RNG) if ONJN requires.
Currency	EUR, USD, crypto (if supported)	RON (primary), EUR
Certification	No external RNG certification required	ONJN approval required. RNG audit trail mandatory.
Bet Types	Real + bonus configurable per jackpot	Real money only (standard)
Language	EN, PT, ES (minimum)	RO, EN (minimum)

NoteAll 4 distribution modes are fully specified in this document. Curaçao and Romania are priority deployment targets but the system supports any jurisdiction via compliance profiles.

Glossary

Term	Definition
Jackpot	A named container holding one or more Levels, with shared configuration for participating games, brands, and currencies.
Level	A single prize tier within a Jackpot (Grand, Major, Minor, Mini, or custom). Each Level has its own pool, seed, target, and trigger rules. Unlimited Levels per Jackpot.
Pool	Accumulated funds for a specific Level in a specific currency. One Pool per Level per currency.
Contribution	Percentage of each qualifying bet directed into pools, split across Levels by operator-defined percentages.
Seed / Reseed	Starting amount after a drop. Random within range (Seed From / Seed To). Auto-reseed after each win.
Drop / Hit	Event when a prize is awarded. Occurs when trigger conditions are met and pool is within target range.
Win Target	Secretly selected amount between Win From and Win To. New random value each cycle. Players cannot see this.
Win Max	Hard ceiling. Pool freezes here if trigger conditions unmet. No prize can exceed Win Max.
Must-Drop	Jackpot guaranteed to pay before Win Max or deadline. Creates urgency.
Warn State	Visual urgency phase (Calm / Heating / On Fire / Must Drop) triggered at randomized percentage thresholds.
Chain Reaction	Bonus prizes distributed to other active players when a main jackpot drops. 1–10 recipients per drop.
Hidden Increment	Portion of pool growth not shown to players. Carries over to boost next cycle's seed amount.
Coefficient	Per-game multiplier on contribution rate. 1.0 = standard, 2.0 = double, 0.5 = half.
Active Player	Player with qualifying bet in last N seconds (configurable, default 60s). Used for min_players trigger check.
Waterfall	Cascade mechanic: Grand drops triggers Major triggers Minor triggers Mini. Multiple winners in sequence.
Compliance Profile	Per-jurisdiction config: allowed distribution modes, certification requirements, audit levels, weight factor restrictions.

Part 2

System Architecture

Eight services communicating via event bus. Standalone microservice architecture.

The Jackpot Engine is a standalone microservice communicating via an event-driven message bus. It does not embed within the game server, wallet service, or CMS. It subscribes to bet events, processes contributions, manages pool state, evaluates trigger conditions, and emits win events and real-time display updates.

The engine receives standardized bet events from the platform's Game Integration Layer. It does not need to know game rules, RTP, volatility, or provider-specific mechanics. A bet event contains: player ID, game ID, brand ID, currency, bet amount, bet type (real/bonus), and timestamp. That is sufficient for all jackpot calculations.

Service Boundaries

Service	Responsibility	Communication
Game Event Adapter	Normalizes provider bet events into unified format	Output: `BetPlaced` events to bus
Jackpot Engine	Pool management, contribution processing, lifecycle management	Subscribes: BetPlaced. Publishes: PoolUpdated, JackpotWon, StateChanged
Trigger Engine	Drop condition evaluation, win targets, anti-prediction logic	Evaluates on each contribution. Initiates drop sequence.
Winner Selection	Selects winner(s) using configured distribution mode (1–4)	Called by Trigger Engine on drop. Returns winner(s).
Payout Service	Credits wins to wallets. Approval queue. Retry logic. Tax.	Receives: CreditJackpotWin. Returns: confirmation/failure.
Player Service	Player data: segment, VIP tier, KYC, jurisdiction, preferences	Queried by eligibility checks. Cached.
Real-Time Gateway	WebSocket/SSE push to all connected frontends	Subscribes: PoolUpdated, JackpotWon, WarnThresholdReached
BO API	REST API for operator management interface	Authenticated, RBAC-enforced. All actions logged.
Widget Service	Embeddable web components for all surfaces	Connects to Real-Time Gateway via WebSocket.
CRM / Notifications	Push, email, SMS, campaign triggers	Subscribes: JackpotWon, WarnThresholdReached, PoolApproachingMax

▶WHY Why this specific service decomposition?

Each service owns its own domain and can be developed, tested, and deployed independently. The engine can be updated without touching game integrations. Widgets can evolve without touching pool math.

The same event bus and architecture will later support Cash Drops, Raffles, Wagering Leaderboards, and Multiplier Challenges — each as a new service subscribing to the same events. This extensibility is why we chose event-driven over direct API calls.

Event Schemas

All communication uses structured events on a message bus (Kafka, RabbitMQ, or equivalent). Every event includes: event_id (UUID), event_type, event_version, timestamp (UTC), and payload.

Inbound Events (consumed by Jackpot Engine)

Event	Payload
BetPlaced	`player_id, game_id, brand_id, currency, bet_amount, bet_type (real\|bonus), session_id, timestamp`
PlayerSessionStart	`player_id, brand_id, session_id, timestamp`
PlayerSessionEnd	`player_id, brand_id, session_id, timestamp`

Outbound Events (published by Jackpot Engine)

Event	Payload
PoolUpdated	`jackpot_id, level_id, currency, current_amount, visible_amount, state (normal\|warn\|critical), timestamp`
JackpotWon	`jackpot_id, level_id, currency, win_amount, winner_player_id, winner_game_id, winner_brand_id, chain_reaction_winners[], timestamp`
JackpotReseeded	`jackpot_id, level_id, currency, new_seed_amount, new_win_target, timestamp`
WarnThresholdReached	`jackpot_id, level_id, currency, current_amount, warn_percentage, timestamp`
JackpotStateChanged	`jackpot_id, level_id, new_state, changed_by (system\|operator_id), reason, timestamp`
PoolApproachingMax	`jackpot_id, level_id, currency, current_amount, win_max, percentage_of_max, timestamp`

DevAll events must include event_id (UUID) and event_version for backward-compatible evolution. Version events to allow schema changes without breaking consumers.

💡Complete Event Flow: €2.00 Bet on Gates of Olympus

1. Player places €2.00 bet on Gates of Olympus (Pragmatic Play) 2. Pragmatic sends round_result to our Game Integration Layer 3. Game Event Adapter normalizes → BetPlaced { player_id, game_id, bet_amount: 2.00, currency: EUR } 4. Jackpot Engine receives BetPlaced. Gates of Olympus in Crown Fortune game list ✔ 5. Contribution: €2.00 × 1.5% rate × 1.2 game coefficient = €0.036 gross 6. House cut: €0.036 × 10% = €0.0036 retained. Net: €0.0324 to pools 7. Split: Grand 40% (€0.013) | Major 25% (€0.008) | Minor 20% (€0.006) | Mini 15% (€0.005) 8. Pool updated atomically. PoolUpdated event published to bus. 9. Real-Time Gateway pushes to all WebSocket clients 10. Player's ticker increments smoothly (200–800ms display lag for smoothing) 11. Trigger Engine: has Grand pool crossed hidden win target? If yes + conditions → DROP SEQUENCE

Data Storage

PostgreSQL: All configuration, pools, contributions, wins, audit logs. Source of truth. ACID transactions for pool updates.
Redis: Current pool amounts, active player counts, ticker display values. Sub-second reads. Always derived from PostgreSQL.

DevRedis is always derived. If Redis crashes, rebuild from DB. If DB crashes, stop everything and queue on bus.

Concurrency

CriticalPool updates must be atomic (row-level locking or optimistic concurrency). Win evaluation must be serialized per level (distributed lock on level_id). If two players qualify simultaneously, first lock holder wins; second bet contributes to reseeded pool. Display may lag reality by up to 500ms — this is acceptable and expected.

Failover Matrix

Failure Scenario	Required Behavior
Jackpot Engine down	Bets continue and queue on message bus. On recovery, engine replays unprocessed events. No contributions lost. During downtime, tickers freeze at last known value.
Database down	Engine stops processing new contributions. Bets queue on bus. Real-time cache continues serving last known values. Alert sent to operator immediately.
Win credit fails	Win event placed in retry queue with exponential backoff. Pool remains in DROPPING state. Does not reseed until credit confirmed. After all retries fail, alert operator for manual resolution.
Real-Time Gateway disconnects	Players see frozen tickers. On reconnect, gateway fetches current state from cache. No impact on pool calculations or win processing.
Partial contribution processed	Idempotency keys on bet events prevent double-processing. On recovery, system re-evaluates pending triggers.

Part 3

Core Engine — Data Models & Pool Mechanics

CriticalSystem must NOT hardcode a fixed number of levels. A jackpot may have 2, 7, or 15 levels. All UI components and data models must support a dynamic number of levels.

Jackpot Entity

Field	Type	Description
jackpot_id	UUID	Unique identifier
name / internal_name	String	Display name (player-facing) and BO reference name
type	Enum	PERSISTENT \| TIMED \| PROMOTIONAL \| MYSTERY
status	Enum	DRAFT \| ACTIVE \| PAUSED \| DROPPING \| EXPIRED \| ARCHIVED
brands[]	UUID[]	Brands where jackpot is visible and active
currencies[]	String[]	Supported currencies (separate pool per currency)
games[]	GameConfig[]	Participating games with per-game coefficient and trigger eligibility flag
contribution_rate	Decimal	Base % of each bet to pools (e.g., 0.015 = 1.5%)
house_cut	Decimal	Operator margin from contributions before pool allocation (e.g., 0.10 = 10%)
compliance_profile	Object	Jurisdiction code, distribution mode, certification requirements, allowed weight factors, prohibited actions
schedule	ScheduleConfig	Activation/deactivation schedule for timed/promotional jackpots
created_at / created_by	Timestamp/UUID	Creation timestamp (UTC) and operator identity

Level Entity

Field	Type	Description
level_id / jackpot_id	UUID	Unique ID and parent jackpot reference
name / display_order	String / Int	Display name (Grand, Diamond, etc.) and position (1 = top/largest)
icon / image_id	String/UUID	Visual asset reference for this level
contribution_split	Decimal	Level's share of total contribution. All levels must sum to 100%.
seed_from / seed_to	Decimal	Random seed range after drop. If equal, seed is fixed.
win_from / win_to	Decimal	Random win target range. System selects secret target each cycle.
win_max	Decimal	Hard ceiling. Pool freezes here. Must be ≥ win_to.
coefficient	Decimal	Base increment coefficient for this level (default 1.0)
warn_from / warn_to	Decimal	Random warn threshold range (% of win target). Randomized each cycle.
min_bet / max_bet	Decimal	Bet range for win eligibility. 0 = no limit.
min_players	Integer	Minimum active players for drop to occur (0 = no restriction)
min_spins	Integer	Minimum qualifying bets player must have in session
hidden_increment	Object	enabled, coefficient (carry-over % from last win to next seed)
chain_reaction	Object	enabled, prize_count (1–10), prize_amounts[], distribution_mode (random\|weighted\|proximity\|targeted)
waterfall	Object	enabled, cascade_delay_seconds, cascade_scope (full\|partial), winner_mode (independent\|same)
range_display	Object	min_display: nothing\|seed_from\|win_from. max_display: nothing\|seed_to\|win_to.
integer_wins_only	Boolean	Round win amounts to whole numbers
lock_on_win	Boolean	Pause winner's game session until win is acknowledged
auto_reset_seconds	Integer	Auto-dismiss win notification (0 = manual dismiss required)
status	Enum	ENABLED \| PAUSED \| NO_WIN \| DISABLED

💡Crown Fortune: Complete Configuration

Jackpot Types

Persistent: Always running. Auto-reseeds after drop. No end date. Standard type. Runs until operator deactivates.
Timed: Active for defined window. Must-drop before deadline. Countdown visible to players. Used for daily drops, weekend specials, event-tied jackpots.
Promotional: Tied to marketing campaign. Start/end dates. Segment restrictions. Can be auto-created from CRM triggers. After campaign ends, remaining funds carry over or force-drop based on config.
Mystery: Player doesn't know which level they're playing for until win. All levels active but only winning level revealed on drop. Single unified ticker or question-mark placeholders.

Lifecycle States

State	Description	Transitions To
DRAFT	Configured but not live. Not visible to players.	ACTIVE
ACTIVE	Live. Accepting contributions. Visible. Can trigger drops.	PAUSED, DROPPING, EXPIRED, ARCHIVED
PAUSED	Temporarily halted. Visible but not incrementing. No drops.	ACTIVE, ARCHIVED
DROPPING	Win being processed. Pool locked. Awaiting wallet confirmation.	ACTIVE (after reseed), EXPIRED
EXPIRED	Timed/promotional past end date. No longer accepting contributions.	ARCHIVED
ARCHIVED	Permanent. History preserved. Not visible. Terminal state.	—

Contribution Pipeline (8 Steps)

Game eligibility check: Is game_id in the jackpot's participating games list? If not, discard. No contribution.
Bet type check: Does the jackpot accept this bet type (real money, bonus money, or both)? Configurable per jackpot. Default: real money only.
Calculate gross contribution: bet_amount × contribution_rate × game_coefficient. Example: €2.00 × 1.5% × 1.2 = €0.036.
Apply house cut: gross × (1 − house_cut). Example: €0.036 × 0.90 = €0.0324 net to pools. Operator keeps €0.0036.
Split across levels: Distribute net according to each level's contribution_split. Example: Grand 40%, Major 25%, Minor 20%, Mini 15%.
Apply hidden increment: If enabled, portion goes to invisible reserve instead of visible amount.
Update pool: Atomically add visible portion to visible_amount and full portion to current_amount. Publish PoolUpdated event.
Evaluate trigger: Check if current_amount ≥ win_target AND all trigger conditions met.

DevSteps 1–2: fast cached lookups. Steps 3–7: must be atomic per pool. Step 8: requires distributed lock on level.

Design DecisionALL bets on qualifying games contribute to pools even below min_bet. Small bets grow the visible number. Only min_bet+ bets can TRIGGER a win. This maximizes pool growth while restricting wins to appropriately-staked players.

▶ WHY Why do ALL bets contribute, but only min_bet can win?

The visible pool number is a marketing asset. If only high-roller bets fed the pool, jackpots would grow agonisingly slowly — killing the "live, breathing" feel. A €0.20 bet from a casual player still adds €0.003 to the pool ticker. Multiply that by 10,000 players and the Grand grows visibly.

But paying out €47,000 to someone who bet €0.20 creates two problems: (1) it feels arbitrary and arbitrary wins are not memorable, they're just lucky accidents. (2) High-value players who feed the pool with €5 bets expect a proportional shot at winning. The min_bet gate is a fairness signal to premium players: "Your bets matter more here."

Newton Slot Management uses this exact pattern in land-based casinos in Romania. It's battle-tested.

Pool State Fields (per Level per Currency)

Field	Description
`current_amount`	Source of truth. Full pool including hidden increment portion. Used for trigger evaluation.
`visible_amount`	Display value shown to players. May differ from current_amount due to smoothing and hidden increment.
`seed_amount`	Starting value after last drop. Recorded for reporting and audit.
`win_target`	Secret. CSPRNG-selected each cycle. Stored encrypted. Not visible to anyone without audit access.
`cycle_contributions`	Total contributions since last reseed. Resets on drop. Used for P&L and simulation calibration.
`cycle_number`	Increments on each reseed. Used for audit trail and cycle history reporting.
`total_contributions`	Lifetime total. Never resets. Used for financial reporting.

Contribution Split Example

Level	Split	Per €1.00 Bet	Per €10.00 Bet
Grand	40%	€0.0060	€0.0600
Major	25%	€0.0038	€0.0375
Minor	20%	€0.0030	€0.0300
Mini	15%	€0.0023	€0.0225

(Assumes 1.5% contribution rate, no house cut, coefficient 1.0)

Per-Game Coefficient

1.0 = standard contribution (default for all games)
2.0 = double contribution (promote specific games)
0.5 = half contribution (high-RTP or low-margin games)
0.0 = game participates and is visible but does not contribute

NoteCoefficient affects contribution TO pool but does NOT affect win eligibility by default. A player on a 0.5 game has the same chance of winning as a player on a 2.0 game (unless weighted selection is configured in Mode 2/3).

Seed Mechanics

Random Seed Range

Operator sets seed_from and seed_to. System selects random value within range for each new cycle. If equal, seed is fixed. Example: seed_from = 5000, seed_to = 8000 → pool reseeds at random value between €5,000 and €8,000.

Hidden Increment Carry-Over

If enabled, a percentage of the previous cycle's win amount is carried over and added to the seed of the new cycle. Creates naturally growing base amounts over time.

💡Hidden Increment in Action

Last win: €25,000. Hidden increment coefficient: 8%. Carry-over: €25,000 × 0.08 = €2,000 Next seed: random(5000, 8000) + 2000 = €7,000 to €10,000 Players see the Grand restart at a higher value. Over cycles, base amounts grow.

▶ WHY Why does the hidden increment carry-over exist? Why not just start each cycle at the same seed?

A jackpot that always resets to €5,000 is predictable. Players quickly learn: "It just dropped at €31,000, so it reseeded at €5,000 — not worth playing for hours now." This rational disengagement kills the product between cycles.

The hidden increment breaks this predictability. Part of the previous win amount adds invisibly to the next seed, so after a large drop the Grand might restart at €8,500 instead of €5,000. Players see a "higher than usual" starting amount without knowing why, which signals: something is different this cycle.

The word "hidden" is doing precise work here — it's not deceptive (the rules document can state that seeds vary by carry-over), but it prevents reverse-engineering of the exact seed amount from observable pool behavior.

Pre-Seed (Operator Funded)

For new or promotional jackpots, the operator funds the initial pool directly before contributions begin. Ensures attractive launch value. Pre-seed amounts tracked separately for financial reporting.

House Cut

Operator's margin applied BEFORE contribution split. Example: 1.5% rate with 10% cut means 1.35% reaches pools, 0.15% retained. Revenue tracked and reported separately.

▶ WHY Why build house cut into the contribution engine rather than pricing it separately?

Without house cut built into the engine, the only way to extract margin from jackpots is to: (a) keep contribution rates intentionally low (meaning slower pool growth = less excitement) or (b) pay out less than what players contributed (obvious and damaging). Neither works.

House cut applies BEFORE pool allocation, so the pool amount players see already reflects the true available prize pool. There is no gap between what the ticker shows and what can be paid. This also means that the financial reporting is clean: house cut revenue is a separate line, not buried in prize payouts.

The operator can set house cut to 0% for flagship jackpots that are loss-leaders for acquisition, and higher on promotional jackpots. This per-jackpot flexibility is what makes the system a financial instrument, not just a slot feature.

Multi-Currency

One pool per level per currency. Completely separate pools.
Currency-specific seed amounts, win ranges, bet thresholds.
Display in player's preferred currency.
No cross-currency pooling unless explicitly configured for network jackpots.

Part 4

Trigger, Drop & Anti-Prediction Mechanics

Win Target Selection

At each cycle start, the system secretly selects a win_target: a random value between win_from and win_to using a cryptographically secure PRNG. Not visible to anyone including operators (unless audit access). The RNG seed and selected target are stored in the audit log for each cycle.

CriticalWin target generated by CSPRNG. Must be auditable and reproducible given the seed. This is a regulatory requirement for RO.

Trigger Evaluation (7 Checks)

On every qualifying bet, after contribution processed, the engine evaluates in this exact sequence. ALL must pass:

Pool ≥ win_target? If no → stop. Pool hasn't reached target.
Triggering bet ≥ min_bet? If no → pool continues toward win_max.
Triggering bet ≤ max_bet? (if max_bet > 0) If no → continues.
Player ≥ min_spins? Has player placed enough qualifying bets in session?
Active players ≥ min_players? Enough concurrent players on qualifying games?
Current time in allowed window? If time/day restrictions configured.
Game eligible to trigger? Not contribution-only?

Criticalmin_players requires enough players are actively playing. It does NOT require all players to meet win conditions. Only the triggering player needs to meet personal conditions (min_bet, min_spins, segment, etc.).

💡Trigger Evaluation: Success vs Failure

Crown Fortune Grand: secret win_target = €27,463. Pool now at €28,100. SCENARIO A (FAIL): Player X bets €0.20 on qualifying game. Check 1: €28,100 ≥ €27,463 ✔ Check 2: €0.20 ≥ €0.50 (min_bet) ✘ FAIL Result: No drop. Pool continues growing. €0.20 still contributes to pool. SCENARIO B (SUCCESS): Pool now at €31,500. Player Y bets €1.00. All 7 checks PASS. → DROP TRIGGERED Overflow: €4,037 above target. Natural + unpredictable.

Win Max Safety Net

When current_amount reaches win_max: pool stops growing. New contributions buffer (or redirect to other levels, configurable). Trigger evaluation continues on every qualifying bet, checking conditions 2–7 only. Alert sent to operator (PoolApproachingMax then PoolAtMax events). Operator can: reduce min_players, extend win_max, force-drop, or relax conditions.

CriticalA pool at win_max for extended period is an operational problem. BO dashboard must visually highlight. Escalating alerts at 2h, 6h, 12h, 24h.

Must-Drop Condition Relaxation

For must-drop timing mode, conditions progressively relax as pool approaches Win Max:

At 90% of Win Max: relax min_players by 50%
At 95%: relax min_bet by 50%
At 98%: remove time-of-day restrictions
At 100%: drop to any eligible player regardless of conditions

NoteRelaxation thresholds and amounts are operator-configurable per level.

Anti-Prediction Mechanisms

Randomized win target: New secret value between Win From and Win To each cycle. Players cannot know the exact target.
Evaluation delay: After pool crosses target, system enters hidden 'armed' state. Triggers after random 1–N additional qualifying bets (configurable per level, default range 1–50). Creates natural overflow.
Condition-gated overflow: Trigger conditions naturally create variation. Pool crosses target at 4am with 3 players but min_players=20 → grows until peak hours.
Randomized warn thresholds: Warn From/To randomized per cycle. Visual transition happens at different amounts each time.
Variable ticker smoothing: Visible ticker uses 200–800ms variable display lag and rounds increments. Prevents reverse-engineering from micro-movements.

DevEvaluation delay count selected at cycle start (same CSPRNG as win target). Logged for audit. Cannot be influenced by real-time conditions.

Drop Timing Modes

Mode	Behavior
Range Drop	Standard: pool crosses target + conditions met + delay expired. Default for persistent progressives.
Must Drop	Guaranteed before Win Max (or deadline). Conditions progressively relaxed as pool approaches max.
Time Drop	Drops at specific deadline regardless of pool amount. For timed jackpots.
Manual Only	No automatic drops. Only operator force-drop. For live-streamed events.

Drop Cooldown

Optional minimum time between consecutive drops on same level. Prevents immediate re-drop after reseed if win_from is close to seed_to. Configurable in minutes (default 0 = no cooldown). During cooldown, contributions continue but trigger evaluation suspended.

▶ WHY Why are there 5 separate anti-prediction mechanisms? Isn't one enough?

Each mechanism closes a different attack vector:

Randomized Win Target prevents "pool tracking." Without this, a player who watches the pool grow across 50 cycles learns the average drop amount and bets heavily in that range.

Evaluation Delay prevents "pattern-of-overflow tracking." Even with a random target, a sophisticated tracker might study how much the pool typically overshoots the warn threshold. The delay adds a random 1–50 additional bets after the target is crossed, making the overflow genuinely unpredictable.

Condition-Gated Overflow is "free" anti-prediction — the min_players requirement naturally creates variable drop points depending on when enough players happen to be active.

Randomized Warn Thresholds prevents "warn-state sniping" — timing maximum bets for when the warn animation triggers, as if the animation is a precise signal of drop proximity. Randomizing the threshold means the animation gives a range, not a precise indicator.

Variable Ticker Smoothing prevents reverse-engineering the pool velocity by watching micro-movements. Without this, an attacker could calculate: "pool grows at €0.03/second → at current rate it crosses target in 40 minutes" — and time bets accordingly.

Professional jackpot abuse is a real industry problem. These five mechanisms work together. Removing any one creates a viable attack surface.

Warn State System

Calm

Blue · Standard ticker · No marketing

Heating

Yellow · Subtle glow · Push notification

On Fire 🔥

Orange · Pulse + flame · Lobby banner

Must Drop 💥

Red · Aggressive pulse · Homepage takeover

DesignerCalm is NOT static! Tickers ALWAYS increment smoothly. The difference between states is intensity, not activity vs inactivity. A calm jackpot looks alive. Sound (optional, player can mute): Calm=silent, Heating=ambient tone, On Fire=heartbeat, Must Drop=tension loop.

▶WHY Why warn states matter more than pool amounts

A jackpot at €38,000 is a number. A jackpot "On Fire 🔥" is a feeling. Players respond to narrative states, not data points. The warn system transforms mathematical proximity into emotional urgency.

Heating → "Something is building." On Fire → "It could happen any second." Must Drop → "It IS happening. The only question is whether I'm here."

Each state change also fires marketing triggers via the Campaign Automation Engine: Heating → push notification, On Fire → lobby banner, Must Drop → homepage takeover. The states drive both player psychology AND operational marketing.

▶ WHY Why four states, and why is 'Calm' never static?

The four-state progression is a narrative arc, not just a UX affordance. Stories need tension buildup. "The jackpot went from normal to exploded" is forgettable. "I watched it heat up, then catch fire, then I was there when it finally dropped" is a story you tell.

The Calm state is never static because a static counter is a dead counter. Dead counters are immediately distrusted — players assume they're fake or broken. The whole emotional engine depends on players believing this is live. The ticker must always increment, even slowly. The difference between Calm and On Fire is intensity, not activity.

Sound design (optional, player-controlled mute) follows the same principle: each state gets an audio layer that is present but not intrusive in Calm, building to the dramatic tension loop of Must Drop. The player's emotional state is being managed by ambient audio, not just visual cues.

Reference: Land-based slot machine designers have known for decades that the approach to a jackpot is more engaging than the jackpot itself. The warn system is the online equivalent of the "spinning lights" on a physical cabinet.

Operator Override Controls

Action	Behavior	Confirmation
Force Drop	Immediately triggers jackpot. Winner from active eligible players (or most recently active). Awards current pool amount.	Double confirmation + reason. Manager+
Delay Drop	Snoozes pending drop for N minutes/hours. During snooze, contributions continue but no drop occurs.	Single + reason. Manager+
Cancel Drop	Voids current win_target. System generates new random target. Pool continues from current amount.	Single + reason. Manager+
Pause / Resume	Stop/restart contributions. Display freezes during pause. Contributions buffer for later application on resume.	Single. Operator+
No-Win Mode	Pool grows and display updates, but no drops even when conditions met. For testing, pool building, migrations.	Single + reason. Admin only
Manual Adjust	Add or remove funds from pool directly. For corrections, pre-seeding, or transfers.	Double + amount + reason. Admin
Void Win	Reverses a completed win. Amount returns to pool. Pool does NOT reseed. Full audit trail with mandatory reason.	Triple + reason + supervisor co-approval. Admin

AuditEvery override action logged: operator ID, timestamp, reason, before/after state, IP address. No exceptions.

Part 5

Player Qualification & Eligibility

Qualification is evaluated at two distinct moments: (a) during contribution processing (does this bet feed the pool?) and (b) during trigger evaluation (can this player WIN?). These are separate checks.

Contribution eligibility: game in list, bet type accepted, player not excluded. No bet size minimum for contributions.

Win eligibility requires ALL conditions met simultaneously:

Condition	Description	Default
Min Bet	Triggering bet ≥ level's min_bet	0 (none)
Max Bet	Triggering bet ≤ level's max_bet (0 = no limit)	0 (none)
Min Spins	Player ≥ min_spins qualifying bets in session	0
Min Players	Active players ≥ min_players on qualifying games	0
Active Status	Last qualifying bet within active_window seconds	60s
Game Eligible	Game can trigger wins (not contribution-only)	All
Player Segment	Player in qualifying segment (VIP, tag, etc.)	All
Not Excluded	Not on exclusion list or self-excluded	Not excluded
Jurisdiction	Player's jurisdiction allows participation	All
Time Window	Current time within allowed drop window	24/7

Active Player Tracking

Active player = qualifying bet within last N seconds (active_window, default 60s). Maintained as sliding window counter in Redis. Updated on every qualifying bet. This count is also displayed to players: "2,418 players chasing" — updated via WebSocket every 5 seconds.

Part 6

Distribution Intelligence — All Four Modes

The brain that decides who wins, when, and why.

ComplianceDifferent jurisdictions have different rules about prize distribution. The system implements four distribution modes. The operator's legal team decides which mode is active per jurisdiction. The system enforces the selection and prevents violations.

Every jackpot carries a compliance_profile defining: jurisdiction code, distribution mode, allowed weight factors, prohibited actions, certification requirements. The system rejects any configuration that violates the active profile.

Pure RNG

Equal probability for all eligible. No behavioral influence. CSPRNG certified.

UK, Sweden, Denmark, NL

2 ★

Behavior-Weighted

Engagement metrics influence probability. Higher engagement = higher chance.

★ PRIORITY — Curaçao + Romania

3 ★

Operator-Directed

Full control. Segment targeting. Star player boost. Jackpot as promotional tool.

★ PRIORITY — Curaçao only

Hybrid

Different modes per jackpot on same platform. Production standard.

Any market

▶ WHY Why separate contribution eligibility from win eligibility at the engine level?

This distinction solves a specific problem: pool growth vs. prize fairness are in tension.

For maximum pool growth, you want every bet from every player on every game contributing. More money in = bigger numbers = more excitement. No restrictions.

For prize fairness (and abuse prevention), you want win eligibility to require meaningful engagement: minimum bet size, enough spins, correct jurisdiction, appropriate player segment, etc.

If you use a single eligibility check, you must choose one or the other. Separating them solves both simultaneously: anyone can feed the pool, but only engaged players with appropriate stakes can win. This is also how some progressive slot systems work in regulated land-based environments — all bets of any denomination build the meter, but only max-bet qualifies for the jackpot.

Mode 1: Pure RNG

Three-layer model: (1) CSPRNG win target at cycle start, (2) eligible player snapshot at trigger moment, (3) uniform random selection from pool. Each player has exactly 1/N probability. No weights.

Sub-option: Trigger Player Mode — the player whose bet triggered the drop wins. No selection algorithm. Direct cause-and-effect. Most common for certified progressives.

CSPRNG externally certifiable (eCOGRA, iTech Labs, BMM, GLI)
RNG seed and all values logged for audit and reproducibility
No backdoors, no overrides, no behavioral influence on selection

▶WHY Why 4 modes instead of just "fair random"?

The industry already operates with varying distribution philosophies. Higher bet levels receiving higher RTP is legal, certified, and standard in many markets. Tombola systems award prizes proportionally to ticket count — more tickets, more chances. Legal everywhere.

In some jurisdictions, jackpots can be classified as promotional tools, giving operators full discretion over distribution. In others, strict RNG certification is mandatory. Same product, different rules, different configuration.

The system doesn't choose one philosophy. It provides configurable tools. The operator's legal team decides which tools are used where. The architecture is a spectrum, not a binary choice. Setting all Mode 2 coefficients to 0.0 reduces it to Mode 1.

Mode 2: Behavior-Weighted RNG ★ PRIORITY

Same three layers as Mode 1, but Layer 3 uses weighted random selection. Higher engagement = higher probability. Legal because it weights behavior patterns, not individuals.

Weight Factors

Factor	Logic	Default Coeff
Bet Size	Triggering bet / average bet. Higher bet = higher weight.	0.3
Contribution Volume	Player's contribution this cycle / average. More contributed = higher weight.	0.2
Session Presence	Active session duration. Longer = higher weight.	0.1
Bet Count	Qualifying bets this cycle. More bets = higher weight.	0.15
Loyalty Tier	VIP/loyalty tier mapped to multiplier.	0.1
Recency	Time since last qualifying bet. More recent = slightly higher.	0.05

player_weight = 1.0 + (bet_factor × 0.3) + (contrib_factor × 0.2) + (session × 0.1) + (bets × 0.15) + (loyalty × 0.1) + (recency × 0.05)

Each factor = player_value / average_value_across_pool. Base weight 1.0 ensures every eligible player always has a non-zero probability.

💡Mode 2: Weighted Selection — 3 Players

3 eligible players at trigger moment: Player A: €5 bet | €120 contributed | 2h session → weight: 1.0 + (0.45×0.3) + (0.30×0.2) + ... = 2.35 → win prob: 38.9% Player B: €2 bet | €80 contributed | 1h session → weight: 1.0 + (0.30×0.3) + (0.20×0.2) + ... = 1.75 → win prob: 33.3% Player C: €0.50 bet | €15 contributed | 15min → weight: 1.0 + (0.15×0.3) + (0.10×0.2) + ... = 1.25 → win prob: 27.8% Player C still has 27.8% chance — higher engagement = higher probability, but nobody is eliminated. Setting all coefficients to 0.0 reduces Mode 2 to Mode 1 (pure 1/N probability). Romania config: Bet Size (0.3) + Contribution (0.2) only. Other factors at 0.0. Curaçao config: All 6 factors active at default coefficients.

ComplianceMode 2 weights BEHAVIOR PATTERNS, never individual identities. The system must never allow "Player ID X gets higher weight." Always "players who bet more get higher weight." The distinction is between rewarding a class of behavior and targeting a specific person.

▶ WHY Why is Mode 2 the priority mode, not Mode 1?

Mode 1 (Pure RNG) treats every eligible player as identical. In a room of 500 players where one person has bet €500 and another has bet €0.50, each has the same 1/500 probability of winning. This is mathematically clean and legally unimpeachable — but it is not how any other reward system in gambling works, and players intuit this unfairness.

Mode 2 answers the question: "Why did someone who just sat down win the Grand jackpot while I've been playing for two hours?" With behavior-weighted selection, the two-hour player genuinely has higher probability. Not guaranteed — the €0.50 player still has a chance — but proportional to their engagement.

This mirrors Novomatic's dual-RTP model (certified, widespread in land-based) and Tombola's ticket-count model. It rewards loyalty without eliminating luck. From a retention standpoint, players who feel their investment matters will play longer and deposit more.

Legal note: Mode 2 weights behavioral patterns (class of behavior), never individual identities (specific people). The distinction matters in regulation. "Players who bet more have higher win probability" is a rule about behavior. "Player #12345 has higher probability" would be manipulation.

Mode 3: Operator-Directed ★ PRIORITY (CW)

Full operator control for jurisdictions where jackpots are classified as promotional tools.

Segment targeting: VIP-only, new-player-only, high-value segment
Custom weight formulas: deposit history, lifetime value, days since last win
Star player boost: CRM-identified high-potential players get configurable weight multiplier
Guaranteed winner rules: "a VIP must win Grand at least once per week"
Win frequency caps: no player wins more than N times per period
Time-of-day targeting: drops preferentially during peak hours

💡Mode 3: Rules Engine (CW VIP Diamond)

IF player_segment = 'VIP_Gold' THEN weight × 1.5 IF player_lifetime_deposits > €10,000 THEN weight × 1.3 IF player_days_since_last_jackpot_win > 30 THEN weight × 1.2 IF current_hour BETWEEN 19 AND 23 THEN drop_probability × 1.5 IF player_wins_this_month >= 3 THEN weight × 0.5 (cool down) Rules weight BEHAVIOR PATTERNS, not individual player IDs. Every eligible player retains non-zero probability.

ComplianceMode 3 only activates in jurisdictions where the compliance profile explicitly allows it. System rejects Mode 3 for Romania compliance profiles.

▶ WHY Why is Mode 3 only for Curaçao, and what's the commercial case for it?

In Romania, jackpots are classified as games of chance and subject to ONJN oversight. Distribution must be demonstrably fair with auditable RNG. Operator discretion in prize distribution is not permitted.

In Curaçao (and many other jurisdictions), jackpots can be classified as promotional tools — closer to a loyalty program than a game of chance. In this classification, the operator has discretion over how prizes are allocated, the same way a poker room can choose who to invite to a VIP freeroll.

The commercial case is powerful: Mode 3 transforms jackpots into precision CRM instruments. Instead of hoping a VIP player happens to win organically (which might not happen for months), the operator can ensure: "Our top 50 players by LTV each win at least one jackpot per month." This creates predictable, budgeted loyalty spend with visible ROI — as opposed to jackpot prize money that might land on a one-time depositor who churns immediately.

The star player boost, win frequency caps, and time-of-day targeting all serve the same goal: jackpots as retention tools, not just entertainment features.

Mode 4: Hybrid (Production Standard)

💡Hybrid: Same Platform, Multiple Modes

Crown Fortune (Persistent) → Mode 2 — behavior-weighted, all markets Mystery Drops (Mystery) → Mode 1 — pure RNG certified Daily Blitz (Timed) → Mode 2 — behavior-weighted VIP Diamond (Promotional) → Mode 3 — operator-directed, CW only Weekend Thunder (Promotional) → Mode 3 — operator-directed, CW only Mega Cascade (Persistent) → Mode 2 — behavior-weighted, all markets Same engine. Different compliance profiles per jackpot. System enforces: Mode 3 logic cannot influence Mode 1 jackpots.

Part 7

Winner Selection, Payout, Waterfall & Chain Reaction

Selection Methods

Trigger Player: bet that triggered the drop wins. Direct cause-and-effect. Default for Mode 1.
Random Eligible: random from active pool. Equal probability (Mode 1) or weighted (Mode 2/3).
Weighted Random: weighted by configured factors. Default for Mode 2 and 3.
Multi-Winner Split: pool divided among N winners. Split configurable (50/30/20 or equal).

Payout Flow (10 Steps)

Lock level → DROPPING state. No further trigger evaluations. Contributions queue.
Record win to database: winner, amount, jackpot, level, game, brand, trigger_bet_id, method, timestamp.
Large win check: if amount > large_win_threshold → flag for manual approval. Pause payout.
Tax calculation: jurisdiction-dependent withholding. Net payout = win_amount − tax.
Credit to wallet: CreditJackpotWin command: player_id, amount, currency, wagering_requirement.
Confirm credit: wait for wallet confirmation. On failure → retry queue (exponential backoff).
Process Chain Reaction: select consolation winners, credit their prizes simultaneously.
Publish JackpotWon event: consumed by real-time gateway, CRM, reporting.
Reseed: new seed (random + hidden increment carry-over). New win_target. Status → ACTIVE. Apply buffered contributions.
Publish JackpotReseeded event: frontends update to show new starting amount.

Wagering requirements: configurable per jackpot. 0x = clean cash (default), Nx = player must wager N times before withdrawal.

Failed Win Handling

Scenario	Handling
Player disconnected	Win credited to wallet. Notification on next login.
Account suspended	Win held in escrow until resolution. Reinstated → credited. Closed → operator decides.
Wallet fails (all retries)	PENDING_MANUAL_RESOLUTION. Operator: retry, void, or alternative payout.
Operator voids win	Amount returns to pool. Pool does NOT reseed. Continues from pre-drop amount. Full audit trail.
Declined in approval queue	Mandatory reason. Fallback winner selection triggered (configurable). If disabled: returns to pool.
Approval expires (72h)	Follows decline logic. Escalating alerts at 24h, 48h, 72h.

Waterfall Cascade

When enabled: Grand drops → automatically triggers Major → triggers Minor → triggers Mini. Four winners in seconds.

Waterfall enabled: toggle per jackpot
Cascade delay: seconds between drops (0 = simultaneous, 3 = dramatic sequence)
Winner mode: independent (different winner per level) or same (one winner gets all)
Cascade scope: full (all levels) or partial (Grand triggers Major only)

💡Waterfall: Crown Fortune Cascade (3-second delay)

T+0s: GRAND drops. Player A wins €31,500. Full-screen celebration. T+3s: MAJOR drops. Player B wins €3,200. Broadcast toast to all players. T+6s: MINOR drops. Player C wins €340. Second broadcast. T+9s: MINI drops. Player D wins €35. Third broadcast. T+9s: Chain Reaction fires: 8 additional players receive €50–€500 each. 12 WINNERS in 9 SECONDS. Activity feed floods with win events. All 4 pools reseed. 'NEW CYCLE' animations fire on all levels.

DesignerDesign as ONE continuous celebration: Grand BURST → Major WAVE → Minor RIPPLE → Mini SPARKLE. Think dominos falling. Sound design: rising crescendo across all 4 drops. Recommendation: use Waterfall on 1–2 flagship jackpots only to maintain dramatic impact.

Chain Reaction

Bonus prizes for other active players when a jackpot drops. Per-level configuration:

Prize count: 1–10 recipients per drop
Prize amounts: fixed per slot, graduated (€500, €250, €100, €100…)
If fewer active players than prizes: distribute what's available, unclaimed prizes not awarded
Prizes credited simultaneously with main prize

Chain Reaction Distribution Modes

Mode	Behavior	Jurisdiction
Random	Pure random from eligible non-winners	Mode 1 markets
Weighted	Higher contributors have higher probability	Mode 2
Proximity	Players "closest" to triggering (by contribution rank). Creates "almost won" narrative.	Mode 2/3
Targeted	Operator defines which segments receive prizes.	Mode 3

💡Chain Reaction: What Each Player Sees

WINNER: Full-screen takeover. Amount reveal animation. "Congratulations!" CHAIN REACTION RECIPIENT: Toast notification: "✨ Luck touched the room! You received €250!" ALL OTHER PLAYERS: Toast: "🏆 Pl***rA won GRAND €31,500! +8 bonus prizes awarded!" COPY RULE: NEVER say "consolation prize". ALWAYS say "bonus prize" or "luck touched the room." The recipient must feel visited by luck, not given a second-place award.

▶ WHY Why Chain Reaction instead of just keeping the prize for one winner?

When a jackpot drops, one player wins. The other 499 active players experience loss. Loss aversion is one of the strongest forces in behavioral psychology — losing (or near-missing) typically hurts twice as much as an equivalent win feels good.

Chain Reaction interrupts the loss frame before it forms. Instead of processing "I didn't win," the player receives a notification: "Luck touched the room. You received €100." This is not a consolation prize — the language specifically avoids that framing. It is a shared luck event. The room wins together, not one person wins while everyone else loses.

The effect on session length is measurable in systems that implement this. Players who receive Chain Reaction prizes continue playing at meaningfully higher rates than non-recipients at the same moment. The €100 prize likely generates €300+ in incremental GGR from extended sessions.

Secondary effect: Chain Reaction creates witnesses. Every player in the session sees the drop happen and receives something. Now they have a story: "I was playing Crown Fortune when it dropped, and I got €100 from it." That story is worth more in word-of-mouth marketing than any banner ad.

Part 8

Back Office

The control center. 14 modules for complete jackpot management.

Core PrincipleOperators must launch a new jackpot in under 15 minutes. Any live intervention in under 30 seconds. No developer, database query, or deployment needed. Ever.

▶ WHY Why 'under 15 minutes' and 'under 30 seconds' as design benchmarks?

These are not aspirational targets — they are product requirements that define the BO's purpose. Here's why they matter commercially:

A jackpot on Friday that could have launched Monday but waited until Thursday (because the operator had to log a developer ticket, wait for deployment, then QA) missed an entire weekend of potential revenue. At €500/hour house cut on a popular jackpot, a 3-day delay costs €36,000 in missed opportunity.

The 30-second intervention target is about live crisis management. When a Grand jackpot sits at Win Max at 3am with zero players and the operator needs to force-drop before morning to reset the cycle for peak hours — they need to be able to do that from a phone. Not by calling an engineer. Not by waiting for a deployment window. Right now, in 30 seconds.

The rule that "no jackpot action should require a developer" is also a talent management decision. Jackpot operations should not require scarce engineering time. If it does, engineers will be constantly interrupted for routine tasks, and operators will be constantly frustrated waiting for them.

Portfolio Dashboard

Home screen. Live grid of all active jackpots. Each card: name, theme icon, pool values per level, active players count, warn state (color-coded: Calm/Heating/On Fire/Must Drop), drop range progress bar, time remaining (if timed), quick action buttons (Pause, Force Drop, Config).

Filter: brand, type (persistent/timed/promotional/mystery), status, warn state
Sort: pool size, closest to drop, most active players, most recent creation
Alert Center: Pools at Win Max (RED), approaching max (ORANGE), approval queue pending (YELLOW), scheduled jackpots activating (INFO)
Activity Feed: drops, chain reactions, warn changes, operator actions — all clickable to jackpot detail

💡Dashboard: What the Operator Sees

Recent Activity Feed

A live feed showing the most recent jackpot events across the system:

Jackpot drops: who won, how much, which game, which jackpot
Chain Reaction prizes awarded (count and total amount)
Warn state changes (Calm → Heating, etc.)
Operator actions: paused by X, force-dropped by Y
New jackpots activated or reseeded

NoteAll items in the activity feed link directly to the relevant jackpot's detail page. The feed serves the same real-time awareness purpose as Newton's Operations Journal, but live and clickable.

Creation Wizard (7 Steps)

NoteAll jackpots start as DRAFT. Require explicit confirmation to go ACTIVE. This prevents accidental launches.

Step 1: Identity & Type

Jackpot name (display + internal), type (Persistent/Timed/Promotional/Mystery), brand(s), currency(ies). Optional: load from template to pre-fill all steps.

Step 2: Level Configuration

Define levels (minimum 1, no maximum). Per level: name, display order, seed_from/to, win_from/to, win_max, contribution_split %, warn_from/to, hidden_increment (enable + coefficient), chain_reaction (enable + count + amounts + distribution mode), waterfall config, range_display, integer_wins_only, lock_on_win, auto_reset_seconds. Visual split indicator validates sum = 100%.

Step 3: Game Participation

Browse by provider (expandable with game count) or category. Search by game name/ID. Bulk select by provider or category. Per-game: contribution coefficient (default 1.0) and trigger eligibility toggle. Per-level game exclusion list.

Step 4: Player Eligibility

Min/max bet per currency, accepted bet types (real/bonus/both), min spins, min active players, active window (seconds). Player segments, country/jurisdiction checklist with flags, player exclusion list, KYC verification toggle.

Step 5: Trigger Configuration

Winner selection method, multi-winner split config, timed drop settings (deadline, timezone), time-of-day and day-of-week restrictions, drop cooldown, wagering requirement on wins, large win threshold for manual approval.

Step 6: Theme & Content

Theme: key image, icon, background, color palette (presets + custom hex), font, per-level visuals (icon/badge/color/name), animation style, total prize pool display toggle + label. Content: multi-language descriptions, rules, win messages with template variables ({jackpot_name}, {level_name}, {current_amount}, {win_amount}, {time_remaining}, {player_name}). Set default language. Live preview: desktop + mobile side by side.

Step 7: Review & Launch

Desktop/mobile/in-game preview. Full config summary. Validation checklist (splits sum to 100%, ≥1 game, ≥1 currency, ≥1 brand). Launch options: Activate Now, Schedule Activation, Save as Draft. Save as Template option. Simulation available before launching.

▶ WHY Why a 7-step wizard with DRAFT-first, not a single config form?

A single config form with 80+ fields is paralyzing. It front-loads every decision simultaneously — seed ranges, win targets, game lists, eligibility rules, content translations, theme assets — before the operator has a clear picture of what they're building.

The 7-step wizard enforces a natural decision hierarchy: identity before mechanics, mechanics before content, content before launch. Each step is completeable in isolation. An operator can define the levels (Step 2) without having decided which games to include (Step 3). This dramatically reduces abandonment of half-configured jackpots.

DRAFT-first prevents accidental launches. This happened to a major operator using an earlier jackpot system — a jackpot in test configuration was accidentally activated because the save button also published. With DRAFT-first, there is an explicit "Are you sure you want this live?" confirmation gate. Potentially millions of euros of liability prevented by one design decision.

The template system solves the experienced operator's frustration: once you've launched Crown Fortune successfully, you want to clone it for a new market in 2 minutes, not rebuild from scratch in 15.

Configuration Panel

Edit any aspect of existing jackpot. Changes apply: Immediately, Next Cycle, or Scheduled.

Warning SystemImpact warnings on live changes: reducing Win From below current pool, changing splits mid-cycle, removing games during active sessions, changing eligibility rules that disqualify current players. All changes logged with operator ID, timestamp, before/after, reason.

Change Apply Timing Options

Timing Option	When Applied	Use Case
Immediately	Next qualifying bet after save	Emergency corrections, bug fixes. Use with caution on live jackpots.
Next Cycle	After current drop and reseed complete	Standard config updates. Allows current cycle to complete naturally.
Scheduled	Operator-specified datetime	Planned changes (new week, new campaign). Prepared in advance.

CriticalChanges to win ranges or contribution splits while a pool is within 10% of win_target trigger an additional confirmation dialog with impact preview. All changes logged in audit trail with operator identity, before/after state, reason, and apply timing chosen.

Change Impact Warnings

Reducing Win From below current pool: Warning — jackpot may drop immediately on next qualifying bet.
Changing contribution splits mid-cycle: Warning — existing pool amounts remain; new splits apply to future contributions only.
Removing games while players are active: Warning — active sessions contribute until session ends, then game is excluded.
Changing eligibility rules: Warning — currently qualifying players may be immediately disqualified.

Live Jackpot Monitor

Current pool value per level, per currency. Primary currency prominent.
Contribution velocity: amount per minute/hour. Trend indicator (↑ increasing, → stable, ↓ decreasing).
Active players count, qualifying spins this cycle.
Warn state with timestamp of last state change.
Predicted drop window: estimated time until drop based on velocity and distance to target. Displayed as range (e.g., "2–4 hours").
Drop range chart: visual showing pool position relative to Seed, Win From, Win To, Win Max.
Cycle history: timeline of all cycles — seed, growth, drop, winner, duration.
Real-time event stream: aggregated contributions, player joins, warn changes, operator actions.
Player activity table: masked ID, game, session duration, contribution, spins, eligibility per level.

Winner Approval Queue

Wins above large_win_threshold require operator approval. Tabs: All, For Approval (default), Paid, Declined/Expired. Columns: timestamp, jackpot/level, masked player + ID link, base currency amount, player currency amount, game, brand, Approve/Decline/Review buttons.

Decline requires reason. Triggers fallback winner selection (configurable). If disabled: returns to pool. Expiry: 72 hours with escalating alerts at 24h, 48h, 72h.

Campaign Templates

Reusable presets storing all config. Operators deploy in minutes.

Template	Configuration
Daily Must Drop	Timed, 1 level, drops within 24h, low seed, resets daily at midnight.
Classic Progressive	Persistent, 4 levels (Grand/Major/Minor/Mini), standard splits 40/25/20/15.
Mystery Drops	Mystery type, 3 levels, hidden tiers, medium seed, warn enabled.
VIP Exclusive	Persistent, VIP segment only, higher min bet, larger seeds, chain reaction.
Weekend Thunder	Promotional, Friday 18:00 to Sunday 23:59, must drop before deadline.
Happy Hour Blitz	Promotional, 2-hour window, fast cycle, low Win Max, multiple quick drops.

Theming Studio

Each jackpot is a branded product. Components: key image, icon, background, color palette (presets: Red/Purple/Dark/Green/Custom + hex), font, per-level visuals (icon/badge/color/name/subtitle), animation style, total prize pool toggle + label.

CriticalAny theming change must render immediately in live preview. Desktop and mobile previews side by side.

Content Manager

Multi-language rich text editor. Per-language: title, subtitle, description, rules, win message, chain reaction message. Default language fallback. Auto-detect player browser language. Variables: {jackpot_name}, {level_name}, {current_amount}, {min_bet}, {max_amount}, {time_remaining}, {player_name}, {win_amount}.

Budget Model

Per-jackpot P&L view accessible from Dashboard and Configuration Panel.

Line Item	Source / Calculation	Classification
Gross Contributions	Sum of all bet contributions before house cut	REVENUE
House Cut Retained	Gross × house_cut %	REVENUE (margin)
Net Pool Contributions	Gross − house cut	POOL INFLOW
Pre-Seed Investment	Operator-funded seeds	COST
Prizes Paid (Main)	All main jackpot wins	COST
Prizes Paid (Chain)	All chain reaction prizes	COST
Manual Adjustments	Net of operator add/remove	VARIABLE
Net Position	House Cut + Adj − Seeds − Prizes	BOTTOM LINE

Expected Value Per Cycle

Avg Seed Cost: (seed_from + seed_to) / 2
Avg Prize: (win_from + win_to) / 2
House Cut Per Cycle: (avg_prize − avg_seed) / (1 − house_cut) × house_cut
Net Per Cycle: house_cut − chain_cost − hidden_increment_cost
Est. Cycle Duration: contributions_needed / velocity_per_hour
Monthly Net: net_per_cycle × (720h / cycle_duration)

Budget Alerts: negative net position, cycle exceeds 150% expected, chain costs > 20% of house cut, pre-seed > house cut over 30 days.

▶ WHY Why is a built-in P&L model a hard requirement, not a nice-to-have?

Without financial visibility, jackpot management drifts toward instinct and vanity metrics: "Our jackpot looks popular" while the house cut is covering 40% of the prize cost and the rest is pure subsidy.

The most common jackpot operations mistake is confusing player engagement with profitability. A jackpot dropping every 3 hours creates genuine excitement and high participation — and might simultaneously be costing the operator €2,000/month more than it generates. Without a P&L view per jackpot, this is invisible until someone runs the quarterly numbers.

The budget model prevents two specific failure modes:

(1) Overly generous configuration: house cut too low, chain reaction prizes too high, hidden increment carrying too much. The jackpot is popular but subsidized.

(2) Under-configured for excitement: house cut 25%, contribution rate 0.5%, prizes small. Financially "safe" but players find it unexciting and don't participate — meaning the jackpot generates no GGR uplift either.

The budget model is the instrument that lets you find the configuration space between these failure modes.

Budget Constraint Mode

Optional hard limits operators can set as safety nets against misconfiguration:

Maximum monthly cost: If total prizes minus house cut exceeds threshold, system alerts and optionally pauses new jackpot activations
Maximum single prize: Hard cap on any single win amount (in addition to win_max per level)
Maximum chain reaction budget per month

NoteBudget constraints are safety nets only. They do not replace proper configuration. They catch misconfiguration before it becomes expensive.

Simulation Engine

Monte Carlo simulation: 1,000+ virtual cycles using proposed config + actual platform data (avg concurrent players, bets/hour, avg bet size, bet distribution, peak/off-peak profile). Run before launching any jackpot with significant pre-seed.

Outputs: avg cycle duration (with range), drop frequency, Win Max hit rate (target < 5%), house cut/month, total prizes/month, net position, warn state dwell time, condition failure analysis. Side-by-side comparison of up to 3 scenarios.

💡Simulation Warnings

Avg cycle < 1 hour → Drops too often. Players won't build excitement. Increase Win From. Avg cycle > 7 days → Stagnates. Players lose interest. Decrease Win To or increase rate. Win Max hit > 10% → Conditions too restrictive. Reduce min_players or time window. Net negative → Costs more than earns. Increase house cut or reduce chain prizes. Warn < 5% of cycle → Players barely feel urgency. Lower Warn From percentage. Drop > 2× Win To → Consistent overflow. Review trigger conditions.

▶ WHY Why Monte Carlo simulation before launch? Can't you just watch how it performs live?

You can — but "watching live" means real players experiencing a misconfigured jackpot. The three worst outcomes of misconfiguration are:

Drops too frequently at tiny amounts: Players see the Grand jackpot "won" for €800 instead of €40,000 and stop caring about it. The jackpot brand is damaged before it establishes itself. Fixing this requires a configuration change and a full cycle reset while players have already formed a negative impression.

Never drops (frozen pool): min_players = 50 on a brand with 200 daily active users on jackpot games means the Grand jackpot grows to win_max and sits there. Every day players see a jackpot "worth €58,000" and feel the system is rigged. Operators face support tickets, complaints, and eventual regulatory risk if the pool never pays out.

Costs far more than expected: Chain reaction prizes of €500/€250/€100 × 8 recipients per drop = €1,600/drop. If the jackpot drops 3 times/day, that's €4,800/day in chain reaction costs alone. The simulation catches this before €144,000 has been distributed in month one.

Monte Carlo with 1,000 simulated cycles using actual platform data gives a realistic probability distribution of these outcomes. The launch decision becomes data-driven, not hopeful.

Simulation Outputs

Output	What to Watch For
Avg cycle duration (min/max range)	Too short (<2h) = over-drops. Too long (>30d) = player disengagement.
Avg prize amount + distribution histogram	Clustering near win_from = predictable. Spread = healthy.
Drops per week / per month	Calibrate marketing cadence and budget expectations.
Win Max hit rate	Target <5% of cycles. Above 10% = conditions too restrictive.
House cut per month / total prizes per month	Core P&L forecast. Compare to budget model.
Net operator position	Positive = self-funding. Negative = subsidized.
Warn state dwell time per cycle	Target 15–90 min. Shorter = urgency not building.
Condition failure analysis	Which conditions (min_bet, min_players, time window) block drops most often and by how much.

Simulation Visualizations

Pool Growth Chart: simulated pool value over time showing seed, growth curve, warn zone, and drop point for multiple representative cycles overlaid
Drop Amount Distribution: histogram of drop amounts across all simulated cycles
Cycle Duration Distribution: histogram of cycle lengths (days/hours)
Monthly P&L Forecast: bar chart of projected revenue vs cost per month
Condition Failure Heatmap: which conditions block drops most often, by hour of day

What-If Scenarios

Side-by-side comparison of up to 3 configurations before going live:

💡What-If: Three Configs Compared

Scenario A: Current config (rate 1.5%, min_players=20, Win To €40k) Scenario B: Higher rate (2.0%, min_players=20, Win To €40k) Scenario C: Wider drop range (rate 1.5%, min_players=10, Win To €35k) Results (1,000 simulated cycles each): A: Avg cycle 8.4d | Avg prize €28k | Win Max hits: 12% ⚠ | Net: +€1,200/mo B: Avg cycle 5.2d | Avg prize €27k | Win Max hits: 4% ✓ | Net: +€2,100/mo C: Avg cycle 6.1d | Avg prize €24k | Win Max hits: 3% ✓ | Net: +€1,800/mo Recommendation: Scenario B solves Win Max pressure and improves net position.

Configuration Warnings from Simulation

Warning	Threshold	Suggested Fix
Win Max hit rate too high	> 10% of cycles	Relax min_players, widen time window, or reduce win_max
Cycle too short	Avg < 2 hours	Reduce contribution rate or raise win_from
Cycle too long	Avg > 30 days	Increase contribution rate, lower win_to, or relax conditions
Net position negative	Expected cost > house cut	Increase house cut, reduce chain reaction amounts, or reduce prize range
Pre-seed exceeds house cut	Pre-seed > 30-day house cut	Reduce pre-seed or increase contribution rate

NoteSimulation is accessible from Creation Wizard Step 7 and as a standalone tool. Running a simulation is strongly recommended for any jackpot with a pre-seed investment above a configurable threshold (default €1,000).

Campaign Automation Engine

IF/THEN rules connecting jackpot events to marketing actions. Visual rule builder in BO — no code required.

Trigger Types

Warn state change, pool threshold, time trigger, player count, jackpot won, jackpot reseeded, lifecycle change, velocity trigger.

Conditions

Time-of-day window, day-of-week, brand, player segment, cooldown (min time between fires), minimum pool amount.

Actions

Push notification, email, SMS, lobby banner, homepage takeover, in-game overlay, social feed post, CRM tag/segment, webhook, activate jackpot from template.

💡Campaign Rules: Real Examples

RULE 1 — URGENCY PUSH:
  IF Grand enters 'On Fire' AND time 18:00–02:00 AND cooldown > 4h
  THEN push: "Crown Fortune at {amount} — On Fire!"
  THEN activate lobby banner

RULE 2 — WIN BROADCAST:
  IF any jackpot drops AND amount > €1,000
  THEN social: "{player} won {amount} on {level}!"
  THEN push to all active: "Jackpot just dropped! New cycle starting!"

RULE 3 — WEEKEND AUTO-LAUNCH:
  IF Friday 18:00
  THEN activate 'Weekend Thunder' from template
  THEN push: "Weekend Thunder is LIVE!"
  THEN homepage takeover banner

RULE 4 — STAGNATION ALERT:
  IF any pool at Win Max > 6 hours
  THEN alert operator
  THEN suggest: "Relax min_players or force-drop at next peak hour."

RULE 5 — DORMANT REACTIVATION:
  IF Daily Blitz pool reaches 90% of Win From
  AND player_segment = 'dormant_7_days'
  THEN email: "Daily Blitz is about to drop — will you be there when luck arrives?"

Safety: max 3 push notifications per player per day, 1h global cooldown, opt-out respect, kill switch for all automation, dry-run mode for testing, optional manager approval for rules reaching > N players.

▶ WHY Why automate marketing actions from jackpot events? Can't the CRM team handle this manually?

Manually: the CRM manager monitors jackpot states, identifies when the Grand enters "On Fire," logs into the push notification tool, writes a notification, selects the audience, schedules it, and sends it — in maybe 10–15 minutes if they're fast and paying attention.

By that time the jackpot might have already dropped. The On Fire window averages 18 minutes. The moment the notification lands, the urgency it describes no longer exists. Worse, sending "Grand jackpot On Fire!" right after it dropped creates confusion and erodes trust.

The Campaign Engine solves timing precision: the push notification fires within seconds of the warn state change, automatically, at 2am on a Sunday. No human needs to be awake. The jackpot works as a marketing instrument around the clock.

The safety systems (rate limits, cooldowns, opt-out respect, dry-run mode) exist because automated systems that reach thousands of players simultaneously are powerful and risky. A misconfigured rule could send 50,000 push notifications in 2 minutes. The kill switch and approval workflow are not optional — they are mandatory.

Campaign Automation Safety

CriticalCampaign rules can reach thousands of players instantly. The following safety measures are mandatory — not optional.

Rate limiting: Maximum 3 push notifications per player per day (configurable)
Global cooldown: Minimum 1 hour between any two campaign rule executions targeting the same player
Opt-out respect: All notification actions must check player communication preferences and consent status before sending
Kill switch: Global emergency disable for all campaign automation rules simultaneously
Dry-run mode: New rules show what WOULD happen without executing. Strongly recommended before activation.
Approval workflow: Optional manager approval gate for rules reaching more than N players (configurable threshold)

Campaign Integration Requirements

The Campaign Engine requires integrations with the following services:

Integration	Purpose	Reference
Push notification service	In-app and mobile push	Firebase, OneSignal, or equivalent
Email delivery service	Campaign emails, dormant reactivation	SendGrid, Mailgun, or equivalent
SMS gateway	High-priority alerts to opted-in players	Twilio or equivalent
CRM / Player data service	Segment resolution, consent lookup	Internal platform CRM
Frontend CMS	Lobby banners, homepage takeovers	Platform CMS API
Webhook delivery	External integrations, partner notifications	Standard HTTP webhooks

DevThe Campaign Engine subscribes to: JackpotWon, PoolUpdated, WarnThresholdReached, JackpotStateChanged, and PoolApproachingMax events from the bus. It evaluates rules against them in real time, within seconds of the event firing.

RBAC & System Controls

Role	Permissions
Viewer	Dashboard, monitor, reports. No configuration or actions.
Operator	+ pause/resume, approve/decline wins, manage content.
Manager	+ create/edit jackpots, configure games/eligibility, force/delay/cancel drops, templates.
Admin	+ no-win mode, manual adjustments, void wins (with supervisor co-approval), system controls, RBAC.
Custom	Granular permission selection from full permission list.

Multi-brand scoping: Operators scoped to assigned brand(s). Manager on Brand A cannot access Brand B. Admins can have cross-brand access.

Audit Trail

CriticalEvery action, every change, every win, every intervention logged permanently. Cannot be modified or deleted. Each record: timestamp (UTC), operator ID + name, action type, target entity, before state, after state, reason (mandatory for interventions), IP address.

Emergency Controls

Global jackpot pause: pauses ALL active jackpots simultaneously.
Emergency shutdown: deactivates entire engine. Bets queue. Requires admin + supervisor.
Health dashboard: service status, message bus lag, contribution processing latency.

Fraud Detection

Multi-accounting: same device/IP on same jackpot simultaneously
Bot detection: inhuman bet cadence or session patterns
Collusion: synchronized play to manipulate min_players conditions
Contribution manipulation: minimum bets in rapid succession to maximize eligibility
Win frequency anomaly: winning significantly more than statistical expectation

Detection triggers BO alerts. Operators investigate. System flags but does not auto-punish.

Part 9

Frontend — The Player Illusion Layer

The Jackpot Universe Page

A dedicated destination page accessible from main navigation. 20+ active jackpots displayed as a live, breathing environment. This is not a list. This is where luck lives.

Hero Section

Global stats, ALL live via WebSocket, updated every 5 seconds:

€2,847,391 in active pools · 4,218 players chasing · 37 won today · €284,000+ paid

Jackpot Radar (Sort Bar)

Closest to Drop (DEFAULT) — sniper sort, hottest targets first
Must Drop Soon — timed jackpots by remaining time
Largest Pool — biggest numbers first
Most Active — most players chasing. Social proof sort.
Recently Won — freshly reseeded, new cycle beginning
Hot Games — filter by player's favorites
By Type — Progressive / Mystery / Daily / VIP

Jackpot Card Grid

Responsive grid: 4 cards/row desktop, 2 tablet, 1 mobile. Each card: theme background image, jackpot name + type badge, level tickers (live animated), warn state badge with animation, progress bar (if range display configured), active players count, countdown timer (if timed), last winner line ("De***so won MAJOR €3,200"), "HUNT THIS JACKPOT" CTA button.

Sections: MEGA JACKPOTS, DROPPING TODAY, MYSTERY ZONE, QUICK DROPS, VIP EXCLUSIVE (teaser card for non-VIPs: "Unlock at VIP Level X"), JUST WON.

DesignerCards must NEVER look static. At minimum: tickers increment smoothly, player count updates every 5 seconds. Even "Calm" state looks alive. The difference between states is intensity, not activity vs inactivity.

▶WHY Why 20+ jackpots and why this specific layout?

In the Romanian market, players see 7+ different provider jackpots on one page — each with different visuals, different rules. They love the variety and the feeling that each one "hits differently."

We replicate that feeling with operator-owned jackpots. Crown Fortune feels different from Mystery Drops which feels different from Daily Blitz — different themes, different mechanics. But behind the curtain, it's all one engine with different configurations. And crucially, all drops go to our players, not to a global provider pool.

When a player lands on a page with 20+ active jackpots, the brain immediately thinks: "There are opportunities everywhere." It creates the same effect as a stock trading dashboard. It activates FOMO and hunting behavior. The "Closest to Drop" default sort puts the hottest targets first — players hunt jackpots like traders hunt markets.

Live Activity Ticker

Scrolling feed at the bottom or side of the page. The heartbeat of the environment:

💡Activity Ticker Examples

"Cr***ng just won GRAND €147,184 on Crown Fortune!" "Mystery Drops Minor just hit — €45 to Al***ex!" "Daily Blitz is On Fire — must drop in 2h 14m!" "Weekend Thunder just reseeded at €5,230!" "Crown Fortune: 3,200 players chasing right now"

▶ WHY Why a dedicated 'Universe' page instead of just listing jackpots in the lobby?

The lobby is a product catalog: games sorted by category. It optimizes for browsing and launching games. It is a functional interface. Functional interfaces do not create excitement.

The Jackpot Universe page is a destination. The design principle is "trading floor, sports betting dashboard, or lottery hall" — environments that communicate activity, urgency, and density of opportunity. When a player enters this page with 20+ live jackpots, each with animated tickers, warn states, player counts, and a scrolling winner feed — the psychological effect is immediate: things are happening right now and I might miss them.

This matters for SEO and marketing too. A dedicated page is linkable, shareable, and promotable. "Check out our jackpots page" is a call to action. "There are jackpots somewhere in the lobby" is not.

The "Closest to Drop" default sort is intentional anti-catalog design. Instead of alphabetical or "featured," the most exciting jackpots appear first automatically. Every page load surfaces the highest-tension opportunities without operator curation. The page is self-organizing around excitement.

Jackpot Detail Page

Reached by clicking a jackpot card. Header: theme background, name, all level tickers (live), warn state, active players, countdown. Three tabs below:

Tab 1: Games — Best Odds Sort ⚡

Signature FeatureNo competitor has this. Games sorted by trigger probability: contribution_coefficient × average_bet_size × active_players. Creates strategic hunting behavior. Players feel they have an edge.

💡Best Odds Game List

1. Gates of Olympus (Pragmatic) — 2x Contribution — 847 active — [HOT TRIGGER] 2. Sweet Bonanza 1000 (Pragmatic) — 1.5x — 612 active — [HIGH CONTRIBUTION] 3. Book of Dead (Play'n GO) — 1.2x — 445 active 4. Shining Crown (EGT) — 1.0x — 328 active Each tile: game thumbnail, provider, coefficient badge, active players, [PLAY] button. Labels: "HOT TRIGGER" (top 3), "HIGH CONTRIBUTION" (coeff > 1.5)

Tab 2: Leaderboard

Top Contributors: ranked by contribution this cycle. Masked name, bet count, total contributed. Updates in real time.
Recent Winners: last N winners. Masked name, level won, amount, game, timestamp. "Play This Game" button — launches the winning game directly. Exploits the belief that "lucky games" exist.

Tab 3: Rules

Description + rules from Content Manager in player's language. Qualifying criteria summary: min bet, eligible games count, jackpot type. Level details: name, current amount, range display (if configured).

My Jackpot Journey (Sidebar)

If player is logged in and has participated, shows personal stats:

Your contribution: €247 · Qualifying spins: 1,438 · Time chasing: 14h 32m · Rank: #47 of 2,418 · Eligible: Grand ✔ Major ✔ Minor ✔ Mini ✔

Designer"My Jackpot Journey" transforms anonymous participation into personal investment. The player sees PROOF they have been showing up and contributing. This reinforces the feeling: "I have earned my place in this hunt."

▶ WHY Why is the 'Best Odds' game sort described as a signature feature? What's the strategic value?

Every casino shows jackpot games. No competitor sorts them by trigger probability. This creates a strategic positioning difference: competitors present jackpots as passive luck. We present jackpots as hunts where skill (game selection) matters.

The player who sorts by "Best Odds" and picks the top game feels like a hunter, not a passive participant. They believe their choice increased their probability. Psychologically, this is the difference between a lottery (passive, low engagement) and poker (active, high engagement). Whether the probability difference is actually large doesn't matter — the feeling of strategic agency dramatically increases session length and return rate.

The "Play This Game" button on recent winners exploits the "hot game" fallacy — the belief that games that recently paid out have something special about them. Rational? No. But it is deeply human behavior, and the UI should work with human nature, not against it.

No major aggregated jackpot (Pragmatic Jackpot Play, EGT Bell Link, SOFTSWISS) offers per-game trigger probability sorting because they don't control the game-level coefficients. We do. This feature is only possible with an operator-owned jackpot engine.

Widget System — 6 Types

All widgets are WebSocket-connected, embeddable with a single HTML tag, responsive, and under 50KB gzipped. The six types cover every surface in the casino ecosystem.

Lobby Ticker Bar: Horizontal bar, 3–6 jackpot levels with live amounts. Auto-rotates between multiple jackpots.
Vertical Stack: Levels stacked top-to-bottom. Grand on top, Mini on bottom. Per-level icons and colors.
Mini Card: Compact, single jackpot. Name, top-level amount, warn state, CTA. For category pages.
In-Game Overlay: Top of game frame or floating corner. Compact tickers, expandable on click. Warn animations when On Fire / Must Drop. Full takeover on win event.
Winner Feed: Scrolling recent wins. Masked name, level, amount, game, timestamp, "Play This Game" link.
Hero Banner: Full-width promotional for homepage. Live tickers, active players, warn state, CTA.

DevEmbed: <jackpot-widget type="ticker" jackpot="crown-fortune" theme="dark" currency="EUR" />. Web components. WebSocket auto-connect. Responsive. Light/dark themes. CSS custom properties for brand integration. Under 50KB gzipped. The in-game overlay is injected by the platform's game wrapper, NOT by the game provider. Provider iframe runs independently. Any game from any provider gets the overlay without modification to the game itself.

Win Celebrations

💡GRAND Win: Second-by-Second Timeline

WINNER EXPERIENCE: T+0.0s: Game overlay darkens. All game audio fades. T+0.5s: Jackpot logo animates in (Crown Fortune branded). T+1.5s: Level name 'GRAND' reveals in gold with particle burst. T+2.5s: Amount rolls from €0 to €31,500 over 3 seconds (accelerating). T+5.5s: Coin/confetti explosion fills screen. T+6.0s: Win message: "Congratulations! You are the lucky winner!" T+7.0s: 'COLLECT' button appears (or auto-dismiss after 15 seconds). BROADCAST (All Other Players): Toast from top-right: "🏆 JACKPOT WON!" "Cr***ng won GRAND €31,500 • Crown Fortune • Gates of Olympus" "+8 bonus prizes awarded!" | [View Jackpot] Auto-dismiss: 8 seconds. Clicking opens jackpot detail page. CHAIN REACTION (8 Recipients): "✨ Luck touched the room! Crown Fortune GRAND just dropped!" "You received €250 as a bonus prize." | [View Jackpot] WATERFALL (If Enabled — 3-second delay): T+3s: MAJOR → T+6s: MINOR → T+9s: MINI. 12 winners in 9 seconds. Activity feed floods. RESEED: Ticker resets to new seed with 'NEW CYCLE' animation. "Just Reset! Starting at €7,520" label for 60 seconds.

DesignerThe celebration must create a memory. The dramatic pause at the start is critical — silence before the reveal. For waterfall cascades, design as ONE continuous celebration: Grand BURST → Major WAVE → Minor RIPPLE → Mini SPARKLE. Sound: rising crescendo across all drops.

▶ WHY Why does the broadcast celebration matter? The winner knows they won — why tell everyone else?

The winner celebration serves the winner. The broadcast serves everyone else — and it serves a completely different purpose.

When a jackpot drops silently, 499 other active players have the abstract awareness that someone won. When a jackpot drops with a toast notification — masked name, amount, which game, which level — those 499 players have a concrete memory: "I was playing Book of Dead at 11:14pm when the Crown Fortune Grand dropped for €47,184. I got €100 from the chain reaction." That is a story. Stories are why people come back.

The toast is deliberately non-intrusive (auto-dismiss at 8 seconds, corner position, doesn't interrupt gameplay) because we want players to witness the event, not be annoyed by it. The in-game mini broadcast is even more restrained. The balance: visible enough to matter, subtle enough not to disrupt.

The reseed animation ("NEW CYCLE — starting at €5,230") serves the same broadcast function but for a different emotion: hope reset. The previous winner is gone. The hunt begins again. Your ticket to this jackpot starts now.

Social Proof Engine

Live Winner Feed: Persistent widget showing recent wins. Masked name, level, amount, game, timestamp, "Play This Game" button. Anywhere: Universe page, lobby, homepage, category pages.
Active Player Counters: Live count per jackpot. Updated via WebSocket. "2,418 players chasing."
Global Stats: Jackpots won today/week/month, total prizes paid, largest win this week.
Winner History Page: Full searchable history. Filter by jackpot, level, time period, game. The ultimate proof page.
Contribution Velocity: Visual indicator on cards: "Slow Build" / "Steady" / "Fast" / "Surging" — creates FOMO when a jackpot is surging.

Player Jackpot Dashboard

My Active Jackpots: jackpots contributed to recently. Per jackpot: contribution, spins, time, eligibility per level.
Lifetime Stats: total contributed, total spins, total wins, total winnings, chain reaction prizes, biggest session.
Jackpot Alerts: opt-in: "Notify me when Crown Fortune enters On Fire" / "when Daily Blitz has < 1h remaining" / "when any GRAND enters Must Drop."

▶ WHY Why does a player need to see their personal contribution stats? Isn't this just vanity data?

This is the sunk cost mechanism, applied ethically to engagement rather than harm.

When a player sees: "Your contribution to Crown Fortune: €247. Your qualifying spins: 1,438. Your rank: #47 of 2,418 players." — they are reading a statement of investment. They have been here. They have contributed. They have earned their place in the hunt. The jackpot is no longer an impersonal slot feature — it is their jackpot too.

This is why we call it "My Jackpot Journey" and not "Your Stats." The word Journey implies ongoing narrative. You are in the middle of a story. Leaving mid-story is psychologically uncomfortable in a way that leaving a slot game is not.

Practically: players with a high contribution amount and good leaderboard rank are precisely the players most likely to convert deposits and extend sessions. They have the most invested. The sidebar surfaces this investment at the decision point (when they're considering stopping).

The leaderboard rank ("You are #47 of 2,418") specifically activates competitive instinct. Top 50 out of 2,418 — "I could break top 40 with one more session." This is gamification applied to the meta-game above the game itself.

Notification System

Type	Trigger	Channel
Urgency	On Fire or Must Drop state	Push, In-App, Lobby Banner
Win Broadcast	Any drop	In-App Toast, Activity Feed
Personal Win	Player wins jackpot or chain	In-Game Takeover, Push, Email
Activation	New jackpot goes live	Push (opted-in), Lobby Banner
Deadline	Timed approaching deadline	Push (opted-in)
Reseed	Jackpot reseeded	Activity Feed, Card Animation
Milestone	Player contribution milestone	In-App Toast

Rules: max 3 push/player/day. 1h cooldown between notifications to same player. Respect opt-out preferences. Context-aware: don't notify for jackpots the player has never played.

Mobile & Performance

Over 70% of traffic is mobile. Mobile is the PRIMARY design target, not an adaptation.

Jackpot Universe: single-column cards, swipeable section carousels
Detail Page: stacked layout, swipeable tab sections
In-game overlay: minimal footprint. NEVER obstructs spin button.
Win celebration: portrait-optimized full-screen takeover
Ticker bar: compact horizontal scroll, 2–3 visible levels

Performance Targets

Jackpot Universe page load: under 2 seconds on 4G
WebSocket connection: under 1 second
Ticker animations: 60fps without jank
Win celebrations: no crash/stutter on mid-range devices
Widget JavaScript: under 50KB gzipped

Dev — Cross-Provider IntegrationThe in-game overlay is injected by the platform's game wrapper, NOT by the provider. The provider's iframe runs independently. The wrapper detects qualifying jackpots, renders the overlay, listens for win events, and triggers celebrations. This means ANY game from ANY provider displays the jackpot overlay without any modification to the game itself. This is how cross-provider jackpots work.

Part 10

Launch Portfolio & Roadmap

Day-One Jackpot Portfolio

Jackpot	Type	Levels	Mechanic	Mode	Key Feature
Crown Fortune	Persistent	4	Progressive	Mode 2	Flagship. Waterfall. Chain Reaction.
Mystery Drops	Persistent	3	Mystery	Mode 1/2	Hidden levels. Surprise wins.
Daily Blitz	Timed	1	Must-Drop	Mode 2	Drops daily. Fast cycle.
VIP Diamond	Persistent	3	Progressive	Mode 3*	VIP-only. Higher stakes.
Lucky Hour	Promotional	1	Must-Drop	Mode 3*	2-hour window. Fast drops.
Weekend Thunder	Promotional	2	Timed	Mode 2	Fri–Sun deadline.
Mega Cascade	Persistent	4	Waterfall	Mode 2	4 winners cascade. 12 winners total.

Note* Mode 3 = Curaçao only. Romania uses Mode 2 for all unless ONJN requires Mode 1. Target: 20+ active jackpots within 60 days of launch.

Development Roadmap (16 Sprints)

Sprint 1–2: Core Engine — pool mechanics, contribution pipeline, trigger evaluation
Sprint 3–4: Distribution modes (1+2+3), Winner Selection, Payout Service
Sprint 5–6: Back Office — Dashboard, Creation Wizard, Trigger Controls, Approval Queue
Sprint 7–8: Real-Time Gateway + Widget System (Lobby Ticker, In-Game Overlay)
Sprint 9–10: Jackpot Universe Page, Detail Page, Best Odds Sort, Win Celebrations
Sprint 11–12: Campaign Automation, Budget Model, Simulation Engine
Sprint 13–14: Theming Studio, Content Manager, Reporting, RBAC
Sprint 15–16: Waterfall Cascade, Chain Reaction enhancements, A/B Testing, Fraud Detection

Reporting (Sprint 13–14)

Financial: contributions, payouts, house cut, net position — by jackpot, level, currency, period
Operational: drop history, cycle history, pool status, operator action log, approval history
Player: top contributors (jackpot hunter identification), win distribution, session length impact, retention correlation
KPI Dashboard: GGR/NGR impact, active players, bet sum/count, ARPU, depositing players, casino hold
Export: CSV, PDF, API access for BI tools, scheduled email delivery

Part 12

System Intelligence & Adaptive Tuning

Continuous monitoring, operator recommendations, fraud detection, and empirical optimization.

The Intelligence Layer continuously monitors the jackpot ecosystem health using real-time metrics. These metrics feed into dashboards, alerts, and a recommendation engine. No auto-adjustment ever occurs. Recommendations are informational. The operator decides everything.

Health Metrics

Metric	Target Range	What Deviation Reveals
Avg Cycle Duration	Jackpot-specific (hours to days)	Too short = not exciting enough. Too long = players disengage before drop.
Drop Amount Distribution	Spread across Win From–Win To	Clustering near Win From = too predictable. Spread = healthy entropy.
Win Max Hit Rate	< 10% of cycles	Above 10% = conditions too restrictive. Pool keeps freezing at ceiling.
Winner Diversity Index	No player >15% of wins in 30d	Low diversity = feels rigged to players. May indicate bot or multi-accounting.
Contribution Velocity Trend	Stable or accelerating	Deceleration = losing player interest. Check theme freshness and game mix.
Warn State Dwell Time	15–90 min per cycle	Too short = no excitement builds. Too long = urgency desensitization.
Post-Win Retention (24h)	>60% return next day	Drop in retention after wins = jackpot not driving loyalty. Chain Reaction underperforming.
Chain Reaction Session Extension	+25% vs non-recipients	Low extension = prize amounts too small or notification experience poor.
Condition Failure Rate	< 30% of trigger evaluations	High failure rate = drop conditions too restrictive. Pool crossing target but can't fire.

Recommendation Engine

CriticalThe system NEVER auto-adjusts RNG parameters, win ranges, or distribution weights without explicit operator action. All recommendations are suggestions displayed in the BO. The operator always decides. This is a legal and operational requirement.

Example Recommendations Generated by the System

🤖Sample BO Recommendation Alerts

Crown Fortune Grand — Cycle Too Long
"Grand has averaged 12-day cycles over the past month (target: 5–7 days).
 Consider: increasing contribution rate 1.5% → 2.0%, or reducing Win To €40k → €35k."

Daily Blitz — Win Max Pressure
"Win Max was reached in 3 of the last 7 cycles. Conditions not met, pool freezing.
 Consider: reducing min_players 20 → 10, or widening the active time window."

Mystery Drops — Declining Participation
"Active player count down 15% over 30 days. Contribution velocity decelerating.
 Consider: refreshing the theme, adding new qualifying games, or activating a promotional campaign."

Crown Fortune — Winner Diversity Warning
"3 players have won 40% of all drops this month (statistical expectation: <8%).
 Consider: enabling Mode 2 contribution-weighted selection to spread wins across the player base."

Daily Thunder — Warn State Too Brief
"Warn state dwell averages only 8 minutes per cycle. Players barely register urgency.
 Consider: lowering Warn From from 70% to 50% to extend the on-fire window."

▶ WHY Why does the system recommend but never act? Isn't auto-tuning better?

Auto-tuning of RNG parameters would be legally catastrophic in regulated jurisdictions. In Romania, any change to win ranges, contribution rates, or distribution weights must be documented and submitted for regulatory review. An algorithm silently adjusting these overnight would invalidate certification.

Even in Curaçao, auto-tuning creates accountability gaps: if a jackpot drops unexpectedly after an automated adjustment, who is responsible? The operator cannot say "the system changed it" — they approved the system, so they own its decisions.

The recommendation engine is more valuable as a briefing tool than as an autopilot. It surfaces the right question at the right time: "Your Grand jackpot hasn't dropped in 12 days — do you want to do something about that?" The operator makes the call with full context. This is how professional jackpot management works in land-based (Newton Slot Management operates exactly this way).

Fraud Detection

The Intelligence Layer monitors for suspicious patterns that may indicate abuse. Detection triggers alerts to the BO. Operators investigate and take action. The system flags — it does not auto-punish.

Fraud Pattern	Detection Signal	Likely Intent
Multi-accounting	Multiple accounts from same device/IP contributing to same jackpot simultaneously	Inflate active player count to meet min_players condition
Bot play	Inhuman bet cadence (perfectly uniform timing), session patterns suggesting automation	Systematic min_spins farming to maintain eligibility
Collusion	Synchronized play patterns — multiple accounts behaving in coordinated ways to time trigger conditions	Force trigger window when confederate player is active
Contribution manipulation	Minimum qualifying bets placed in rapid succession across multiple games	Maximize eligibility while minimizing spend (exploit contribution-vs-win separation)
Win frequency anomaly	Player winning significantly more than statistical expectation across all jackpots	May indicate Mode 2/3 weight gaming or insider knowledge
Velocity spike	Unusual bet frequency spike just before predicted trigger window	Timing manipulation based on reverse-engineered pool state

NoteFraud detection is monitoring + alerting only. The system flags patterns. Operators investigate. Automatic exclusion or win voiding requires human decision with documented reasoning in the audit trail.

A/B Testing Framework

For operators who want to optimize configurations empirically rather than relying on simulation:

Split player base into test groups (50/50 or 80/20 control/test)
Group A: sees jackpot with configuration A (e.g., current). Group B: sees configuration B (e.g., lower min bet, higher contribution rate)
Track: participation rate, session length, deposit rate, return rate, jackpot GGR impact
Statistical significance calculator built into BO reporting — tells you when results are conclusive
Combine with Simulation Engine: run simulation predictions for both configs, then validate against live A/B data

NoteA/B testing works on all jackpot types and all distribution modes. It is the most rigorous optimization path. Typical test duration: 2–4 weeks for statistically significant results on contribution rate changes. Longer for win-rate related changes (due to lower event frequency).

▶ WHY Why invest in A/B testing infrastructure for jackpots?

Every jackpot configuration choice is a hypothesis: "Players will engage more with a warn state starting at 50% rather than 70%." The simulation engine tests this theoretically. A/B testing proves it on real players with real money.

The combinations of variables (contribution rate, warn thresholds, prize ranges, game mix, chain reaction amounts) are too numerous to optimize by intuition. Data-driven operators who run structured A/B tests consistently outperform those who configure by gut feel. The GGR difference on a well-optimized vs. average-configured jackpot portfolio can be 15–25%.

This is also a competitive differentiator. Our competitors (SOFTSWISS, Pragmatic Jackpot Play) do not offer per-operator A/B testing on jackpot configurations because they run shared infrastructure. We can offer it because the jackpot engine is ours.

"You are present in a place where luck might appear."

Jackpot System · Complete Specification v2.0 · Confidential · March 2026