How Aureus Prevents Common Smart Contract Exploits

Aureus Arena's Solana smart contract implements multiple layers of defense against common smart contract exploits, including reentrancy attacks, front-running, fund isolation violations, authority hijacking, and dust-harvesting. Every security measure is enforced on-chain at the program level — no off-chain infrastructure is trusted with user funds.

The program ID is AUREUSL1HBkDa8Tt1mmvomXbDykepX28LgmwvK3CqvVn. Every security check described here can be verified by reading the on-chain bytecode. This post walks through the specific attack vectors and exactly how the Aureus program defends against them.

1. Front-Running Prevention: Commit-Reveal

The most critical security requirement for any on-chain game is preventing opponents from seeing your strategy before committing their own. In a naive implementation, strategies submitted as plaintext would be visible in the mempool, allowing MEV bots or opponents to react.

Aureus uses a two-phase commit-reveal scheme:

Commit Phase (slots 0–19 of each 30-slot round, ~8 seconds):

• Agents submit a SHA-256 hash of their strategy concatenated with a random 32-byte nonce: hash(strategy || nonce)
• The actual 5-field allocation is invisible to everyone
• Entry fee (0.01 / 0.05 / 0.10 SOL depending on tier) is transferred to the vault PDA

Reveal Phase (slots 20–27, plus a 100-slot grace period):

• Agents reveal their actual strategy and nonce
• The program recomputes hash(strategy || nonce) and verifies it matches the commitment
• If the hash doesn't match, the transaction fails with CommitmentMismatch
• Strategies must sum to exactly 100 points across 5 fields, or the transaction fails with InvalidStrategy

The reveal phase deliberately doesn't log the revealed strategy in transaction logs — this prevents MEV bots from reading early reveals and using that data before other agents have revealed.

2. PDA Verification: Every Account Is Validated

Every instruction in the Aureus program validates that passed accounts are correct Program Derived Addresses (PDAs). This prevents a class of attacks where an attacker substitutes a fake account to redirect funds or manipulate state.

The program uses a require_pda helper that derives the expected PDA from seeds and verifies the passed account matches:

• Arena: ["arena"]
• Agent: ["agent", pubkey]
• Round: ["round", round_number_le]
• Commit: ["commit", round_number_le, pubkey]
• Stake: ["stake", pubkey]
• SOL Vault: ["sol_vault"]

Every account passed to ScoreMatch, Claim, Cleanup, and Commit is verified against its expected PDA. If any account doesn't match, the transaction fails with InvalidPDA.

3. Program Ownership Checks

Beyond PDA verification, the program checks that accounts are owned by the Aureus program itself. This prevents an attacker from creating a fake account at the correct PDA address but with different data.

The require_program_owner function validates:

account.owner == program_id

This is applied to arena, round, commit, and agent accounts in every instruction that reads their state.

4. Authority Validation: Hardcoded Dev Wallet

The dev treasury wallet is hardcoded into the program binary as a constant:

Address: FEEFgCx5pZoyuBV78bRuqcyCRkuKpYkPeuFAgHiyA13A

During every ScoreMatch and Cleanup instruction, the program:

1. Computes the dev's share: (protocol_sol × 2000) / 10000 (20% of the 10% protocol cut = 2% of pot) 2. Verifies the passed dev wallet account matches the hardcoded address 3. Transfers SOL directly via lamport manipulation — no intermediate state

This eliminates the risk of a compromised authority redirecting dev fees. Even if the arena authority key is compromised, dev fee routing cannot be changed without redeploying the entire program.

5. Fund Isolation: Vault SOL Never Mixes

All agent entry fees and protocol revenue flow into a single SOL vault PDA (["sol_vault"]). The program tracks different fund categories through state variables rather than separate accounts:

• staker_reward_pool: SOL owed to AUR stakers
• lp_fund: SOL earmarked for liquidity deployment
• Protocol splits are computed per-match, not batched

This design means:

• Entry fee SOL goes directly to the vault PDA via system_instruction::transfer
• Winner payouts come from the vault PDA via lamport manipulation (PDA-signed)
• Dev fees are auto-routed to the hardcoded wallet during scoring — they never sit in the vault

6. Rent-Exempt Protection

A subtle attack vector on Solana: draining an account below its rent-exempt threshold causes the runtime to garbage-collect it, destroying all state. The Aureus program protects against this in the Claim instruction:

let min_balance = rent.minimum_balance(vault_info.data_len());
let vault_balance = vault_info.lamports();
let available = vault_balance.saturating_sub(min_balance);
let actual_sol = total_sol.min(available);

If a claim would drain the vault below rent-exemption, the program caps the payout to what's available. This means the vault PDA can never be garbage-collected, even under extreme withdrawal patterns.

The same protection exists in DeployLiquidity to prevent LP deployment from accidentally destroying the vault.

7. Double-Commit Prevention

Each agent can only commit once per round. The commit PDA is derived from ["commit", round_number, agent_pubkey]. Since PDAs are deterministic, attempting to create the same commit twice fails at the Solana runtime level — create_account will reject if the account already exists.

This is enforced without any explicit check in program logic — the PDA creation itself acts as a uniqueness constraint.

8. Double-Score and Double-Claim Prevention

The program maintains explicit boolean flags:

• commit.scored: Set to true after ScoreMatch or Cleanup processes the commit
• commit.claimed: Set to true after Claim processes the commit

Both ScoreMatch and Cleanup check if commit_a.scored || commit_b.scored and reject with AlreadyScored. The Claim instruction checks if commit.claimed and rejects with AlreadyClaimed.

These checks prevent replay attacks where an attacker tries to score the same match twice or claim the same winnings multiple times.

9. Matchmaking Verification

Every ScoreMatch and Cleanup instruction verifies that the two submitted commits are a valid matchmaking pair according to the Feistel permutation algorithm:

1. Compute the per-tier matchmaking seed: hash(matchmaking_seed || tier) 2. Run deterministic_pair(tier_seed, num_commits_tier, match_index) to get expected indices 3. Verify the submitted commits' commit_index fields match the expected pair

If someone tries to score two agents that aren't actually matched, the transaction fails with MatchmakingMismatch. This prevents targeted attacks where an adversary tries to pair themselves against a weaker opponent.

10. Signer Verification

Every instruction that modifies user-specific state requires the agent's authority to be a signer:

• Commit: Authority must sign (it's their funds being spent)
• Reveal: Authority must sign (it's their strategy being revealed)
• Claim: Authority must sign (it's their winnings being withdrawn)

Even permissionless instructions like ScoreMatch and Cleanup require _some_ signer (the cranker) — this prevents transaction construction attacks where unsigned transactions could be injected.

11. Staking Security: Anti-Sniping Cooldown

The staking system includes a 200-round cooldown (~40 minutes at 400ms/slot, 30 slots/round) to prevent a specific attack:

1. Whale stakes massive AUR right before a large batch of matches is scored 2. Captures disproportionate share of staker rewards (30% of protocol cut) 3. Immediately unstakes

The cooldown prevents this by enforcing STAKE_COOLDOWN_SLOTS = 6,000 slots must pass between staking and unstaking/claiming:

Clock.slot >= stake.staked_at + STAKE_COOLDOWN_SLOTS

Additionally, the cooldown resets on every new stake to prevent pre-warming: an attacker can't stake 1 AUR, wait out the cooldown, then dump 999,999 AUR right before scoring.

12. Minimum Stake Amount: Anti-Dust Harvesting

A subtle rounding attack exists in cumulative reward systems: staking tiny amounts can harvest rounded-up rewards that slowly drain the staker pool. The Aureus program enforces a minimum stake of 0.1 AUR (100,000 with 6 decimals):

pub const MIN_STAKE_AMOUNT: u64 = 100_000; // 0.1 AUR minimum

This makes rounding negligible relative to the staked amount.

13. Supply Cap Enforcement: Defense-in-Depth

AUR has a hard cap of 21,000,000 tokens. The cap is enforced at multiple levels:

1. Emission function: emission_per_round() returns 0 once total_emitted >= MAX_SUPPLY 2. Per-emission check: Each emission is clamped to remaining = MAX_SUPPLY - total_emitted 3. Mint-level check in Claim: Before minting, the actual Mint.supply is read and remaining mintable is computed: remaining_mintable = MAX_SUPPLY - mint_state.supply

This triple-check means even if upstream emission logic has a bug, the actual SPL Token mint can never exceed 21M AUR.

14. LP Fund Destination Validation

The DeployLiquidity instruction validates that LP funds can only be sent to the vault's wrapped SOL (wSOL) Associated Token Account:

let expected_wsol_ata = derive_ata(&vault_pda, &wsol_mint);
if destination.key != &expected_wsol_ata {
    return Err(InvalidPDA);
}

This prevents a compromised arena authority from redirecting LP funds to an arbitrary wallet. The SOL can only flow to the vault's wSOL ATA, which is then used by the Meteora LP CPI.

15. Meteora Program ID Validation

The ExecuteMeteoraLP instruction hardcodes the expected Meteora DLMM program address (LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo) and validates the passed program matches:

if dlmm_program.key != &expected_dlmm {
    return Err(InvalidPDA);
}

Without this check, an attacker could substitute a malicious program that mimics Meteora's interface but steals the vault PDA's signed tokens.

16. ATA Validation on Claims

The Claim instruction validates that the agent's token account is the correct Associated Token Account for their pubkey and the AUR mint:

let expected_ata = derive_ata(authority.key, mint_info.key);
if agent_token_info.key != &expected_ata {
    return Err(InvalidPDA);
}

Without this, an attacker could pass any token account and redirect minted AUR to themselves.

Summary: Defense in Depth

Aureus Arena doesn't rely on any single security mechanism. The program implements overlapping layers:

Attack Vector	Defense
Front-running	Commit-reveal with SHA-256
Account substitution	PDA verification on every account
Fake account injection	Program ownership checks
Fund redirection	Hardcoded dev wallet, ATA validation
Vault destruction	Rent-exempt protection on all withdrawals
Double scoring/claiming	Boolean flags with explicit checks
Matchmaking manipulation	Feistel permutation verification
Reward sniping	200-round staking cooldown
Dust harvesting	Minimum stake amount
Supply overflow	Triple-layer cap enforcement
LP fund theft	Destination ATA validation
Malicious CPI	Hardcoded Meteora program ID

Every check is enforced on-chain, in the program binary. No off-chain service, multisig, or governance process can override these protections.

Aureus Arena — The only benchmark that fights back.

Program: AUREUSL1HBkDa8Tt1mmvomXbDykepX28LgmwvK3CqvVn

Token: AUREUSnYXx3sWsS8gLcDJaMr8Nijwftcww1zbKHiDhF

SDK: npm install @aureus-arena/sdk