A progressive jackpot is the only part of a slot game whose advertised number is also a live liability. The base game pays what the model says it pays; the jackpot on the cabinet says a figure that grows with other people’s play, resets when it is won, and belongs to a pool that somebody has to fund, disclose, secure and eventually close. That makes it a commissioning decision rather than a feature request, because every one of those obligations is cheaper to write into the brief than to retrofit into a live product.
The buyer’s decision is narrow and concrete: whether the commission should include a progressive at all, and if it does, which funding model, which disclosure set and which settlement rule the build must implement. The UK Gambling Commission states the duty in its remote technical standards. RTS 9A requires that an explanation of the jackpot rules be clearly available to the customer before they commit to gamble, and RTS 9B requires jackpot systems to be configured and operated with adequate fairness and security. The implementation guidance behind those two sentences is where a commissioning brief gets its real checklist.
This is a procurement decision rather than a platform build. The control model, pool accounting and acceptance schedule that sit underneath it are covered in the jackpot platform architecture guide; what follows is what a publisher has to settle with a studio before the first line of that build is written.
Decide the funding model before the paytable
The first question is not how big the jackpot should be but where the money comes from, because the answer changes the game’s economics and its evidence obligations. Four models cover most commissions, and each one obliges something different.
Operator-seeded, contribution-funded. The operator puts up a starting value and a fixed percentage of each qualifying stake feeds the pool. This is the shape the Commission’s guidance describes most directly: the rules must state how the jackpot is funded, what the start-up seed is and what ceiling values apply. It keeps the pool inside one product and one operator’s reporting line, which makes the settlement rules simple and the disclosure short.
Network or shared pool. Several brands feed and win the same pool. It produces a larger headline number, and it moves three hard problems into the commission: arbitration of simultaneous wins across operators, one contribution rate for every participant’s configuration, and a decommissioning rule that survives one brand leaving. A shared pool also means the game is no longer independently releasable — the feature flag and release discipline that protects a normal certified build now has to cover a pool whose state is shared with parties outside the release.
Local per-game pool. Each game instance holds its own value. Cheap to operate and easy to cap, but the pool resets constantly and the displayed figure moves fast enough that the display-frequency requirement becomes a real engineering constraint rather than a cosmetic one.
Capped pool with an overflow rule. The jackpot stops growing at a ceiling and further contributions go somewhere else — a reserve, a second tier, or back into the game’s return. The guidance is explicit that where a jackpot is capped, the rules must explain how subsequent player contributions are handled, naming the operation of any redirected overflow or reserve pools. This is the model most likely to be underspecified in a brief, because the overflow is invisible until the cap is reached, and by then the money has been flowing for months.
Whichever model is chosen, the pooled money is not the game’s money. Ask on the first call who holds it, who reconciles it and what happens to it if the product is withdrawn.
The disclosure set the rules must carry
RTS 9A’s guidance is unusually specific, and it makes an excellent acceptance list because every item is checkable in the built help screen rather than in a meeting.
- Funding, seed and ceiling, in plain language, in the rules the customer can open before staking.
- The return to player treatment. The Commission’s guidance expects the jackpot system’s RTP to be displayed as RTS 3C requires, either as one combined game-and-jackpot figure or broken down into the base game and the jackpot component. A combined figure that quietly excludes the pool is a disclosure defect even when the arithmetic is right.
- Eligibility, and the RTP that applies when a player is not eligible. Not every stake in every state qualifies. The guidance says that where a player is not eligible for a game’s progressive jackpot prize, this should be made clear along with their respective theoretical RTP. In a market with stake-dependent eligibility, that is two numbers on one screen, and the client has to switch between them without ambiguity.
- How prizes are determined and awarded, including the case where two or more players trigger the same jackpot at once, or appear to — the guidance names network latency as the example.
- The current value, visible to all eligible players, updated as frequently as is practicable, and especially after a reset following a win. RTS 3D’s guidance adds the same point about displays of jackpot amounts that change over time.
That list is the cheapest part of the commission to get right and the most expensive to discover late, because the rules text, the help screen, the eligibility logic and the display all have to agree at once. A studio that treats the jackpot rules as marketing copy will produce a screen that describes a product slightly different from the one it shipped.
Simultaneous wins are a settlement question, not a UX question
Two players hitting the same progressive in the same second is not a hypothetical edge case; it is the normal consequence of a shared pool and a fast game. The Commission’s guidance requires the rules to describe what happens in that situation, including an apparent simultaneous trigger caused by latency. That sentence is doing a lot of work: it forces the commission to name an authority for ordering that is not the client.
The workable shape is a server-side arbitration on the round record. Each qualifying round is evaluated with the pool value and a pool version attached, the award is serialised by the server as it is generated, and the first committed award takes the pool and resets it. Everything after that — the second player’s event, the notification, the display — is a presentation of a settlement that has already happened. A client that decides the outcome by animating “you won the jackpot” and then asking the pool has inverted the order, and the defect will show up in exactly the traffic conditions nobody tests: a slow network and a large advertised number.
This is the same principle that makes deterministic replay worth building before the incident rather than after it. A jackpot dispute is a round dispute with a large number attached, and the round identifier plus the pool state at evaluation time is the only evidence that resolves it without an argument about timestamps.
Configuration and change control
RTS 9B’s guidance asks for strict access and logging controls over the configuration of live jackpots and the changes made to them. In practice that means a small number of named roles, a change log that records the before and after value of every parameter, and a rule that no contribution rate, seed or ceiling changes inside a live promotional window without a signed record.
The second half of the same guidance is the part that changes paytable design: where a customer contributes to a jackpot pool, that customer should be eligible to win the jackpot while playing that game, and the chances of winning should increase in correlation with the amount contributed. A pool that accepts contributions from a stake that cannot win it is not a marketing nuance; it is the defect the guidance exists to prevent. Test it as an eligibility matrix — every stake, every jurisdiction, every player state — rather than as a single happy-path spin.
Chances increasing with contribution also has a modelling consequence. If the trigger probability scales with stake, the jackpot’s contribution to RTP is not a constant, and the math package has to state the function rather than a single average. Ask for the function; “the jackpot adds a couple of percent” is not a specification.
Failure, interruption and the value of the pool
A progressive adds one requirement to every failure plan: the value of the pool has to survive. RTS 10’s guidance is direct. Where an interruption occurs, progressive jackpot values should be restored to their pre-failure state, and the recovery capability in RTS 10B lists the value of any progressive jackpots among the information a system must be able to restore.
Read that as a design constraint on state. A pool held only in a cache, or reconstructed at boot from the current session, cannot satisfy it. The pool needs a durable record with a version, the contribution ledger that produced it, and a restore path that a test can exercise — which is the same backup and restore evidence the platform side already owes, narrowed to one number.
It also settles a question players ask and operators dread: if the game goes down while a jackpot is being won, what happens? The Commission’s guidance on interrupted gambling says that where the customer can have no further influence on the outcome after their gamble is received, the result stands; the jackpot value is restored so the completed round can settle against the pool it was evaluated against. Whether that is implemented is discoverable in a drill, not in a design document.
Decommissioning and leftover contributions
Every progressive ends. The guidance anticipates three fair routes when a jackpot containing player contributions is decommissioned: wait until it is next awarded before closing it, move the remaining contributions onto another jackpot system preferably with a similar player base, or return the remaining contributions as a one-off event with adequate customer disclosure explaining the origin of the money.
The commission should pick one before launch, not at withdrawal. A contract that is silent on the residual pool leaves a live liability with no owner precisely when the commercial relationship is ending. If the publisher intends to migrate the game to another platform, the pool’s portability is a technical question too: the version, the ledger and the reset state have to move with the product, or the migration quietly becomes a closure.
The handover list
For a jackpot build, the acceptance pack is a short extension of the usual studio commissioning checks:
- the funding model in one page, with the seed, contribution rate, ceiling and overflow route stated numerically;
- the combined or split RTP presentation, with the eligibility matrix that produces the second figure;
- the arbitration rule for simultaneous triggers, expressed as a server-side ordering on the round record, plus a fixture that exercises it;
- the pool’s durable record and a restore test that proves the pre-failure value returns;
- the access and change-control list, with the log format for a live parameter change;
- the decommissioning route, chosen and written into the contract;
- the rules text, help screen and client display reviewed together as one artefact.
None of this is exotic engineering. It is the difference between a jackpot that is a product feature and a jackpot that is an unmanaged pool of other people’s money with a number on a screen. Where a publisher is commissioning the build rather than inheriting it, the whole set can be settled in the scope before production starts. The Engine project brief is the route to request a project quote with the jackpot model, markets and evidence list agreed in writing first.
Frequently asked questions
What must a slot’s jackpot rules disclose?
The rules must explain how the jackpot is funded, the start-up seed and any ceiling values, how prizes are determined and awarded, and what happens when two players trigger the same jackpot at once or appear to because of network latency. The jackpot’s RTP must be shown as RTS 3C requires, either combined with the game or split into base game and jackpot components, and a player who is not eligible must be told so along with their own theoretical RTP.
Who should fund the seed of a progressive jackpot?
That is a commercial decision rather than a technical one, but it has to be written down before the paytable is fixed. An operator-funded seed keeps the pool inside one reporting line and makes settlement simple; a network pool spreads the cost and adds cross-operator arbitration and a shared decommissioning rule. Whichever is chosen, the seed, the contribution rate and the ceiling belong in the rules text the customer can read.
How should two players winning the same progressive at once be handled?
With a server-side arbitration rule on the round record, stated in the rules. Each qualifying round is evaluated against a pool value and version, the award is committed in order, and the first commit takes the pool and resets it. The second event becomes a presentation of a settlement that has already happened. A client-side decision based on animation timing cannot order two awards correctly.
What happens to a progressive jackpot when a game is decommissioned?
The UK Gambling Commission’s guidance sets out three fair approaches for a jackpot containing player contributions: wait until the jackpot is next awarded before decommissioning, move the remaining contributions onto another jackpot system preferably with a similar player base, or return them as a one-off event with adequate disclosure explaining the origin of the money. The route should be chosen in the commission contract, not at withdrawal.
Does a progressive jackpot change the game’s RTP evidence?
Yes, if the chance of winning scales with the stake. Then the jackpot’s contribution to return is a function of stake rather than a constant, and the math package has to state the function instead of a single average figure. The simulated return should be reconciled with the displayed combined or split presentation so the number the test house sees is the number the player is shown.
