查尔斯国王 (Charles) security report
Radar AI scanned the verified 查尔斯国王 (Charles) smart contract on BNB Smart Chain. Slither was not run. Material findings include a conditional high-severity uninitialized-clone takeover risk, plus medium-severity transfer-blocking and tax-processor dependency risks.
The source does not show owner-controlled minting, blacklist logic, proxy upgrade functions, or configurable transfer taxes after initialization. However, deployment must atomically initialize the token, and the configured dividend and tax-processing contracts must be trusted and operational. GoPlus reports zero buy, sell, and transfer tax, no proxy, no mintable flag, no blacklist flag, and a zero owner address; these signals do not remove the source-level initialization and external-dependency risks.
Trust score: 58/100. Source verified: Yes. Chain: bsc. Contract: 0xb456f3ac7e234acb008836b01c009f4ea8227777.
This report was last modified on 2026-10-13 and contains 3 material findings.
high finding: Uninitialized clone can be claimed and fully configured by the first caller
The external initialize function is protected only by the one-time initializer guard and has no deployer or launcher authorization. If a proxy or clone is deployed without an atomic initialization call, any caller can initialize it, become the owner, choose the pools and external dependencies, and receive the entire maxSupply through _mint(msg.sender, maxSupply).
Evidence: FlapTaxTokenV3.initialize(InitParams memory params) is external and uses initializer without an access-control check. It calls __Ownable_init(), which makes the caller the owner, and then executes _mint(msg.sender, maxSupply). The function also accepts tax rates, taxProcessor, dividendContract, pools, and router addresses from the caller. Initializable.sol warns that an uninitialized proxy can be taken over.
Recommendation: Initialize the proxy or clone atomically during deployment and verify the Initialized event and owner immediately afterward. Factory code should reject deployments whose initialization transaction was not executed successfully, and operators should verify that the initialized parameters match the intended token configuration.
medium finding: Configured dividend contract can block token transfers
After initialization, transfers involving ordinary addresses synchronously call the configured dividend contract twice. If either setShare call reverts, the entire token transfer reverts. A misconfigured, incompatible, unavailable, or intentionally reverting dividend contract can therefore prevent affected transfers.
Evidence: _afterTokenTransfer calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) unless the address is exempt. Each call is wrapped in try/catch, but the catch executes revert DividendShareUpdateFailed(...). dividendContract is assigned in initialize and there is no public setter to replace it.
Recommendation: Use a well-tested dividend implementation with bounded gas and non-reverting share updates, or isolate dividend accounting from ERC20 transfer success. Add an operational recovery mechanism that can disable or replace a failed dividend dependency under tightly governed access control.
medium finding: External tax processor controls tax handling and receives a broad failure fallback
Collected tax tokens are approved to the configured taxProcessor and processed through an external call. If that call fails, the token contract transfers its entire token balance to taxProcessor rather than retaining or safely isolating the funds. This creates a material dependency and custody risk tied to the processor configuration and behavior.
Evidence: _processTax approves taxProcessor for type(uint256).max when needed and calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount). In the catch branch, it reads balanceOf(address(this)) and calls _plainTransfer(address(this), taxProcessor, remainingBalance), which transfers all token balance held by the token contract to the processor. taxProcessor is set during initialize and has no setter in FlapTaxTokenV3.
Recommendation: Minimize approvals, transfer only the intended tax amount, and define a recovery path that does not send unrelated token balances to the processor. Validate the processor implementation and permissions before initialization, and monitor processor failures and token balances.