2% progressive contribution#

The shared Afterlife progressive is Live in simulation only. It is separate from the fixed five-SCATTER jackpot feature and disabled in mainnet beta.

Contribution split#

Each paid simulation spin contributes:

Destination	Share of total bet
Visible progressive meter	1.5%
Reset reserve	0.5%
Total progressive allocation	2.0%

The implementation converts the wager to integer microcredits and floors each contribution:

$$c_{\text{visible}}=\left\lfloor0.015b\right\rfloor_{10^{-6}},\qquad c_{\text{reserve}}=\left\lfloor0.005b\right\rfloor_{10^{-6}}$$

Here b is the paid total bet. Awarded free spins do not create separate progressive contributions.

Meter lifecycle#

1. The visible meter begins at 2,500 credits.
2. A hidden trigger is selected uniformly in integer microcredits between 7,500 and 12,500 credits, inclusive.
3. Each paid simulation spin adds its 1.5% visible contribution.
4. If the funded meter reaches the hidden trigger, the complete funded meter is paid.
5. The visible meter resets to 2,500 credits.
6. The reserve pays for that reset, and a new hidden trigger is selected.

The public jackpot endpoint exposes the visible value, reset, earliest and latest trigger bounds, contribution rates, pool version, hit count, last win, and last-hit time. It does not expose the current hidden trigger.

RTP interpretation#

The progressive design allocates 2% of paid simulation wagers to the meter and reset reserve. Combined with the 92% regular target, the simulation targets 94%.

This accounting target does not guarantee a 2% realized progressive payout in a finite sample. Hits are infrequent, contributions are floored to microcredits, and the timing of a hit can make observed results volatile.

Settlement and concurrency#

The simulation spin, ledger entry, session revision, progressive event, and pool version are settled together in a database batch. If another spin updates the pool first, the server reloads the current pool and retries. Reusing a settled request ID returns the stored progressive result rather than deliberately contributing twice.

These are accounting and replay controls. The hidden trigger and its random selection are not yet player-verifiable. See What is and is not player-verifiable.