Mainnet USDC payouts#

Status: Live in the MVP Mainnet Beta.

After a verified wallet converts eligible assets, meets the 1× wagering target, and wins in the real-value game, Afterlife can automatically pay capped winnings in Circle-issued USDC on Solana mainnet.

Current payout asset and limits#

• Mint: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
• Decimals: 6
• Destination: the canonical associated token account of the wallet that owns the Mainnet Beta session
• Fee payer: the configured Afterlife treasury
• Minimum request: $0.01
• Maximum request: $10
• Wallet 24-hour ceiling: $10
• Wallet lifetime cash-out ceiling: $10
• Platform 24-hour ceiling: $50

The mint is pinned to Circle's official USDC contract-address registry. The browser cannot choose a different payout mint, source account, fee payer, or destination wallet.

Automatic treasury mode#

The public MVP currently uses the automatic-treasury signer mode. The signing secret is encrypted in the production hosting environment and must derive the configured treasury owner. It is never sent to the browser, stored in application database rows, or committed to the repository.

This is an explicitly custodial, tightly capped beta architecture. The $10 lifetime-wallet ceiling and $50 platform-day ceiling bound exposure while Afterlife gathers operating evidence. Before materially larger limits, the signer should move to stronger HSM/MPC or multisig custody with role separation and independent approval policy.

User authorization#

The payout destination is bound to the verified wallet. The request records the exact amount, USDC mint, destination, treasury identity, signer mode, consent version, and idempotency key. The 1× wagering target and all request, wallet, platform, balance, and reserve checks must pass before funds are held.

Excess winnings remain in the game balance. They do not bypass the lifetime ceiling.

Durable lifecycle#

prepared → approved → submitted → finalized → reconciled

• prepared: the exact request, wallet, destination, amount, configuration snapshot, and balance hold are recorded.
• approved: automatic policy approval has passed and the transaction is eligible to be built.
• submitted: the exact signed transaction and public signature are stored before or with broadcast.
• finalized: Solana reports finality for the stored signature.
• reconciled: the finalized message and exact USDC token deltas match the bound payout.
• reconciling: a signature may exist or verification is incomplete; a replacement must not be created.
• rejected, cancelled, or failed: the hold is released only when non-payment is established under the state-machine rules.

The application uses request IDs, unique database constraints, conditional transitions, session revisions, daily/lifetime counters, and signature uniqueness to prevent replay, double debit, and double payout.

Transaction verification#

The server derives the canonical treasury and destination token accounts, creates only the bound memo, idempotent associated-token-account instruction when needed, and TransferChecked instruction, then simulates the exact transaction.

After signing, Afterlife verifies the unchanged transaction message and expected treasury signer before broadcast. Final reconciliation verifies:

• the canonical USDC mint;
• exact base-unit amount;
• treasury source and verified-wallet destination;
• fee payer and signer;
• finalized pre/post token deltas; and
• no unexpected treasury-owner delta.

The current production verification mode is single-primary-mvp. Secondary independent RPC verification is the next reliability upgrade before limits expand.

Reserve and pause controls#

Real-value play and payouts depend on a fresh reserve snapshot, the configured 120% reserve ratio, total-liability ceiling, daily limits, and clear application/database pause state. The active health endpoint reports payout, play, and submission readiness plus blocker count.

During an incident, new submission can be paused without discarding the data needed to reconcile signatures already onchain.

Ambiguous payout rule#

If a signature exists, never credit, release, rebuild, or manually pay a replacement until the stored transaction is reconciled. A network timeout does not prove non-payment. Preserve the exact transaction and signature, query finality, compare the bound message and token deltas, and settle or release only from conclusive evidence.

Beta expansion gates#

The current path is operational inside its published cap. Higher limits should follow:

1. secondary archival RPC verification and alerting;
2. HSM/MPC or multisig custody and separate operator roles;
3. formal incident, support, and reconciliation ownership;
4. independent backend, Solana, and treasury-control review;
5. stronger responsible-play, eligibility, and location controls; and
6. jurisdiction-specific legal and compliance review.

See Mainnet safety, Product status, and Responsible play.