Blockster Bankroll — security audit.

The settle_bet instruction takes four caller-supplied arguments: nonce, server_seed, won, and payout. The program verifies three things:

• SHA256(server_seed) == bet_order.commitment_hash
• the bet has not expired
• payout ≤ bet_order.max_payout

Critically, the program does not verify that the submitted won and payout are consistent with the revealed server seed and the bet parameters. The settler is trusted to derive them honestly off-chain.

Because the settler is a single Solana keypair (game_registry.settler) rather than a multisig, compromise of that key grants an attacker unilateral authority over outcomes. The per-bet guard payout ≤ max_payout limits exfiltration per bet to at most 2× the wager, but systematic abuse (e.g. declaring every bet a win) could drain the vault over many bets.

Scenario 1: Settler key compromise. Attacker can route losing bets to themselves as wins (at up to 2× amount) and redirect payouts to a controlled wallet via referral misdirection. Bounded per-bet but unbounded in aggregate.

Scenario 2: Settler-player collusion. Operator can collude with a specific wallet, marking every bet from that wallet as a win at max_payout. Because the off-chain RNG is private, this is undetectable to external observers absent the losing verification that M-01's remediation would enable.

Scenario 3: Buggy settler. A bug in the off-chain outcome derivation (e.g. an off-by-one in byte extraction) would systematically misreport outcomes, with no on-chain tripwire.

Scope. Affects LP solvency in the long run. Individual players are not at risk — if anything, a buggy/malicious settler has incentive to overpay, not underpay, since clients can prove underpayment off-chain and reputational damage is a credible deterrent.

Primary remediation (v2). Move outcome derivation on-chain. Store the bet's difficulty and predictions (max 5 bytes as a packed u8) in BetOrder. On settle, the program should:

1. Recompute the client seed from SHA256(player_pubkey ++ amount ++ vault_type ++ difficulty ++ predictions).
2. Compute combined = SHA256(server_seed ++ client_seed ++ nonce).
3. Derive flips from the first N bytes, compute win per mode.
4. Compute payout as amount × multiplier / 10000 if won, else 0.
5. Reject the settlement if the caller's submitted won/payout disagree with the derived values. (Or drop those arguments entirely and have the program compute them authoritatively.)

This eliminates the settler's outcome authority without changing the user experience. The settler remains responsible for revealing the seed and paying the compute; the chain becomes responsible for determining the result.

Interim remediation. Migrate the settler keypair to a Squads-style multisig, publish the outcome-derivation algorithm in documentation (done: see Provably Fair page), and provide a first-class verification tool so anyone can audit a posteriori.

The authority field of GameRegistry is written exactly once — at initialize_registry — and there is no instruction to update it. The authority can rotate the settler via update_config, but cannot rotate itself.

If the authority key is compromised, the only path to rotation is redeploying the program under a new authority via the off-chain upgrade authority (a separate key). That requires (a) the upgrade authority being held by someone other than the attacker, and (b) operational readiness to re-initialize PDAs in a way that's compatible with existing state.

A compromised authority can:

• Register a new game with arbitrary multipliers (e.g., 100× with unchecked max_bet_bps up to 5%), converting LP capital to house losses one bet at a time.
• Rotate the settler to an attacker-controlled address and collect all rent / gain arbitrary outcome control per M-01.
• Pause the program and leave it paused, denying users withdrawals (settlements still work, but deposits/withdrawals do not).

Caps on per-game max_bet_bps (500 = 5%) and fee_bps (1000 = 10%) bound the rate of exfiltration. The minimum multiplier of 100 (1×) prevents immediate zero-payout games, though nothing prevents the authority from registering a 1.01× game that is unprofitable for LPs over time.

Preferred (v2). Add a two-step transfer_authority instruction with:

1. propose_authority(new: Pubkey) — writes pending_authority and propose_timestamp.
2. accept_authority() — callable only by pending_authority, and only after a timelock of (say) 24h. Clears pending_authority and overwrites authority.

The timelock gives observers time to react if a proposed transfer looks suspicious. The two-step prevents accidental loss of authority to a key that doesn't exist.

Interim. Hold the authority key in a 2-of-3 Squads multisig, document the key custody clearly, and publish an incident-response runbook for upgrade-authority-assisted rotation.

Each bet is bounded in isolation by potential_profit ≤ net_balance, where net_balance = vault − rent − total_liability. As total_liability grows, net_balance shrinks, which tightens subsequent bets — but there is no hard upper bound on what fraction of the vault can be booked as liability at once.

In an extreme scenario with many simultaneous bets placed under max_bet_bps = 5% and the 31.68× difficulty, total_liability could asymptotically approach the vault balance, leaving little or no available liquidity for withdrawals until bets settle.

Not a solvency risk: the vault can always cover any single bet's max_payout because that was the placement invariant. It is a liquidity risk: withdrawals would revert with InsufficientLiquidity until pending bets resolve. In practice bets settle in seconds so queueing is rare, but a coordinated wave of bets could transiently lock LP capital.

Introduce a system-level constant (e.g. MAX_LIABILITY_BPS = 5000) and enforce total_liability ≤ vault_balance × MAX_LIABILITY_BPS / 10000 at placement. New bets revert with a new LiabilityCapExceeded error rather than BetTooLarge.

Each BetOrder stores the rent_payer at placement time (enforced to equal the current settler). On settle_bet / reclaim_expired, the account closes and rent returns to that stored rent_payer via has_one.

If the settler is rotated via update_config while bets are pending, those pending bets still reference the old settler. The old key must remain accessible to:

• Sign settle_bet (settler is the signer).
• Receive the rent rebate on BetOrder close (both settle and reclaim).

If the old key is destroyed (e.g. compromise-forced rotation), the in-flight bets can only be resolved via reclaim_expired (player-signed), and the rent will still flow to the old settler's pubkey — which may now be attacker-controlled.

Operational inconvenience rather than a fund-loss risk for users. The rent amount per BetOrder is small (around 2,000,000 lamports / 0.002 SOL). Total at-risk rent at any moment is bounded by unsettled_count × rent_per_bet, typically under 0.1 SOL.

Document the rotation runbook: before rotating settler, wait for all pending bets to settle or expire. For compromise-forced rotation, accept the transient rent loss. Alternatively, relax the has_one = rent_payer constraint to allow either the stored rent_payer or the current settler to receive rent.

update_config allows the authority to rewrite new_game_multipliers: [u16; 9] at any time. Each multiplier must be >=100 if non-zero but is otherwise unbounded.

Placed bets are unaffected (their max_payout is fixed at placement). New bets use the new multipliers at placement time. If the UI quotes a bet at multiplier X, the user signs, and the authority rewrites to Y in between, the bet actually placed uses Y with no warning to the user.

A user can end up betting on less-favourable terms than they agreed to. Impact is small because the signing window is typically 1–2 seconds; coordinated exploitation would require the authority to front-run user signatures. Most adversarial in a compromised-authority scenario (see M-02).

Add an optional expected_multiplier_bps: Option<u64> argument to place_bet_sol/place_bet_bux. When Some, the program verifies it matches the current multiplier for the requested difficulty and reverts otherwise. Have the UI populate it from the live quote.

Alternatively, add a timelock to multiplier changes: writes take effect N seconds after they are proposed, giving clients time to re-quote.

GameEntry.fee_bps is set by register_game (capped at 1000 bps) and writable via update_config, but is never read by settle_bet or any other instruction. The field is effectively dead.

Confusing for auditors and integrators reading the code — implies a protocol fee that doesn't exist. No security impact.

Either wire it in (deduct payout × fee_bps / 10000 from payouts and accumulate in a protocol_fee_accrued field, plus a withdrawal instruction) or remove the field in the next account-layout upgrade.

In settle_bet.rs:77 and reclaim_expired.rs:60, 69, the has_one = player constraint carries the error InvalidServerSeed. A player-mismatch at settlement will surface to clients as "invalid server seed", which is misleading.

Debug and monitoring ergonomics. No security impact.

Add an InvalidPlayer error code and use it for player-mismatch constraints. InvalidServerSeed should remain exclusive to the SHA-256 check in the handler.

submit_commitment uses init_if_needed to create the player's PlayerState PDA, with payer = settler. Nothing stops the settler from calling submit_commitment for randomly generated pubkeys, allocating a PlayerState (~326 bytes, ~2.5 million lamports rent) for each. This is self-harm — the settler is spending its own SOL — but can drain a misconfigured fee-payer budget quickly.

If the settler's SOL budget is exhausted, legitimate submit_commitment and place_bet_* calls (which require the settler as rent_payer) will fail, effectively pausing the game. The settler's private key is the only thing that can trigger this so it's a self-inflicted wound, not an external attack surface.

Monitor the settler balance and alert below a threshold. Consider moving PlayerState rent to the player (paid at set_referrer or first place_bet) — this pushes rent cost onto the real user who benefits from the state rather than onto the settler.

PlayerState.has_active_order: bool is declared and initialised to false in submit_commitment.rs:50 and set_referrer.rs:58, but never read or toggled. Appears to be vestigial from a design where concurrent bets per player were forbidden. Remove or repurpose.

Both SOL (9 decimals) and BUX (9 decimals) use MINIMUM_LIQUIDITY = 10_000, which is 0.00001 of either token. Negligible at real deposit sizes. If a future vault is added with 6 decimals, 10,000 base units would represent 0.01 units — still small but proportionally ~1000× larger. Consider scaling MINIMUM_LIQUIDITY by 10^(9 - decimals) when registering new vaults.

Depositors cannot specify min_lp_out; withdrawers cannot specify min_underlying_out. The program uses the LP price computed from live vault state, so a bet settling in the same transaction or block could shift the effective balance and mint the LP at a different rate than the UI quoted. In practice drift is tiny, but MEV-style sandwiching isn't theoretically prevented.

The require!(nonce >= player_state.nonce, ...) check allows the settler to set pending_nonce to any value greater than or equal to the current. This is intentional (allows pre-commitment batching) but a buggy client could leave the player stuck at a huge nonce with a stale commitment. Consider capping the gap at a small number (say 10) unless an explicit batch flag is passed.

On loss, referral rewards of up to 1.5% combined (tier-1 + tier-2) are deducted from the same vault that backs LP positions — reducing LPs' share of the house edge. There is no protocol-side accrual or separate treasury. This is a design choice, not a bug, but LPs should understand they are funding the referral programme.

The paused flag gates deposits, withdrawals, bet placement, commitment submission, and referrer-setting, but not settle_bet or reclaim_expired. This is correct: pausing must not trap pending bets. But it means that in an incident response scenario where the settler key is believed compromised, pause alone does not stop the settler from continuing to settle bets at attacker-chosen outcomes. Consider adding a separate deep_pause or settle_pause flag for that scenario.

pause.rs:10 and update_config.rs:11 both raise UnauthorizedSettler when the signer doesn't match game_registry.authority. The error message says "Unauthorized settler" but the role being checked is actually authority. Add a distinct UnauthorizedAuthority error code.

BetPlaced, BetSettled, and BetReclaimed emit player and nonce, which is sufficient to derive the BetOrder PDA, but not the PDA address directly. Including it would spare indexers the derivation and make logs more self-contained.