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.

On-chain security analysis — is it a scam or legit?
Is Momentum Safe?
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 →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- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking94.3%
- Walletsanonymous holders, free to sell1.7%
- Everyone elsethe rest of the supply4.0%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x0ed9…9706No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighOracle 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
MediumMissing 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
nonReentrant Modifier on Critical FunctionsIssue
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
MediumInefficient 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
executeBondLiquidity LogicIssue
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
LowInsufficient 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
executeBondLiquidityIssue
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
InfoCentralization 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
InfoHardcoded 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
launchTimeIssue
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 4The 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.
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).
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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