Quantum Audit Logo

Is Ark Of Panda Safe?

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

Is this your token? Publish your own audit on this page →

Ark Of Panda AOP
0xd5df…16c7
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$1.20M
Liquidity
$1.15M
Price
$0.03125
Token Age
10mo
Top 10 Holders
89.1%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control via Ownable Pattern

H-01The 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).
IssueThe 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).
FixImplement 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.
StatusUnresolved
Medium

`maxSupply` Check After `_mint` Operation

M-01In 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).
IssueIn 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).
FixMove 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.
StatusUnresolved
Low

Very Large `maxSupply` Value

L-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved
Info

Inconsistent Custom Error Usage

I-01The 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).
IssueThe 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).
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalLow7/10

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).

GovernanceMedium5/10

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).

UpgradesLow8/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

89.1% in top 10
23.7% in wallets65.5% in contracts
Effective Concentration49.8%

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.

Liquidity Depth

$1.15M across 6 pairs
Pancakeswap v3USDTanalysed$1.15M100.0%Pancakeswap v2USDT$800.0%Pancakeswap v3USDT$70.0%Pancakeswap v3WBNB$40.0%Pancakeswap v3WBNB$00.0%Pancakeswap v3USDT$00.0%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xfb13…eb7b
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.

What Raised This Score

8 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

Related Audits

6 more on the record
APRO oracle Token (AT)Medium Riskutility token (UTILITY)Medium RiskHOMER CZ (HOMER)Medium RiskBaby Doge Coin (BABYDOGE)Medium RiskBitway Token (BTW)Medium RiskMarsCoinMedium Risk

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