boar (boar) security report
Radar AI scanned Boar's verified Base contract and reviewed GoPlus evidence. Material findings include privileged cross-chain minting without enforcement of maxSupply, bridge-authorized burns from arbitrary addresses, and highly concentrated reported holdings. Slither was not run.
The contract was AI scanned. A high-severity trust and supply risk exists because the designated SuperchainTokenBridge can mint any amount without enforcing the constructor maxSupply and can burn tokens from arbitrary addresses. GoPlus also reports approximately 99.897% of supply held by one contract address. No honeypot, transfer tax, blacklist, pausing, or upgradeability was identified in the supplied source and evidence.
Trust score: 68/100. Source verified: Yes. Chain: base. Contract: 0x0cbf291ba052174879d90bf781df1a5f2bc5bb07.
This report was last modified on 2026-09-30 and contains 2 material findings.
high finding: Privileged bridge can mint without the declared max supply
The constructor uses maxSupply_ only for the initial mint and does not store it as a persistent cap. crosschainMint() allows the SuperchainTokenBridge predeploy to call _mint(_to, _amount) with any amount, limited only by the much larger ERC20Votes uint208 safety cap. A compromised, misconfigured, or governance-controlled bridge could therefore create substantial additional supply and dilute holders.
Evidence: src/ClankerToken.sol: the constructor calls _mint(msg.sender, maxSupply_) only when block.chainid == initialSupplyChainId_. crosschainMint(address _to, uint256 _amount) checks only msg.sender == Predeploys.SUPERCHAIN_TOKEN_BRIDGE and then calls _mint(_to, _amount); no maxSupply_ value is stored or checked. GoPlus reports is_mintable=0, but the verified source exposes this bridge-specific mint path.
Recommendation: Document the bridge as a critical trust dependency and monitor all CrosschainMint events. If a hard supply cap is required, store and enforce a cap across initial and cross-chain mints, or use a formally verified bridge supply accounting model that prevents net over-minting across supported chains.
high finding: Privileged bridge can burn tokens from arbitrary addresses
The SuperchainTokenBridge can invoke crosschainBurn() for any _from address without requiring an allowance or signature from that account. This is intended for bridge transfers, but compromise, misconfiguration, or unauthorized operation of the designated bridge could irreversibly destroy user balances or lock assets during cross-chain activity.
Evidence: src/ClankerToken.sol: crosschainBurn(address _from, uint256 _amount) checks only msg.sender == Predeploys.SUPERCHAIN_TOKEN_BRIDGE and then calls _burn(_from, _amount). Unlike ERC20Burnable.burnFrom(), no allowance is checked.
Recommendation: Treat the bridge and its message-validation system as a critical custody component. Monitor CrosschainBurn events, verify deployment against the canonical Base SuperchainTokenBridge, and ensure operational controls and incident procedures can suspend cross-chain functionality at the protocol level if the bridge is compromised.