Quantum Audit Logo
Launch App

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

Is Momentum Safe?

MNTMBNB Chain
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
SummaryAI Copilot

The MomentumToken contract implements an ERC20 token with custom tax mechanics, a vesting system, and integrations with PancakeSwap for liquidity management and price discovery.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (96.0% total → 39.5% effective; 1.7% in EOAs, 94.3% in contracts — moderate)
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 2 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 46 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 5%

Holders

as of audit · Sep 4, 2026
94.3%Contracts4.0%
94.3%Contracts
ContractsWalletsEveryone elseBubble area = share of supply
96.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking94.3%
  • Walletsanonymous holders, free to sell1.7%
  • Everyone elsethe rest of the supply4.0%
Effective concentrationwhat the score reads39.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$911.8K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$911.8KShare of depth100.0%
LP Burned99.9% · ≈ permanent lock
LP Locked99.9% · Null Address
Unlocked LP held by
0x0ed9…9706

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

Security Findings

1 High2 Medium1 Low2 Info
High

Oracle Manipulation Risk from Spot Price

The livePrice() and calcAvgExecPrice() functions directly query the spot reserves from the PancakeSwap V2 pair (IPancakePair(pancakePair).getReserves()). Spot prices from AMMs are highly susceptible to manipulation via flash loans or large trades within a single block. An attacker could temporarily inflate or deflate the MNTM price to exploit functions that rely on these price feeds, potentially leading to incorrect calculations for executeBondLiquidity or other price-sensitive operations (7.4 Economic).H-01

Issue

The livePrice() and calcAvgExecPrice() functions directly query the spot reserves from the PancakeSwap V2 pair (IPancakePair(pancakePair).getReserves()). Spot prices from AMMs are highly susceptible to manipulation via flash loans or large trades within a single block. An attacker could temporarily inflate or deflate the MNTM price to exploit functions that rely on these price feeds, potentially leading to incorrect calculations for executeBondLiquidity or other price-sensitive operations (7.4 Economic).

Fix

Implement a more robust and decentralized price oracle solution. Consider using a Time-Weighted Average Price (TWAP) oracle from PancakeSwap V2 (if available and suitable for the required time window) or integrate with a decentralized oracle network like Chainlink. Ensure that any critical logic relying on token prices is resilient to short-term price fluctuations and manipulations.

Status

Unresolved

Medium

Missing nonReentrant Modifier on Critical Functions

While the contract inherits ReentrancyGuard, the nonReentrant modifier is not explicitly applied to the executeBondLiquidity function. This function performs multiple external calls to the PancakeRouter (swapExactTokensForTokens, addLiquidity) and transfers tokens (safeTransferFrom). Without the nonReentrant guard, a malicious contract could potentially re-enter the function during an external call, leading to unexpected state changes or double-spending (7.2 Code Security). Furthermore, if the truncated claimVesting function involves external token transfers, it would also be a critical candidate for this modifier.M-01

Issue

While the contract inherits ReentrancyGuard, the nonReentrant modifier is not explicitly applied to the executeBondLiquidity function. This function performs multiple external calls to the PancakeRouter (swapExactTokensForTokens, addLiquidity) and transfers tokens (safeTransferFrom). Without the nonReentrant guard, a malicious contract could potentially re-enter the function during an external call, leading to unexpected state changes or double-spending (7.2 Code Security). Furthermore, if the truncated claimVesting function involves external token transfers, it would also be a critical candidate for this modifier.

Fix

Apply the nonReentrant modifier to executeBondLiquidity and any other functions that perform external calls to untrusted contracts and modify the contract's state, especially those involving token transfers or value calculations. For example: function executeBondLiquidity(...) external nonReentrant { ... }.

Status

Unresolved

Medium

Inefficient and Complex executeBondLiquidity Logic

The executeBondLiquidity function's logic for swapping USDT to MNTM is inefficient. It first swaps USDT for MNTM, sending the MNTM to the logicContract, and then immediately transfers that MNTM from logicContract back to the MomentumToken contract using safeTransferFrom. This adds an unnecessary intermediate transfer, increases gas costs, and requires the logicContract to have approved the MomentumToken contract to spend its MNTM, introducing an additional point of failure (7.1 Architecture, 7.2 Code Security).M-02

Issue

The executeBondLiquidity function's logic for swapping USDT to MNTM is inefficient. It first swaps USDT for MNTM, sending the MNTM to the logicContract, and then immediately transfers that MNTM from logicContract back to the MomentumToken contract using safeTransferFrom. This adds an unnecessary intermediate transfer, increases gas costs, and requires the logicContract to have approved the MomentumToken contract to spend its MNTM, introducing an additional point of failure (7.1 Architecture, 7.2 Code Security).

Fix

Optimize the executeBondLiquidity function by having the PancakeRouter swap USDT directly to the MomentumToken contract's address instead of the logicContract. This eliminates the need for the intermediate safeTransferFrom and the associated approval, reducing complexity, gas costs, and potential failure points.

Status

Unresolved

Low

Insufficient Slippage Protection in executeBondLiquidity

In the executeBondLiquidity function, the swapExactTokensForTokens call uses minMNTMOut = 1. This value provides extremely minimal slippage protection. If market conditions change unfavorably or if the transaction is front-run, a significant portion of the half USDT could be exchanged for a much smaller amount of MNTM than expected, leading to value loss for the protocol (7.4 Economic).L-01

Issue

In the executeBondLiquidity function, the swapExactTokensForTokens call uses minMNTMOut = 1. This value provides extremely minimal slippage protection. If market conditions change unfavorably or if the transaction is front-run, a significant portion of the half USDT could be exchanged for a much smaller amount of MNTM than expected, leading to value loss for the protocol (7.4 Economic).

Fix

Implement a more robust slippage control mechanism. The logicContract (or the caller of executeBondLiquidity) should calculate and provide a reasonable minMNTMOut based on current market conditions and an acceptable slippage tolerance, rather than a fixed low value like 1. This would protect against unfavorable trade execution.

Status

Unresolved

Info

Centralization Risk with Privileged Roles

The owner role holds significant control over critical contract parameters, including setting the logicContract, pancakePair, taxWallet, projectWallet, and managing taxExempt addresses. The logicContract itself possesses powerful capabilities, such as minting new tokens and executing bond liquidity. While common for initial deployments, this centralization introduces a single point of failure; compromise of either the owner or logicContract address could lead to severe consequences for the protocol. If ownership has been renounced (as indicated by external data), the logicContract becomes the primary point of centralized control for ongoing operations, making its securit…I-01

Issue

The owner role holds significant control over critical contract parameters, including setting the logicContract, pancakePair, taxWallet, projectWallet, and managing taxExempt addresses. The logicContract itself possesses powerful capabilities, such as minting new tokens and executing bond liquidity. While common for initial deployments, this centralization introduces a single point of failure; compromise of either the owner or logicContract address could lead to severe consequences for the protocol. If ownership has been renounced (as indicated by external data), the logicContract becomes the primary point of centralized control for ongoing operations, making its securit…

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the owner and logicContract roles to distribute control and reduce the risk associated with a single compromised private key. For parameters that are intended to be immutable after initialization, ensure they can only be set once or are hardcoded.

Status

Unresolved

Info

Hardcoded launchTime

The launchTime is a hardcoded constant set in the constructor. While this ensures immutability, it removes any flexibility to adjust the launch schedule. In the event of unforeseen delays, market volatility, or critical issues discovered pre-launch, the contract's tax and trading restrictions tied to launchTime cannot be modified without redeployment (7.8 Operations).I-02

Issue

The launchTime is a hardcoded constant set in the constructor. While this ensures immutability, it removes any flexibility to adjust the launch schedule. In the event of unforeseen delays, market volatility, or critical issues discovered pre-launch, the contract's tax and trading restrictions tied to launchTime cannot be modified without redeployment (7.8 Operations).

Fix

For future deployments or similar contracts, consider making critical timestamps like launchTime configurable by the owner within a specific window, or through a governance mechanism, to allow for greater operational flexibility in response to real-world events. If immutability is the desired design, ensure thorough pre-launch testing and planning.

Status

Unresolved

Analysis

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

The MomentumToken contract implements an ERC20 token with custom tax mechanics, a vesting system, and integrations with PancakeSwap for liquidity management and price discovery. The contract utilizes OpenZeppelin libraries and includes a reentrancy guard. Key findings include a reliance on spot prices from PancakeSwap V2, which is susceptible to manipulation, and the absence of the nonReentrant modifier on critical functions involving external calls. Additionally, the executeBondLiquidity function exhibits inefficient token transfer logic. The audit was conducted on partial source code, specifically the vesting-related functions were truncated, limiting a full assessment of that module.

Technical9/10Low risk

The contract leverages OpenZeppelin's ERC20 and ReentrancyGuard for foundational security, and employs custom error types for clarity (7.2 Code Security). However, the reliance on PancakeSwap V2's spot price for livePrice() and calcAvgExecPrice() introduces a significant oracle manipulation risk (7.4 Economic). The nonReentrant modifier is not applied to executeBondLiquidity, which performs external calls, potentially exposing it to reentrancy (7.2 Code Security). The executeBondLiquidity function also uses an inefficient token transfer pattern, adding complexity and gas costs (7.1 Architecture). The vesting functions were truncated, preventing a complete security review of that module.

Governance8/10Low risk

The protocol's economic model includes a 5% sell tax on transfers to the PancakeSwap pair, directed to a taxWallet, which is a common tokenomic feature (7.4 Economic). Centralized control is significant, with the owner able to set critical parameters like logicContract and pancakePair, and the logicContract having powerful abilities such as token minting and executing bond liquidity (7.3 Access Control, 7.8 Operations). The launchTime is hardcoded, limiting flexibility for launch adjustments (7.8 Operations). The reliance on PancakeSwap V2 spot prices for internal calculations introduces a risk of economic manipulation (7.4 Economic).

Upgrades10/10Low risk

The MomentumToken contract is not designed as an upgradeable proxy (7.7 Upgrades). This means its core logic is immutable once deployed, eliminating risks associated with upgrade mechanisms but also removing the flexibility to fix bugs or introduce new features without a full redeployment and migration.

Final RecommendationWhat to do about this score

Prioritize addressing the oracle manipulation vulnerability by implementing a robust price oracle solution, such as a Time-Weighted Average Price (TWAP) or a decentralized oracle network, for any critical operations relying on token prices.

Ensure all functions performing external calls and modifying state are protected with the nonReentrant modifier. Review and optimize the executeBondLiquidity function's token transfer logic to enhance efficiency and reduce potential attack surface. Consider the implications of centralized control and implement multi-signature wallets for privileged roles to enhance security.

Contract & Record

1 audit on record
TypeMomentumToken
NetworkBNB Chain
Token age15d
Contract0x05ae…b455
Deployer0xf592…550c
Badge for your website
Momentum 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, 20268Low

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

Frequently Asked Questions

What is the MNTM contract address?

The Momentum (MNTM) contract on BNB Chain is 0x05ae9ac4878f18d9ae11f804079cfffd0844b455. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Momentum a scam?

Quantum Audit's risk score for Momentum is 8/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 5%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is MNTM liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $911.8K.

Who holds MNTM?

As of Sep 4, 2026, the 10 largest holders own 96.0% of the supply. The Holders section on this page shows who they are by holder type.

Would You Like a More Detailed Audit of Momentum?

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