Quantum Audit Logo

Is Momentum Safe?

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

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

Momentum MNTM
0x05ae…b455
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive 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. 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.

1 High2 Medium1 Low2 Informational
Volume 24h
$613.1K
Liquidity
$911.8K
Price
$2.0420
Token Age
15d
Top 10 Holders
96.0%

Security Findings

1 High2 Med1 Low2 Info
High

Oracle Manipulation Risk from Spot Price

H-01The `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).
IssueThe `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).
FixImplement 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.
StatusUnresolved
Medium

Missing `nonReentrant` Modifier on Critical Functions

M-01While 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.
IssueWhile 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.
FixApply 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 { ... }`.
StatusUnresolved
Medium

Inefficient and Complex `executeBondLiquidity` Logic

M-02The `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).
IssueThe `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).
FixOptimize 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.
StatusUnresolved
Low

Insufficient Slippage Protection in `executeBondLiquidity`

L-01In 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).
IssueIn 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).
FixImplement 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.
StatusUnresolved
Info

Centralization Risk with Privileged Roles

I-01The `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…
IssueThe `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…
FixConsider 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.
StatusUnresolved
Info

Hardcoded `launchTime`

I-02The `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).
IssueThe `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).
FixFor 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.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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.

GovernanceLow8/10

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

UpgradesLow10/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.1%

Holder Composition

96.0% in top 10
1.7% in wallets94.3% in contracts
Effective Concentration39.5%

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

$911.8K

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

LP Burned99.9% · ≈ permanent lock
LP Locked99.9% · Null Address

Key Addresses

2 addresses
Deployer
0xf592…550c
Unlocked LP Held By
0x0ed9…9706

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

What Raised This Score

5 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

Related Audits

6 more on the record
BroccoliLow RiskBanana For Scale (BANANAS31)Low RiskWorld of Dypians (WOD)Low RiskTagger (TAG)Low RiskSmart Solve Token (SST)Low RiskCubus Store Coin (CSC)Low Risk

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