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

Is Monkey a Scam?

MONKEY

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

Chart

90/ 100

Critical RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical3/10 Governance2/10 Upgrades3/10 Checks passed4 of 5 Findings2 Critical · 2 High · 1 Medium · 1 Low · 1 Info7

SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and pool state management.

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Top-10 concentration > 50%
Liquidity < $50k
Token age < 7 days
2 Critical finding(s) from audit
2 High finding(s) from audit
1 Medium finding(s) from audit
1 Low finding(s) from audit

Exact 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

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.

Security Checklist

as of audit · Sep 44 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

91.2%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking38.8%
Walletsanonymous holders, free to sell52.4%
Everyone elsethe rest of the supply8.8%

Effective concentrationwhat the score reads67.9%

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

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$14.3KShare of depth100.0%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Security Findings

2 Critical2 High1 Medium1 Low1 Info

Critical

Immutable Variables in Upgradeable Contract

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

Issue

Fix

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

Status

Unresolved

Critical

Incomplete `_processTax` Logic and External Call Risks

The _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.C-02

Issue

Fix

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

Status

Unresolved

High

Centralized Control over Pool State Transitions

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

Issue

Fix

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

Status

Unresolved

High

Denial of Service via `_processTax` Revert

The _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.H-02

Issue

Fix

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

Status

Unresolved

Medium

Unused State Variables

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

Issue

Fix

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

Status

Unresolved

Low

Reliance on `block.timestamp` for Critical Expiration

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

Issue

Fix

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

Status

Unresolved

Info

Efficient Struct Packing

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

Issue

Fix

Maintain this practice for future struct definitions to ensure optimal gas efficiency.

Status

Resolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical3/10High risk

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

Governance2/10High risk

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

Upgrades3/10High risk

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

Final RecommendationWhat to do about this score

Address the critical upgradeability issue by removing immutable keywords from state variables in the upgradeable contract and managing their values through storage slots and initializer functions.

Provide the complete implementation of the _processTax function to allow for a thorough security review of its external interactions and reentrancy safeguards. Consider implementing a more decentralized governance mechanism for critical state transitions to mitigate centralization risks. Ensure robust error handling and gas considerations for all external calls to prevent denial-of-service scenarios.

Contract & Record

1 audit on record

TypeFlapTaxTokenV3

NetworkBNB Chain

Token age2d

Contract0x4ac8…7777

Deployer0x0d98…bd6f

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

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, 202690Critical
Aug 11, 202689Critical

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

Frequently Asked Questions

What is the MONKEY contract address?

The Monkey contract on BNB Chain is 0x4ac85f2a2d22956a15a95ebe142d442da35e7777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.