Docs
Browse documentation

Start here

Product

Trust and safety

Reference

DocsProduct

Current server-authoritative status#

Status: Live server authority · Planned player-verifiable fairness

The Afterlife server is the source of truth for game outcomes and balances. The browser requests a spin and animates the result returned by the server; it does not select symbols or calculate the authoritative payout.

Spin settlement sequence#

For each request, the server:

  1. loads the active session from the session cookie;
  2. floors and validates the requested total bet;
  3. rejects a missing request ID, an out-of-range bet, or insufficient balance;
  4. loads previously converted assets for reel personalization;
  5. reads wallet-linked collection progress;
  6. generates random values with crypto.getRandomValues in the server runtime;
  7. resolves the grid, paylines, free spins, feature tiers, collection progress, and regular cap;
  8. resolves the shared progressive for simulation sessions;
  9. updates balance, wagered amount, session revision, spin record, ledger entry, collection progress, and jackpot state; and
  10. returns the stored outcome and frame-by-frame timeline.

The complete regular outcome is generated before the browser begins its final reel presentation.

Replay and concurrency controls#

Each balance mutation uses a request ID. The database has unique session/request constraints for spins, conversions, gifts, and related records. A retry with an already settled ID returns the stored result.

Session revisions serialize balance-changing actions. The progressive has its own version, and settlement guards require both the session update and progressive update to change exactly one expected record. A concurrent progressive race is retried with fresh pool state.

These controls reduce duplicate and stale-state settlement. They do not prove that the random draw was unbiased.

Current random source#

The game uses the runtime's cryptographic random generator rather than browser randomness or Math.random. Random units drive symbol selection and weighted feature tiers. The progressive trigger uses a higher-precision random unit from two 32-bit values.

Using a cryptographic random source is a useful implementation property, but it is not player-verifiable. A player cannot see the server's random bytes or prove which bytes existed before the wager.

Next: What is and is not player-verifiable.