Fairness#

Afterlife publishes its current game math and its current limitation plainly: the MVP is server-authoritative and is not yet player-verifiably provably fair.

In this section#

• Current server-authoritative status
• What is and is not player-verifiable
• Verification roadmap

The regular game and progressive targets are documented separately under Game mechanics.

What server-authoritative means#

For each spin, the server:

1. loads the active session and validates the total bet;
2. rejects bets outside 0.10–1.00 credits or above the balance;
3. generates random values with the runtime's cryptographic random source;
4. resolves the grid, paylines, free spins, fixed features, and regular cap;
5. resolves the simulation progressive in the same database settlement, when applicable;
6. updates balance, wagered amount, collection progress, spin record, ledger entry, and jackpot state; and
7. returns the stored result and animation timeline to the browser.

The browser animates the settled result. It does not determine the payout.

Replay safety is not provable fairness#

Mutating requests carry a request ID. A repeated request for the same session returns the previously stored conversion, gift, spin, withdrawal, or plan rather than intentionally applying it twice. Session revisions guard overlapping balance updates. Simulation spins also settle session and progressive versions together; a conflicting jackpot update is retried against fresh state.

These controls help prevent accidental double settlement. They do not let a player prove that the random outcome was selected without operator influence.

Current RTP targets#

RTP is a long-run mathematical expectation, not the result of a session and not a promise to an individual player.

Component	Target allocation	Applies to
Regular game, including line wins, free spins, fixed jackpot wheel, and Collect 12	92%	Simulation and mainnet-beta slot
Shared progressive	2%	Simulation paid spins only
Combined target	94%	Simulation only

The paytable scale is 18.28. The repository regression suite runs 100,000 deterministic regular-game spins and requires the observed result to remain between 90% and 94%, bracketing the approved 92% target. That test is a regression signal, not a proof of the exact theoretical RTP or future production behavior.

The exact implemented paytable and feature rules are in Game mechanics.

Progressive accounting#

For a paid simulation wager $b$:

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

The two allocations total 2% before integer microcredit flooring. The visible pool starts and resets at 2,500 credits. After each reset, the server draws a hidden trigger uniformly in integer microcredits from 7,500 through 12,500. A paid spin first adds its visible contribution; if the funded pool reaches the trigger, that funded pool is paid and the visible pool resets. The reserve receives the 0.5% allocation and funds the reset amount.

The design allocates 2% of paid wagers to progressive funding. Realized RTP over a finite sample can vary materially, especially because jackpot hits are infrequent. The hidden trigger and random draw cannot currently be verified by the player.

What a player can verify today#

A player can inspect:

• the published paytable, paylines, feature rules, cap, and RTP targets;
• the returned grid, feature timeline, payout breakdown, and balance change;
• recent server ledger entries in the session;
• whether a retried request returned the already stored outcome;
• mainnet transaction signatures and on-chain effects when those identifiers are made available; and
• the visible progressive state exposed by the simulation endpoint, including value, reset, bounds, version, hit count, and last-win information.

These observations can reveal inconsistencies. They cannot reconstruct the random draws or prove that an unseen alternative outcome was impossible.

What cannot be verified today#

The MVP does not currently provide:

• a pre-spin commitment to a secret server seed;
• a player-selected client seed;
• a public monotonically increasing fairness nonce;
• a revealed seed after rotation;
• a specified deterministic mapping from seed material to every random draw;
• a player-facing result digest and one-click verifier;
• a cryptographic commitment to the progressive trigger;
• an independently certified theoretical-math report; or
• an independent security or game-fairness audit.

No documentation or interface should call the current game “provably fair” or “audited.”

Verification roadmap#

The conservative roadmap is:

1. Specify a versioned random transcript covering grid draws, no-duplicate reel selection, feature tiers, free-spin chains, collection prizes, and progressive triggers.
2. Commit to a secret server seed before play and publish the commitment hash.
3. Accept a player-controlled client seed and use a monotonic nonce per settled spin.
4. Derive random bytes through a documented cryptographic construction with unbiased range conversion.
5. Store seed identifiers, nonce, algorithm version, result digest, and progressive version with each spin.
6. Reveal retired server seeds and provide open verification code that reproduces historical outcomes.
7. Define a separate commitment-and-reveal treatment for the shared progressive so a hidden must-hit trigger cannot be changed after commitment.
8. Independently review the theoretical math, implementation, deployment controls, and verifier before making a provable-fairness claim.

Decision required — verification standard: The founder must select the fairness construction, seed-rotation policy, independent reviewer, publication artifacts, and acceptance criteria. “Audit” must identify its scope and date rather than operate as a generic badge.

Mainnet reserve enforcement#

The Mainnet Beta spin route requires a fresh reserve snapshot and serializes a reservation for the complete 2,000× published regular maximum before accepting a real-value bet. The default reserve ratio is 120%, and active game balances, payout holds, and current maximum-win or burn-credit reservations count toward coverage.

This solvency control is independent from outcome fairness: adequate reserve does not prove that a random result was unbiased, and a fairness transcript would not by itself prove treasury solvency.

See Key risks and Roadmap.