# Fixed-deposit game balance

## Can the game work without connecting a wallet every round?

Yes. A player can fund a site balance once and place later bets against an internal ledger. A wallet or external exchange is still needed to send the first deposit unless the operator accepts another payment rail.

Recommended flow:

1. Player creates an account with a passkey and receives a unique deposit account or deposit reference.
2. The cashier offers quick presets from `config.cashier.fixedDepositAmounts` and also accepts a custom amount inside the server-enforced `EJECT_DEPOSIT_MIN` / `EJECT_DEPOSIT_MAX` range.
3. An indexer verifies the mint, destination account, exact amount and required Solana finality.
4. The ledger credits the deposit exactly once using the transaction signature as the idempotency key.
5. Bets atomically move ledger funds from `available` to `locked`. A crash settles `locked` to the house; a successful cash-out settles the authoritative payout to `available`.
6. The player submits a withdrawal address and request. Manual review may approve or reject it under a published policy. Every decision is written to an immutable audit log.
7. An isolated signer or multisig sends approved withdrawals. The web server never stores a dev-wallet seed phrase.

## Required ledger invariants

- `available + locked + withdrawn` must reconcile with confirmed deposits plus settled game results.
- Every deposit, bet, cash-out and withdrawal has a unique idempotency key.
- A bet and its liability reservation commit in one database transaction.
- Admins cannot edit balances directly. Corrections use compensating, reasoned audit entries.
- Withdrawal review must have documented limits and timeframes; it cannot be advertised as instant if it is discretionary.
- Reserves must cover all player balances plus open-round maximum liability.

## Safer alternative

A Solana program vault plus a short-lived session key lets a player deposit once and play many rounds without wallet popups while keeping withdrawals user-controlled. This reduces custody and operator-abuse risk. It requires an audited program and session-key permissions limited by amount and expiry.

## Current implementation and launch boundary

The local server implements authenticated deposit intents, finalized exact-transfer verification, an internal player balance, balance reservation when a withdrawal is requested, a manual operator queue, rejection refunds and finalized exact-payout verification. It deliberately does not store a seed phrase or sign payouts automatically.

The included JSON ledger is a development/integration implementation. Public custody requires a transactional database, isolated signer or multisig, reconciliation, account recovery, rate limits, monitoring, backups, a published withdrawal policy and jurisdiction-specific legal review before real deposits are opened to users.