Blokeys (BLOKEYS) security report
Radar AI scanned Blokeys on Base and identified privileged cross-chain mint and burn controls, plus deployment-time initial supply allocation risk. Slither was not run.
Blokeys has material privileged supply and balance-control risks. The canonical SuperchainTokenBridge can mint without the configured maxSupply limit and can burn from any address when called with that address and amount. The initial supply is assigned to the deployment caller rather than the admin address.
Trust score: 42/100. Source verified: Yes. Chain: base. Contract: 0xf9cdf67dd3dde76a72f37ce4f0a27325ba25f4d9.
This report was last modified on 2026-10-10 and contains 4 material findings.
high finding: Privileged bridge can mint beyond the configured initial supply
The SuperchainTokenBridge is authorized to call crosschainMint for any recipient and amount. This function invokes _mint directly, while maxSupply_ is used only for the constructor mint and is not stored or enforced as a token supply cap. A compromised, misconfigured, or improperly validating bridge could therefore create additional supply and dilute existing balances.
Evidence: In ClankerToken.crosschainMint, the only check is msg.sender != Predeploys.SUPERCHAIN_TOKEN_BRIDGE; after that, _mint(_to, _amount) is called. The constructor uses maxSupply_ only in _mint(msg.sender, maxSupply_) when block.chainid equals initialSupplyChainId_. GoPlus also reports is_mintable=1.
Recommendation: Document the bridge as a trusted monetary authority and enforce bridge-side accounting and message validation. If a hard maximum supply is intended, store maxSupply_ and reject any mint that would exceed it, including cross-chain mints. Monitor bridge mint events and use governance or protocol-level controls for bridge upgrades and incidents.
high finding: Privileged bridge can burn tokens from arbitrary addresses
The bridge can invoke crosschainBurn with any _from address and amount. Unlike burnFrom, this path does not require an allowance from the account being burned; it relies entirely on the bridge address being trusted and correctly validating cross-chain transfer messages. Bridge compromise or authorization failure could cause irreversible loss of token balances.
Evidence: ClankerToken.crosschainBurn checks only that msg.sender equals Predeploys.SUPERCHAIN_TOKEN_BRIDGE, then calls _burn(_from, _amount). No allowance, signature, or ownership check is performed in this function.
Recommendation: Ensure the bridge implementation strictly authenticates and uniquely processes cross-chain messages before calling this function. Consider adding defense-in-depth constraints, event monitoring, pause or incident-response controls at the bridge layer, and formal documentation that the bridge has unilateral burn authority.
medium finding: Constructor assigns the initial supply to the deployment caller
When deployed on the configured initial supply chain, the entire maxSupply_ amount is minted to msg.sender, not to admin_. This creates a material allocation and operational-control dependency on the deployer transaction sender. The configured admin does not automatically receive or control the initial token balance.
Evidence: The constructor contains if (block.chainid == initialSupplyChainId_) { _mint(msg.sender, maxSupply_); }. The admin_ parameter is assigned to _originalAdmin and _admin but is not used as the recipient of the initial mint.
Recommendation: Make the intended allocation explicit and mint to a designated recipient or admin-controlled treasury when appropriate. Validate deployment parameters before launch, document the deployer’s allocation responsibility, and use a controlled deployment account if the deployer is meant to hold the initial supply.
medium finding: Cross-chain supply semantics depend on an external predeploy authority
The token delegates minting and burning authority to the hard-coded SuperchainTokenBridge predeploy. The token itself does not validate source-chain identity, message uniqueness, transfer limits, or bridge accounting. This is a material protocol-dependency risk: token integrity depends on the external bridge’s implementation and security assumptions.
Evidence: Both crosschainMint and crosschainBurn accept requests solely from Predeploys.SUPERCHAIN_TOKEN_BRIDGE, defined as 0x4200000000000000000000000000000000000028. The token contains no additional message, nonce, amount, or source-chain validation in either function.
Recommendation: Assess the deployed Base bridge implementation and its cross-chain message validation separately. Document the trust model, monitor CrosschainMint and CrosschainBurn events, and establish an incident response or bridge-upgrade process before relying on cross-chain supply behavior.