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
0x664e…6e81
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 4d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The MomoToken contract is a standard ERC20 token implementation, inheriting from OpenZeppelin's ERC20, ERC20Burnable, and ERC20Permit contracts. It features a fixed initial supply minted to a specified recipient during deployment. The contract exhibits a low overall risk profile due to its simplicity, reliance on battle-tested libraries, and lack of complex custom logic or privileged roles post-deployment. No critical or high-severity vulnerabilities were identified.

1 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (4d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$3.4K
Liquidity
$47.3K
Price
$0.0002444
Token Age
4d
Top 10 Holders
83.4%

Security Findings

1 Low2 Info
Low

Unused State Variable `_PERMIT_TYPEHASH_DEPRECATED_SLOT`

L-01The `ERC20Permit` contract declares a private state variable `bytes32 private _PERMIT_TYPEHASH_DEPRECATED_SLOT;` which is never assigned a value or used within the contract. This represents dead code and a minor inefficiency.
IssueThe `ERC20Permit` contract declares a private state variable `bytes32 private _PERMIT_TYPEHASH_DEPRECATED_SLOT;` which is never assigned a value or used within the contract. This represents dead code and a minor inefficiency.
FixRemove the unused state variable `_PERMIT_TYPEHASH_DEPRECATED_SLOT` to improve code clarity and slightly reduce contract deployment size.
StatusUnresolved
Info

Use of Draft ERC Standard

I-01The contract utilizes `ERC20Permit`, which is currently a 'draft' ERC standard (indicated by `draft-ERC20Permit.sol` in OpenZeppelin). While functional, draft standards are subject to change and may not be as widely adopted or battle-tested as finalized standards.
IssueThe contract utilizes `ERC20Permit`, which is currently a 'draft' ERC standard (indicated by `draft-ERC20Permit.sol` in OpenZeppelin). While functional, draft standards are subject to change and may not be as widely adopted or battle-tested as finalized standards.
FixBe aware that draft standards may evolve. Monitor the status of ERC20Permit and consider the implications if the standard undergoes significant changes in the future. For production systems, finalized standards are generally preferred.
StatusUnresolved
Info

Fixed Supply and No Central Control

I-02The MomoToken contract has a fixed `INITIAL_SUPPLY` minted entirely to a single recipient during construction. There are no owner-controlled minting, burning, pausing, or upgrade functionalities. This design ensures decentralization and predictability of the token supply.
IssueThe MomoToken contract has a fixed `INITIAL_SUPPLY` minted entirely to a single recipient during construction. There are no owner-controlled minting, burning, pausing, or upgrade functionalities. This design ensures decentralization and predictability of the token supply.
FixThis is a design choice that enhances decentralization and reduces governance risk. Ensure this aligns with the long-term vision for the token. No action is required if this is the intended design.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) of MomoToken is robust, leveraging OpenZeppelin's well-audited ERC20, ERC20Burnable, and ERC20Permit implementations. The custom logic is minimal, consisting solely of a constructor that mints a fixed initial supply to a specified address, with a zero-address check. Code security (7.2) is high, benefiting from OpenZeppelin's `unchecked` blocks used safely after boundary checks and the use of `constant` for `INITIAL_SUPPLY`. Access control (7.3) is decentralized, as there are no privileged roles or owner functions beyond standard ERC20 operations. External dependencies (7.6) are limited to OpenZeppelin, which are industry-standard. Operational aspects (7.8) are straightforward with no complex off-chain interactions.

GovernanceHigh1/10

The economic model (7.4) for MomoToken is simple and transparent: a fixed total supply is minted once at deployment, with no further inflation mechanisms. Deflation is possible only through standard ERC20 `burn` and `burnFrom` functions initiated by token holders. There are no centralized governance features (7.5) or privileged roles that could manipulate the token supply or transfer mechanisms post-deployment, ensuring a high degree of decentralization and predictability. This design minimizes economic and governance risks by removing single points of control.

UpgradesMedium6/10

The MomoToken contract is implemented as a standard, non-upgradeable contract. This design choice inherently eliminates all risks associated with upgrade mechanisms (7.7), such as proxy implementation vulnerabilities, upgrade pauses, or administrative key compromises. The contract's immutability ensures its logic remains constant after deployment, providing predictable behavior and reducing long-term operational complexity.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

83.4% in top 10
19.0% in wallets64.4% in contracts
Effective Concentration44.7%

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

$47.3K

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

Key Addresses

3 addresses
Deployer
0x0371…0b60
Unlocked LP Held By
0xe3b7…df740x1dc7…af25

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 > 30% (83.4% total → 44.7% effective; 19.0% in EOAs, 64.4% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($47,328 across 1 pairs — thin market)
  • LP top1 unlocked holder = 99.3% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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
Safe Token (SAFE)High RiskLQTYHigh RiskVestra DAO (VSTR)High RiskDog Food Token (OISHII)High RiskCapHigh Riskc8ntinuum (CTM)High 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