Quantum Audit Logo
Launch App

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

Is Starman Safe?

STARMANEthereum
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance7/10Upgrades9/10Checks passed5 of 5Findings1 Critical · 1 High · 4 Medium · 1 Low7
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.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • Liquidity < $50k
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 4 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
31.2%Contracts12.0%Wallets56.7%Everyone else
31.2%Contracts12.0%56.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
43.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking31.2%
  • Walletsanonymous holders, free to sell12.0%
  • Everyone elsethe rest of the supply56.7%
Effective concentrationwhat the score reads24.5%
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$48.8K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$48.8KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 Critical1 High4 Medium1 Low
Critical

Truncated Core Transfer Logic Prevents Full Audit

The 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.C-01

Issue

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

Fix

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

Status

Unresolved

High

Immutability of Critical Parameters Post-Renunciation

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

High Initial Transaction Taxes

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

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

Prior 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.M-02

Issue

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

Fix

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

Status

Unresolved

Medium

Fixed Max Transaction and Wallet Size Limits

The 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.M-03

Issue

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

Fix

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

Status

Unresolved

Medium

Inferred swapAndLiquify Mechanism Risks

The _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.M-04

Issue

The _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.

Fix

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

Status

Unresolved

Low

_taxWallet Immutability and Single Point of Failure

The _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.L-01

Issue

The _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.

Fix

Ensure the _taxWallet address is correct, secure, and controlled by the intended recipient before deployment and especially before renouncing ownership.

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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.

Governance7/10Low risk

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

Upgrades9/10Low risk

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.

Final RecommendationWhat to do about this score

Given the truncated source code for the core transfer logic, users should exercise extreme caution.

A full and verifiable source code must be provided for a comprehensive security assessment. Furthermore, users must understand that due to renounced ownership, all contract parameters, including taxes, transaction limits, and bot lists, are permanently fixed. Investors should carefully review these fixed parameters to ensure they align with their risk tolerance and expectations for the token's long-term viability. Ensure the _taxWallet address is legitimate and secure, as it is immutable.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age2y
Contract0x1241…e671
Deployer0x034d…536e
Badge for your website
Starman 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. Sep 4, 202633Low
  2. Jul 31, 202627Low

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

Related Audits

6 more on the recordAll audits
Immutable XIMX · Ethereum33LowPrometheusEthereum32LowVERAVRA · Ethereum32LowPendleEthereum34LowWrapped SOLSOL · Ethereum34LowTraivoTRVO · Ethereum32Low

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 Is this your token? Publish your own audit on this page