Quantum Audit Logo

Is BaseStonk Safe?

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

BaseStonk BSTONK
0x0f61…dfc9
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Critical2 High1 Medium1 Low1 Informational
Volume 24h
$537.4K
Liquidity
$141.6K
Price
$0.002609
Token Age
13d
Top 10 Holders
31.2%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Denial of Service via External Call Revert

C-01The `_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).
IssueThe `_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).
FixImplement 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`.
StatusUnresolved
High

Irreversible `rewardTracker` Address and Immutable Launcher Role

H-01The `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).
IssueThe `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).
FixImplement 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.
StatusUnresolved
High

Unchecked Return Value of External Call

H-02The 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).
IssueThe 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).
FixAlways 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).
StatusUnresolved
Medium

Centralized Control over Max Wallet Exemptions

M-01The `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).
IssueThe `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).
FixEvaluate 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.
StatusUnresolved
Low

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

L-01The `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).
IssueThe `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).
FixDocument 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.
StatusUnresolved
Info

Hardcoded Exempt Addresses

I-01Several 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).
IssueSeveral 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).
FixDocument 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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).

GovernanceHigh2/10

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).

UpgradesMedium5/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

31.2% in top 10
25.3% in wallets5.9% in contracts
Effective Concentration27.6%

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

$194.4K across 26 pairs
Uniswap v4USDCanalysed$141.6K72.8%Uniswap v4USDC$48.3K24.8%Uniswap v4ETH$3.1K1.6%Uniswap v3WETH$5390.3%Uniswap v4USDC$4060.2%Uniswap v4ETH$1420.1%
Show 4 more pairsShow less
Uniswap v4USDC$1370.1%Uniswap v4USDC$890.0%Uniswap v4USDC$370.0%AerodromeWETH$360.0%

The 16 remaining pairs hold $35 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.

LP Distribution

Top-1 Unlocked Holder38.1%
Top-3 Unlocked77.1%

Key Addresses

11 addresses
Deployer
0x9372…ad82
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.

What Raised This Score

8 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

Related Audits

6 more on the record
Wrapped State Street SPDR Portfolio S&P 500 ETF ST0x (WTSPYM)High RiskVelvetHigh RiskDiemHigh Riskether.fi governance token (ETHFI)High RiskjesseHigh RiskRipe DAO Governance Token (RIPE)High Risk

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