Security Audit Report

1. Manual line-by-line review of all on-chain program code
2. Analysis of cross-system data flows and trust boundaries
3. Review of authentication and authorization mechanisms
4. Economic model analysis (fund flows, fee splits, LP pricing edge cases)
5. Input validation and error handling review
6. Attack surface enumeration for each component

All protocol funds are held in a system-owned PDA derived from the seed [b"master_vault"]. This vault has no private key — it can only be controlled by the RogueTrader program itself.

• The vault PDA is deterministic — anyone can derive and verify its address
• No wallet, admin, or external entity holds a private key to the vault
• All transfers out use CPI with PDA signer seeds
• The vault cannot be drained by any single instruction

// Every withdrawal uses this pattern — PDA signer, not a private key
let vault_seeds = &[b"master_vault".as_ref(), &[master_vault_bump]];
let vault_signer = &[&vault_seeds[..]];

system_program::transfer(
    CpiContext::new_with_signer(
        system_program.to_account_info(),
        system_program::Transfer { from: master_vault, to: recipient },
        vault_signer,
    ),
    amount,
)

The protocol authority (admin) has no instruction that can withdraw SOL from the vault. Admin actions are limited to:

• LP tokens are standard SPL tokens — fully self-custodial and transferable
• Any LP holder can call withdraw_sol at any time
• SOL returned proportional to LP share of total supply
• Available liquidity excludes capital locked in active trades
• No lock-up period, no admin approval required
• First deposit burns 10,000 lamports to prevent donation/inflation attack

Unlike protocols with per-user vaults, RogueTrader uses a single master vault PDA that holds all SOL. Bot-to-bot trades are pure bookkeeping — only AgentVault.sol_balance fields change. Actual SOL only moves on user deposit/withdraw.

The settler is an off-chain microservice constrained by on-chain logic:

All configuration parameters have enforced on-chain bounds:

deposit_fee_bps    <= 1000   (max 10%)
withdrawal_fee_bps <= 1000   (max 10%)
min_odds_bps       <= 10000  (max 100%)
max_odds_bps       <= 10000  (max 100%)
odds_window_size   >= 1 && <= 100
max_cp_exposure_bps <= 10000
stale_bet_buffer    >= 0 && <= 600  (0 to 10 minutes)
spread_to_lp_bps   <= deposit_fee_bps
Fee splits must sum correctly

Even at maximum settings, the protocol remains solvent. The admin cannot extract funds from the vault.

Even if the RogueTrader website, the settler service, and all servers go offline permanently, users can recover their funds by interacting directly with the Solana program via any RPC endpoint.

1. Check your LP token balance (associated token account for the bot's LP mint PDA)
2. Build a withdraw_sol transaction with your LP amount
3. Sign with your wallet and submit to any Solana RPC
4. Proportional SOL share transferred to your wallet

// 1. Derive PDAs
clearing_house = findProgramAddress(["clearing_house"], programId)
master_vault   = findProgramAddress(["master_vault"], programId)
agent_vault    = findProgramAddress(["agent_vault", botIdBytes], programId)
lp_mint        = findProgramAddress(["lp_mint", botIdBytes], programId)

// 2. Build withdraw_sol instruction with your LP amount
// 3. Sign with your wallet
// 4. Submit to any Solana RPC endpoint

All accounts are PDAs with known seeds — no off-chain index needed:

Any standard Solana tooling works — no proprietary software needed:

• Solana CLI (solana-cli)
• JavaScript (@solana/web3.js + @coral-xyz/anchor)
• Any Solana wallet (Phantom, Solflare, etc.)
• Any Solana explorer (Solscan, Solana FM)

RogueTrader uses Pyth Network's pull oracle model with persistent PriceFeedAccount. Trade outcomes are determined entirely by on-chain oracle prices — the settler cannot influence results.

// Pyth pull model with persistent PriceFeedAccount
// 1. Settler calls addUpdatePriceFeed(base64Data, shardId=0)
//    to update the persistent PriceFeedAccount
// 2. On-chain program reads PriceFeedAccount:
//    - Validates 8-byte discriminator
//    - Checks feed_id against GroupConfig
//    - Enforces staleness (60s max age)
//    - Validates confidence interval (<2% of price)
//    - Verifies account owner == Pyth Receiver program

When a bot proposes a trade, all 29 other bots contribute proportionally as counterparties:

// Counterparty allocation in propose_bet:
for each of 29 other bots:
  proportional = cp_free * cp_pool_target / total_free
  cap          = cp_free * max_cp_exposure_bps / 10,000
  cp_stake     = min(proportional, cap)

// If sum(capped) < target: scale down proposer stake
// All 29 counterparty vaults updated atomically in one TX

The counterparty exposure cap (max_cp_exposure_bps) prevents any single bot from being over-exposed to a single trade. All 29 counterparty vaults are updated atomically in a single transaction using Address Lookup Tables.

All PDAs are validated by Anchor's seeds and bump constraints, ensuring accounts cannot be spoofed. Cross-account validation ensures fee recipients match on-chain configuration and proposer vaults are linked to their trades.

All arithmetic uses Rust's checked methods with 128-bit intermediates for large multiplications:

// Multiplication with overflow check
.checked_mul(value).ok_or(RogueTraderError::MathOverflow)?

// 128-bit intermediates for LP token calculations
let lp_amount_u128 = (deposit_amount as u128)
    .checked_mul(lp_supply as u128)?
    .checked_div(vault_balance as u128)?;
let lp_tokens = u64::try_from(lp_amount_u128)?;

Observation: The program is upgradeable by a single deploy authority wallet. A compromised authority could deploy a malicious upgrade.

Impact: Users must trust the deploy authority. Industry practice for DeFi protocols is multi-sig with a timelock.

Assessment: Standard for early-stage protocols. The deploy authority address is published and the program is verified by OtterSec, so any changes to the deployed code are detectable.

Observation: update_config allows instant changes to 22 parameters including settler pubkey and fee wallets. No timelock or multi-sig.

Impact: A compromised authority could silently redirect fees or change the settler. All parameters have on-chain bounds, so the impact is limited to fee redirection, not fund theft.

Assessment: Mitigated by bounded parameters and the fact that the authority cannot access vault funds directly. Authority transfer uses a two-step propose/accept pattern to prevent accidental or malicious instant transfers.

Observation: ReferralState.total_earnings is declared and initialized to zero but never incremented by any on-chain instruction. Fee distributions transfer SOL directly to referrer wallets via CPI but do not update this counter.

Impact: On-chain state does not reflect actual referral earnings. Off-chain tracking (Phoenix application) is the authoritative source.

Assessment: The _reserved bytes on ReferralState provide space to add this tracking in a future upgrade if desired.

Observation: total_referral_paid, total_nft_rewards_paid, total_platform_fees_paid, and total_bonus_paid in ClearingHouseState are never incremented. Only the aggregate total_deposit_fees and total_withdrawal_fees counters are maintained.

Impact: On-chain analytics for per-category fee breakdown are unavailable. The aggregate fee counters provide sufficient data for solvency verification.

Observation: Large _reserved arrays are allocated across all state accounts. For the fixed accounts (1 ClearingHouseState + 30 AgentVaults + 5 GroupConfigs), the total overhead is approximately 0.04 SOL. For per-user accounts, each user pays ~0.001 SOL extra in rent.

Assessment: Standard practice for upgradeable programs needing future field expansion without account reallocation. Minor additional cost.

Observation: bets_proposed, bets_won, bets_lost, bets_tied use u32 (max ~4.3 billion).

Assessment: At 50 trades/day per bot, overflow takes ~235,000 years. Theoretical only.

Observation: AgentVault.authorized_executor is set to the settler pubkey on vault creation but never referenced in any authorization logic.

Assessment: Unused field reserved for future functionality. All settler auth uses clearing_house.settler. Removing it would require an account migration.

Observation: Two simultaneous proposals race for the same trade PDA. The second TX fails because the PDA already exists (init constraint).

Assessment: Handled gracefully by settler retry logic. The failed TX wastes compute but causes no state corruption.

Observation: The minimum (30 seconds) and maximum (24 hours) bet duration bounds in propose_bet are compile-time constants, not configurable via update_config. Changing bounds requires a program upgrade.

Assessment: Bet durations are settler-controlled and current bounds are appropriate. These could be moved to ClearingHouseState using reserved bytes if dynamic adjustment is needed.

Observation: The Pyth validation checks staleness (60s), confidence (<2%), positive price, feed ID, and account owner — but does not check the verification_level field. A Partial verification is accepted equally to Full.

Assessment: On mainnet, the Pyth Receiver program enforces its own verification thresholds before writing price data. The staleness and confidence checks provide sufficient protection.

// Core solvency invariant:
sum(all AgentVault.sol_balance) + rewards_pool_balance == master_vault.lamports - rent_exempt

// Before deposit: LP tokens minted proportional to vault share
// Before withdrawal: available = sol_balance - locked_sol
require!(withdraw_amount <= available_liquidity)

// Trades are zero-sum: SOL only moves between AgentVault.sol_balance fields
// Win tax moves SOL from winner's payout to rewards_pool_balance
// Raffle moves SOL from rewards_pool_balance to winner bot's sol_balance
// No SOL created or destroyed through trading or raffles

Because trades are zero-sum (SOL only moves between AgentVault sol_balance fields), and actual SOL only enters/leaves through user deposits and withdrawals, the invariant is maintained automatically.

Each bot tracks locked_sol (capital locked as proposer in its own trades) and counterparty_locked_sol (capital locked as counterparty in other bots' trades). Available liquidity for withdrawals is sol_balance - locked_sol - counterparty_locked_sol. LP withdrawals cannot touch locked capital.

If the database and on-chain state diverge (e.g., due to network failures during trade proposal), the system self-heals automatically:

1. StatsTracker detects discrepancies between DB and on-chain vault state every 10 seconds
2. After ~5 minutes of persistent discrepancy, triggers reconciliation
3. Reconciliation uses getProgramAccounts to find ALL unsettled bet accounts on-chain
4. Orphaned trades (on-chain but not in DB) are auto-expired via expire_stale_bet
5. Vault counters are recomputed from actual on-chain bet accounts and corrected via admin_reset_vault

If a bot experiences net losses, its LP token value drops proportionally. This is by design — LP holders are choosing which bots to back and accept this risk. Losses flow to the bots that won the trades. LPs can withdraw at any time with no lock-up period.

1. Check your LP token balance for the bot(s) you deposited into
2. Derive the AgentVault and LP mint PDAs from the bot's ID (0-29)
3. Build and submit withdraw_sol with your LP amount
4. LP tokens burned, proportional SOL transferred to your wallet

1. If a trade is stuck (proposer or counterparty capital locked), wait for the stale trade buffer to elapse
2. Authority or settler can call expire_stale_bet to return all capital as a tie
3. If vault counters are incorrect, admin_reset_vault corrects them
4. The self-healing reconciliation loop handles this automatically in normal operation