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

Is CZBURN a Scam?

CBURN

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 · 22h old

Chart

44/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical8/10 Governance5/10 Upgrades5/10 Checks passed4 of 5 Findings1 High · 2 Medium · 1 Low · 2 Info6

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 > 30%
Liquidity < $50k
Token age < 24h
1 High finding(s) from audit
2 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 > 30% (98.9% total → 42.2% effective; 4.3% in EOAs, 94.5% in contracts — moderate)
Liquidity < $50k ($33,815 across 1 pairs — thin market)
Token age < 24h (brand new — bot activity, unproven)
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

Early-stage analysis. This token has limited on-chain history (22h 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

98.9%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking94.5%
Walletsanonymous holders, free to sell4.3%
Everyone elsethe rest of the supply1.1%

Effective concentrationwhat the score reads42.2%

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

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$33.8KShare of depth100.0%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Security Findings

1 High2 Medium1 Low2 Info

High

Reentrancy Vulnerability in `_liquidateTax`

The _liquidateTax function modifies poolState.notLiquidating to false, then makes an external call to _processTax(taxAmount), and only after the external call, resets poolState.notLiquidating to true. If the taxProcessor contract is malicious or compromised, it could re-enter the _transfer function (which calls _liquidateTax) while notLiquidating is still false. This could lead to _processTax being called multiple times with the same taxAmount, potentially draining the contract's tax balance or causing incorrect state transitions and economic manipulation.H-01

Issue

Fix

Implement a reentrancy guard (e.g., OpenZeppelin's ReentrancyGuard) on the _liquidateTax function or ensure that all state changes (effects) are completed before any external calls (interactions). Specifically, set poolState.notLiquidating to true immediately after the _processTax call, or consider moving the external call to _processTax to a separate, owner-triggered function if it doesn't strictly need to happen within the same transaction as a transfer.

Status

Unresolved

Medium

Potential Denial of Service for Transfers to `mainPool`

The _liquidateTax function is called on every transfer to the mainPool. This function includes an external call to _processTax on the taxProcessor contract. If the _processTax call reverts for any reason (e.g., taxProcessor is paused, buggy, or runs out of gas), the entire _transfer transaction will revert. This could prevent all transfers to the mainPool, effectively halting a critical part of the token's functionality and causing a denial of service for users attempting to interact with the main liquidity pool.M-01

Issue

Fix

Implement robust error handling for the external call to _processTax. Consider wrapping the call in a try/catch block to gracefully handle failures. In case of a revert, the contract could log the error and allow the transfer to proceed without tax processing, or temporarily disable tax processing until the issue with taxProcessor is resolved. Additionally, provide an owner-controlled mechanism to update or pause the taxProcessor address.

Status

Unresolved

Medium

Unused State Variables and Parameters

Several state variables are initialized but not used within the provided contract code. Specifically, liqExpectedOutputAmount, v2Router, quoteToken, and dividendContract are set during initialization but do not appear to be referenced in any of the contract's functions. While these might be intended for external interaction or future functionality, their current unused status can indicate incomplete design, potential for future integration issues, or simply dead code, increasing contract complexity unnecessarily.M-02

Issue

Fix

Review the contract's design to ensure all state variables serve a clear purpose within the contract or are explicitly documented as external dependencies. Remove any truly unused variables to reduce contract size, improve readability, and minimize potential attack surface. If they are intended for future use, consider adding placeholder functions or comments to indicate their purpose.

Status

Unresolved

Low

Hardcoded `maxSupply` and Tax Rate Divisor

The maxSupply is declared as a constant 1e9 ether, fixing the total token supply permanently. While this might be an intentional design choice, it removes any flexibility for future adjustments to the token's supply cap. Similarly, tax rates are consistently divided by 10000 ((amount * rate) / 10000), implying a fixed basis point precision for tax calculations. This hardcoded divisor means that changing the precision of tax rates would require a contract upgrade.L-01

Issue

Fix

Clearly document the implications of a fixed maxSupply for the token's economic model. For the tax rate divisor, consider making it a configurable parameter (e.g., TAX_RATE_DENOMINATOR) if future flexibility in tax precision is desired. If not, ensure the current precision is well-understood and accepted by the protocol's stakeholders.

Status

Unresolved

Info

Insufficient Event Emission for Critical State Changes

The contract emits PoolStateChanged when the state enum changes. However, other critical economic parameters and internal states that can be modified within _liquidateTax are not accompanied by event emissions. Specifically, changes to poolState.liquidationThreshold, poolState.taxExpirationTime, poolState.buyTaxRate, poolState.sellTaxRate (when state becomes TaxFree), and poolState.notLiquidating are not explicitly logged. This lack of events makes it challenging for off-chain monitoring, analytics, and user interfaces to accurately track the token's real-time economic parameters.I-01

Issue

Fix

Emit events for all significant state changes, especially those affecting economic parameters or internal flags that influence core logic. This includes liquidationThreshold, taxExpirationTime, buyTaxRate, sellTaxRate, and notLiquidating. Comprehensive event logging enhances transparency, auditability, and allows for more robust off-chain integration.

Status

Unresolved

Info

Potential Truncation in `antiFarmerExpirationTime` Type Casting

The antiFarmerExpirationTime variable is declared as uint48. It is set by casting block.timestamp + antiFarmerDuration (both uint256) to uint48. While block.timestamp is unlikely to exceed 2^48 - 1 in the foreseeable future (approximately 8.9 million years), if antiFarmerDuration is set to an extremely large value, or if the contract remains active for an exceptionally long period, the sum block.timestamp + antiFarmerDuration could exceed the maximum value of uint48. This would result in silent truncation of the value, leading to an incorrect expiration time.I-02

Issue

Fix

Ensure that the combined value of block.timestamp and antiFarmerDuration will not exceed uint48 maximum. Consider adding a require check during initialization or when antiFarmerDuration is set to prevent values that would lead to truncation. Alternatively, use a larger integer type (e.g., uint64) for antiFarmerExpirationTime if there's a possibility of very long durations or contract longevity.

Status

Unresolved

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 a high-severity reentrancy vulnerability in the tax liquidation process, which could lead to unintended fund manipulation or state corruption. Additionally, potential denial of service for transfers to the main pool and several medium to informational findings were noted. The contract utilizes OpenZeppelin's upgradeable patterns correctly, demonstrating a solid architectural foundation for upgradeability.

Technical8/10Low risk

The contract leverages OpenZeppelin's upgradeable ERC20 and Ownable patterns, contributing to a robust architectural foundation (7.1 Architecture). However, a significant reentrancy vulnerability was identified in the _liquidateTax function due to an external call to _processTax before state updates, posing a risk to code security (7.2 Code Security). Access control (7.3 Access Control) is appropriately managed with onlyOwner for critical state transitions like migration. The use of SafeERC20 is a positive security practice.

Governance5/10Medium risk

The economic model (7.4 Economic) involves dynamic tax rates and liquidation thresholds, which are managed through state transitions. A potential denial of service exists for transfers to the mainPool if the external taxProcessor call reverts, impacting operations (7.8 Operations). Governance (7.5 Governance) is centralized with an Owner role for critical state changes, which is typical for initial phases but could evolve. Hardcoded maxSupply and tax rate divisor limit future economic flexibility.

Upgrades5/10Medium risk

The contract is designed as an upgradeable proxy using OpenZeppelin's Initializable and Upgradeable patterns (7.7 Upgrades). The _disableInitializers() call in the constructor and the use of the initializer modifier are correctly implemented, ensuring proper initialization in the proxy environment. This setup allows for future enhancements and bug fixes without redeploying the entire system, provided upgrade safety best practices are followed during implementation of new versions.

Final RecommendationWhat to do about this score

Address the high-severity reentrancy vulnerability by implementing a reentrancy guard or strictly adhering to the Checks-Effects-Interactions pattern in the _liquidateTax function.

Mitigate the denial of service risk for mainPool transfers by adding robust error handling for external calls to taxProcessor, potentially allowing transfers to proceed without tax processing in case of external failures. Review and either utilize or remove all unused state variables to improve code clarity and reduce potential for future issues.

Contract & Record

1 audit on record

TypeFlapTaxTokenV3

NetworkBNB Chain

Token age22h

Contract0x3094…7777

Deployer0xdc04…086d

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, 202644Medium
Aug 12, 202636Medium

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

Frequently Asked Questions

What is the CBURN contract address?

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