Is OLAXBT (AIO) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med2 Info

High

Centralized Control of Total Supply by Vesting Contract

H-01The entire token supply (1,000,000,000 tokens with 18 decimals) is minted to a single `vesting` address during contract deployment. This design choice places the sole control and distribution responsibility of all tokens in the hands of the specified vesting contract. This creates a significant single point of failure; if the `vesting` contract is compromised or mismanaged, the entire token supply is at risk.

IssueThe entire token supply (1,000,000,000 tokens with 18 decimals) is minted to a single `vesting` address during contract deployment. This design choice places the sole control and distribution responsibility of all tokens in the hands of the specified vesting contract. This creates a significant single point of failure; if the `vesting` contract is compromised or mismanaged, the entire token supply is at risk.

FixEnsure the `vesting` contract is robustly secured, thoroughly audited, and managed with the highest security standards. Consider implementing multi-signature wallets, time-locked contracts, or other decentralized control mechanisms for the vesting contract to distribute risk and enhance security.

StatusUnresolved

Medium

Absence of Emergency Admin Controls

M-01The `Token` contract lacks any administrative functions such as pausing transfers, blacklisting malicious addresses, or upgrading the contract logic. While this promotes decentralization and immutability, it also means there is no mechanism for emergency response in case of critical vulnerabilities, exploits, or unforeseen market conditions affecting the token.

IssueThe `Token` contract lacks any administrative functions such as pausing transfers, blacklisting malicious addresses, or upgrading the contract logic. While this promotes decentralization and immutability, it also means there is no mechanism for emergency response in case of critical vulnerabilities, exploits, or unforeseen market conditions affecting the token.

FixEvaluate the project's risk tolerance for immutability versus the need for emergency intervention. If emergency controls are deemed necessary, consider implementing a robust, multi-signature-controlled admin role with limited, well-defined capabilities (e.g., `pause`, `unpause`) in a future iteration or a separate governance contract.

StatusUnresolved

Info

Immutability and Non-Upgradeability

I-01The `Token` contract is deployed as a standard, non-upgradeable ERC-20 implementation. This means its logic cannot be modified or updated after deployment. This is a common design choice for simple tokens, ensuring immutability.

IssueThe `Token` contract is deployed as a standard, non-upgradeable ERC-20 implementation. This means its logic cannot be modified or updated after deployment. This is a common design choice for simple tokens, ensuring immutability.

FixThis design choice ensures immutability and predictability. However, it implies that any discovered bugs or desired feature enhancements post-deployment would necessitate a new contract deployment and token migration. Ensure the current implementation is thoroughly tested and meets all long-term requirements.

StatusUnresolved

Info

Redundant Constructor Check

I-02The constructor includes a `require(totalSupply > 0, "Total supply cannot be zero");` check. Given that `totalSupply` is explicitly initialized to `1_000_000_000 ether`, which is a large positive number, this check is always true and therefore redundant.

IssueThe constructor includes a `require(totalSupply > 0, "Total supply cannot be zero");` check. Given that `totalSupply` is explicitly initialized to `1_000_000_000 ether`, which is a large positive number, this check is always true and therefore redundant.

FixRemove the redundant `require(totalSupply > 0, ...)` statement to slightly optimize gas usage and improve code clarity.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The `Token` contract (7.1 Architecture) is a straightforward ERC-20 implementation, leveraging the robust and audited OpenZeppelin Contracts library, which significantly reduces the risk of common vulnerabilities (7.2 Code Security). The use of Solidity ^0.8.28 ensures modern compiler features and safety checks. A minor informational finding includes a redundant `require` statement in the constructor, which does not pose a security risk.

GovernanceHigh2/10

The economic model (7.4 Economic) dictates that the entire token supply is minted to a single `vesting` address upon deployment. This design choice centralizes control over all tokens, making the security and operational integrity of the `vesting` contract paramount (7.8 Operations). Any compromise of this address would directly impact the entire token supply. The contract lacks any governance mechanisms (7.5 Governance) or administrative controls (7.3 Access Control) for post-deployment adjustments or emergency interventions.

UpgradesMedium6/10

The `Token` contract is deployed as a standard, non-upgradeable implementation (7.7 Upgrades). This means its logic cannot be modified or updated after deployment. While this ensures immutability, it also implies that any discovered bugs or desired feature enhancements post-deployment would necessitate a new contract deployment and token migration, which can be a complex and costly process.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

95.5% in top 10

18.4% in wallets77.1% in contracts

Effective Concentration49.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

$78.7K across 3 pairs

UniswapUSDTanalysed$49.1K Pancakeswap v3USDT$29.6K Pancakeswap v2USDT$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 Holder57.2%

Top-3 Unlocked77.8%

Key Addresses

11 addresses

Deployer

0xe5a2…0b5c

Unlocked LP Held By

0x3eff…ce450x575e…fe980xaf12…6f040x6fff…2d740xe43f…5e120xb16e…39f20x61d9…f2970xa37b…14730xd48d…9bd80x3262…f28a

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 > 30% (95.5% total → 49.2% effective; 18.4% in EOAs, 77.1% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 57.2% (independent LP — depth risk, pool = 62% of DEX liquidity)
1 High finding(s) from audit
1 Medium 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

Is OLAXBT Safe?

Security Findings

Centralized Control of Total Supply by Vesting Contract

Absence of Emergency Admin Controls

Immutability and Non-Upgradeability

Redundant Constructor Check

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of OLAXBT?