Quantum Audit Logo

Is OKZOO Safe?

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

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

OKZOO AIOT
0x55ad…b4a5
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

The OkzooToken contract is a standard ERC-20 token implementation, inheriting directly from OpenZeppelin's battle-tested ERC20 contract. It features a single constructor that initializes the token's name, symbol, and mints an initial supply to a specified recipient. The contract exhibits a high degree of security due to its reliance on well-audited OpenZeppelin libraries and its minimal custom logic. No critical or high-severity vulnerabilities were identified.

1 Low2 Informational
Volume 24h
$231.7K
Liquidity
$1.14M
Price
$0.03896
Token Age
1y
Top 10 Holders
81.9%

Security Findings

Low

Lack of Administrative Control Functions

L-01The OkzooToken contract does not include any administrative control functions such as `pause`, `blacklist`, or `owner`-restricted minting/burning capabilities beyond the initial constructor mint. While this design choice minimizes centralization risk and potential attack vectors associated with privileged roles, it also means there is no mechanism to halt transfers in an emergency (e.g., a critical bug in a DeFi protocol interacting with the token) or to recover tokens sent to incorrect addresses.
IssueThe OkzooToken contract does not include any administrative control functions such as `pause`, `blacklist`, or `owner`-restricted minting/burning capabilities beyond the initial constructor mint. While this design choice minimizes centralization risk and potential attack vectors associated with privileged roles, it also means there is no mechanism to halt transfers in an emergency (e.g., a critical bug in a DeFi protocol interacting with the token) or to recover tokens sent to incorrect addresses.
FixAssess whether the absence of administrative controls aligns with the project's long-term strategy and risk tolerance. If emergency response capabilities are deemed necessary, consider implementing a separate governance or multi-sig controlled contract that can interact with the token, or deploying a token with such features from the outset. For this specific contract, no changes are recommended if the current design is intentional.
StatusUnresolved
Info

Reliance on OpenZeppelin Standard Implementation

I-01The OkzooToken contract inherits directly from OpenZeppelin's ERC20 contract, which is a widely used and thoroughly audited library. This significantly reduces the likelihood of common ERC-20 vulnerabilities such as reentrancy, integer overflows/underflows, and incorrect token accounting. The custom logic is limited to the constructor, which performs an initial mint.
IssueThe OkzooToken contract inherits directly from OpenZeppelin's ERC20 contract, which is a widely used and thoroughly audited library. This significantly reduces the likelihood of common ERC-20 vulnerabilities such as reentrancy, integer overflows/underflows, and incorrect token accounting. The custom logic is limited to the constructor, which performs an initial mint.
FixNo specific recommendation is required as this is a strength. Continue to monitor OpenZeppelin's security advisories for any potential issues in the base contracts, although this is generally handled by the OpenZeppelin team.
StatusUnresolved
Info

Fixed Token Supply After Initial Mint

I-02The total supply of OkzooToken is determined solely by the `mintAmount` parameter provided during the contract's deployment in the constructor. There are no functions available to mint additional tokens or burn tokens (beyond the internal `_burn` function which is not exposed externally) after the initial deployment. This results in a fixed supply token.
IssueThe total supply of OkzooToken is determined solely by the `mintAmount` parameter provided during the contract's deployment in the constructor. There are no functions available to mint additional tokens or burn tokens (beyond the internal `_burn` function which is not exposed externally) after the initial deployment. This results in a fixed supply token.
FixEnsure that the initial `mintAmount` is carefully chosen and verified, as it cannot be altered post-deployment. This fixed supply characteristic is generally a security strength, preventing arbitrary inflation, but it also means the token's supply cannot be adjusted to respond to future economic or protocol needs.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is straightforward, implementing a standard ERC-20 token. Code security (7.2) is robust, primarily due to the use of OpenZeppelin's ERC20 library, which incorporates best practices for integer arithmetic and common attack vectors. For instance, `unchecked` blocks are safely guarded by `require` statements to prevent underflow in functions like `_transfer` and `_burn`. Access control (7.3) is minimal, limited to standard ERC-20 permissions, which reduces the attack surface.

GovernanceMedium4/10

The economic model (7.4) is simple: a fixed supply token minted once at deployment. There are no complex DeFi primitives or external dependencies (7.6) that could introduce economic exploits or oracle manipulation risks. Governance (7.5) is not present within this contract, as there are no administrative roles or upgrade mechanisms. This design choice simplifies the contract and reduces centralization risks associated with privileged roles.

UpgradesMedium6/10

The contract is not designed to be upgradeable (7.7), meaning its logic is immutable once deployed. This eliminates upgrade-related risks such as proxy implementation bugs or administrative key compromise for upgrades. However, it also means that any discovered vulnerabilities or desired feature changes would necessitate a new contract deployment and migration.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

14.5% in wallets67.4% in contracts
Effective Concentration41.4%

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

Show 3 more pairsShow less

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 Holder27.3%
Top-3 Unlocked61.1%

Key Addresses

Deployer
0x781a…1098
Unlocked LP Held By
0x2fbe…da9a0x9571…bf640xbc7a…3e710x5c71…39c90x2799…64c30x0360…692a0x1262…3df00x1498…d27e0x5fbe…94c40x4cc4…2ee2

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (81.9% total → 41.4% effective; 14.5% in EOAs, 67.4% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 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

FrippyLow RiskGiggle Mascot (MAX)Low RiskBinance Cat (BNBCAT)Low RiskNianNianLow RiskARIA.AI (ARIA)Low RiskBuild On BNB (BOB)Low Risk

Would You Like a More Detailed Audit of OKZOO?

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

Get Detailed Audit