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

Is MOMO a Scam?

Ethereum

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 recordNew Launch · 4d old

Chart

47/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical8/10 Governance1/10 Upgrades6/10 Checks passed3 of 5 Findings1 Low · 2 Info3

SummaryAI Copilot

The MomoToken contract is a standard ERC20 token implementation, inheriting from OpenZeppelin's ERC20, ERC20Burnable, and ERC20Permit contracts.

Read the full analysis

What raised the score

Ownership status UNKNOWN
Top-10 concentration > 30%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k
LP top1 unlocked holder = 99.3%
LP top3 unlocked holders = 100.0%
Token age < 7 days
1 Low finding(s) from audit

Exact 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

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.

Security Checklist

as of audit · Sep 43 of 5 checks passed

Contract verifiedVerified

OwnershipUnknown

MintNo mint

Liquidity lockNot locked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

83.4%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking64.4%
Walletsanonymous holders, free to sell19.0%
Everyone elsethe rest of the supply16.6%

Effective concentrationwhat the score reads44.7%

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$47.3K

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$47.3KShare of depth100.0%

Top-1 Unlocked Holder99.3%

Top-3 Unlocked100.0%

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.

Security Findings

1 Low2 Info

Low

Unused State Variable `_PERMIT_TYPEHASH_DEPRECATED_SLOT`

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

Issue

Fix

Remove the unused state variable _PERMIT_TYPEHASH_DEPRECATED_SLOT to improve code clarity and slightly reduce contract deployment size.

Status

Unresolved

Info

Use of Draft ERC Standard

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

Issue

Fix

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

Status

Unresolved

Info

Fixed Supply and No Central Control

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

Issue

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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.

Governance1/10High risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to ensure the initialRecipient address provided during deployment is correct and secure, as all initial tokens will be minted to this address.

Given the contract's immutable nature, any errors in the constructor parameters cannot be rectified post-deployment. For future developments, consider the implications of using draft standards like ERC20Permit and monitor their evolution.

Contract & Record

1 audit on record

TypeMomoToken

NetworkEthereum

Token age4d

Contract0x664e…6e81

Deployer0x0371…0b60

Badge for your website

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

Sep 4, 202647Medium
Aug 11, 202641Medium

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

Frequently Asked Questions

What is the MOMO contract address?

The MOMO contract on Ethereum is 0x664e9d73db2a3514f6b437137de4779977a06e81. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.