Quantum Audit Logo
Launch App

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

Is BaseStonk Safe?

BSTONKBase
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 →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance2/10Upgrades5/10Checks passed5 of 7Findings1 Critical · 2 High · 1 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The AdvancedLaunchToken contract is an ERC20 token with a max wallet cap feature and an external reward tracker integration.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 30 days
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (31.2% total → 27.6% effective; 25.3% in EOAs, 5.9% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
5.9%Contracts25.3%Wallets68.8%Everyone else
5.9%25.3%Wallets68.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
31.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking5.9%
  • Walletsanonymous holders, free to sell25.3%
  • Everyone elsethe rest of the supply68.8%
Effective concentrationwhat the score reads27.6%
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 4$194.4K across 26 pairs
Show 4 more pairs

The 16 remaining pairs hold $35 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$141.6KShare of depth72.8%
Top-1 Unlocked Holder38.1%
Top-3 Unlocked77.1%
Unlocked LP held by
0x8f9b…eb3f0x4c12…da0a0x5004…4d870x3a26…1a280x73e3…93d50xbfdf…ebbd0x6f6b…88f20x1983…a2580x2f14…0a7b0x1690…1c15

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

Security Findings

1 Critical2 High1 Medium1 Low1 Info
Critical

Denial of Service via External Call Revert

The _update function, called on every token transfer, includes an external call to rewardTracker.call{gas: 600_000}(...). If this external call reverts for any reason (e.g., rewardTracker is a malicious contract, a buggy contract, or a non-contract address), the entire _update transaction will revert. This effectively blocks all token transfers for all users, creating a severe denial of service vulnerability (7.2 Code Security, 7.8 Operations).C-01

Issue

The _update function, called on every token transfer, includes an external call to rewardTracker.call{gas: 600_000}(...). If this external call reverts for any reason (e.g., rewardTracker is a malicious contract, a buggy contract, or a non-contract address), the entire _update transaction will revert. This effectively blocks all token transfers for all users, creating a severe denial of service vulnerability (7.2 Code Security, 7.8 Operations).

Fix

Implement robust error handling for external calls. The ok boolean returned by call should be checked, and the transaction should not revert if the external call fails. Consider using a try/catch block around the external call to gracefully handle failures without blocking core token functionality. Ensure the rewardTracker is a trusted, audited contract that cannot revert on ping.

Status

Unresolved

High

Irreversible rewardTracker Address and Immutable Launcher Role

The rewardTracker address can only be set once by the launcher (if (rewardTracker == address(0)) rewardTracker = tracker;). If this address is set incorrectly, to a malicious contract, or if the legitimate tracker needs to be updated or replaced, it is impossible to change it. This creates a permanent single point of failure and limits operational flexibility. Furthermore, the launcher role itself is immutable, meaning if the launcher key is compromised or lost, the ability to set the rewardTracker (if not already set) or manage exemptions is permanently lost (7.3 Access Control, 7.8 Operations).H-01

Issue

The rewardTracker address can only be set once by the launcher (if (rewardTracker == address(0)) rewardTracker = tracker;). If this address is set incorrectly, to a malicious contract, or if the legitimate tracker needs to be updated or replaced, it is impossible to change it. This creates a permanent single point of failure and limits operational flexibility. Furthermore, the launcher role itself is immutable, meaning if the launcher key is compromised or lost, the ability to set the rewardTracker (if not already set) or manage exemptions is permanently lost (7.3 Access Control, 7.8 Operations).

Fix

Implement a mechanism to allow the rewardTracker to be updated by a trusted entity (e.g., a multi-signature wallet or governance) after an appropriate timelock. Consider making the launcher role upgradeable or managed by a multi-sig to mitigate the risk of a single point of failure and enhance long-term security.

Status

Unresolved

High

Unchecked Return Value of External Call

The external call to rewardTracker.call{gas: 600_000}(...) does not check the boolean ok return value. While the transaction will revert if the target contract reverts, if the target contract simply returns false without reverting, the _update function will proceed as if the call was successful. This can lead to unexpected or incorrect state in the rewardTracker or the overall protocol, as the success of the ping operation is not confirmed (7.2 Code Security, 7.6 External).H-02

Issue

The external call to rewardTracker.call{gas: 600_000}(...) does not check the boolean ok return value. While the transaction will revert if the target contract reverts, if the target contract simply returns false without reverting, the _update function will proceed as if the call was successful. This can lead to unexpected or incorrect state in the rewardTracker or the overall protocol, as the success of the ping operation is not confirmed (7.2 Code Security, 7.6 External).

Fix

Always check the return value of low-level call functions. If the ping operation is critical, ensure ok is true and handle cases where it is false. If it's best-effort, consider logging the failure but not reverting the transaction (after addressing the critical DoS issue).

Status

Unresolved

Medium

Centralized Control over Max Wallet Exemptions

The launcher address has the sole ability to add or remove addresses from the exemptFromMaxWallet list via the setExempt function. This centralization of control means a single entity can decide which users are subject to the maxWalletBps cap and which are not. This introduces a trust assumption in the launcher and could potentially be abused to unfairly exempt large holders or manipulate market dynamics (7.3 Access Control, 7.5 Governance).M-01

Issue

The launcher address has the sole ability to add or remove addresses from the exemptFromMaxWallet list via the setExempt function. This centralization of control means a single entity can decide which users are subject to the maxWalletBps cap and which are not. This introduces a trust assumption in the launcher and could potentially be abused to unfairly exempt large holders or manipulate market dynamics (7.3 Access Control, 7.5 Governance).

Fix

Evaluate if this level of centralized control is necessary long-term. Consider transitioning this power to a more decentralized governance mechanism or a multi-signature wallet after the initial launch phase to reduce single-point-of-failure risk and increase transparency.

Status

Unresolved

Low

Max Wallet Cap Inactive During Pre-Launch and for 100%+ Caps

The maxWalletBps cap is only enforced if (launched) and if (maxWalletBps < BPS). This means during the initial phase before finishLaunch() is called, or if maxWalletBps is set to 100% (10,000 BPS) or higher, the wallet cap is not active. While this might be an intentional design choice for initial distribution, it allows for large accumulations before the cap becomes active (7.4 Economic).L-01

Issue

The maxWalletBps cap is only enforced if (launched) and if (maxWalletBps < BPS). This means during the initial phase before finishLaunch() is called, or if maxWalletBps is set to 100% (10,000 BPS) or higher, the wallet cap is not active. While this might be an intentional design choice for initial distribution, it allows for large accumulations before the cap becomes active (7.4 Economic).

Fix

Document the intended behavior of the maxWalletBps cap during the pre-launch phase and when set to 100% or more. Ensure that the project's whitepaper or documentation clearly explains these conditions to users to manage expectations.

Status

Unresolved

Info

Hardcoded Exempt Addresses

Several addresses are hardcoded as exempt from the max wallet cap in the constructor: mintTo, poolManager, 0x0000…dEaD, and creator_. While mintTo and creator_ are parameters, 0x00...dEaD is a literal. Hardcoding addresses can sometimes lead to issues if the purpose of that address changes or if it's a typo (7.1 Architecture).I-01

Issue

Several addresses are hardcoded as exempt from the max wallet cap in the constructor: mintTo, poolManager, , and creator_. While mintTo and creator_ are parameters, 0x00...dEaD is a literal. Hardcoding addresses can sometimes lead to issues if the purpose of that address changes or if it's a typo (7.1 Architecture).

Fix

Document the precise purpose of each hardcoded exempt address, especially 0x00...dEaD. Ensure that the use of 0x00...dEaD is intentionally for a burn address or similar and does not conflict with other protocol mechanics or future plans.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The AdvancedLaunchToken contract is an ERC20 token with a max wallet cap feature and an external reward tracker integration. The audit identified a critical denial of service vulnerability due to an unchecked external call that can block all transfers. High-severity issues include irreversible roles and external contract settings, and unchecked return values from external calls. The contract exhibits high centralization, with key administrative functions controlled by an immutable 'launcher' address. While the core ERC20 functionality is robust due to OpenZeppelin inheritance, the custom logic introduces significant operational and security risks.

Technical6/10Medium risk

The contract leverages OpenZeppelin's robust ERC20 implementation, providing a solid foundation for token functionality (7.2 Code Security). However, a critical vulnerability exists in the _update function, where an external call to rewardTracker can revert, causing a denial of service for all token transfers (7.2 Code Security). Additionally, the return value of this external call is not checked, which can lead to silent failures (7.2 Code Security). The max wallet cap logic is correctly applied after transfers, preventing users from exceeding the cap (7.2 Code Security).

Governance2/10High risk

The contract exhibits high centralization, with the launcher address holding immutable control over critical functions like setting exemptions, the reward tracker, and finishing the launch (7.3 Access Control, 7.5 Governance). This single point of failure poses a significant risk if the launcher key is compromised or lost. The rewardTracker address can only be set once, making it irreversible if set incorrectly or if the tracker needs updating (7.8 Operations). The max wallet cap is not active during the pre-launch phase or if set to 100% or more, which could allow for initial large accumulations (7.4 Economic).

Upgrades5/10Medium risk

The AdvancedLaunchToken contract is not designed as an upgradeable proxy (7.7 Upgrades). This means that once deployed, its logic cannot be modified or updated. While this eliminates risks associated with proxy patterns (e.g., storage collisions, upgrade path vulnerabilities), it also means that any discovered bugs or desired feature enhancements cannot be implemented without a full redeployment and migration.

Final RecommendationWhat to do about this score

Prioritize addressing the critical denial of service vulnerability by implementing robust error handling for external calls to the rewardTracker.

Consider using a try/catch block or ensuring the rewardTracker is a highly trusted and audited contract that cannot revert on ping. Evaluate the long-term implications of immutable administrative roles and single-set addresses. Implement mechanisms for role transfers or multi-signature control for critical functions like launcher and rewardTracker to enhance operational flexibility and reduce single points of failure. Ensure all external dependencies, especially the rewardTracker, are thoroughly audited and trusted.

Contract & Record

1 audit on record
TypeAdvancedLaunchToken
NetworkBase
Token age13d
Contract0x0f61…dfc9
Deployer0x9372…ad82
Badge for your website
BaseStonk security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 30, 202664Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
Wrapped State Street SPDR Portfolio S&P 500 ETF ST0xWTSPYM · Base64MediumVelvetBase63MediumDiemBase63Mediumether.fi governance tokenETHFI · Base65HighjesseBase63MediumRipe DAO Governance TokenRIPE · Base63Medium

Would You Like a More Detailed Audit of BaseStonk?

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