Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Ark Of Panda Safe?

AOPBNB Chain
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance5/10Upgrades8/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The AOPToken contract implements a standard ERC20 token with an Ownable access control pattern and a capped maximum supply.

Read the full analysis
What raised the score
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30% (89.1% total → 49.8% effective; 23.7% in EOAs, 65.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
65.5%Contracts23.7%Wallets10.9%Everyone else
65.5%Contracts23.7%Wallets10.9%
ContractsWalletsEveryone elseBubble area = share of supply
89.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking65.5%
  • Walletsanonymous holders, free to sell23.7%
  • Everyone elsethe rest of the supply10.9%
Effective concentrationwhat the score reads49.8%
How holder types affect the score

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.15M across 6 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.15MShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x59e9…35470x94d3…64d70x6458…2df5

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control via Ownable Pattern

The contract uses the Ownable pattern, granting a single external address (the owner) exclusive control over critical functions such as mint and transferOwnership. If the owner's private key is compromised, a malicious actor could mint the entire maxSupply of tokens, leading to severe economic consequences for the token holders. This represents a significant single point of failure (7.3 Access Control, 7.5 Governance).H-01

Issue

The contract uses the Ownable pattern, granting a single external address (the owner) exclusive control over critical functions such as mint and transferOwnership. If the owner's private key is compromised, a malicious actor could mint the entire maxSupply of tokens, leading to severe economic consequences for the token holders. This represents a significant single point of failure (7.3 Access Control, 7.5 Governance).

Fix

Implement a multi-signature wallet (e.g., Gnosis Safe) as the contract owner to distribute control among multiple trusted parties. This significantly reduces the risk of a single point of compromise. For less critical operations, consider implementing a time-locked governance mechanism.

Status

Unresolved

Medium

maxSupply Check After _mint Operation

In the mint function, the maxSupply check (if (totalSupply() > maxSupply)) occurs after the _mint internal function has already updated the _totalSupply and _balances state variables. While the transaction will revert if maxSupply is exceeded, this approach is less gas-efficient as it performs state changes that are then discarded. It is generally better practice to validate conditions that would cause a revert *before* modifying state (7.2 Code Security, 7.4 Economic).M-01

Issue

In the mint function, the maxSupply check (if (totalSupply() > maxSupply)) occurs after the _mint internal function has already updated the _totalSupply and _balances state variables. While the transaction will revert if maxSupply is exceeded, this approach is less gas-efficient as it performs state changes that are then discarded. It is generally better practice to validate conditions that would cause a revert *before* modifying state (7.2 Code Security, 7.4 Economic).

Fix

Move the maxSupply check to occur before the _mint call. For example, add `require(totalSupply() + amount_ <= maxSupply, 'AOPToken: mint exceeds max supply'); before _mint(to_, amount_);` to prevent unnecessary state changes and reverts.

Status

Unresolved

Low

Very Large maxSupply Value

The maxSupply is set to 2,000,000,000 ether (2 * 10^27), which is an extremely large number. While this is a design choice and not a technical vulnerability, such a high maximum supply, combined with owner-controlled minting, implies a significant potential for token inflation if the owner decides to mint a substantial portion of the supply. This could impact the token's value and market dynamics (7.4 Economic).L-01

Issue

The maxSupply is set to 2,000,000,000 ether (2 * 10^27), which is an extremely large number. While this is a design choice and not a technical vulnerability, such a high maximum supply, combined with owner-controlled minting, implies a significant potential for token inflation if the owner decides to mint a substantial portion of the supply. This could impact the token's value and market dynamics (7.4 Economic).

Fix

Ensure that the project's economic model and whitepaper clearly articulate the rationale behind such a large maxSupply and the owner's minting capabilities. Transparency regarding potential inflation scenarios is crucial for investor confidence. If possible, consider if a smaller, more controlled maxSupply would better align with the project's long-term vision.

Status

Unresolved

Info

Inconsistent Custom Error Usage

The contract defines a custom error AOPTokenError and uses it for the maxSupply check. However, other require statements throughout the contract (including inherited OpenZeppelin functions) use traditional string messages for reverts. Adopting a consistent error handling strategy, either using custom errors or string messages exclusively, can improve code readability and potentially reduce gas costs for reverts (7.2 Code Security).I-01

Issue

The contract defines a custom error AOPTokenError and uses it for the maxSupply check. However, other require statements throughout the contract (including inherited OpenZeppelin functions) use traditional string messages for reverts. Adopting a consistent error handling strategy, either using custom errors or string messages exclusively, can improve code readability and potentially reduce gas costs for reverts (7.2 Code Security).

Fix

Consider refactoring all revert conditions to use custom errors for consistency and potential gas optimization benefits (as custom errors can be cheaper than string reverts in certain scenarios). Alternatively, remove the custom error and use consistent string messages.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The AOPToken contract implements a standard ERC20 token with an Ownable access control pattern and a capped maximum supply. The contract leverages well-tested OpenZeppelin patterns for its core ERC20 functionality. Key features include owner-controlled minting up to a defined maxSupply. The primary risks identified relate to the centralized control inherent in the Ownable pattern and a minor inefficiency in the mint function's supply check.

Technical7/10Low risk

The AOPToken contract is built upon robust OpenZeppelin ERC20 and Ownable implementations, ensuring a solid foundation for its core functionality (7.1 Architecture, 7.2 Code Security). The use of Solidity 0.8.0+ provides default overflow/underflow protection, and unchecked blocks are appropriately used where safety is guaranteed by preceding require statements. A minor technical inefficiency exists where the maxSupply check occurs after the _mint operation, leading to a revert if exceeded, rather than preventing the state change upfront (7.2 Code Security).

Governance5/10Medium risk

The contract employs an Ownable pattern, granting the deployer (owner) significant control, including the ability to mint tokens up to a maxSupply (7.3 Access Control, 7.5 Governance). This centralization introduces a single point of failure; compromise of the owner's private key could lead to unauthorized token minting and potential economic instability. The maxSupply is set to a very large value (2 billion ether), which, while capped, represents a substantial potential for inflation if the owner chooses to mint extensively (7.4 Economic).

Upgrades8/10Low risk

The AOPToken contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard, non-upgradeable implementation. Therefore, there are no specific upgrade safety issues to address. Any future changes to the token's logic would require deploying a new contract and migrating assets, which is a common approach for non-proxy contracts.

Final RecommendationWhat to do about this score

It is recommended to implement multi-signature control for critical administrative functions, especially for the mint function and transferOwnership, to mitigate the single point of failure risk associated with the Ownable pattern.

Additionally, consider refining the mint function to perform the maxSupply check prior to executing state changes for improved gas efficiency and clarity. Ensure the project's documentation clearly communicates the implications of the large maxSupply and the owner's minting capabilities.

Contract & Record

1 audit on record
TypeAOPToken
NetworkBNB Chain
Token age10mo
Contract0xd5df…16c7
Deployer0xfb13…eb7b
Badge for your website
Ark Of Panda security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202640Medium
  2. Aug 13, 202654Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
APRO oracle TokenAT · BNB Chain40Mediumutility tokenUTILITY · BNB Chain40MediumHOMER CZHOMER · BNB Chain40MediumBUDDY - First Crypto DogBUDDY · BNB Chain40MediumBaby Doge CoinBABYDOGE · BNB Chain41MediumBitway TokenBTW · BNB Chain39Medium

Would You Like a More Detailed Audit of Ark Of Panda?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page