Quantum Audit Logo

Is Monkey a Scam?

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

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

Monkey MONKEY
0x4ac8…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and pool state management. The audit identified critical upgradeability flaws due to the incorrect use of immutable variables in an upgradeable context, and a significant portion of the core tax processing logic (`_processTax`) was truncated, preventing a full security assessment. Additionally, high-severity centralization risks and potential denial-of-service vectors were found. The contract demonstrates good practices in some areas, such as efficient struct packing and the use of OpenZeppelin upgradeable standards, but these are overshadowed by the critical issues.

2 Critical2 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$26.0600
Liquidity
$14.3K
Price
$0.00001993
Token Age
2d
Top 10 Holders
91.2%

Security Findings

2 Crit2 High1 Med1 Low1 Info
Critical

Immutable Variables in Upgradeable Contract

C-01The `FlapTaxTokenV3` contract declares `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` as `immutable` variables. In an upgradeable contract using a proxy pattern (like UUPS), the constructor of the implementation contract is only called once upon its initial deployment, not when the proxy is initialized or upgraded. Consequently, these `immutable` variables will always read as their default value (zero) when accessed through the proxy, leading to incorrect contract behavior and a fundamental design flaw for the token's core logic.
IssueThe `FlapTaxTokenV3` contract declares `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` as `immutable` variables. In an upgradeable contract using a proxy pattern (like UUPS), the constructor of the implementation contract is only called once upon its initial deployment, not when the proxy is initialized or upgraded. Consequently, these `immutable` variables will always read as their default value (zero) when accessed through the proxy, leading to incorrect contract behavior and a fundamental design flaw for the token's core logic.
FixRemove the `immutable` keyword from `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD`. Instead, declare them as regular state variables and initialize their values within the `initialize` function. This ensures they are correctly set in the proxy's storage during deployment and accessible as intended.
StatusUnresolved
Critical

Incomplete `_processTax` Logic and External Call Risks

C-02The `_processTax` function, which is invoked within `_liquidateTax` to handle collected taxes, is truncated in the provided source code. This function is critical as it likely involves external calls to `taxProcessor` and `dividendContract`. Without its full implementation, it is impossible to assess potential reentrancy vulnerabilities, gas limit issues, or other external call risks that could lead to loss of funds, incorrect tax distribution, or denial of service. The reentrancy guard (`notLiquidating`) around the call is noted, but the external call's internal logic remains unknown.
IssueThe `_processTax` function, which is invoked within `_liquidateTax` to handle collected taxes, is truncated in the provided source code. This function is critical as it likely involves external calls to `taxProcessor` and `dividendContract`. Without its full implementation, it is impossible to assess potential reentrancy vulnerabilities, gas limit issues, or other external call risks that could lead to loss of funds, incorrect tax distribution, or denial of service. The reentrancy guard (`notLiquidating`) around the call is noted, but the external call's internal logic remains unknown.
FixProvide the complete and verified source code for the `_processTax` function and any related external contracts (`ITaxProcessor`, `IDividend`). A thorough review of this critical component is essential to ensure proper security, reentrancy protection, and correct handling of funds.
StatusUnresolved
High

Centralized Control over Pool State Transitions

H-01The `startMigration` and `finalizeMigration` functions, which control critical transitions between pool states (e.g., from `BondingCurve` to `Migrating`, and `Migrating` to `TaxEnforcedAntiFarmer`), are restricted to `onlyOwner`. This grants the contract owner sole authority over these significant operational changes. A compromised or malicious owner could unilaterally alter the token's behavior, potentially enabling or disabling taxes, or changing transfer restrictions, without community consensus.
IssueThe `startMigration` and `finalizeMigration` functions, which control critical transitions between pool states (e.g., from `BondingCurve` to `Migrating`, and `Migrating` to `TaxEnforcedAntiFarmer`), are restricted to `onlyOwner`. This grants the contract owner sole authority over these significant operational changes. A compromised or malicious owner could unilaterally alter the token's behavior, potentially enabling or disabling taxes, or changing transfer restrictions, without community consensus.
FixConsider implementing a more decentralized governance mechanism for critical state transitions. This could involve a multi-signature wallet, a time-locked governance contract, or a community-driven voting system. If centralized control is intended, ensure robust operational security for the owner's private key.
StatusUnresolved
High

Denial of Service via `_processTax` Revert

H-02The `_liquidateTax` function is called at the beginning of every `_transfer` operation where the `to` address is the `mainPool`. If the external call within the (truncated) `_processTax` function reverts for any reason (e.g., insufficient gas, external contract error, or malicious reentrancy attempt that causes a revert), the entire `_transfer` transaction will revert. This could lead to a denial of service, preventing users from transferring tokens to the `mainPool` and potentially disrupting liquidity provision or other core functionalities.
IssueThe `_liquidateTax` function is called at the beginning of every `_transfer` operation where the `to` address is the `mainPool`. If the external call within the (truncated) `_processTax` function reverts for any reason (e.g., insufficient gas, external contract error, or malicious reentrancy attempt that causes a revert), the entire `_transfer` transaction will revert. This could lead to a denial of service, preventing users from transferring tokens to the `mainPool` and potentially disrupting liquidity provision or other core functionalities.
FixImplement robust error handling for the `_processTax` function. Consider using a `try-catch` block for external calls to gracefully handle reverts without blocking the main `_transfer` functionality. Alternatively, design `_processTax` to be pull-based or to use a separate, non-blocking mechanism for tax distribution, ensuring that `_transfer` remains resilient.
StatusUnresolved
Medium

Unused State Variables

M-01The state variables `liqExpectedOutputAmount`, `initialLiquidationThreshold`, and `MIN_LIQ_THRESHOLD` are declared and initialized but are not referenced or utilized anywhere in the provided contract logic. While `MIN_LIQ_THRESHOLD` is also affected by the immutable variable issue (C-01), its general lack of use suggests either incomplete development, dead code, or a potential misunderstanding of the contract's intended functionality. This can lead to confusion, increased complexity, and wasted storage.
IssueThe state variables `liqExpectedOutputAmount`, `initialLiquidationThreshold`, and `MIN_LIQ_THRESHOLD` are declared and initialized but are not referenced or utilized anywhere in the provided contract logic. While `MIN_LIQ_THRESHOLD` is also affected by the immutable variable issue (C-01), its general lack of use suggests either incomplete development, dead code, or a potential misunderstanding of the contract's intended functionality. This can lead to confusion, increased complexity, and wasted storage.
FixReview the contract's design to determine if these variables are truly necessary. If they are intended for future functionality, add comments explaining their purpose. If they are not needed, remove them to reduce contract size, complexity, and gas costs associated with storage. Ensure all critical parameters are actively used in the contract's logic.
StatusUnresolved
Low

Reliance on `block.timestamp` for Critical Expiration

L-01The contract relies on `block.timestamp` for checking `taxExpirationTime` and `antiFarmerExpirationTime`. While `block.timestamp` is commonly used for time-based logic, miners have a limited ability to manipulate its value (up to 900 seconds on Ethereum, typically less on other EVM chains like BSC). For critical, short-duration events, this manipulation could potentially be exploited by miners to front-run or delay state transitions, although the impact on long-term expiration times is generally minimal.
IssueThe contract relies on `block.timestamp` for checking `taxExpirationTime` and `antiFarmerExpirationTime`. While `block.timestamp` is commonly used for time-based logic, miners have a limited ability to manipulate its value (up to 900 seconds on Ethereum, typically less on other EVM chains like BSC). For critical, short-duration events, this manipulation could potentially be exploited by miners to front-run or delay state transitions, although the impact on long-term expiration times is generally minimal.
FixFor time-sensitive operations where miner manipulation could have a significant impact, consider using alternative time sources or mechanisms that are less susceptible to manipulation, such as a decentralized oracle for time. For expiration times spanning days or longer, `block.timestamp` is generally acceptable, but developers should be aware of its limitations.
StatusUnresolved
Info

Efficient Struct Packing

I-01The `PackedPoolState` struct is designed efficiently by carefully ordering and sizing its member variables (`uint8`, `uint16`, `uint16`, `bool`, `uint96`, `uint64`, `uint48`). The total bit size (256 bits) allows the entire struct to fit within a single storage slot. This optimization reduces gas costs associated with reading and writing the struct to storage, demonstrating good Solidity development practices.
IssueThe `PackedPoolState` struct is designed efficiently by carefully ordering and sizing its member variables (`uint8`, `uint16`, `uint16`, `bool`, `uint96`, `uint64`, `uint48`). The total bit size (256 bits) allows the entire struct to fit within a single storage slot. This optimization reduces gas costs associated with reading and writing the struct to storage, demonstrating good Solidity development practices.
FixMaintain this practice for future struct definitions to ensure optimal gas efficiency.
StatusResolved

Category Ratings

TechnicalHigh3/10

The technical architecture leverages OpenZeppelin's upgradeable ERC20 and access control patterns (7.1 Architecture). However, a critical flaw exists with immutable variables in the upgradeable context, rendering them unusable (7.7 Upgrades). The core tax processing logic (`_processTax`) is incomplete, preventing a full assessment of reentrancy and external call risks (7.2 Code Security). A reentrancy guard is present in `_liquidateTax`, but the overall security of external interactions cannot be confirmed. A potential denial-of-service vector exists if `_processTax` reverts (7.8 Operations).

GovernanceHigh2/10

The contract's economic model includes dynamic buy/sell taxes and an anti-farmer mechanism, managed through various pool states (7.4 Economic). Critical state transitions, such as `startMigration` and `finalizeMigration`, are controlled solely by the contract owner (7.5 Governance), introducing a high degree of centralization. This centralized control could allow a compromised owner to manipulate the token's economic parameters. The tax collection and liquidation mechanism is central to the token's economy, but its full implementation is missing (7.4 Economic).

UpgradesHigh3/10

The contract is designed to be upgradeable using OpenZeppelin's UUPS proxy pattern, indicated by `Initializable` and `_disableInitializers()` (7.7 Upgrades). However, the use of `immutable` variables (`MIN_LIQ_THRESHOLD`, `START_LIQ_THRESHOLD`) is fundamentally incompatible with this pattern. These variables are initialized in the implementation's constructor, which is not called when interacting via the proxy, causing them to always read as zero. This critical flaw undermines the intended functionality and upgrade safety of the contract (7.7 Upgrades).

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

91.2% in top 10
52.4% in wallets38.8% in contracts
Effective Concentration67.9%

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

$14.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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0x0d98…bd6f

What Raised This Score

9 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 50% (91.2% total → 67.9% effective; 52.4% in EOAs, 38.8% in contracts — heavy)
  • Liquidity < $50k ($14,317 across 1 pairs — thin market)
  • Token age < 7 days (early, volatile)
  • 2 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 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
MonkeyCritical RiskInvesqo QQQ (QQQB)Critical RiskWIKI CAT (WKC)Critical RiskTether Gold (XAUT)Critical RiskETHGas (GWEI)Critical RiskBlock Street (BSB)Critical Risk

Would You Like a More Detailed Audit of Monkey?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit