Quantum Audit Logo

Is AITECH Cloud Network Safe?

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

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

AITECH Cloud Network ACN
0x3e76…b2a4
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? → Medium Risk
Executive SummaryAI Copilot

The ACNToken contract is an ERC20Burnable token that implements EIP-3009 for gasless meta-transactions. The contract leverages well-audited OpenZeppelin libraries for its core ERC20 functionality and EIP-712 signature handling. The overall code quality is high, and no critical or high-severity technical vulnerabilities were identified. Informational findings relate to initial token distribution and the inherent complexity of EIP-3009, while a low-severity finding addresses a potential race condition in authorization cancellation.

1 Low2 Informational
Volume 24h
$90.8K
Liquidity
$528.5K
Price
$0.004433
Token Age
5mo
Top 10 Holders
75.6%

Security Findings

1 Low2 Info
Low

Race Condition in `cancelAuthorization`

L-01A race condition exists where a `cancelAuthorization` transaction could be front-run by a `transferWithAuthorization` or `receiveWithAuthorization` transaction using the same nonce. If the transfer/receive transaction executes first, the authorization will be marked as used, and the subsequent cancellation will fail. While the authorization cannot be replayed, users attempting to cancel an authorization might find it already executed if a malicious actor or a legitimate recipient front-runs their cancellation (7.2 Code Security).
IssueA race condition exists where a `cancelAuthorization` transaction could be front-run by a `transferWithAuthorization` or `receiveWithAuthorization` transaction using the same nonce. If the transfer/receive transaction executes first, the authorization will be marked as used, and the subsequent cancellation will fail. While the authorization cannot be replayed, users attempting to cancel an authorization might find it already executed if a malicious actor or a legitimate recipient front-runs their cancellation (7.2 Code Security).
FixUsers should be made aware of this potential race condition. Off-chain systems should prioritize the submission of `cancelAuthorization` transactions or provide clear warnings to users about the possibility of front-running. Consider if a mechanism to revoke all outstanding authorizations by the authorizer is feasible, though this adds complexity.
StatusUnresolved
Info

Centralized Initial Token Distribution

I-01The entire `TOTAL_SUPPLY` of 2,000,000,000 ACN tokens is minted to the `msg.sender` (the deployer address) during contract construction. This design choice centralizes the initial token supply, giving the deployer complete control over the initial distribution. While common for new tokens, it's a significant point for transparency regarding initial ownership and potential market impact (7.4 Economic).
IssueThe entire `TOTAL_SUPPLY` of 2,000,000,000 ACN tokens is minted to the `msg.sender` (the deployer address) during contract construction. This design choice centralizes the initial token supply, giving the deployer complete control over the initial distribution. While common for new tokens, it's a significant point for transparency regarding initial ownership and potential market impact (7.4 Economic).
FixEnsure the community is fully aware of this distribution model. If a more decentralized distribution is desired, consider implementing a vesting schedule, airdrop, or public sale mechanism post-deployment.
StatusUnresolved
Info

EIP-3009 Complexity and Off-Chain Reliance

I-02The implementation of EIP-3009 for meta-transactions (`transferWithAuthorization`, `receiveWithAuthorization`, `cancelAuthorization`) adds significant complexity to the token's functionality. While correctly implemented using OpenZeppelin standards, it requires robust off-chain infrastructure for signature generation, nonce management, and relaying transactions. Any flaws in the off-chain components could lead to user experience issues or potential misuse, though not directly a smart contract vulnerability (7.6 External).
IssueThe implementation of EIP-3009 for meta-transactions (`transferWithAuthorization`, `receiveWithAuthorization`, `cancelAuthorization`) adds significant complexity to the token's functionality. While correctly implemented using OpenZeppelin standards, it requires robust off-chain infrastructure for signature generation, nonce management, and relaying transactions. Any flaws in the off-chain components could lead to user experience issues or potential misuse, though not directly a smart contract vulnerability (7.6 External).
FixThoroughly test and secure all off-chain components responsible for generating, managing, and relaying EIP-3009 authorizations. Provide clear documentation and SDKs for users and integrators to ensure correct and secure usage.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) of the ACNToken contract is robust, built upon battle-tested OpenZeppelin ERC20, ERC20Burnable, and EIP712 components. Code security (7.2) is enhanced by using Solidity 0.8.28, which includes built-in overflow/underflow checks, and the `SignatureChecker` utility for secure signature validation. Access control (7.3) for EIP-3009 functions relies on cryptographically secure EIP-712 signatures, ensuring only authorized parties can initiate transfers or cancellations. No reentrancy or other common technical vulnerabilities were found.

GovernanceHigh1/10

The economic model (7.4) of ACNToken is straightforward: a fixed total supply of 2 billion tokens is minted entirely to the deployer address upon contract creation. This design choice centralizes initial token ownership, which is a common pattern but should be transparently communicated. There are no explicit governance mechanisms (7.5) within the contract, meaning no on-chain voting or administrative roles beyond the initial token distribution. The token is standard ERC20, allowing for basic transfer and burn operations.

UpgradesMedium6/10

The ACNToken contract is not designed to be upgradeable (7.7), as it does not implement any proxy patterns. This eliminates the risks associated with upgradeability, such as proxy misconfigurations or logic errors during upgrades. Any changes to the contract's functionality would require deploying a new contract and migrating assets, which is a standard approach for non-upgradeable tokens.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

75.6% in top 10
34.9% in wallets40.7% in contracts
Effective Concentration51.2%

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

$528.5K

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

2 addresses
Deployer
0x0a9b…ef78
Unlocked LP Held By
0x9dc4…5cd6

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

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 50% (75.6% total → 51.2% effective; 34.9% in EOAs, 40.7% in contracts — heavy)
  • 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 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
Artificial Superintelligence Alliance (FET)Medium RiskOndoMedium RiskRequest Token (REQ)Medium RiskIdentity.md (IMD)Medium RiskHighstreet token (HIGH)Medium RiskOutBurnMedium Risk

Would You Like a More Detailed Audit of AITECH Cloud Network?

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

Get Detailed Audit