Quantum Audit Logo

Is ARAI Token Safe?

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

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

ARAI Token AA
0x01bf…6936
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 18d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The ARAI_TOKEN contract is a standard ERC20 token implementation, leveraging battle-tested OpenZeppelin libraries for its core functionality and access control. The contract features a fixed total supply minted to the owner at deployment and includes owner-only functions to rescue accidentally sent ERC20 tokens or native currency. The audit identified no critical or high-severity vulnerabilities. Findings are limited to low-severity and informational items concerning centralized control over rescue functions and the immutability of the token's design.

1 Low2 Informational
Volume 24h
$810.4K
Liquidity
$464.4K
Price
$0.009105
Token Age
10mo
Top 10 Holders
97.7%

Security Findings

1 Low2 Info
Low

Centralized Control over Rescue Functions

L-01The `rescueAssets` and `rescueBNB` functions are protected by the `onlyOwner` modifier, granting the contract owner exclusive control over the recovery of any ERC20 tokens or native currency (BNB) accidentally sent to the contract. While the owner is a multisig (2/3), this still represents a centralized point of control. A compromise of the multisig keys could lead to unauthorized draining of these recoverable assets.
IssueThe `rescueAssets` and `rescueBNB` functions are protected by the `onlyOwner` modifier, granting the contract owner exclusive control over the recovery of any ERC20 tokens or native currency (BNB) accidentally sent to the contract. While the owner is a multisig (2/3), this still represents a centralized point of control. A compromise of the multisig keys could lead to unauthorized draining of these recoverable assets.
FixEnsure the multisig owner's keys are managed with the highest security standards, including robust key custody, secure operational procedures, and regular audits of multisig signers. While this centralization is common for recovery functions, maintaining strong security around the owner address is paramount.
StatusUnresolved
Info

Fixed Supply and Non-Upgradeability

I-01The ARAI_TOKEN contract has a fixed total supply of 1 billion tokens, all minted to the owner during deployment. There are no mechanisms for further minting or burning. Additionally, the contract is not designed to be upgradeable, meaning its logic is immutable once deployed. This design choice ensures predictability and immutability but removes the flexibility to introduce new features, fix bugs, or adapt to future requirements without a new deployment.
IssueThe ARAI_TOKEN contract has a fixed total supply of 1 billion tokens, all minted to the owner during deployment. There are no mechanisms for further minting or burning. Additionally, the contract is not designed to be upgradeable, meaning its logic is immutable once deployed. This design choice ensures predictability and immutability but removes the flexibility to introduce new features, fix bugs, or adapt to future requirements without a new deployment.
FixThis is a design choice. Ensure that the project's long-term roadmap accounts for the immutability of the token's economic model and functionality. If future flexibility is desired, consider an upgradeable proxy pattern for future contracts.
StatusUnresolved
Info

Use of `transfer` for Native Token Recovery

I-02The `rescueBNB` function uses `payable(owner()).transfer(_amount)` to send native currency to the owner. The `transfer` method has a fixed gas stipend of 2300 gas. While this is generally safer against reentrancy, it can cause issues if the recipient `owner()` address is a smart contract that requires more than 2300 gas to process incoming native tokens in its `receive()` or `fallback()` function, leading to a silent failure of the transfer.
IssueThe `rescueBNB` function uses `payable(owner()).transfer(_amount)` to send native currency to the owner. The `transfer` method has a fixed gas stipend of 2300 gas. While this is generally safer against reentrancy, it can cause issues if the recipient `owner()` address is a smart contract that requires more than 2300 gas to process incoming native tokens in its `receive()` or `fallback()` function, leading to a silent failure of the transfer.
FixFor robust native token transfers, especially to potentially complex contract addresses, consider using `call` with proper checks for success. For example: `(bool success, ) = payable(owner()).call{value: _amount}(""); require(success, "Transfer failed");`. However, for a trusted owner address (like a multisig), `transfer` is often considered acceptable if the owner's contract is known to handle low-gas transfers.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is robust, implementing a standard ERC20 token with OpenZeppelin's well-audited `ERC20` and `Ownable` contracts. Code security (7.2) is high, benefiting from Solidity 0.8+ default overflow/underflow checks and the absence of complex logic that could introduce reentrancy or other common vulnerabilities. Access control (7.3) is correctly implemented using the `onlyOwner` modifier for administrative functions like `rescueAssets` and `rescueBNB`, ensuring only authorized entities can perform these operations.

GovernanceHigh3/10

The economic model (7.4) is straightforward, with a fixed total supply of 1 billion tokens minted entirely to the owner upon deployment, and no further minting or burning mechanisms. Governance (7.5) is centralized through the `Ownable` pattern, but the owner is a 2/3 multisig, which significantly enhances security by requiring multiple approvals for critical actions and mitigating single-point-of-failure risks. Operational aspects (7.8) include `rescueAssets` and `rescueBNB` functions, allowing the owner to recover funds accidentally sent to the contract, which is a beneficial feature for asset protection.

UpgradesLow7/10

The contract is not designed to be upgradeable (7.7), meaning its logic is immutable once deployed. This design choice eliminates all upgrade-related risks, such as proxy misconfigurations, storage collisions, or insecure upgrade paths. However, it also implies that no future bug fixes or feature enhancements can be implemented without deploying a new contract.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

97.7% in top 10
33.5% in wallets64.2% in contracts
Effective Concentration59.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

$464.5K across 6 pairs
Pancakeswap v3WBNBanalysed$464.4K100.0%Pancakeswap v2USDT$250.0%Pancakeswap v3WBNB$50.0%Pancakeswap v2DPJF$10.0%Pancakeswap v2DPJF$10.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

2 addresses
Deployer
0xba3a…c52a
Unlocked LP Held By
0x37ce…d153

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 NOT renounced — Multisig (2-of-3)
  • Top-10 concentration > 50% (97.7% total → 59.2% effective; 33.5% in EOAs, 64.2% 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

Frequently Asked Questions

Is ARAI Token a scam?

Based on automated analysis, ARAI Token scores 65/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is ARAI Token safe to buy?

Our scanner flagged a risk score of 65/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has ARAI Token been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
吉祥马Medium RiskCZBURN (CBURN)Medium RiskGeniusMedium RiskRiverMedium RiskKavaMedium RiskGUAMedium Risk

Would You Like a More Detailed Audit of ARAI Token?

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

Get Detailed Audit