The Aria token contract is a standard ERC20 implementation leveraging OpenZeppelin libraries. The initial token supply is fully minted to the deployer. The airdrop function, while present, is effectively disabled due to the reported renunciation of ownership, limiting future administrative actions.

On-chain security analysis — is it a scam or legit?
Is ARIA.AI Safe?
Not verified
This 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 →The Aria token contract is a standard ERC20 implementation leveraging OpenZeppelin libraries.
Read the full analysis- Top-10 concentration > 70%
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- 1 Low finding(s) from audit
Exact factors
- Top-10 concentration > 70% (86.1% total → 79.6% effective; 75.3% in EOAs, 10.8% in contracts — extreme)
- 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking10.8%
- Walletsanonymous holders, free to sell75.3%
- Everyone elsethe rest of the supply13.9%
How holder types affect the score
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.
Holder balances as recorded by the audit of Sep 4, 2026
Liquidity
as of audit · Sep 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xaaf2…a6010xbc7a…3e710x8a4a…0bf40x26b3…c34c0x4157…63e40x1a13…9ac2No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
LowCentralized Initial Token Distribution
The contract's constructor mints the entire _tTotal supply of 1,000,000,000 ARIA tokens (1 billion) to the contract deployer (msg.sender). This results in a highly centralized initial token distribution, where a single address holds 100% of the total supply (7.4 Economic, 7.5 Governance).L-01
Issue
The contract's constructor mints the entire _tTotal supply of 1,000,000,000 ARIA tokens (1 billion) to the contract deployer (msg.sender). This results in a highly centralized initial token distribution, where a single address holds 100% of the total supply (7.4 Economic, 7.5 Governance).
Fix
While this is a common design choice for new tokens, it implies significant control by the initial owner over the token's early distribution. Projects should clearly communicate this distribution model to their community to manage expectations regarding decentralization.
Status
Unresolved
InfoUnusable airdrop Function After Ownership Renunciation
The airdrop function is protected by the onlyOwner modifier. The provided prefill data indicates that ownership of the contract has been renounced (transferred to address(0)). When ownership is renounced, the owner() function returns address(0), making the onlyOwner modifier always revert for any transaction sender. Consequently, the airdrop function becomes permanently inaccessible and unusable (7.3 Access Control, 7.8 Operations).I-01
airdrop Function After Ownership RenunciationIssue
The airdrop function is protected by the onlyOwner modifier. The provided prefill data indicates that ownership of the contract has been renounced (transferred to address(0)). When ownership is renounced, the owner() function returns address(0), making the onlyOwner modifier always revert for any transaction sender. Consequently, the airdrop function becomes permanently inaccessible and unusable (7.3 Access Control, 7.8 Operations).
Fix
Confirm if the permanent inaccessibility of the airdrop function was an intended consequence of ownership renunciation. If the airdrop functionality was critical, ownership should not have been renounced, or a different access control mechanism should have been used.
Status
Unresolved
InfoPotential High Gas Costs for Large Airdrop Arrays
The airdrop function iterates through recipients and amounts arrays. If these arrays contain a very large number of elements, the transaction's gas cost could become prohibitively high, potentially exceeding the block gas limit. This would prevent the airdrop from being executed in a single transaction (7.1 Architecture, 7.2 Code Security). This issue is currently moot due to the airdrop function being unusable (I-01).I-02
Issue
The airdrop function iterates through recipients and amounts arrays. If these arrays contain a very large number of elements, the transaction's gas cost could become prohibitively high, potentially exceeding the block gas limit. This would prevent the airdrop from being executed in a single transaction (7.1 Architecture, 7.2 Code Security). This issue is currently moot due to the airdrop function being unusable (I-01).
Fix
If the airdrop function were to be made usable in a future iteration, consider implementing pagination or batching mechanisms to process large airdrops across multiple transactions, or limit the maximum array length to a reasonable number to ensure transactions remain within gas limits.
Status
Unresolved
InfoLeveraging Standard OpenZeppelin ERC20 Implementation
The Aria token contract correctly inherits and utilizes the battle-tested ERC20 and Ownable contracts from OpenZeppelin. This approach significantly reduces the risk of common vulnerabilities such as reentrancy, integer overflows/underflows, and standard ERC20 compliance issues, as these libraries have undergone extensive audits and community review (7.2 Code Security).I-03
Issue
The Aria token contract correctly inherits and utilizes the battle-tested ERC20 and Ownable contracts from OpenZeppelin. This approach significantly reduces the risk of common vulnerabilities such as reentrancy, integer overflows/underflows, and standard ERC20 compliance issues, as these libraries have undergone extensive audits and community review (7.2 Code Security).
Fix
Continue to rely on well-audited and widely adopted libraries like OpenZeppelin for core functionalities. Ensure that any custom logic built on top of these libraries maintains the same high security standards.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The contract is a standard ERC20 token built upon OpenZeppelin's secure and audited libraries, minimizing common vulnerabilities like reentrancy and integer overflows (7.2 Code Security). The airdrop function correctly validates input lengths and ensures sufficient balance before transfers (7.1 Architecture). However, the airdrop function is only callable by the owner, and if ownership is renounced, this function becomes permanently inaccessible (7.3 Access Control).
The initial token distribution is highly centralized, with all 1 billion tokens minted to the deployer (7.4 Economic). However, the contract leverages the battle-tested OpenZeppelin Ownable contract, and the prefill indicates ownership has been renounced. This renunciation effectively disables the airdrop function and removes any further administrative control, decentralizing future operations but also making the airdrop function permanently unusable (7.5 Governance).
The contract is not designed with upgradeability features, such as proxy patterns. This eliminates risks associated with upgrade mechanisms, ensuring the contract's logic is immutable post-deployment (7.7 Upgrades).
The Aria token contract is robust due to its reliance on OpenZeppelin standards.
Given the reported renunciation of ownership, the contract's administrative functions are permanently disabled, which should be a conscious design decision. For future developments, consider the implications of such immutability on potential future needs for administrative actions or feature enhancements.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202612Low
- Aug 11, 202623Low
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the ARIA contract address?
The ARIA.AI (ARIA) contract on BNB Chain is 0x5d3a12c42e5372b2cc3264ab3cdcf660a1555238. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is ARIA.AI a scam?
Quantum Audit's risk score for ARIA.AI is 12/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is ARIA liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.29M.
Who holds ARIA?
As of Sep 4, 2026, the 10 largest holders own 86.1% of the supply. The Holders section on this page shows who they are by holder type.
Would You Like a More Detailed Audit of ARIA.AI?
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page