Quantum Audit Logo

Is Starman Safe?

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

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

Starman STARMAN
0x1241…e671
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The Starman token contract implements standard ERC-20 functionality along with custom features such as transaction taxes, anti-bot measures, and max transaction/wallet limits. A critical limitation of this audit is the truncated source code for the core `_transfer` function, which prevents a full security analysis. Furthermore, the contract's ownership has been renounced, making all administrative parameters immutable. While this enhances decentralization, it also means any misconfigurations or unforeseen issues with fixed parameters (e.g., high taxes, bot lists, max limits) cannot be corrected. Users should be aware of these fixed parameters and the inherent risks of an unauditable core transfer logic.

1 Critical1 High4 Medium1 Low
Volume 24h
$2.1K
Liquidity
$48.8K
Price
$0.0001053
Token Age
2y
Top 10 Holders
43.3%

Security Findings

1 Crit1 High4 Med1 Low
Critical

Truncated Core Transfer Logic Prevents Full Audit

C-01The provided contract code for the `_transfer` function is truncated. This prevents a complete security analysis of the core token transfer logic, including tax calculations, bot checks, max transaction/wallet size enforcement, and the `swapAndLiquify` mechanism. Without the full code, critical vulnerabilities such as reentrancy, logic errors, or incorrect tax applications cannot be identified or ruled out.
IssueThe provided contract code for the `_transfer` function is truncated. This prevents a complete security analysis of the core token transfer logic, including tax calculations, bot checks, max transaction/wallet size enforcement, and the `swapAndLiquify` mechanism. Without the full code, critical vulnerabilities such as reentrancy, logic errors, or incorrect tax applications cannot be identified or ruled out.
FixA full and verifiable source code for the entire contract, including the complete `_transfer` function, must be provided to conduct a comprehensive security audit and ensure the integrity of the token's core functionality.
StatusUnresolved
High

Immutability of Critical Parameters Post-Renunciation

H-01The contract's ownership has been renounced, permanently disabling all `onlyOwner` functions. Consequently, critical parameters such as transaction taxes (`_initialBuyTax`, `_finalBuyTax`), maximum transaction amounts (`_maxTxAmount`), maximum wallet sizes (`_maxWalletSize`), the `_taxWallet` address, and the `bots` and `_isExcludedFromFee` lists are immutable. Any misconfiguration or unforeseen issues with these parameters cannot be corrected, posing a significant risk to the token's long-term functionality and user experience.
IssueThe contract's ownership has been renounced, permanently disabling all `onlyOwner` functions. Consequently, critical parameters such as transaction taxes (`_initialBuyTax`, `_finalBuyTax`), maximum transaction amounts (`_maxTxAmount`), maximum wallet sizes (`_maxWalletSize`), the `_taxWallet` address, and the `bots` and `_isExcludedFromFee` lists are immutable. Any misconfiguration or unforeseen issues with these parameters cannot be corrected, posing a significant risk to the token's long-term functionality and user experience.
FixUsers should be fully aware that all administrative controls are permanently relinquished. Before renouncing ownership, all critical parameters should be thoroughly reviewed and set to optimal values, and the `_taxWallet` should be verified to prevent permanent issues.
StatusUnresolved
Medium

High Initial Transaction Taxes

M-01The contract implements a high initial buy and sell tax of 20% (`_initialBuyTax`, `_initialSellTax`). While these taxes are designed to reduce to 0% after a certain number of buys (`_reduceBuyTaxAt`), the initial high percentage can significantly impact early trading, deter legitimate users, and potentially reduce liquidity. After ownership renunciation, these tax rates are fixed and cannot be adjusted if they prove detrimental.
IssueThe contract implements a high initial buy and sell tax of 20% (`_initialBuyTax`, `_initialSellTax`). While these taxes are designed to reduce to 0% after a certain number of buys (`_reduceBuyTaxAt`), the initial high percentage can significantly impact early trading, deter legitimate users, and potentially reduce liquidity. After ownership renunciation, these tax rates are fixed and cannot be adjusted if they prove detrimental.
FixProjects should carefully consider the impact of high transaction taxes on user adoption and trading behavior. Ensure the tax reduction mechanism (`_buyCount` and `_reduceBuyTaxAt`) is robust and achieves the desired final tax rates in a timely manner.
StatusUnresolved
Medium

Centralized Control over Bot/Exclusion Lists (Pre-Renunciation) and Subsequent Immutability

M-02Prior to ownership renunciation, the owner had the ability to arbitrarily add or remove addresses from the `bots` list and the `_isExcludedFromFee` list. This centralized control could have been abused to censor users or grant preferential treatment. Post-renunciation, these lists are immutable. This means if a legitimate user was accidentally added to the `bots` list, they are permanently blocked. Conversely, if new malicious actors emerge, they cannot be added to the `bots` list.
IssuePrior to ownership renunciation, the owner had the ability to arbitrarily add or remove addresses from the `bots` list and the `_isExcludedFromFee` list. This centralized control could have been abused to censor users or grant preferential treatment. Post-renunciation, these lists are immutable. This means if a legitimate user was accidentally added to the `bots` list, they are permanently blocked. Conversely, if new malicious actors emerge, they cannot be added to the `bots` list.
FixWhile renunciation removes the risk of ongoing abuse, users should be aware that the initial configuration of these lists is permanent. Projects should ensure these lists are accurately configured before renouncing ownership.
StatusUnresolved
Medium

Fixed Max Transaction and Wallet Size Limits

M-03The contract enforces maximum transaction amounts (`_maxTxAmount`) and maximum wallet sizes (`_maxWalletSize`). These limits are fixed after ownership renunciation. If these values are set too low, they could hinder large legitimate transactions or prevent accumulation by significant investors. If set too high, they might not effectively prevent large dumps or whale manipulation. Any adjustment to these limits is impossible after renunciation.
IssueThe contract enforces maximum transaction amounts (`_maxTxAmount`) and maximum wallet sizes (`_maxWalletSize`). These limits are fixed after ownership renunciation. If these values are set too low, they could hinder large legitimate transactions or prevent accumulation by significant investors. If set too high, they might not effectively prevent large dumps or whale manipulation. Any adjustment to these limits is impossible after renunciation.
FixThe project should ensure that the initial `_maxTxAmount` and `_maxWalletSize` are carefully chosen to balance anti-whale measures with legitimate trading needs, as these parameters cannot be changed post-renunciation.
StatusUnresolved
Medium

Inferred `swapAndLiquify` Mechanism Risks

M-04The `_transfer` function (partially provided) indicates the presence of a `swapAndLiquify` mechanism for tax collection and liquidity provision. Without the full code for this function, potential vulnerabilities such as reentrancy during ETH transfers, excessive slippage during swaps, or gas limit issues for complex operations cannot be fully assessed.
IssueThe `_transfer` function (partially provided) indicates the presence of a `swapAndLiquify` mechanism for tax collection and liquidity provision. Without the full code for this function, potential vulnerabilities such as reentrancy during ETH transfers, excessive slippage during swaps, or gas limit issues for complex operations cannot be fully assessed.
FixA full audit of the `swapAndLiquify` function is necessary to ensure its security and efficiency. Common best practices include reentrancy guards, slippage protection, and gas optimization.
StatusUnresolved
Low

`_taxWallet` Immutability and Single Point of Failure

L-01The `_taxWallet` address, which receives collected taxes, is set during construction and becomes immutable after ownership renunciation. If this address is incorrect, a dead address, or becomes compromised, all collected taxes will be permanently lost or diverted, creating a single point of failure for the project's revenue stream.
IssueThe `_taxWallet` address, which receives collected taxes, is set during construction and becomes immutable after ownership renunciation. If this address is incorrect, a dead address, or becomes compromised, all collected taxes will be permanently lost or diverted, creating a single point of failure for the project's revenue stream.
FixEnsure the `_taxWallet` address is correct, secure, and controlled by the intended recipient before deployment and especially before renouncing ownership.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract utilizes `SafeMath` for arithmetic operations, mitigating common integer overflow/underflow vulnerabilities (7.2 Code Security). It implements standard ERC-20 functions and an `Ownable` pattern for initial administrative control (7.3 Access Control). However, the provided source code for the critical `_transfer` function is truncated, preventing a complete analysis of its internal logic, including tax calculations, bot checks, and the `swapAndLiquify` mechanism (7.2 Code Security). This truncation represents a significant technical risk as core functionalities remain unaudited.

GovernanceLow7/10

The contract's economic model includes dynamic transaction taxes (initial 20% buy/sell, reducing to 0%), max transaction amounts, and max wallet sizes (7.4 Economic). These parameters, along with anti-bot and fee exclusion lists, were initially controlled by the owner. However, ownership has been renounced, making all these parameters immutable (7.5 Governance). This immutability means that if the initial tax rates are too high, or if the max limits are restrictive, or if the bot list is misconfigured, these issues cannot be corrected, posing a high economic risk to users and the token's liquidity. The `_taxWallet` is also fixed, creating a single point of failure for collected taxes (7.8 Operations).

UpgradesLow9/10

The contract is a standard implementation and does not utilize any proxy patterns, meaning it is not upgradeable (7.7 Upgrades). This eliminates upgrade-related risks such as proxy implementation mismatches or malicious upgrade paths. However, the renounced ownership also means that no parameters can be modified post-deployment, which can be a double-edged sword: it guarantees immutability but prevents any bug fixes or parameter adjustments if needed.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

43.3% in top 10
12.0% in wallets31.2% in contracts
Effective Concentration24.5%

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

$48.8K

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0x034d…536e

What Raised This Score

6 factors
  • Top-10 concentration > 20% (43.3% total → 24.5% effective; 12.0% in EOAs, 31.2% in contracts — mild)
  • Liquidity < $50k ($48,760 across 1 pairs — thin market)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 4 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
PrometheusMedium RiskVERA (VRA)Medium RiskPendleMedium RiskI love puppies (PUPPIES)Medium RiskAliensMedium RiskwojakMedium Risk

Would You Like a More Detailed Audit of Starman?

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

Get Detailed Audit