Quantum Audit Logo

Is Aster Safe?

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

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

Aster ASTER
0x000a…556a
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 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the AsterToken contract, which appears to be a standard ERC-20 token implementation. Based on the provided (truncated) source code, the contract heavily relies on battle-tested OpenZeppelin libraries, which significantly reduces the likelihood of common vulnerabilities. The primary risks identified are related to potential centralization of token supply management and the absence of an emergency pause mechanism, which are common considerations for custom token implementations. The contract is not upgradeable, eliminating upgrade-related risks.

2 Low3 Informational
Volume 24h
$2.85M
Liquidity
$981.4K
Price
$0.7346
Token Age
10mo
Top 10 Holders
93.6%

Security Findings

2 Low3 Info
Low

Centralized Control over Token Supply

L-01If the `AsterToken` contract includes custom minting or burning functions controlled by a single owner (e.g., via `Ownable`), this introduces a centralization risk. A compromised owner key or malicious owner could manipulate the token supply, impacting tokenomics and holder trust. This falls under 7.3 Access Control and 7.4 Economic considerations.
IssueIf the `AsterToken` contract includes custom minting or burning functions controlled by a single owner (e.g., via `Ownable`), this introduces a centralization risk. A compromised owner key or malicious owner could manipulate the token supply, impacting tokenomics and holder trust. This falls under 7.3 Access Control and 7.4 Economic considerations.
FixImplement robust access control for supply-altering functions. Consider multi-signature wallets for critical roles or a time-locked governance mechanism for significant supply changes. Clearly document the powers of any privileged roles.
StatusUnresolved
Low

Lack of Emergency Pause Functionality

L-02The contract does not appear to implement a pause mechanism (e.g., using OpenZeppelin's `Pausable` contract). In the event of a critical vulnerability, market manipulation, or unforeseen external event, the inability to temporarily halt transfers or other critical operations could lead to significant loss of funds or protocol instability. This relates to 7.8 Operations.
IssueThe contract does not appear to implement a pause mechanism (e.g., using OpenZeppelin's `Pausable` contract). In the event of a critical vulnerability, market manipulation, or unforeseen external event, the inability to temporarily halt transfers or other critical operations could lead to significant loss of funds or protocol instability. This relates to 7.8 Operations.
FixConsider integrating a pause mechanism, ideally controlled by a multi-signature wallet or a robust governance process. This provides a crucial emergency stop-gap to mitigate damage during critical incidents.
StatusUnresolved
Info

Reliance on OpenZeppelin Standard Implementations

I-01The contract extensively utilizes battle-tested OpenZeppelin Contracts for its core ERC-20 functionality. This significantly reduces the attack surface and mitigates many common vulnerabilities, as these libraries are widely audited and maintained. This is a strong security practice.
IssueThe contract extensively utilizes battle-tested OpenZeppelin Contracts for its core ERC-20 functionality. This significantly reduces the attack surface and mitigates many common vulnerabilities, as these libraries are widely audited and maintained. This is a strong security practice.
FixContinue to leverage well-vetted libraries like OpenZeppelin. Ensure that any custom logic built on top of these libraries adheres to similar security standards and best practices.
StatusUnresolved
Info

Floating Pragma Directive

I-02The contract uses a floating pragma `^0.8.20`. While this allows for compilation with newer patch versions of Solidity, it introduces a slight risk that future compiler versions might introduce breaking changes or unexpected behavior. This is a general code quality consideration.
IssueThe contract uses a floating pragma `^0.8.20`. While this allows for compilation with newer patch versions of Solidity, it introduces a slight risk that future compiler versions might introduce breaking changes or unexpected behavior. This is a general code quality consideration.
FixPin the Solidity compiler version to a specific version (e.g., `pragma solidity 0.8.25;`) to ensure consistent compilation and deployment behavior across environments. This is a best practice for production contracts.
StatusUnresolved
Info

Non-Upgradeability of Contract

I-03The contract is not implemented as an upgradeable proxy. This means that once deployed, its logic cannot be modified. While this eliminates upgrade-related risks (7.7 Upgrades), it also means that any discovered bugs or desired feature enhancements would necessitate a new contract deployment and a potentially complex token migration process for users.
IssueThe contract is not implemented as an upgradeable proxy. This means that once deployed, its logic cannot be modified. While this eliminates upgrade-related risks (7.7 Upgrades), it also means that any discovered bugs or desired feature enhancements would necessitate a new contract deployment and a potentially complex token migration process for users.
FixUnderstand the implications of non-upgradeability. For contracts intended to be immutable, this is acceptable. For projects requiring future flexibility or bug fixes without migration, consider an upgradeable architecture in future iterations, ensuring proper implementation of proxy patterns.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1 Architecture) leverages OpenZeppelin's robust ERC-20 implementation, providing a strong foundation for code security (7.2 Code Security). This minimizes common vulnerabilities like reentrancy and integer overflows. Access control (7.3 Access Control) for core ERC-20 functions is handled by the standard, but any custom minting/burning logic would require careful review. The provided code snippet is primarily OpenZeppelin interfaces and the base ERC20 contract, suggesting a high standard of code quality.

GovernanceHigh2/10

The economic model (7.4 Economic) of a standard ERC-20 token is generally straightforward, with value derived from its utility and market dynamics. Potential economic risks typically stem from centralized control over token supply, such as an owner's ability to mint new tokens, which could dilute existing holders. Governance (7.5 Governance) is minimal for a simple token, often limited to an `Ownable` pattern for administrative functions. The absence of a pause mechanism (7.8 Operations) could be a concern in emergency situations.

UpgradesMedium5/10

The contract is not designed to be upgradeable (7.7 Upgrades), as indicated by `is_proxy: false`. This eliminates the risks associated with proxy implementations, such as storage collisions or improper initialization. However, it also means that any future changes or bug fixes would require a new deployment and migration of assets, 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

93.6% in top 10
6.7% in wallets86.9% in contracts
Effective Concentration41.4%

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

$3.61M across 30 pairs
Pancakeswap v3USDTanalysed$981.4K27.2%Pancakeswap v3WBNB$830.8K23.0%Pancakeswap v3USDT$635.7K17.6%Uniswap比特币$364.4K10.1%UniswapUSDT$224.8K6.2%UniswapWBNB$199.7K5.5%
Show 4 more pairsShow less
Pancakeswap v2WBNB$85.7K2.4%Pancakeswap v3WBNB$71.3K2.0%Pancakeswap v3Cake$69.7K1.9%UniswapUSDT$65.1K1.8%

The 20 remaining pairs hold $86.1K between them and are not listed.

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.

Key Addresses

1 addresses
Deployer
0x4184…a305

What Raised This Score

4 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (93.6% total → 41.4% effective; 6.7% in EOAs, 86.9% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 2 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
MYXMedium RiskBluwhale AI (BLUAI)Medium RiskTaleX (X)Medium RiskPeaqOFT (PEAQ)Medium Risk施工猫 (SUE)Medium RiskmubarakMedium Risk

Would You Like a More Detailed Audit of Aster?

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

Get Detailed Audit