CZHY (CZHY) security report
Radar AI scanned the verified CZHY contract on BNB Smart Chain. No Critical or High findings were established. Medium findings cover transfer-blocking dividend callbacks, owner-controlled migration states, and unchecked tax-rate initialization.
No Critical or High findings were established from the supplied source and GoPlus evidence. Three Medium findings were identified. The main operational risk is that dividendContract.setShare() is called during transfers and any failure reverts the transfer. The owner also controls migration timing, while initialization accepts tax rates above 10000 basis points.
Trust score: 62/100. Source verified: Yes. Chain: bsc. Contract: 0xf5ccda43eddb03f9e03b9f332b79ee78da1c7777.
This report was last modified on 2026-10-10 and contains 3 material findings.
medium finding: Dividend callback can block token transfers
When dividendContract is configured, ordinary transfers call IDividend.setShare() for the sender and recipient. Any callback failure is caught and rethrown as DividendShareUpdateFailed, causing the entire token transfer to revert. A failing, unavailable, or incompatible dividend contract can therefore prevent transfers for affected addresses.
Evidence: In _afterTokenTransfer(), calls to IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) are wrapped in try/catch blocks that revert with DividendShareUpdateFailed on failure. These hooks execute from the ERC20 _transfer path.
Recommendation: Use a non-blocking dividend update design, isolate share updates from transfers, or provide a recovery mechanism to disable or replace a failing dividend integration. Test behavior when the dividend contract reverts, runs out of gas, or is misconfigured.
medium finding: Owner controls migration states and tax enforcement timing
The owner can start and finalize migration, while the contract does not provide an autonomous transition or public validation of the migration schedule. During Migrating, transfers involving pools are allowed without tax. The owner can also delay migration or leave the contract in a state that changes transfer and tax behavior materially.
Evidence: startMigration() and finalizeMigration() are both external onlyOwner functions. _transfer() permits plain transfers in the Migrating state and only applies pool taxes in TaxEnforcedAntiFarmer or TaxEnforced states. The supplied GoPlus evidence identifies the owner address as 0xe2ce6ab80874fa9fa2aae65d277dd6b8e65c9de0.
Recommendation: Use an explicitly bounded and auditable migration process, enforce expected state-transition conditions, and disclose the owner’s ability to control migration timing. Consider timelocks or governance controls for operationally significant transitions.
medium finding: Initialization accepts tax rates above the valid basis-point range
The initializer accepts uint16 buyTax and sellTax values without requiring them to be at most 10000 basis points. If a configured rate exceeds 10000, the calculated tax can exceed the transfer amount and amount - tax reverts, potentially blocking taxed buys or sells while that tax state is active.
Evidence: initialize() stores params.buyTax and params.sellTax directly in poolState. _getTaxWithPoolState() calculates amount * taxRate / 10000, and _taxedTransfer() then performs uint256 remainingAmount = amount - tax without a rate cap or explicit validation.
Recommendation: Require buyTax and sellTax to be less than or equal to 10000 during initialization, and add tests covering zero, boundary, and excessive tax values before deployment.