Base Inu (BINU) security report
Radar AI scanned Base Inu on Base using verified source and GoPlus evidence. The material risks are a launcher-configurable transfer-blocking reward tracker and mutable wallet-cap exemptions. Slither was not run.
The token has no public mint, blacklist, fee, proxy, or pause function in the reviewed source, and GoPlus reports corresponding negative signals. However, the launcher retains material control over transfer execution through the reward tracker and can selectively bypass the max-wallet rule through exemptions.
Trust score: 62/100. Source verified: Yes. Chain: base. Contract: 0x2cc93433eca5a3e4377c478819f049feb591e222.
This report was last modified on 2026-10-07 and contains 2 material findings.
high finding: Launcher can configure a transfer-blocking reward tracker
The launcher can set the reward tracker once, and every non-mint transfer subsequently performs a direct external debit call to that tracker. If the selected tracker reverts, transfers revert as well. Because rewardTracker cannot be replaced after being set, a malicious or faulty launcher-selected tracker can permanently prevent token transfers.
Evidence: In setRewardTracker, only msg.sender == launcher is accepted, and rewardTracker may be set once after checking only tracker.token() == address(this) and tracker.launcher() == launcher. In _update, every transfer with a nonzero tracker executes IRewardTrackerV7(tracker).debit(from) without try/catch before continuing. A reverting debit call reverts the entire token transfer.
Recommendation: Treat the launcher as a high-trust role. Use an immutable or independently governed tracker, restrict the tracker interface to a vetted implementation, add failure isolation so tracker failures cannot block ERC-20 transfers, and provide a recovery path if the configured tracker becomes unavailable.
medium finding: Launcher can bypass the max-wallet restriction for arbitrary addresses
After launch, the token enforces the max-wallet cap only for recipients that are not exempt. The launcher can add or remove exemptions for any address at any time, allowing selected recipients to receive balances above the configured cap and weakening the stated transfer restriction.
Evidence: setExempt(address who, bool on) is callable only by launcher but has no timelock, limit, or one-way restriction. In _update, the cap check returns immediately when exemptFromMaxWallet[to] is true. The maxWalletBps value is immutable, but the exemption mapping remains launcher-controlled after deployment.
Recommendation: Use immutable exemptions where possible, or govern exemption changes through a timelock and transparent event-based process. Document all intended exempt addresses and consider removing privileged exemption changes after launch.