Is CZBURN (CBURN) a Scam? New Token Security Check

Security Findings

1 High2 Med1 Low2 Info

High

Reentrancy Vulnerability in `_liquidateTax`

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

IssueThe `_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.

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

StatusUnresolved

Medium

Potential Denial of Service for Transfers to `mainPool`

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

IssueThe `_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.

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

StatusUnresolved

Medium

Unused State Variables and Parameters

M-02Several 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.

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

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

StatusUnresolved

Low

Hardcoded `maxSupply` and Tax Rate Divisor

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

IssueThe `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.

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

StatusUnresolved

Info

Insufficient Event Emission for Critical State Changes

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

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

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

StatusUnresolved

Info

Potential Truncation in `antiFarmerExpirationTime` Type Casting

I-02The `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.

IssueThe `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.

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceMedium5/10

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.

UpgradesMedium5/10

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.

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

98.9% in top 10

4.3% in wallets94.5% in contracts

Effective Concentration42.2%

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

$33.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 Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

1 addresses

Deployer

0xdc04…086d

What Raised This Score

8 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

Is CZBURN a Scam?

Security Findings

Reentrancy Vulnerability in `_liquidateTax`

Potential Denial of Service for Transfers to `mainPool`

Unused State Variables and Parameters

Hardcoded `maxSupply` and Tax Rate Divisor

Insufficient Event Emission for Critical State Changes

Potential Truncation in `antiFarmerExpirationTime` Type Casting

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of CZBURN?