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
0x626e…bf18
Ethereum
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 an owner-controlled minting and burning mechanism, capped by a maximum total supply. Initial token distribution includes direct mints and vesting through dynamically created Timelock contracts. While the core ERC-20 functionality is largely sound, a significant logical flaw in the `transferFrom` function, coupled with high centralization of control and reliance on unaudited external contracts, elevates the overall risk level to High. Addressing these issues is crucial for the security and reliability of the token.

2 High1 Medium1 Low1 Informational
Volume 24h
$503.9K
Liquidity
$2.00M
Price
$0.1366
Token Age
5y
Top 10 Holders
44.0%

Security Findings

2 High1 Med1 Low1 Info
High

`transferFrom` Logic Inversion

H-01The `transferFrom` function performs the token transfer (`_transfer`) before checking and decreasing the allowance. While the `require` statement for allowance will revert the transaction if insufficient, this order deviates from the standard ERC-20 implementation where allowance is checked and reduced *before* the transfer. This inversion can lead to unexpected gas consumption for failed transactions and non-standard behavior, potentially causing integration issues with systems expecting the conventional ERC-20 flow.
IssueThe `transferFrom` function performs the token transfer (`_transfer`) before checking and decreasing the allowance. While the `require` statement for allowance will revert the transaction if insufficient, this order deviates from the standard ERC-20 implementation where allowance is checked and reduced *before* the transfer. This inversion can lead to unexpected gas consumption for failed transactions and non-standard behavior, potentially causing integration issues with systems expecting the conventional ERC-20 flow.
FixReorder the operations within `transferFrom` to first check the allowance, then perform the transfer, and finally decrease the allowance. This aligns with the ERC-20 standard and improves gas efficiency for failed transactions. The corrected logic should be: ```solidity function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) { uint256 currentAllowance = _allowances[sender][msg.sender]; require(currentAllowance >= amount, "ERC20: tr…
StatusUnresolved
High

Centralized Control by Owner

H-02The `owner` address, currently an EOA, has exclusive control over the `mint` and `burn` functions. This allows the owner to increase the total supply (up to `_maxTotalSupply`) or decrease it at will. Such centralized control introduces a single point of failure and a high degree of trust in the owner's security and integrity, which could be a significant risk if the owner's private key is compromised or misused.
IssueThe `owner` address, currently an EOA, has exclusive control over the `mint` and `burn` functions. This allows the owner to increase the total supply (up to `_maxTotalSupply`) or decrease it at will. Such centralized control introduces a single point of failure and a high degree of trust in the owner's security and integrity, which could be a significant risk if the owner's private key is compromised or misused.
FixConsider transferring ownership to a multi-signature wallet (e.g., Gnosis Safe) to distribute control and require multiple approvals for critical operations like minting and burning. This significantly reduces the risk associated with a single point of failure. Alternatively, implement a time-lock mechanism for sensitive owner actions.
StatusUnresolved
Medium

Unaudited External Contracts (TimelockFactory & TokenTimelock)

M-01The `AIOZToken` constructor deploys and interacts with `TimelockFactory` and `TokenTimelock` contracts for vesting purposes. The source code for these external contracts was not provided for review. The security and correctness of the token's vesting schedules and overall distribution heavily rely on the proper functioning and security of these unaudited contracts. Any vulnerabilities within them could impact the integrity of the token distribution.
IssueThe `AIOZToken` constructor deploys and interacts with `TimelockFactory` and `TokenTimelock` contracts for vesting purposes. The source code for these external contracts was not provided for review. The security and correctness of the token's vesting schedules and overall distribution heavily rely on the proper functioning and security of these unaudited contracts. Any vulnerabilities within them could impact the integrity of the token distribution.
FixConduct a thorough security audit of the `TimelockFactory` and `TokenTimelock` contracts to ensure they are free from vulnerabilities, correctly implement the intended vesting logic, and adhere to best security practices. If possible, use well-vetted and audited implementations (e.g., OpenZeppelin's `TokenTimelock`).
StatusUnresolved
Low

Hardcoded Addresses in Constructor

L-01Multiple recipient addresses for initial token distribution and vesting are hardcoded directly within the `AIOZToken` constructor. While this is common for initial deployments, it means that any changes to these recipient addresses or their allocated amounts would necessitate redeploying the entire contract, which is costly and disruptive.
IssueMultiple recipient addresses for initial token distribution and vesting are hardcoded directly within the `AIOZToken` constructor. While this is common for initial deployments, it means that any changes to these recipient addresses or their allocated amounts would necessitate redeploying the entire contract, which is costly and disruptive.
FixFor future deployments or similar contracts, consider using a configurable deployment script or a separate configuration contract to manage initial distribution parameters. This allows for greater flexibility without requiring contract redeployment for minor changes.
StatusUnresolved
Info

Lack of Specific Events for Owner Actions

I-01The `mint` and `burn` functions, which are critical owner-only operations affecting the total supply, only emit the generic `Transfer` event (from `address(0)` for mint, to `address(0)` for burn). While technically correct, emitting more specific events (e.g., `Minted(address account, uint256 amount)`, `Burned(address account, uint256 amount)`) would enhance off-chain monitoring, auditing, and transparency of these privileged actions.
IssueThe `mint` and `burn` functions, which are critical owner-only operations affecting the total supply, only emit the generic `Transfer` event (from `address(0)` for mint, to `address(0)` for burn). While technically correct, emitting more specific events (e.g., `Minted(address account, uint256 amount)`, `Burned(address account, uint256 amount)`) would enhance off-chain monitoring, auditing, and transparency of these privileged actions.
FixConsider adding custom events for `mint` and `burn` operations. This would provide clearer and more specific logs for off-chain services, making it easier to track and audit changes to the token supply initiated by the owner.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture (7.1) is based on a standard ERC-20 implementation, inheriting from OpenZeppelin-like patterns for `ERC20` and `Ownable`. The contract enforces a maximum total supply for minting, which is a good security practice. However, a critical logic inversion in the `transferFrom` function (7.2 Code Security) deviates from the ERC-20 standard, checking allowance after the transfer attempt, which can lead to unexpected gas costs for failed transactions. Access control (7.3) is managed via `Ownable`, granting the deployer significant power over token supply.

GovernanceHigh1/10

The economic model (7.4) includes a fixed maximum total supply, which provides predictability for token holders. Initial token distribution is handled in the constructor, utilizing both direct mints and vesting schedules via `TokenTimelock` contracts. However, the owner (7.5 Governance) retains centralized control over `mint` and `burn` functions, posing a single point of failure risk. The security of the `TokenTimelock` contracts, which are critical for vesting, could not be fully assessed as their code was not provided (7.6 External).

UpgradesHigh3/10

The AIOZToken contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard, non-upgradeable implementation. Therefore, there are no specific upgrade-related risks or considerations for this contract.

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

44.0% in top 10
44.0% in wallets0.0% in contracts
Effective Concentration44.0%

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

$2.33M across 7 pairs
Uniswap v3WETHanalysed$2.00M85.6%Pancakeswap v3WETH$306.9K13.1%Curve twoWETH$29.2K1.2%Uniswap v4ETH$2580.0%Uniswap v2WETH$50.0%Curve triUSDC$40.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
0x62e8…366a
Unlocked LP Held By
0x6c3d…c7af0xdea4…03410xc00d…6127

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

What Raised This Score

9 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (44.0% total → 44.0% effective; 44.0% in EOAs, 0.0% 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, pool = 86% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 86% of DEX liquidity)
  • 2 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
trUSDCritical RiskAethir Token (ATH)Critical RiskMain Street USD (MSUSD)Critical RiskSynapse (SYN)Critical RiskCovalent X Token (CXT)Critical RiskAutonolas (OLAS)Critical 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