Smart Contract Analysis Statement (V2 Re-Audit)

Contract Analysis

The Token ICO contract implements a Solana-based multi-stage presale program built with Anchor 0.32, featuring configurable token pricing, stablecoin and native SOL payment acceptance (via Pyth oracle), staged token claiming, and admin-gated lifecycle management across 15 on-chain instructions. This is a re-audit following the V1 report; the development team addressed several findings and provided explicit design-decision responses for others. While the overall design follows sound Anchor patterns and the core arithmetic and PDA logic is correct, the following items remain noteworthy:

• No vault balance guard in buy (Low — downgraded from Critical, acknowledged by client): The buy instruction does not verify that the token vault holds enough tokens to fulfill the purchase. Users can pay real funds (stablecoins or SOL) for tokens that may not yet be available to claim. The client explicitly chose this design: the admin is responsible for funding the vault before enabling claims via enable_stage_claim. The claim instruction does verify vault.amount >= claimable (claim.rs line 26-29), providing a safety net at claim time. The README at line 13 still incorrectly states that buy performs this check.
• Single-step admin transfer (Low — downgraded from High, acknowledged by client): The transfer_admin instruction performs an irrevocable, single-transaction reassignment of the admin key. A typo or compromised RPC endpoint permanently locks all admin-gated functionality and traps all funds in program PDAs. The client declined to implement the 2-step nominate/accept pattern, stating no requirement for complex admin transfer logic. The README was updated with an explicit warning about irreversibility. The zero-address check (Pubkey::default()) prevents the most common accidental lockout.
• Stablecoin payments hardcoded at $1.00 (Low — downgraded from High, acknowledged by client): All whitelisted stablecoins are valued at exactly $1.00 regardless of market conditions. During a depeg event (historically observed with USDC and USDT), buyers can acquire ICO tokens at a discount. The client confirmed this is the intended design — USDC/USDT are converted at a 1:1 ratio by agreement. The README was updated to document this. The admin can use toggle_pause to halt sales during a depeg event.
• Residual README-to-code divergence (Informational): The README was substantially updated in V2 — the dual-path fund architecture is now documented, the admin transfer warning was added, the NoPendingAdmin error was removed, and the stablecoin pricing note was added. However, 10 residual inaccuracies remain, including: a documented update_treasury instruction that does not exist, references to a treasury field in IcoConfig, the staleness threshold stated as 300s when code uses 120s, and a pending_admin reference.

Resolved Findings from V1

The following V1 findings were confirmed as properly addressed in V2:

• M-03 (Premature Stage Closure): close_stage now requires tokens_claimed_total == tokens_sold before a stage can be closed, preventing permanent loss of unclaimed user entitlements. New error UnclaimedTokensRemaining added.
• M-04 (Input Validation Gap): Both create_stage and update_stage now validate that timestamps are non-negative, that end_time is in the future when set, and that end_time > start_time when both are set. New errors InvalidTimeRange and EndTimeExpired added.
• L-03 (Price Oracle Staleness): Pyth staleness threshold reduced from 300s to 120s.
• O-01 (Double Clock::get()): Clock instance is now passed as a parameter to compute_sol_usd_value, eliminating the redundant syscall.
• I-02, I-06, L-04: Documentation inaccuracies corrected (NoPendingAdmin removed, dual-path architecture documented, set_whitelist_token params corrected).

Ownership Privileges

The ownership of the contract is centralized in a single admin key stored in the IcoConfig PDA. The admin retains full privileges including:

• Creating, updating, activating, and closing presale stages with arbitrary pricing and allocation
• Enabling or disabling token claiming per stage, including while a stage is still active for purchases (acknowledged race condition — M-02)
• Emergency withdrawal of any SPL token (including ICO tokens and collected payments) from any ATA of the ico_config PDA, at any time, with no minimum balance enforcement (acknowledged centralization risk — M-01)
• Emergency withdrawal of SOL from the ico_config PDA (above rent-exempt minimum)
• Pausing and unpausing the contract, which disables buy and claim for all users
• Whitelisting and disabling payment tokens
• Irrevocable single-step transfer of admin privileges to any non-zero address

Limitations on the admin:

• The admin cannot mint new ICO tokens (mint authority is external to the contract)
• The admin cannot modify a user's purchase record or claim on their behalf
• The admin cannot bypass PDA seed constraints or forge CPI signatures
• The admin cannot re-initialize the ICO after the initial initialize_ico call (PDA already exists)
• The admin cannot close a stage while users still have unclaimed balances (tokens_claimed_total == tokens_sold required — M-03 resolved)

Security Features

The contract implements several positive security features:

• Checked arithmetic throughout: All arithmetic operations use checked_add, checked_sub, checked_mul, checked_div, and u64::try_from with explicit IcoError::Overflow handling. The workspace release profile also sets overflow-checks = true.
• Correct PDA derivation and bump verification: All program-derived addresses use deterministic seeds with stored bump values, and all account constraints verify bumps on access.
• Pyth oracle validation: SOL/USD price feeds are validated for program ownership (Pyth Push Oracle or Receiver), data integrity (Anchor deserialization), feed identity (SOL/USD feed ID), price positivity, and staleness (120-second threshold, reduced from 300s in V2).
• Manual UncheckedAccount validation for payment accounts: The buy handler manually deserializes and validates user_payment_account and payment_vault for mint, owner, and token-program ownership in the stablecoin path, preventing account spoofing.
• Single-active-stage invariant: The current_stage field on IcoConfig ensures only one stage can be active for purchases at any time, preventing cross-stage conflicts.
• Rent-exemption protection on SOL withdrawal: The emergency_withdraw_sol handler correctly computes and preserves the minimum rent-exempt balance before allowing SOL extraction from the PDA.
• Settlement guard on stage closure (V2): The close_stage instruction now requires all purchased tokens to be claimed (tokens_claimed_total == tokens_sold) before the stage account can be closed, preventing permanent loss of user entitlements.
• Stage time window validation (V2): Both create_stage and update_stage now enforce non-negative timestamps, future end_time, and proper end_time > start_time ordering. The buy instruction enforces the time window at purchase time.

Testing Assessment

The test suite (62 tests, all passing) covers the core happy-path operations and basic error conditions for all 15 instructions. The expectError helper was improved to use exact matching on AnchorError.error.errorCode.code as the primary assertion path. However, significant gaps remain: zero coverage for the SOL/Pyth payment flow, zero coverage for the newly added stage time-window enforcement (V2 code with zero tests), no vault-underfunding scenarios (despite the claim-time vault check being the critical safety net for C-02), no account-spoofing resistance tests for the UncheckedAccount fields in buy, and no test for the InvalidAdmin error path. The emergency_withdraw_sol test uses synthetic airdrop funding instead of actual SOL buy transactions, and two test cases serve only as state setup without assertions. The entire suite remains a single monolithic describe block with sequential test coupling — no test can run in isolation.

Note — This re-audit report consists of a security analysis of the Token ICO smart contract deployed on Solana, following the initial V1 audit and the client’s response addressing or acknowledging each finding. This analysis did not include economic analysis of the project’s tokenomics, token distribution schedule, or vesting mechanisms. Moreover, we only audited the on-chain Anchor program under programs/contract/ and its associated TypeScript test suite. Off-chain CLI scripts in app/, deployment tooling, and any other contracts or programs associated with the project were not audited by our team. We recommend investors do their own research before participating in the token sale.