Binancat (Binancat) security report
Binancat was AI scanned through an independent Solidity source review and supplied GoPlus evidence. GoPlus found no honeypot, minting, blacklist, pause, or proxy signals. Material risks remain around uninitialized clone takeover, owner-controlled migration, uncapped initialization tax rates, and external dividend and tax-processor callbacks. Slither was not run.
The supplied evidence does not prove a honeypot or direct theft path. However, users face meaningful conditional risks: an uninitialized clone can be seized, an ownerless contract may be unable to complete migration, initialization can configure trading-breaking taxes, and the configured dividend contract can make ordinary transfers revert.
Trust score: 55/100. Source verified: Yes. Chain: bsc. Contract: 0x366298a43da785e53a30d2a5f4fee97b75467777.
This report was last modified on 2026-09-26 and contains 5 material findings.
high finding: Owner-controlled migration can keep pool trading restricted or leave migration incomplete
The owner exclusively controls startMigration and finalizeMigration. In BondingCurve state, transfers involving any configured pool revert. If the owner does not start and finalize migration, pool trading remains restricted. If ownership is renounced during BondingCurve or Migrating, no account can call the required transition functions, potentially leaving the pool permanently unusable.
Evidence: _transfer requires !pools[from] && !pools[to] in PoolState.BondingCurve. Both startMigration() and finalizeMigration() are onlyOwner.
Recommendation: Verify the live state(), poolState(), and migration events. Use an automated, permissionless or timelocked migration path where possible, and do not renounce ownership until migration is finalized and independently verified.
high finding: Initialization accepts tax rates that can make buying or selling revert
Buy and sell tax values are accepted as uint16 values without a maximum of 10000 basis points. A rate above 10000 causes _taxedTransfer to calculate a tax greater than amount and revert on amount - tax; a 10000 rate transfers zero tokens to the user or pool. This can create a trading lock or severe loss depending on the initialization parameters.
Evidence: initialize stores params.buyTax and params.sellTax directly in poolState. _getTaxWithPoolState computes amount * rate / 10000, while _taxedTransfer executes uint256 remainingAmount = amount - tax without enforcing tax <= amount.
Recommendation: Require both tax parameters to be <= 10000 during initialization, publish the deployed values, and independently monitor buyTaxRate(), sellTaxRate(), and getPoolStateData() before trading.
medium finding: Dividend callback can block ordinary token transfers
When dividendContract is nonzero, every transfer involving a non-excluded sender or recipient synchronously calls dividendContract.setShare(). Any revert from that external call causes the entire token transfer to revert through DividendShareUpdateFailed. A broken, incompatible, or malicious dividend contract can therefore materially restrict transfers and integrations.
Evidence: _afterTokenTransfer calls IDividend(dividendContract).setShare(...) for both sides unless the address is the token contract, zero address, dead address, dividend contract, or a configured pool. Failed calls are caught and immediately reverted with DividendShareUpdateFailed.
Recommendation: Use a trusted, audited dividend contract, add a safe failure mode that cannot block ERC20 transfers, and provide an emergency mechanism to disable or replace the callback if the architecture permits.
medium finding: External tax processor controls handling of accumulated tax proceeds
The token grants the configured taxProcessor an unlimited allowance and calls it during liquidation. If processing reverts, the fallback transfers the entire token contract balance directly to taxProcessor. This is not an arbitrary-user exploit because the address is fixed at initialization, but a malicious or compromised processor can take accumulated tax tokens and can influence liquidation behavior.
Evidence: _processTax sets allowance(address(this), taxProcessor) to type(uint256).max, calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount), and on failure executes _plainTransfer(address(this), taxProcessor, remainingBalance). There is no setter to replace or revoke taxProcessor.
Recommendation: Use an audited immutable processor, restrict processor spending to the requested amount, avoid transferring the full balance on failure, and add transparent monitoring for allowance changes and tax-processor transfers.
medium finding: Tax liquidation and transfers depend on an external callback without a reentrancy guard
Transfers to mainPool can invoke _liquidateTax, which makes an external call to taxProcessor before the outer transfer completes. The notLiquidating flag limits repeated liquidation, but the processor can reenter other public token functions during the callback. This creates composability and state-ordering risk and should be reviewed together with the processor implementation.
Evidence: _transfer calls _liquidateTax(to) before completing the transfer. _liquidateTax sets poolState.notLiquidating to false and invokes ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) through an external call.
Recommendation: Add a dedicated reentrancy guard or rigorously enforce checks-effects-interactions around liquidation, and audit the concrete taxProcessor implementation for callbacks into the token and dependent contracts.