Quantum Audit Logo

Is MOMO a Scam?

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

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

MOMO MOMO
0xbc5f…4024
BNB Chain
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.Own this token? Put it under verification →
Last checked 10d ago 1 audit on record New Launch · 5d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The BrewToken contract is a standard ERC20 implementation inheriting from OpenZeppelin's battle-tested library. It includes immutable `creator` and `brewFactory` addresses and a fixed `metadataURI`. The contract's simplicity and reliance on well-audited components contribute to a low overall risk profile. No critical or high-severity vulnerabilities were identified.

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

Security Findings

1 Low3 Info
Low

Lack of Emergency Token Recovery

L-01The `BrewToken` contract does not include a function to recover arbitrary ERC20 tokens (other than BrewToken itself) that might be accidentally sent to the contract address. Such tokens would become permanently locked and inaccessible, leading to potential loss of funds if users or other contracts mistakenly send them.
IssueThe `BrewToken` contract does not include a function to recover arbitrary ERC20 tokens (other than BrewToken itself) that might be accidentally sent to the contract address. Such tokens would become permanently locked and inaccessible, leading to potential loss of funds if users or other contracts mistakenly send them.
FixImplement a `recoverERC20` function, callable by a trusted address (e.g., `creator` or a designated owner), to retrieve accidentally sent tokens. This enhances operational safety and prevents permanent loss of assets.
StatusUnresolved
Info

Unconventional `tokenURI()` in ERC20

I-01The `BrewToken` contract includes a `tokenURI()` function, which is typically associated with ERC721 or ERC1155 NFTs for retrieving token-specific metadata. While not a vulnerability, its presence in an ERC20 token might lead to confusion regarding the token's nature or expected functionality among users or integrators.
IssueThe `BrewToken` contract includes a `tokenURI()` function, which is typically associated with ERC721 or ERC1155 NFTs for retrieving token-specific metadata. While not a vulnerability, its presence in an ERC20 token might lead to confusion regarding the token's nature or expected functionality among users or integrators.
FixClarify the purpose of `tokenURI()` in documentation or consider if it's truly necessary for an ERC20 token. If it's intended for off-chain metadata, ensure the `metadataURI` is robust and its purpose is well-communicated.
StatusUnresolved
Info

Immutable `metadataURI`

I-02The `metadataURI` variable is set only during contract construction and cannot be modified thereafter. This design choice makes the token's metadata immutable. If there's a future need to update or change the metadata (e.g., due to broken links or evolving project branding), this contract design would prevent it without a redeployment.
IssueThe `metadataURI` variable is set only during contract construction and cannot be modified thereafter. This design choice makes the token's metadata immutable. If there's a future need to update or change the metadata (e.g., due to broken links or evolving project branding), this contract design would prevent it without a redeployment.
FixConfirm that the immutability of `metadataURI` aligns with the project's long-term requirements. If dynamic metadata is desired, a setter function with appropriate access control would be required in a future version or an upgradeable contract design.
StatusUnresolved
Info

Unused Immutable Variables

I-03The `creator` and `brewFactory` addresses are stored as immutable state variables but are not utilized in any access control mechanisms or special logic within the contract. They serve purely as informational fields, which might lead to questions about their practical purpose if not clearly documented.
IssueThe `creator` and `brewFactory` addresses are stored as immutable state variables but are not utilized in any access control mechanisms or special logic within the contract. They serve purely as informational fields, which might lead to questions about their practical purpose if not clearly documented.
FixDocument the intended purpose of these variables clearly. If they are meant to signify origin or a related entity, ensure this is communicated to users. If they were intended for access control, consider adding functions that leverage them.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is straightforward, implementing a standard ERC20 token with minimal custom logic. Code security (7.2) is robust due to the use of OpenZeppelin's ERC20 library, which handles common vulnerabilities like integer overflows safely. Access control (7.3) is limited to standard ERC20 permissions, with no additional privileged roles defined beyond the initial token minting. A minor point is the inclusion of a `tokenURI()` function, which is more common in NFT standards, potentially causing conceptual ambiguity.

GovernanceHigh2/10

The economic model (7.4) is a simple fixed-supply ERC20 token, minted entirely during deployment. There are no complex tokenomics, fees, or rebase mechanisms, which simplifies economic analysis and reduces attack surfaces. Governance (7.5) is non-existent within the contract itself, as there are no functions allowing for parameter changes or administrative actions post-deployment. The `creator` and `brewFactory` variables are immutable and do not confer any special economic or governance powers.

UpgradesMedium6/10

The contract is not designed to be upgradeable (7.7), as it does not implement any proxy patterns. This eliminates the risks associated with upgradeability, such as proxy misconfigurations or logic errors during upgrades. However, it also means that any future changes or bug fixes would require a new deployment and migration of assets, which could be a significant operational (7.8) undertaking.

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

33.6% in top 10
12.3% in wallets21.3% in contracts
Effective Concentration20.8%

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.1K across 3 pairs
Pancakeswap v3ZECanalysed$198.7K95.1%Pancakeswap v3WBNB$8.6K4.1%Pancakeswap v3USDT$1.7K0.8%

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

Key Addresses

2 addresses
Deployer
0x64f3…efd3
Unlocked LP Held By
0xd4b4…3c5f

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% (33.6% total → 20.8% effective; 12.3% in EOAs, 21.3% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% 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
Cets On Gold (CETS)Medium RiskXPIN Token (XPIN)Medium RiskTRADOORMedium RiskBeat Token (BEAT)Medium RiskNew BNB Coin (NNB)Medium RiskSpaceXcoinMedium Risk

Would You Like a More Detailed Audit of MOMO?

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

Get Detailed Audit