SolGuardian — exploit hunt report

migrate() executes `target.delegatecall(...)`. the delegatecall target `target` is an instruction argument, so any caller chooses the code that runs inside this contract's storage. delegatecall keeps this contract's storage and msg.sender, so the callee can rewrite owner/admin/implementation slots, mint, drain, or call selfdestruct. Authorisation on the wrapper (absent) does not help if the target itself is attacker-chosen.

(bool ok, ) = target.delegatecall(data);

skill skills/delegatecall-proxy/SKILL.md checklist satisfied:

• The delegatecall target resolves to a constant or admin-upgraded implementation address -
• Writes to logic pointers are guarded by an admin role **and** a timelock/delay, and emit an

load_foreign_config() reinterprets borrowed account bytes as `*const VaultConfig` and dereferences it. The layout of an account is entirely caller-supplied: there is no owner check and no length/discriminator check here, so the program reads memory it never validated. That is a type-conflict / out-of-bounds read on a chain where the runtime will not save you - and even when it only reads garbage, the value becomes trusted state.

corroborated independently by 1 other detector(s), 1 rule(s): ACCT-001 (SG-SOL-014) (annotation only — does not change this grade)

let cfg: &VaultConfig = unsafe { &*(data.as_ptr() as *const VaultConfig) };

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• SPL accounts assert `owner == token_program`, the right `mint`, and the expected authority
• `remaining_accounts` are length-checked **before** indexing and validated individually -

claimTreasuryGrant() pays out on a verified signature but no nonce, no mapping write and no already-used check exists anywhere in the contract. The signer's single authorisation is therefore an unlimited mint: the same (v, r, s) can be submitted in an unbounded number of transactions by anyone who has seen it once - including from public mempool history.

corroborated independently by 2 other detector(s), 3 rule(s): CEI-001 (SG-EVM-003), EC-001 (SG-EVM-010), EC-003 (SG-EVM-024) (annotation only — does not change this grade)

function claimTreasuryGrant(bytes32 doc, uint8 v, bytes32 r, bytes32 s, uint256 amount) external {

skill skills/signature-replay/SKILL.md checklist satisfied:

• A spend-once record exists (per-hash mapping or per-signer nonce) and is written in the same
• Batch payloads bind the whole payload hash (no partial-subset replay).

claimTreasuryGrant() performs an external interaction (payable(msg.sender).transfer) at line 90 and only updates contract state afterwards (borrowed). A callee can re-enter claimTreasuryGrant() during that callback and still see the pre-call balance, so the same funds can be withdrawn repeatedly. No reentrancy guard and no checks-effects-interactions ordering were found in this function.

corroborated independently by 2 other detector(s), 6 rule(s): EC-001 (SG-EVM-010), EC-003 (SG-EVM-024), SR-001 (SG-EVM-017), SR-002 (SG-EVM-002), SR-003 (SG-EVM-020), SR-004 (SG-EVM-023) (annotation only — does not change this grade)

payable(msg.sender).transfer(amount);

skill skills/reentrancy/SKILL.md checklist satisfied:

• State writes (`balances[...]`, totals, flags, allowances, nonces) are ordered strictly
• A reentrancy guard (`nonReentrant`, OZ `ReentrancyGuard`, ERC-7201 transient storage
• before** the interaction - checks-effects-interactions holds.
• Callbacks from the callee (`onERC721Received`, `tokensReceived`, `ERC4626` deposit hooks,

decommission() can destroy IHyperCorePriceOracle and force-send the whole native balance to an address the caller picks (`beneficiary`). There is no authorisation check at all on this path. Destructible state also kills any index that assumed code persists, and it makes an irreversible action available without a timelock or governance delay.

selfdestruct(beneficiary);

skill skills/fund-recovery/SKILL.md checklist satisfied:

• `selfdestruct` does not exist in application code. If it does, it is reachable only behind a

withdraw() performs an external interaction (msg.sender.call) at line 74 and only updates contract state afterwards (balanceOf[msg.sender], totalDeposits). A callee can re-enter withdraw() during that callback and still see the pre-call balance, so the same funds can be withdrawn repeatedly. No reentrancy guard and no checks-effects-interactions ordering were found in this function.

(bool ok, ) = msg.sender.call{value: amount}("");

skill skills/reentrancy/SKILL.md checklist satisfied:

• State writes (`balances[...]`, totals, flags, allowances, nonces) are ordered strictly
• A reentrancy guard (`nonReentrant`, OZ `ReentrancyGuard`, ERC-7201 transient storage
• before** the interaction - checks-effects-interactions holds.
• Callbacks from the callee (`onERC721Received`, `tokensReceived`, `ERC4626` deposit hooks,

adminDrain() is external, moves value to `to`, and writes payout, yet nothing in the function proves who the caller is: no `only*` modifier, no `require(msg.sender == ...)`, no role check, and no caller-scoped accounting. So the state it touches is not limited to the caller's own balance - any address can call it. This is a total-loss path: the destination is fully caller-chosen.

corroborated independently by 2 other detector(s), 2 rule(s): CEI-001 (SG-EVM-007), SD-002 (SG-EVM-009) (annotation only — does not change this grade)

function adminDrain(address to, uint256 amount) external {

skill skills/access-control/SKILL.md checklist satisfied:

• Each privileged function has either a modifier (`onlyOwner`, `onlyRole`, `onlyAdmin`)
• Build the list of externally callable functions and mark which ones mutate privileged state.

adminDrain() performs an external interaction (to.call) at line 85 and only updates contract state afterwards (totalDeposits). A callee can re-enter adminDrain() during that callback and still see the pre-call balance, so the same funds can be withdrawn repeatedly. No reentrancy guard and no checks-effects-interactions ordering were found in this function.

corroborated independently by 2 other detector(s), 2 rule(s): AC-001 (SG-EVM-006), SD-002 (SG-EVM-009) (annotation only — does not change this grade)

(bool sent, ) = to.call{value: payout}("");

skill skills/reentrancy/SKILL.md checklist satisfied:

• State writes (`balances[...]`, totals, flags, allowances, nonces) are ordered strictly
• A reentrancy guard (`nonReentrant`, OZ `ReentrancyGuard`, ERC-7201 transient storage
• before** the interaction - checks-effects-interactions holds.
• Callbacks from the callee (`onERC721Received`, `tokensReceived`, `ERC4626` deposit hooks,

`raw_config` is declared as AccountInfo<info> in the `LoadConfig` accounts struct, so Anchor cannot prove it was signed. load_foreign_config() still uses it to authorise a privileged state change. On Solana an unsigned account is just bytes anyone can craft: an attacker supplies their own account with the right key/shape and the program accepts the instruction. The handler contains no `is_signer` check either and no `Signer` account exists in the struct at all.

pub raw_config: AccountInfo<'info>,

skill skills/solana-signer/SKILL.md checklist satisfied:

• Every account whose **signature** is required is typed `Signer<'info>`; the type system is
• The key stored as the future authority (`vault.authority = authority.key()`) comes from a

assetValue() derives a price from in-pool reserves (`getReserves`), which is the pool's own balance ratio rather than a traded price. Any caller with enough capital - typically a flash loan - can skew that ratio in a single transaction, and the contract will read the manipulated number in the same block. There is no time-weighting and no second source here.

(uint112 reserve0, uint112 reserve1, ) = pool.getReserves();

skill skills/oracle-price/SKILL.md checklist satisfied:

• Identify the pricing source: in-pool reserves (spot), a single Chainlink round, a
• The price cannot be moved inside the same transaction that consumes it (flash-loan
• A second, independent source or a max-deviation circuit breaker exists for anything that

The `Withdraw` constraint list contains no `Signer`, yet withdraw() performs a privileged operation (`.lamports_mut(`). Permissionless mutation is exactly the class of bug that empties programs on Solana: there is no `msg.sender` equivalent to fall back on, so the account list is the only authorisation surface.

corroborated independently by 2 other detector(s), 2 rule(s): AUTH-003 (SG-SOL-021), MATH-002 (SG-SOL-023) (annotation only — does not change this grade)

ctx.accounts.user_authority.lamports_mut(|l| *l += amount)?;

skill skills/solana-signer/SKILL.md checklist satisfied:

• Every account whose **signature** is required is typed `Signer<'info>`; the type system is

The `Slash` constraint list contains no `Signer`, yet slash() performs a privileged operation (`+=`). Permissionless mutation is exactly the class of bug that empties programs on Solana: there is no `msg.sender` equivalent to fall back on, so the account list is the only authorisation surface.

corroborated independently by 2 other detector(s), 2 rule(s): CPI-003 (SG-SOL-015), MATH-004 (SG-SOL-025) (annotation only — does not change this grade)

ctx.accounts.vault_token_account.amount += shares;

skill skills/solana-signer/SKILL.md checklist satisfied:

• Every account whose **signature** is required is typed `Signer<'info>`; the type system is

The `SetLimiter` constraint list contains no `Signer`, yet set_limiter() performs a privileged operation (`ctx.accounts.vault_config.limiter = `). Permissionless mutation is exactly the class of bug that empties programs on Solana: there is no `msg.sender` equivalent to fall back on, so the account list is the only authorisation surface.

ctx.accounts.vault_config.limiter = limiter;

skill skills/solana-signer/SKILL.md checklist satisfied:

• Every account whose **signature** is required is typed `Signer<'info>`; the type system is

deposit() hands `ctx.accounts.user_token_account` to an SPL token CPI while the account is only an UncheckedAccount. Nothing proves its owner is the token program, that it is the vault's token account, or that its mint is the expected one. The CPI happily operates on whatever account the client supplied, which is the standard way vaults end up paying out of the wrong pot.

corroborated independently by 1 other detector(s), 3 rule(s): MATH-001 (SG-SOL-010), MATH-002 (SG-SOL-022), MATH-003 (SG-SOL-016) (annotation only — does not change this grade)

from: ctx.accounts.user_token_account.to_account_info(),

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• SPL accounts assert `owner == token_program`, the right `mint`, and the expected authority

`signer_program` is declared as UncheckedAccount in `SettleExternal` and is used as the program id for a cross-program call. Anchor only checks that an account is a *program* when it is typed `Program<'info, T>` (or when `is_program()` is called). Here the client picks the 'program', so the instruction is executed against code the program never vouched for - typically a spoofed token program that returns success without moving anything.

corroborated independently by 1 other detector(s), 1 rule(s): ACCT-001 (SG-SOL-013) (annotation only — does not change this grade)

pub signer_program: UncheckedAccount<'info>,

skill skills/solana-cpi/SKILL.md checklist satisfied:

• The callee is a `Program<'info, T>` account (or `is_program()` verified), never a raw

adminDrain() moves native value to `to`, which is supplied by the caller rather than derived from the contract's own accounting. It is unguarded. Any caller (or any caller that can reach this path) chooses the destination, so shared funds can be redirected at will.

corroborated independently by 2 other detector(s), 2 rule(s): AC-001 (SG-EVM-006), CEI-001 (SG-EVM-007) (annotation only — does not change this grade)

(bool sent, ) = to.call{value: payout}("");

skill skills/fund-recovery/SKILL.md checklist satisfied:

• No value-moving call takes its destination from instruction arguments without deriving it from

`reporter` is declared as UncheckedAccount<info> in the `Slash` accounts struct, so Anchor cannot prove it was signed. slash() still uses it to authorise a privileged decision. On Solana an unsigned account is just bytes anyone can craft: an attacker supplies their own account with the right key/shape and the program accepts the instruction. The handler contains no `is_signer` check either and no `Signer` account exists in the struct at all.

pub reporter: UncheckedAccount<'info>,

skill skills/solana-signer/SKILL.md checklist satisfied:

• Every account whose **signature** is required is typed `Signer<'info>`; the type system is
• The key stored as the future authority (`vault.authority = authority.key()`) comes from a

`authority` is declared as AccountInfo<info> in the `SetLimiter` accounts struct, so Anchor cannot prove it was signed. set_limiter() still uses it to authorise a privileged decision. On Solana an unsigned account is just bytes anyone can craft: an attacker supplies their own account with the right key/shape and the program accepts the instruction. The handler contains no `is_signer` check either and no `Signer` account exists in the struct at all.

pub authority: AccountInfo<'info>,

skill skills/solana-signer/SKILL.md checklist satisfied:

• Every account whose **signature** is required is typed `Signer<'info>`; the type system is
• The key stored as the future authority (`vault.authority = authority.key()`) comes from a

deposit() computes `(amount / vault.total_deposits) * 1_000_000_000`. Rust integers truncate, so dividing first throws away the remainder before the scaling factor is applied: for `amount < divisor` the result is exactly zero, and for larger amounts the user loses up to `divisor-1` units of precision per operation. This is the classic share-accounting bug - deposits silently credit 0 shares.

corroborated independently by 1 other detector(s), 2 rule(s): ACCT-001 (SG-SOL-012), ACCT-002 (SG-SOL-006) (annotation only — does not change this grade)

let shares = (amount / vault.total_deposits) * 1_000_000_000; // precision loss

skill skills/solana-math/SKILL.md checklist satisfied:

• Multiplication happens **before** division; division-first expressions are precision-loss
• Rounding direction is deliberate and always favours the pool (virtual offset / ERC-4626-style

settle_external() performs a cross-program invocation and throws the `Result` away (no `?`, no `require!`). If the callee reverts, the CPI error is swallowed and this handler still returns `Ok(())`, so the program records the external operation as if it succeeded. Every downstream accounting decision then runs on a state that never happened.

corroborated independently by 1 other detector(s), 1 rule(s): ACCT-001 (SG-SOL-013) (annotation only — does not change this grade)

anchor_lang::solana_program::program::invoke(&instruction, &account_infos);

skill skills/solana-cpi/SKILL.md checklist satisfied:

• Every CPI result is propagated (`?`) or explicitly handled; a dropped `Result` means the

claimTreasuryGrant() calls out to e(msg.sender) and ignores the result. e(msg.sender).transfer() can fail silently: low-level `call` returns false instead of reverting, and `send`/`transfer` return false when the recipient cannot accept the value. State that was already updated before the call is not rolled back, so the contract's view of itself diverges from the chain - for accounting code that is a direct loss of user funds.

corroborated independently by 2 other detector(s), 5 rule(s): CEI-001 (SG-EVM-003), SR-001 (SG-EVM-017), SR-002 (SG-EVM-002), SR-003 (SG-EVM-020), SR-004 (SG-EVM-023) (annotation only — does not change this grade)

require(signer == admin, "hyprivault: bad signature");

skill skills/external-calls/SKILL.md checklist satisfied:

• Non-standard ERC20s (USDT-style no-return, fee-on-transfer, rebasing) are handled with

setOperator() authorises the caller with `tx.origin` instead of `msg.sender`. tx.origin is the EOA that started the transaction and it keeps equaling the owner even when the owner is tricked into calling a malicious contract first. Any phishing-style interaction therefore hands over full authorisation of this function, which is exactly why Solidity deprecated the pattern.

require(tx.origin == owner, "vault: not owner (tx.origin)");

skill skills/access-control/SKILL.md checklist satisfied:

• `tx.origin` is **never** the authorisation basis (`msg.sender` is the caller).

refundPending() calls out to n and ignores the result. n.transfer() can fail silently: low-level `call` returns false instead of reverting, and `send`/`transfer` return false when the recipient cannot accept the value. State that was already updated before the call is not rolled back, so the contract's view of itself diverges from the chain - for accounting code that is a direct loss of user funds.

corroborated independently by 1 other detector(s), 1 rule(s): AC-001 (SG-EVM-019) (annotation only — does not change this grade)

pendingRewards[user] = 0;

skill skills/external-calls/SKILL.md checklist satisfied:

• Non-standard ERC20s (USDT-style no-return, fee-on-transfer, rebasing) are handled with

setReserveFactor() rewrites security-critical storage (reserveFactorBps) with no authorisation check. An unguarded price feed, fee, cap or reserve parameter is the usual first step of a composed exploit: the attacker does not break the vault directly, they turn the vault's own inputs until a legitimate code path pays them. On HyperEVM treat HyperCore-style reads with the same caution.

function setReserveFactor(uint256 bps) external {

skill skills/access-control/SKILL.md checklist satisfied:

• Each privileged function has either a modifier (`onlyOwner`, `onlyRole`, `onlyAdmin`)
• Build the list of externally callable functions and mark which ones mutate privileged state.

assetValue() takes the answer from `latestRoundData()` but never inspects `updatedAt`, `startedAt`, `answeredInRound` or `roundId`. A stale round, a round still in progress, or a negative/zero answer therefore passes straight through, and the contract keeps pricing off a print that may be hours old. The `require(answer > 0)` guard alone is not a freshness check.

(, int256 answer, , , ) = priceFeed.latestRoundData();

skill skills/oracle-price/SKILL.md checklist satisfied:

• Chainlink reads validate all four of: `updatedAt` freshness, `answeredInRound >= roundId`,

setPriceFeed() rewrites security-critical storage (priceFeed) with no authorisation check. An unguarded price feed, fee, cap or reserve parameter is the usual first step of a composed exploit: the attacker does not break the vault directly, they turn the vault's own inputs until a legitimate code path pays them. On this chain treat HyperCore-style reads with the same caution.

function setPriceFeed(address feed) external {

skill skills/access-control/SKILL.md checklist satisfied:

• Each privileged function has either a modifier (`onlyOwner`, `onlyRole`, `onlyAdmin`)
• Build the list of externally callable functions and mark which ones mutate privileged state.

`user_token_account` in the `Deposit` constraint list is typed as UncheckedAccount<info>, so Anchor performs no deserialisation, owner or discriminator check on it - yet deposit() passes it into program logic. That is account-confusion territory: an attacker can substitute a look-alike account (wrong owner, wrong mint, wrong program) and the handler has no way to notice. Typing it as `Account<'info, T>` / `Program<'info, T>` makes the runtime enforce it for free.

corroborated independently by 1 other detector(s), 3 rule(s): MATH-001 (SG-SOL-010), MATH-002 (SG-SOL-022), MATH-003 (SG-SOL-016) (annotation only — does not change this grade)

pub user_token_account: UncheckedAccount<'info>,

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• SPL accounts assert `owner == token_program`, the right `mint`, and the expected authority
• Every account that authorises a privileged action is typed `Signer<'info>` (or its

`signer_program` in the `SettleExternal` constraint list is typed as UncheckedAccount<info>, so Anchor performs no deserialisation, owner or discriminator check on it - yet settle_external() passes it into program logic. That is account-confusion territory: an attacker can substitute a look-alike account (wrong owner, wrong mint, wrong program) and the handler has no way to notice. Typing it as `Account<'info, T>` / `Program<'info, T>` makes the runtime enforce it for free.

corroborated independently by 1 other detector(s), 2 rule(s): CPI-001 (SG-SOL-011), CPI-002 (SG-SOL-007) (annotation only — does not change this grade)

pub signer_program: UncheckedAccount<'info>,

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• SPL accounts assert `owner == token_program`, the right `mint`, and the expected authority
• Every account that authorises a privileged action is typed `Signer<'info>` (or its

`raw_config` in the `LoadConfig` constraint list is typed as AccountInfo<info>, so Anchor performs no deserialisation, owner or discriminator check on it - yet load_foreign_config() passes it into program logic. That is account-confusion territory: an attacker can substitute a look-alike account (wrong owner, wrong mint, wrong program) and the handler has no way to notice. Typing it as `Account<'info, T>` / `Program<'info, T>` makes the runtime enforce it for free.

corroborated independently by 1 other detector(s), 1 rule(s): DESER-001 (SG-SOL-001) (annotation only — does not change this grade)

pub raw_config: AccountInfo<'info>,

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• SPL accounts assert `owner == token_program`, the right `mint`, and the expected authority
• Every account that authorises a privileged action is typed `Signer<'info>` (or its

setImplementation() assigns `implementation` with no authorisation check. Whoever controls that slot controls the logic every delegatecall in this proxy resolves to, which is equivalent to owning the contract and all of its storage. This is the storage-collision/upgrade footgun class: the slot is also shared with the implementation's own layout, so ordering matters.

implementation = newImpl;

skill skills/delegatecall-proxy/SKILL.md checklist satisfied:

• Writes to logic pointers are guarded by an admin role **and** a timelock/delay, and emit an

claimTreasuryGrant() verifies a signature with raw `ecrecover` on a caller-supplied hash. The digest does not commit to the verifying contract address or the chain id (no EIP-712 domain separator), so one valid signature is valid everywhere the same bytecode is deployed - every fork, every testnet-to-mainnet copy, and every sibling contract that shares the signer.

corroborated independently by 2 other detector(s), 3 rule(s): CEI-001 (SG-EVM-003), EC-001 (SG-EVM-010), EC-003 (SG-EVM-024) (annotation only — does not change this grade)

address signer = ecrecover(doc, v, r, s);

skill skills/signature-replay/SKILL.md checklist satisfied:

• The digest commits to the verifying context: EIP-712 domain separator with `name`,

`pendingAdmin` is declared as a storage address and used as the only authorisation for recoverTokens(), but nothing in this contract ever assigns it. It is therefore zero (`address(0)`), and no caller can ever satisfy the check. The function is dead code, which means value that only this path can move - ETH and tokens held by the contract - is permanently stranded.

require(msg.sender == pendingAdmin, "hyprivault: not pending admin");

skill skills/fund-recovery/SKILL.md checklist satisfied:

• Token recovery uses `SafeERC20` and checks the return data - a rescue that silently fails is

refundPending() is public, moves value to `user`, and writes owed, yet nothing in the function proves who the caller is: no `only*` modifier, no `require(msg.sender == ...)`, no role check, and no caller-scoped accounting. So the state it touches is not limited to the caller's own balance - any address can call it. The destination is a named user, so the direct risk is griefing/replay of that user's claim rather than an empty contract.

corroborated independently by 1 other detector(s), 1 rule(s): EC-001 (SG-EVM-012) (annotation only — does not change this grade)

function refundPending(address user) public returns (uint256 paid) {

skill skills/access-control/SKILL.md checklist satisfied:

• Each privileged function has either a modifier (`onlyOwner`, `onlyRole`, `onlyAdmin`)
• Build the list of externally callable functions and mark which ones mutate privileged state.

slash() writes `ctx.accounts.vault_token_account.amount` directly. An SPL token account is owned by the token program, so a well-behaved runtime will reject the mutation; where the owner check is weak (or the account was passed as a raw/duplicated account) the balance can be forged inside the transaction, letting an attacker mint purchasing power without moving tokens.

corroborated independently by 2 other detector(s), 2 rule(s): MATH-004 (SG-SOL-025), SIGNER-002 (SG-SOL-004) (annotation only — does not change this grade)

ctx.accounts.vault_token_account.amount += shares;

skill skills/solana-cpi/SKILL.md checklist satisfied:

• Every CPI result is propagated (`?`) or explicitly handled; a dropped `Result` means the

deposit() divides by `vault.total_deposits`, which is program state that can legitimately be zero (a fresh vault). On Solana an integer division by zero panics the builtin, the transaction fails with an opaque error, and the first depositor can never complete the flow - an availability bug rather than a theft, but it blocks the account's own happy path.

corroborated independently by 1 other detector(s), 2 rule(s): ACCT-001 (SG-SOL-012), ACCT-002 (SG-SOL-006) (annotation only — does not change this grade)

let shares = (amount / vault.total_deposits) * 1_000_000_000; // precision loss

skill skills/solana-math/SKILL.md checklist satisfied:

• Divisors can never be zero: the empty-vault case is special-cased or guarded with

settle_many() reads `remaining_accounts[0]` from `ctx.remaining_accounts` before checking how many accounts the client actually sent. A short account list panics on the slice index (an uncaught panic in the handler, not a clean program error), and any validation that *would* have happened afterwards is skipped - note the ordering here: the read precedes the `require!`.

let first = &ctx.remaining_accounts[0];

skill skills/solana-cpi/SKILL.md checklist satisfied:

• `remaining_accounts` lengths are validated before they are used as CPI accounts.

The account constraint uses `bump = vault_config.bump`, and that stored bump was written from an instruction argument in `initialize`. Anchor will therefore accept *any* bump the client first persisted, so the seeds constraint stops pinning the address to a single canonical PDA. Bump values are part of the address derivation: letting the client choose them is a validation gap.

#[account(mut, seeds = [b"vault", vault_config.key().as_ref()], bump = vault_config.bump)]

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• PDAs are derived, not trusted: `seeds` + `bump` verified by Anchor, or

The account constraint uses `bump = vault_config.bump`, and that stored bump was written from an instruction argument in `initialize`. Anchor will therefore accept *any* bump the client first persisted, so the seeds constraint stops pinning the address to a single canonical PDA. Bump values are part of the address derivation: letting the client choose them is a validation gap.

corroborated independently by 1 other detector(s), 1 rule(s): AUTH-002 (SG-SOL-024) (annotation only — does not change this grade)

#[account(mut, seeds = [b"vault", vault_config.key().as_ref()], bump = vault_config.bump, realloc = 8, realloc::payer = vault_config, realloc::zero = false)]

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• PDAs are derived, not trusted: `seeds` + `bump` verified by Anchor, or

initialize() takes `bump: u8` straight from the instruction and stores it, and other handlers then use that stored value as their seeds constraint (`bump = config.bump`). A PDA is only canonical when the bump is derived with `find_program_address`; storing the caller's number means the first writer decides how authority is derived. Even where `init` seeds constrain this particular deployment, the pattern is how upgrade/freeze/mint authority bugs hide.

pub fn initialize(ctx: Context<Initialize>, bump: u8, limiter: u64) -> Result<()> {

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• PDAs are derived, not trusted: `seeds` + `bump` verified by Anchor, or
• SPL accounts assert `owner == token_program`, the right `mint`, and the expected authority

claimTreasuryGrant() accepts a signature with no deadline and no expiry check. A signer's intent is usually time-bounded - rates, collateral ratios and allowances change - so a signature that was reasonable on the day it was signed can be catastrophic months later, and a leaked offline payload never expires.

corroborated independently by 2 other detector(s), 3 rule(s): CEI-001 (SG-EVM-003), EC-001 (SG-EVM-010), EC-003 (SG-EVM-024) (annotation only — does not change this grade)

function claimTreasuryGrant(bytes32 doc, uint8 v, bytes32 r, bytes32 s, uint256 amount) external {

skill skills/signature-replay/SKILL.md checklist satisfied:

• A `deadline` is part of the signed payload and is enforced against `block.timestamp`.

The recovery path does a low-level `token.call(...)` and then discards the boolean (the code shape here is `(bool ok, ) = ...; ok;`). A non-standard or pausable token that returns false makes the caller believe the rescue succeeded, so a failed recovery looks like a completed one.

(bool ok, ) = token.call(abi.encodeWithSelector(0xa9059cbb, to, amount));

skill skills/fund-recovery/SKILL.md checklist satisfied:

• Token recovery uses `SafeERC20` and checks the return data - a rescue that silently fails is

`user_authority` in `Withdraw` reads like an authority (AccountInfo<info>) but is not a `Signer`, is not tied by `has_one`/`constraint`/`seeds`, and withdraw() still consumes it. Any mint / freeze / close authority check the program assumes happens here is really happening on an account the client chose. The privilege exists; nothing in the source limits who exercises it.

corroborated independently by 2 other detector(s), 2 rule(s): MATH-002 (SG-SOL-023), SIGNER-002 (SG-SOL-003) (annotation only — does not change this grade)

pub user_authority: AccountInfo<'info>,

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• SPL accounts assert `owner == token_program`, the right `mint`, and the expected authority
• Every account that authorises a privileged action is typed `Signer<'info>` (or its

priceOf() trusts one oracle call (oracle.spotPrice) for a value-deciding calculation, with no deviation check, no second source and no circuit breaker.On HyperEVM the HyperCore spot read is itself a consensus input, so treat unit/exponent mismatches and asset-alias confusion as the realistic failure mode. If that single print is wrong - manipulated, stale, or a different asset's unit - every dependent decision is wrong in the same direction.

return oracle.spotPrice(asset);

skill skills/oracle-price/SKILL.md checklist satisfied:

• A second, independent source or a max-deviation circuit breaker exists for anything that
• Units/exponents are asserted (1e8 Chainlink vs 1e18 pool decimals vs HyperCore asset

deposit() assigns `ctx.accounts.user_vault.shares = ctx.accounts.user_vault.shares + shares` from an arithmetic expression with no `checked_*`/`Saturating` wrapper. Token amounts are `u64`; in an anchor build with overflow checks on, an overflow panics the instruction (DoS of the account), and anywhere the checks are off - or the value is derived from a cast - it wraps around and produces a tiny or absurd balance.

corroborated independently by 1 other detector(s), 2 rule(s): ACCT-001 (SG-SOL-012), ACCT-002 (SG-SOL-006) (annotation only — does not change this grade)

ctx.accounts.user_vault.shares = ctx.accounts.user_vault.shares + shares;

skill skills/solana-math/SKILL.md checklist satisfied:

• Arithmetic uses `checked_add/sub/mul/div` or `Saturating`. If the workspace sets
• Intermediates are widened (`u128`) and narrowed only at the end, after bounds checks.

withdraw() assigns `user_vault.shares = user_vault.shares - amount` from an arithmetic expression with no `checked_*`/`Saturating` wrapper. Token amounts are `u64`; in an anchor build with overflow checks on, an overflow panics the instruction (DoS of the account), and anywhere the checks are off - or the value is derived from a cast - it wraps around and produces a tiny or absurd balance.

corroborated independently by 2 other detector(s), 2 rule(s): AUTH-003 (SG-SOL-021), SIGNER-002 (SG-SOL-003) (annotation only — does not change this grade)

user_vault.shares = user_vault.shares - amount;

skill skills/solana-math/SKILL.md checklist satisfied:

• Arithmetic uses `checked_add/sub/mul/div` or `Saturating`. If the workspace sets
• Intermediates are widened (`u128`) and narrowed only at the end, after bounds checks.

claimTreasuryGrant() calls `ecrecover` directly. Secp256k1 signatures are malleable: (v, r, s) and (v', r, n-s) both recover the same address. Without a high-s rejection, and without restricting v to {27,28}, the same authorisation appears as two different hashes, which breaks any de-duplication or replay map keyed on the payload.

corroborated independently by 2 other detector(s), 3 rule(s): CEI-001 (SG-EVM-003), EC-001 (SG-EVM-010), EC-003 (SG-EVM-024) (annotation only — does not change this grade)

address signer = ecrecover(doc, v, r, s);

skill skills/signature-replay/SKILL.md checklist satisfied:

• Malleability is handled by a library (`ECDSA.recover`/`tryRecover`, enforced low-s,

`Withdraw` resizes an account and charges the rent delta to `vault_config`, which is not declared in this struct. Solana requires the rent payer of a resize to be a writable, funded signer; a PDA or program-owned account cannot pay it, so the resize fails (availability) or - if the slot can be filled by whoever calls - the cost lands on a third party. This is a design note rather than a proof of theft, which is why it is graded low/medium.

corroborated independently by 1 other detector(s), 1 rule(s): ACCT-003 (SG-SOL-019) (annotation only — does not change this grade)

#[account(mut, seeds = [b"vault", vault_config.key().as_ref()], bump = vault_config.bump, realloc = 8, realloc::payer = vault_config, realloc::zero = false)]

skill skills/solana-account-validation/SKILL.md checklist satisfied:

• SPL accounts assert `owner == token_program`, the right `mint`, and the expected authority

slash() casts through a narrower integer while computing token amounts. Combined with the multiply/divide ordering above, silent truncation is the second half of the precision bug: the math can be right in `u128` and wrong once cast back.

corroborated independently by 2 other detector(s), 2 rule(s): CPI-003 (SG-SOL-015), SIGNER-002 (SG-SOL-004) (annotation only — does not change this grade)

let shares = (report.amount as u64) * vault.limiter;

skill skills/solana-math/SKILL.md checklist satisfied:

• `as` casts are reviewed for truncation (`u128 as u64`, `i64 as u64`).
• Multiplication happens **before** division; division-first expressions are precision-loss

claimTreasuryGrant() forwards value with `.transfer/send()`, which forwards exactly 2300 gas. That is enough for a plain wallet but not for most smart-contract recipients, so payments to contracts (multisigs, other vaults, account-abstraction wallets) fail - and on HyperEVM the stipend assumption has changed more than once. Reported as low because it is availability, not theft.

corroborated independently by 2 other detector(s), 5 rule(s): CEI-001 (SG-EVM-003), SR-001 (SG-EVM-017), SR-002 (SG-EVM-002), SR-003 (SG-EVM-020), SR-004 (SG-EVM-023) (annotation only — does not change this grade)

payable(msg.sender).transfer(amount);

skill skills/external-calls/SKILL.md checklist satisfied:

• The 2300-gas stipend of `send`/`transfer` is acceptable for every plausible recipient