CYBERCLAW (CLAW) security report
Radar by SecureChain AI scanned CYBERCLAW on BNB Smart Chain. Material findings include an NFT portal that can burn arbitrary balances without allowance, a staking-fee sink when no vault is configured, and owner-controlled transfer restrictions and exemptions.
The contract is not free of material risks. The highest concern is the owner-controlled NFT portal, which can irreversibly burn arbitrary token balances without approval. A separate fee-accounting issue can silently remove the staking-fee portion from balances when no staking vault is configured.
Trust score: 35/100. Source verified: Yes. Chain: bsc. Contract: 0xc4bfd4be41f7600afc1c0288b2b9c7d75167cf3e.
This report was last modified on 2026-10-10 and contains 3 material findings.
high finding: Owner-controlled NFT portal can burn tokens from arbitrary addresses
The configured nftMintPortal can call burnForNftMint with any minter address and amount. The function checks only that the target has enough tokens; it does not require an allowance, signature, or consent from the target. Because the owner can replace nftMintPortal, an owner-selected portal can irreversibly remove tokens from arbitrary addresses.
Evidence: burnForNftMint(address minter, uint256 amount) requires only msg.sender == nftMintPortal and _balances[minter] >= amount, then subtracts the amount and credits DEAD_ADDRESS. setNftMintPortal(address _portal) is restricted to owner and accepts any nonzero address.
Recommendation: Restrict burns to tokens explicitly authorized by the holder, such as allowance-based burning or a holder signature. Consider making the portal immutable or subjecting portal changes to a timelock and emitting a clearly monitored change event.
medium finding: Staking fee can be deducted without being credited to a staking vault
When a transfer is treated as a sell, the contract calculates the staking fee and subtracts it from the sender. The fee is credited to stakingPoolVault only when that address is nonzero. Until the owner configures a vault, the staking-fee amount is removed from the sender balance without being transferred to a reserve or the dead address, while totalSupply remains unchanged.
Evidence: The constructor does not initialize stakingPoolVault. In _transfer, stakingFee is included in transferAmount = value - devFee - stakingFee, but _balances[stakingPoolVault] += stakingFee executes only when stakingPoolVault != address(0). The fee path activates when to == pancakePair and the parties are not excluded from fees.
Recommendation: Require a valid staking vault before enabling the pair or fee path, or route an unset-vault fee to an explicitly documented destination. Add invariant and integration tests covering sells before and after vault configuration.
medium finding: Owner can materially change transfer restrictions and fee exemptions
The owner can disable the anti-whale check, raise the transaction limit, designate a presale address exempt from the limit, and exempt arbitrary accounts from sell fees. These controls are centralized and can materially change how transfers and sells behave after deployment.
Evidence: setAntiWhaleEnabled, setMaxTxAmount, setPresaleContract, and setExcludedFromFees are all protected only by onlyOwner. _transfer skips the transaction limit for owner and presaleContract and applies sell fees only when the sender and configured pair are not excluded. GoPlus also reports anti_whale_modifiable as 1.
Recommendation: Use governance or a timelock for policy changes, publish permitted ranges and role responsibilities, and consider permanently fixing the anti-whale and fee-exemption policy after launch.