Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Octopus Info

octoai.app

9 brains. 3 hearts. One system. OctopusAI was born from a strange pattern. When AI systems were asked to choose their favourite animal, one answer kept returning: the octopus. A symbol of intelligence, adaptability, memory, and evolution. That idea became OctopusAI — an AI ecosystem built for the crypto trenches. OctopusAI reads charts, scans tokens, tracks wallets, generates memes, remembers conversations, and powers intelligent mining infrastructure designed to fuel the network as it evolves. Built to learn. Built to adapt. Built for the future of crypto AI.

Octopus Logo
Onboarded date 21/05/2026

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

74.76
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

Select the audit
"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
C9wBYD...x8BE
Network
Solana - Mainnet
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2026/05/29
Revision date 2026/06/04

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner cannot blacklist addresses.

It is not possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Contract cannot be locked

Owner cannot lock any user funds.

Token cannot be burned

There is no burning within the contract without any allowances

Ownership is renounced

The contract does not include owner functions that allow post-deployment modifications.

Contract is not upgradeable

The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Smart Contract Audit Statement

Audit Scope

This statement covers the third-cycle security re-audit of the OctopusAI Mining Solana staking program, reviewing audit_package_v5 against the prior re-audit. Users deposit $OCTOPUS and earn a stated 19% APY from a pre-loaded reward pool; entries and exits carry a 0.3% fee split 40% burn / 40% revenue-share / 20% treasury; and a 24-hour lock applies between requesting and claiming an unstake.

Note - This audit consists of a security analysis of the OctopusAI Mining Solana program source. This analysis did not include economic analysis of the project's tokenomics, and only the main program was audited. On-chain bytecode was not independently fetched or verified. We recommend investors do their own research before investing.

Files and details

Findings and Audit result

Critical
High
Medium
3
Low
2
Optimization
9
Informational
high Issues | 2 findings

Resolved

#1 high Issue
Re-stake reward inflation: last_claim_at not reset when stake is added to an active position
lib.rs
Lstart_mining state-update block
Description

A larger staked_amount could previously harvest APY over a pre-existing window because last_claim_at was pinned at first-stake time.

Comments

mine.last_claim_at = now is set unconditionally on every deposit, so a larger staked_amount can no longer harvest APY over a pre-existing window.

Resolved

#2 high Issue
distribute does not advance last_claim_at, enabling a double payment via claim_rewards
lib.rs
Ldistribute (removed)
Description

claim_rewards previously re-paid a window that distribute had already covered.

Comments

Resolved structurally: the distribute instruction (handler, RewardsDistributed event, and Distribute accounts struct) has been removed from the program entirely, so the oracle-distribute-then-user-claim double-payment path no longer exists. claim_rewards is now the only reward-payout path and resets last_claim_at = now after each payout.

medium Issues | 2 findings

Resolved

#1 medium Issue
USDC deposit path is structurally unreachable
lib.rs, consts.rs, errors.rs
Lmultiple
Description

The previously advertised USDC path could never succeed against the octopus-only vault.

Comments

USDC has been removed end-to-end and the program is now single-asset, accepting only $OCTOPUS.

Resolved

#2 medium Issue
Centralized authority with no pause, timelock, or two-step transfer
lib.rs, consts.rs, state.rs
Lprogram-wide (consts.rs ORACLE; state.rs RewardPool)
Description

A single hardcoded ORACLE controls every privileged instruction with no emergency pause, no timelock, and no two-step transfer. With distribute removed and the program reportedly renounced, the prior reward-pool drain vector is closed; user-deposit principal remains protected by the staking vault's PDA authority.

Comments

Blast radius substantially reduced: distribute was removed, so the oracle no longer has any instruction that can move tokens out of the reward vault or the staking vault. Client also states the program upgrade authority has been renounced (immutable). NOTE: renouncement is an on-chain property and could not be verified from the delivered source; it must be confirmed against the deployed program. Residual: a single hardcoded ORACLE still gates the one-shot initialize_* instructions and inject_rewards (which only adds funds), with no pause flag, timelock, or two-step transfer; the worst-case oracle action is now funding the pool rather than draining it.

low Issues | 9 findings

Resolved

#1 low Issue
APY math final as u64 cast is unchecked
lib.rs
Lcalculate_pending_reward final downcast
Description

claim_rewards computed reward in u128 and then downcast with a plain `as u64`, which could silently truncate. The checked conversion now fails on any value exceeding u64::MAX.

Comments

The trailing `... as u64` has been replaced with `u64::try_from(reward_u128).map_err(|_| ErrorCode::MathOverflow)?` inside the shared calculate_pending_reward helper, which fails closed instead of silently truncating.

Acknowledged

#2 low Issue
Missing overflow-checks = true in [profile.release]
Cargo.toml
L1-22
Description

Release builds default to overflow-checks = false.

Comments

UNVERIFIED. The client states overflow-checks = true was added to a workspace [profile.release], but the only Cargo.toml in the delivered package (the program crate) contains no [profile.release] block, no overflow-checks key, and no [workspace] table. Cannot confirm the fix from the provided source. Provide the workspace-root Cargo.toml that carries [profile.release] overflow-checks = true to close this item.

Resolved

#3 low Issue
mine_account is not closed after full unstake; rent is permanently locked
lib.rs
LClaimUnstake context
Description

After claim_unstake the MineAccount previously remained on-chain with staked_amount = 0, leaving roughly 0.00134 SOL of rent locked per user.

Comments

close = user has been added to the mine_account constraint in ClaimUnstake, so rent lamports are returned to the user and the account is zeroed and closed through Anchor's safe close path. A later stake cleanly re-creates a fresh position via init_if_needed (the staked_amount == 0 branch resets owner and bump).

Acknowledged

#4 low Issue
Canonical bumps for vault PDAs are not stored
lib.rs
Lmultiple Accounts structs
Description

Anchor recomputes the canonical bump on every call, which is correct but wastes compute.

Comments

Acknowledged (will not fix): client considers this a compute optimization, not a security issue. The vault, vault_authority, reward_pool_vault and reward_authority accounts still use the bare bump constraint, so Anchor recomputes the canonical bump on every call, which is correct but wastes compute.

Resolved

#5 low Issue
Missing token::mint constraints on user / fee-wallet token accounts
lib.rs
Lmultiple Accounts structs
Description

Several token accounts previously lacked an explicit token::mint = octopus_mint constraint.

Comments

All externally-supplied token accounts are now mint-checked: StartMining.user_token_account carries token::mint = octopus_mint plus a runtime require!, and runtime require!(account.mint == OCTOPUS_MINT) was added for claim_unstake.user_token_account, inject_rewards.oracle_token_account, and claim_rewards.user_token_account. validate_fee_wallets() also checks the burn/revshare/treasury wallet mints. The program-owned vault and reward_pool_vault PDAs are created with token::mint = octopus_mint at init, and the removed Distribute struct no longer applies.

Acknowledged

#6 low Issue
Transitive RUSTSEC advisories via the Solana 1.18.26 SDK
Cargo.lock
Ln/a
Description

2 vulnerabilities (curve25519-dalek RUSTSEC-2024-0344, ed25519-dalek RUSTSEC-2022-0093) and 8 unmaintained/unsound warnings (atty x2, bincode, derivative, libsecp256k1, paste, borsh 0.9.3, rand 0.7.3).

Comments

Acknowledged (will not fix): all advisories are transitive through solana-sdk 1.18.26 and none are reachable in the on-chain BPF program. Cargo.lock is unchanged, so a fresh cargo audit still reports 2 vulnerabilities and 8 warnings. Track the SDK upgrade path and re-run cargo audit before each release.

Resolved

#7 low Issue
Reward solvency keyed to RewardPool.balance bookkeeping field instead of live vault balance
lib.rs
Lclaim_rewards solvency check
Description

This is not exploitable for theft, since the SPL transfer still caps every payout at the real balance, but tokens sent to the reward vault outside inject_rewards previously became unwithdrawable, and pool.balance was the sole security boundary and could desync from the live vault balance.

Comments

claim_rewards now gates on the live SPL balance via let vault_balance = ctx.accounts.reward_pool_vault.amount; require!(reward <= vault_balance, InsufficientRewardPool), which is self-correcting and also accounts for direct transfers into the vault. The distribute path that previously gated on pool.balance has been removed. (See STK-031-class note: the RewardPool.balance field is now incremented on inject but never decremented; this is bookkeeping only and not the security boundary.)

Resolved

#8 low Issue
Re-stake silently forfeits unclaimed accrued rewards
lib.rs
Lstart_mining (rewards_forfeited)
Description

start_mining resets last_claim_at = now on re-stake, so re-staking an active position without first claiming discards all accrued rewards. v5 surfaces the discarded amount in an event field instead of preventing the loss.

Comments

Addressed by transparency rather than prevention: the v4 PendingRewardsExist reject guard was removed, and start_mining now computes the pending reward at the old staked_amount and emits it as the rewards_forfeited field of the MiningStarted event before resetting last_claim_at = now. IMPORTANT: the accrued rewards are still forfeited on re-stake (and on claim_unstake, which closes the account without paying rewards) - the forfeiture is no longer silent but is not eliminated on-chain. Loss-free compounding depends on the frontend calling claim_rewards before start_mining. A settle-by-capitalisation approach (folding the pending reward into staked_amount) would remove the forfeiture entirely.

Resolved

#9 low Issue
Re-stake liveness coupling: cannot add to a position while the reward pool cannot cover pending rewards
lib.rs
Lstart_mining (guard removed)
Description

An interaction between the v4 re-stake guard and the InsufficientRewardPool gate degraded the availability of the add-to-position flow under reward-pool underfunding. Removing the guard eliminates the coupling.

Comments

Resolved: the PendingRewardsExist guard introduced in v4 has been removed, so a re-stake no longer requires a prior claim_rewards and never depends on reward-pool liquidity. Re-stake always succeeds (subject to the unstake-pending check). The trade-off is that pending rewards are now forfeited on re-stake rather than blocked - tracked under STK-024.

optimization Issues | 4 findings

Resolved

#1 optimization Issue
ClaimUnstake account fields are not boxed
lib.rs
LClaimUnstake context
Description

ClaimUnstake previously kept plain Account fields.

Comments

All TokenAccount fields in ClaimUnstake (and every other context) are boxed as Box<Account<'info, TokenAccount>>.

Acknowledged

#2 optimization Issue
Sequential token transfers in fee-split paths
lib.rs
Lstart_mining
Lclaim_unstake
Description

The fee split requires multiple CPIs.

Comments

Acknowledged (will not fix): each fee-split path issues up to four token::transfer CPIs, which is unavoidable with the legacy SPL Token program and is acceptable within the compute ceiling.

Acknowledged

#3 optimization Issue
Doc-markdown lint on mine_account reference
lib.rs
LDistribute mine_owner doc comment (struct removed)
Description

clippy::doc_markdown fires on an unbackticked identifier.

Comments

Acknowledged (will not fix): cosmetic clippy::pedantic lint only; the default clippy run is clean. The Distribute struct that carried the unbackticked doc comment has since been removed, so the original trigger no longer exists.

Resolved

#4 optimization Issue
mine_account uses bare Account instead of Box; stack-overflow framing is inaccurate
lib.rs, AUDIT_UPDATE.md
LStartMining.mine_account
Description

Boxing was inconsistent on the most account-heavy context.

Comments

Resolved: StartMining.mine_account is now Box<Account<'info, MineAccount>>, consistent with the other account-heavy contexts and providing stack headroom.

informational Issues | 12 findings

Resolved

#1 informational Issue
TREASURY_PCT is declared but never used
consts.rs
Ln/a (removed)
Description

TREASURY_PCT = 20 was previously unused.

Comments

TREASURY_PCT has been removed and the treasury share is derived by subtraction in split_fee().

Acknowledged

#2 informational Issue
SECONDS_PER_YEAR uses 365 days instead of 365.25
consts.rs
LSECONDS_PER_YEAR
Description

The denominator is 365 days.

Comments

Acknowledged (will not fix): the denominator 31_536_000 (365 days) yields an effective APY of about 19.013%, which the client accepts and documents.

Resolved

#3 informational Issue
STABLE_FEE_BPS marketed as 0.345% but is 0.35%
consts.rs
Ln/a (removed)
Description

STABLE_FEE_BPS = 35 (0.35%) was previously commented as 0.345%.

Comments

Moot now that the USDC path and its STABLE_FEE_BPS constant have been removed.

Acknowledged

#4 informational Issue
Interactions-then-Effects ordering in token-moving instructions
lib.rs
Lstart_mining
Lclaim_unstake
Lclaim_rewards
Description

CPIs precede state writes.

Comments

Acknowledged (will not fix): CPIs still precede state mutation. This is safe under the legacy SPL Token program (no transfer hooks, no synchronous reentrancy) and should be revisited only under any Token-2022 migration.

Acknowledged

#5 informational Issue
Magic number 100 used as percent denominator
lib.rs
Lsplit_fee()
Description

The literal 100 remains in two divisions inside split_fee.

Comments

Acknowledged (will not fix): client considers the literal 100 readable as-is in split_fee().

Acknowledged

#6 informational Issue
init_if_needed Anchor feature is enabled
Cargo.toml, lib.rs
Linit-if-needed feature; StartMining.mine_account
Description

init_if_needed is used on mine_account.

Comments

Acknowledged (will not fix): use of init_if_needed on the user-seeded, discriminator-checked mine PDA is safe. v5 adds an explanatory doc comment above StartMining describing why it is safe and how a closed position is cleanly re-initialised on a later stake.

Acknowledged

#7 informational Issue
OCTOPUS_MINT is currently the devnet test mint
consts.rs
LOCTOPUS_MINT
Description

The constant previously decoded to the devnet test mint; in v5 it is the mainnet mint while the oracle and fee wallets remain devnet keys.

Comments

Acknowledged: OCTOPUS_MINT has been updated to the mainnet $OCTOPUS mint (oCToFrqzfrsXQ2qEG3FF4wjR2pCm3HKC8ra81XYWyoz). Remaining launch-config items: the hardcoded ORACLE and the three fee wallets are still devnet keys, and the source declare_id! is C9wBYDyEvPCpXm96tRNJhLtveqA7jcetb8JYU7ZCx8BE. Reconcile all network targets (mint, oracle, fee wallets, program id) before mainnet and verify source against the on-chain binary.

Acknowledged

#8 informational Issue
Missing doc comments on public instruction handlers and account structs
lib.rs
Lmultiple
Description

There are no /// docs on most public items.

Comments

Acknowledged (will not fix): client considers this cosmetic. The code uses banner comments plus a doc comment on StartMining; full /// docs with # Errors sections are not added.

Acknowledged

#9 informational Issue
RewardPool.authority is stored but redundant with the hardcoded ORACLE constraint
lib.rs
Linitialize_pool
LInjectRewards
Description

The oracle gate on inject_rewards is indirect, relying on the value written at pool init.

Comments

Acknowledged (will not fix): client treats the stored authority as a deliberate design choice. inject_rewards is gated by constraint = reward_pool.authority == oracle.key(), set to ORACLE at pool init (the Distribute struct that shared this pattern was removed).

Acknowledged

#10 informational Issue
Rewards keep accruing while an unstake is pending; no cancel-unstake path
lib.rs
Lrequest_unstake
Lclaim_rewards
Lclaim_unstake
Description

There is no drain beyond normal APY emission, but the lifecycle is undocumented and start_mining is blocked while a request is pending.

Comments

Acknowledged (will not fix): client states this is by design. request_unstake leaves is_active = true and does not touch last_claim_at, so claim_rewards keeps paying full APY until claim_unstake, and there is no cancel path.

Resolved

#11 informational Issue
distribute payout amount is decoupled from the time-weighted accrual it now resets
lib.rs
Ldistribute (removed)
Description

The two reward mechanisms (discretionary distribute and formulaic claim_rewards) shared a marker without a shared formula; distribute has since been removed.

Comments

Resolved: the distribute instruction has been removed entirely, so there is no longer a discretionary oracle payout that resets accrual independently of the claim_rewards time-weighted formula.

Acknowledged

#12 informational Issue
Delivered package ships stale audit artifacts and an AUDIT_UPDATE.md that omits all v4 changes
AUDIT_UPDATE.md, audit_output/
Ln/a (package metadata)
Description

Traceability/process issue: the change log and committed audit artifacts do not reflect the v5 source. Not a program vulnerability, but it can mislead reviewers about what is actually deployed.

Comments

Acknowledged (noted): the delivered v5 package still ships the prior cycle's artifacts. audit_output/ is a verbatim copy of the v4 deliverables (the report is titled Re-Audit (v4), cites the old program ID, and the raw logs reference the audit_package_v4 path and old line numbers), and AUDIT_UPDATE.md still documents the removed distribute instruction (Fix 2). Regenerate AUDIT_UPDATE.md and all audit artifacts from the v5 source on every revision and verify the recorded .so hash matches a clean rebuild.