Docs
Browse documentation

Start here

Product

Trust and safety

Reference

DocsTrust and safety

Security and privacy#

This page describes the working MVP Mainnet Beta. It is a technical disclosure, not a certification, audit report, privacy policy, or guarantee of security.

Session model#

Afterlife uses a server-side session and secure browser cookie. Mainnet authorization is bound to the verified Solana wallet, expires after 30 minutes, rotates an opaque bearer token on re-verification, stores only its SHA-256 hash, and invalidates older cookies for the same durable wallet session.

Logging out revokes browser access but preserves durable submitted conversion, game-liability, and payout state so onchain work can be reconciled safely. Demo and mainnet-beta sessions remain isolated.

Wallet signatures#

The first mainnet signature is a five-minute, single-use text challenge. It proves wallet control and cannot move funds.

Conversion signatures are different: they approve the exact burn-and-close or Jupiter swap transaction shown to the user. The server verifies message-byte equality, signer identity, and signature validity before submission.

Payout requests and transactions are bound to the wallet that owns the session. Afterlife never needs a user's seed phrase or private key and should never ask for either in the site, documentation, support, logs, or forms.

Data handled#

Depending on the path, the service processes and stores:

  • session identifiers, hashed bearer tokens, and cookies;
  • public wallet, token-account, mint, treasury, and transaction addresses;
  • token balances, authorities, metadata, prices, routes, and rent amounts;
  • conversion plans, quotes, unsigned/signed transaction evidence, signatures, fees, and reconciliation results;
  • bets, complete spin outcomes, features, payouts, balances, wagering totals, and progress;
  • payout holds, limits, approvals, finality evidence, and audit events; and
  • request IDs, revisions, timestamps, status, and bounded failure reasons.

Wallet addresses and onchain activity are public but can still be personal data when linked to a person. The current application schema does not require a name, email, government identifier, card number, seed phrase, or user private key.

Infrastructure and providers#

The production application runs on Vercel with Neon Postgres. Mainnet discovery, conversion, reserves, and settlement use configured Solana RPC access plus Jupiter and independent DEX Screener data. Public identifiers required for those requests reach the applicable providers.

Remote token metadata is presentation-only and cannot override program, authority, price, route, or action-policy checks. Missing, stale, conflicting, or unsafe dependency data fails closed for real-value action.

Treasury signing boundary#

The public beta uses a capped automatic-treasury payout mode. Its encrypted signing secret is server-only, must derive the configured treasury owner, and is excluded from repository, browser, database, and documentation output. The architecture is explicitly custodial and limited by the $10 lifetime-wallet and $50 platform-day payout ceilings.

Moving to materially larger limits requires stronger custody such as HSM/MPC or multisig, role separation, protected approval, independent RPC verification, monitoring, and incident drills.

Current safeguards#

  • Wallet-bound, short-lived authorization with bearer-token rotation.
  • Read-only discovery before separate transaction consent.
  • Policy-driven asset exclusions and fresh rescan before construction.
  • Independent price evidence and fail-closed price/route conflict rules.
  • Exact-message and signer verification for conversion and payout transactions.
  • RPC preflight, simulation, finalization, and action-specific token/account reconciliation.
  • Fresh reserve snapshots, 120% reserve ratio, maximum-exposure reservations, and hard payout caps.
  • Request IDs, unique constraints, conditional state transitions, settlement guards, and session revisions.
  • Durable recovery of submitted/reconciling work after reconnect.
  • Server-side secrets, structured Postgres records, and operator-visible health/pause state.

Known limitations#

  • No independent security or game-math audit is claimed.
  • The slot is server-authoritative and does not publish a player-verifiable random transcript.
  • Production uses an explicit single-primary-RPC MVP verification mode.
  • The automatic treasury signer is a bounded beta custody tradeoff rather than separated institutional custody.
  • No public data-retention schedule, export/deletion workflow, vulnerability-disclosure policy, or complete privacy notice is published.
  • Public wallet activity can be correlated across providers.
  • Provider failures can pause classification, conversion, reserves, or reconciliation.

These limitations define priorities for expansion; they do not change the current status as an operating Mainnet Beta.

See Mainnet safety, Fairness and RTP, Mainnet USDC payouts, and FAQ.