Quantum Audit Logo

Is MUSWORLD a Scam?

Early-stage security check — honeypot & rug-pull analysis

MUSWORLD MUSEWORLD
0x882c…29f8
Base
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.
Last checked 1d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The LaunchToken contract is a standard ERC20 token with EIP-2612 permit functionality, built upon battle-tested OpenZeppelin libraries. The custom logic is minimal, primarily involving the setting of immutable addresses and initial token minting in the constructor. The contract exhibits high code quality and security due to its simplicity and reliance on audited components, resulting in a low overall risk profile.

1 Low4 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$1.21M
Liquidity
$202.7K
Price
$0.00063
Token Age
1d
Top 10 Holders
43.0%

Security Findings

1 Low4 Info
Low

Centralized Initial Token Distribution

L-01The constructor of the `LaunchToken` contract mints the entire initial `supply` to `msg.sender` (the `factory` address). This means that the deployer of the contract holds 100% of the initial token supply. While common for token launches, this represents a single point of control over the token's initial distribution.
IssueThe constructor of the `LaunchToken` contract mints the entire initial `supply` to `msg.sender` (the `factory` address). This means that the deployer of the contract holds 100% of the initial token supply. While common for token launches, this represents a single point of control over the token's initial distribution.
FixProjects should clearly communicate this centralized initial distribution to their community. Consider implementing a more distributed initial allocation strategy, such as a vesting schedule, airdrop, or liquidity pool seeding, to mitigate risks associated with a single entity holding all tokens.
StatusUnresolved
Info

Unused `launcher` Variable

I-01The `launcher` address is passed as a constructor argument and stored as an `immutable` public variable. However, this variable is never referenced or used within any of the contract's functions or logic.
IssueThe `launcher` address is passed as a constructor argument and stored as an `immutable` public variable. However, this variable is never referenced or used within any of the contract's functions or logic.
FixReview the intended purpose of the `launcher` variable. If it serves no on-chain function, consider removing it to reduce contract size and improve clarity. If it's intended for off-chain use, document this clearly.
StatusUnresolved
Info

`metadataURI` Not Explicitly Immutable

I-02The `metadataURI` variable is set in the constructor and is public, but it is not declared `immutable`. While there is no setter function, making it effectively immutable, explicitly declaring it `immutable` would clearly communicate its intended immutability and prevent any future confusion or accidental modification if the contract were to be extended.
IssueThe `metadataURI` variable is set in the constructor and is public, but it is not declared `immutable`. While there is no setter function, making it effectively immutable, explicitly declaring it `immutable` would clearly communicate its intended immutability and prevent any future confusion or accidental modification if the contract were to be extended.
FixIf `metadataURI` is intended to be unchangeable after deployment, declare it as `immutable` in the contract definition.
StatusUnresolved
Info

Sole Reliance on OpenZeppelin Libraries

I-03The `LaunchToken` contract heavily relies on OpenZeppelin's `ERC20` and `ERC20Permit` implementations. While these libraries are highly regarded and extensively audited, any undiscovered vulnerability in the specific versions used (`^0.8.20` and `^0.8.26` for `LaunchToken`) could potentially impact the security of this contract.
IssueThe `LaunchToken` contract heavily relies on OpenZeppelin's `ERC20` and `ERC20Permit` implementations. While these libraries are highly regarded and extensively audited, any undiscovered vulnerability in the specific versions used (`^0.8.20` and `^0.8.26` for `LaunchToken`) could potentially impact the security of this contract.
FixRegularly monitor OpenZeppelin's security advisories and updates for the versions of contracts used. While direct action on this contract might not be possible if it's not upgradeable, awareness is key for future deployments or related projects.
StatusUnresolved
Info

No Direct Burning Mechanism for `factory` or `launcher`

I-04The contract includes an internal `_burn` function inherited from ERC20, but there is no public function exposed that allows the `factory` (deployer) or `launcher` to directly burn tokens from their own balance or from others (with approval). Tokens can only be 'burned' by transferring them to `address(0)` via standard ERC20 `transfer` or `transferFrom`.
IssueThe contract includes an internal `_burn` function inherited from ERC20, but there is no public function exposed that allows the `factory` (deployer) or `launcher` to directly burn tokens from their own balance or from others (with approval). Tokens can only be 'burned' by transferring them to `address(0)` via standard ERC20 `transfer` or `transferFrom`.
FixIf there is a design requirement for the `factory` or `launcher` to have a direct token burning capability, consider adding a specific public function for this purpose. Otherwise, ensure that the current method of sending to `address(0)` is sufficient for any intended tokenomics.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is robust, leveraging OpenZeppelin's ERC20 and ERC20Permit implementations, which are widely audited and secure. Code security (7.2) is high due to minimal custom logic and proper use of `unchecked` blocks in OpenZeppelin's `_update` function after necessary checks. Access control (7.3) is limited to standard ERC20 roles, with no complex custom permissions, reducing attack surface. No reentrancy or oracle manipulation vectors were identified.

GovernanceHigh2/10

The economic model (7.4) is a standard ERC20 token, with the initial supply minted entirely to the deployer, which is a common but centralized distribution method (L-01). There are no governance mechanisms (7.5) implemented within the contract, simplifying its design. External interactions (7.6) are limited to standard ERC20 interfaces, minimizing external dependencies and associated risks.

UpgradesMedium6/10

The LaunchToken contract is not designed to be upgradeable (7.7), which eliminates all risks associated with upgrade mechanisms, such as proxy implementation bugs or administrative key compromises during upgrades. This design choice contributes to the contract's overall simplicity and security.

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

43.0% in top 10
18.5% in wallets24.5% in contracts
Effective Concentration28.3%

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

$209.3K across 8 pairs
Uniswap v4GITLAWBanalysed$202.7K96.8%Uniswap v4USDC$3.4K1.6%Uniswap v3USDC$2.0K1.0%Uniswap v4USDC$8060.4%Uniswap v4USDC$4610.2%Uniswap v4ETH$290.0%
Show 1 more pairShow less
Uniswap v4USDC$20.0%

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 Holder62.4%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0xd700…f3d4
Unlocked LP Held By
0x7ea1…55900x1690…1c15

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

What Raised This Score

7 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (43.0% total → 28.3% effective; 18.5% in EOAs, 24.5% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 62.4% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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
OpenGradient (OPG)Medium RiskZoraMedium RisknoiceMedium RiskChainLink Token (LINK)Medium Riskthe sleeping giant (TSG)Medium RiskAave Token (AAVE)Medium Risk

Would You Like a More Detailed Audit of MUSWORLD?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit