zikeke (ZKK) security report
Radar AI scanned the verified zikeke (ZKK) contract on BNB Smart Chain. The review found a conditional uninitialized-clone takeover path, owner-controlled pool restrictions before normal mode, and external fee-processing dependencies that may revert transfers.
The source contains material conditional risks. An uninitialized clone can be claimed by the first caller through the public init function, and the owner can restrict transfers involving configured pools before normal mode is permanently enabled. No upgrade proxy or owner mint function was identified.
Trust score: 43/100. Source verified: Yes. Chain: bsc. Contract: 0x9f26d65b44438ec1a9ec85ea88737b04b31affff.
This report was last modified on 2026-10-08 and contains 4 material findings.
high finding: Uninitialized clones can be initialized by any caller
The clone initialization function is public and has no factory-only or owner-only access control. Any caller that reaches an uninitialized instance can supply initialization parameters, become the owner through _transferOwnership(msg.sender), and mint the configured total supply to that owner.
Evidence: Token9.sol defines function init(ITokenCreator9.InitParams memory a) public with no access modifier or caller check. FourToken._init requires only !_initialized, then executes _transferOwnership(msg.sender) and _mint(owner(), a.totalSupply). The risk requires an instance to remain uninitialized and externally callable.
Recommendation: Ensure clone deployment and initialization occur atomically, or restrict init to the authorized token-creator contract. Add an explicit initializer authorization check and test that an uninitialized clone cannot be claimed by an arbitrary address.
high finding: Owner-controlled pre-migration pool restrictions can block trading
Before normal mode is enabled, the owner can mark arbitrary addresses as migrated pools. Transfers involving a marked address revert, allowing the owner to block buys or sells through a configured pool while the token remains in a non-normal mode. The owner can also leave the token in a restricted mode indefinitely.
Evidence: FourToken.setMigratedPool and setMigratedPools are onlyOwner functions that control migratedPools. FourToken._beforeTokenTransfer calls _blocksBeforeMigration, which returns true when _mode is not MODE_NORMAL and either transfer endpoint is marked. FourToken._init sets _mode to MODE_TRANSFER_RESTRICTED, while setMode can change it only while it is not MODE_NORMAL.
Recommendation: Use an immutable or time-bounded migration state, restrict pool configuration to a trusted deployment process, and expose clear safeguards against leaving the token in a transfer-blocking mode. Test buys, sells, and wallet transfers across every migration state.
medium finding: Fee dispatch depends on external helper calls that can revert transfers
Normal-mode transfers can invoke fee dispatch, which directly calls the configured helper to swap accumulated token fees into the quote token. If that external call reverts, the surrounding token transfer also reverts. This creates a conditional transfer or trading denial when accumulated fees reach the configured dispatch threshold and the helper is unavailable or rejects the call.
Evidence: Token9._transfer calls _dispatchFee before processing a sell to the pair and after eligible transfers. _dispatchFee calls _swapForQuote, which sets _swapping and directly invokes ITokenHelper(TOKEN_HELPER_5).swapForQuote(to, amountToken) without try/catch. The helper address is a fixed external contract constant, and _getMinDispatchAmount determines when dispatch is attempted.
Recommendation: Wrap fee conversion in a failure-tolerant path, preserve accumulated fees when conversion fails, and prevent fee settlement from reverting ordinary transfers. Add monitoring and fallback handling for helper availability and abnormal return values.
medium finding: Controlled transfer mode does not enforce the documented owner-side restriction
The contract defines MODE_TRANSFER_CONTROLLED and documents it as allowing transfers only when one side is the owner, but the implemented migration guard does not enforce that rule. In controlled mode, transfers are blocked only when an endpoint is listed in migratedPools; ordinary transfers remain possible.
Evidence: FourToken declares MODE_TRANSFER_CONTROLLED = 2 and comments that controlled mode requires one transfer side to be the owner. However, _blocksBeforeMigration checks only whether _mode is MODE_NORMAL and whether migratedPools[from] or migratedPools[to] is true. No owner-side condition appears in the transfer path.
Recommendation: Either implement the documented controlled-mode condition in _blocksBeforeMigration or remove the mode and its documentation. Add tests covering owner-to-user, user-to-user, and pool-related transfers in every mode.