Quantum Audit Logo

Is AIOZ Network Safe?

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

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

AIOZ Network AIOZ
0x33d0…741d
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The AIOZToken contract implements a standard ERC-20 token with owner-controlled minting and burning capabilities, and a fixed maximum total supply. Initial token distribution includes vesting via a TimelockFactory. A critical vulnerability was identified in the custom ERC20 implementation's `transferFrom` function, which can lead to tokens being transferred without sufficient allowance. Additionally, significant centralization risks exist due to owner-controlled supply management and an EOA owner.

1 Critical1 High2 Medium1 Low
Volume 24h
$1.96M
Liquidity
$1.67M
Price
$0.1365
Token Age
2y
Top 10 Holders
64.0%

Security Findings

1 Crit1 High2 Med1 Low
Critical

Incorrect `transferFrom` Logic in Custom ERC20 Implementation

C-01The `transferFrom` function in the custom `ERC20` contract first executes the `_transfer` of tokens and then performs the allowance check (`require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance")`) and allowance reduction. If `_transfer` succeeds but the subsequent allowance check fails, the transaction will revert, but the tokens will have already been moved. This breaks the fundamental ERC20 invariant that `transferFrom` should only succeed if the allowance is sufficient *before* the transfer, leading to an inconsistent state where tokens are transferred without proper authorization and the allowance state is not correctly updated.
IssueThe `transferFrom` function in the custom `ERC20` contract first executes the `_transfer` of tokens and then performs the allowance check (`require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance")`) and allowance reduction. If `_transfer` succeeds but the subsequent allowance check fails, the transaction will revert, but the tokens will have already been moved. This breaks the fundamental ERC20 invariant that `transferFrom` should only succeed if the allowance is sufficient *before* the transfer, leading to an inconsistent state where tokens are transferred without proper authorization and the allowance state is not correctly updated.
FixThe allowance check and reduction must occur *before* the `_transfer` call within the `transferFrom` function. The correct order of operations should be: 1) Check allowance, 2) Reduce allowance, 3) Perform transfer. This issue requires a contract redeployment.
StatusUnresolved
High

Centralized Control of Token Supply

H-01The `mint` and `burn` functions are protected by the `onlyOwner` modifier, granting a single address (the contract owner) exclusive control over increasing or decreasing the total supply of AIOZ tokens. This centralization introduces a significant risk, as a compromised owner key or malicious owner could manipulate the token supply, leading to severe economic consequences for token holders, such as inflation or deflation.
IssueThe `mint` and `burn` functions are protected by the `onlyOwner` modifier, granting a single address (the contract owner) exclusive control over increasing or decreasing the total supply of AIOZ tokens. This centralization introduces a significant risk, as a compromised owner key or malicious owner could manipulate the token supply, leading to severe economic consequences for token holders, such as inflation or deflation.
FixConsider implementing a more decentralized approach for supply management. This could involve a time-locked multi-signature wallet for minting/burning operations, or a community governance mechanism. If centralization is intended, ensure the owner's private key is secured with the highest possible standards.
StatusUnresolved
Medium

Owner is an Externally Owned Account (EOA)

M-01The contract owner, which controls critical functions like `mint`, `burn`, and `transferOwnership`, is an Externally Owned Account (EOA). EOAs are single points of failure; if the private key associated with this EOA is compromised, an attacker would gain full control over the token's supply management, posing a significant security risk.
IssueThe contract owner, which controls critical functions like `mint`, `burn`, and `transferOwnership`, is an Externally Owned Account (EOA). EOAs are single points of failure; if the private key associated with this EOA is compromised, an attacker would gain full control over the token's supply management, posing a significant security risk.
FixIt is highly recommended to transfer ownership to a multi-signature wallet (e.g., Gnosis Safe) to distribute control and reduce the risk associated with a single point of failure. This adds an extra layer of security by requiring multiple approvals for sensitive operations.
StatusUnresolved
Medium

Reliance on Custom ERC20 Implementation

M-02The `ERC20` contract is a custom implementation rather than importing a battle-tested and audited library like OpenZeppelin Contracts. While the code largely mirrors standard ERC20 functionality, custom implementations are more susceptible to subtle bugs or deviations from the standard that may not be immediately apparent, as demonstrated by the critical `transferFrom` issue.
IssueThe `ERC20` contract is a custom implementation rather than importing a battle-tested and audited library like OpenZeppelin Contracts. While the code largely mirrors standard ERC20 functionality, custom implementations are more susceptible to subtle bugs or deviations from the standard that may not be immediately apparent, as demonstrated by the critical `transferFrom` issue.
FixFor future token deployments, strongly consider using well-established and audited ERC20 implementations from reputable libraries (e.g., OpenZeppelin). These libraries undergo extensive security audits and community review, significantly reducing the risk of fundamental vulnerabilities.
StatusUnresolved
Low

Unused `TimelockFactory` Instance in Constructor

L-01In the `AIOZToken` constructor, a `TimelockFactory` instance is created (`TimelockFactory timelockFactory = new TimelockFactory();`) and used to create initial timelock contracts. However, the `timelockFactory` variable is local to the constructor and its address is not stored in a state variable. This means the `AIOZToken` contract itself cannot interact with or manage the deployed `TimelockFactory` after its construction, limiting potential future operational flexibility if dynamic timelock creation by the token contract was ever envisioned.
IssueIn the `AIOZToken` constructor, a `TimelockFactory` instance is created (`TimelockFactory timelockFactory = new TimelockFactory();`) and used to create initial timelock contracts. However, the `timelockFactory` variable is local to the constructor and its address is not stored in a state variable. This means the `AIOZToken` contract itself cannot interact with or manage the deployed `TimelockFactory` after its construction, limiting potential future operational flexibility if dynamic timelock creation by the token contract was ever envisioned.
FixIf there is no intention for the `AIOZToken` contract to interact with the `TimelockFactory` post-deployment, this is an informational observation. If future dynamic creation of timelocks by the token contract is a possibility, consider storing the `TimelockFactory` address in a state variable for later use.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The technical architecture is a custom ERC-20 token with `Ownable` access control and a hard-capped total supply (7.1 Architecture). The contract uses Solidity 0.8.0+, mitigating common integer overflow/underflow issues. However, a critical bug was found in the `transferFrom` function where allowance checks occur after the token transfer, potentially allowing transfers without proper authorization (7.2 Code Security). The custom ERC20 implementation, rather than using audited libraries, increases the risk of such subtle bugs.

GovernanceHigh1/10

The token's economic model includes a fixed maximum total supply, which is a positive aspect for predictability (7.4 Economic). However, the `mint` and `burn` functions are `onlyOwner`, granting a single entity complete control over the token supply (7.3 Access Control). This centralization, coupled with the owner being an EOA, poses a significant risk of manipulation or compromise (7.5 Governance, 7.8 Operations). Initial token distribution utilizes a `TimelockFactory` for vesting, which is a standard practice.

UpgradesHigh2/10

The AIOZToken contract is not designed as an upgradeable proxy (7.7 Upgrades). This means that once deployed, its logic cannot be modified. While this eliminates upgrade-specific risks, it also means that any discovered vulnerabilities or desired feature enhancements would require deploying a new token contract and migrating the entire token supply, which is a complex and costly operation.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

64.0% in top 10
25.6% in wallets38.5% in contracts
Effective Concentration40.9%

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.69M across 11 pairs
Pancakeswap v3WBNBanalysed$1.67M99.2%Pancakeswap v1WBNB$13.1K0.8%Pancakeswap v2WBNB$6790.0%Pancakeswap v3USDT$2770.0%0x6fB6…cbE5USDT$490.0%0x1a05…23b6WBNB$80.0%
Show 4 more pairsShow less
Pancakeswap v2Cake$60.0%UniswapBNBTiger$30.0%SushiswapWBNB$00.0%Pancakeswap v1Cake$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 Holder99.8%
Top-3 Unlocked99.9%

Key Addresses

8 addresses
Deployer
0xb7c8…5b9d
Unlocked LP Held By
0x0a51…5e6d0x556b…d59e0xfcbc…139e0x9bf3…60de0xef5e…3cb00xa148…741f0xba9b…dc72

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

What Raised This Score

10 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (64.0% total → 40.9% effective; 25.6% in EOAs, 38.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.8% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 99.9% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 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
United Stables (U)Critical RiskCATCritical RiskVortexPad (VPAD)Critical RiskNVIDIA Corp (NVDAB)Critical RiskGiggle Tom (TOM)Critical RiskDexeCritical Risk

Would You Like a More Detailed Audit of AIOZ Network?

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

Get Detailed Audit