Bunker Mode (BUNKER) security report
Radar AI scanned Bunker Mode's verified Ethereum contract. The code is a minimal OpenZeppelin ERC-20 with no visible blacklist, tax, upgrade, pause, or post-deployment mint controls. The main finding is that the constructor assigns the entire fixed supply to the deployer, creating an initial distribution-control risk. Slither was not run.
The verified contract does not expose apparent honeypot, blacklist, fee-manipulation, upgrade, or privileged post-deployment mint paths. The main material risk is that the constructor mints the full 1,000,000,000-token supply to the deployment address, so initial token distribution depends on that address's actions.
Trust score: 91/100. Source verified: Yes. Chain: ethereum. Contract: 0x41a4594575557efbf85cd950749bb0c1e99bcefd.
This report was last modified on 2026-10-10 and contains 3 material findings.
medium finding: Entire initial supply is assigned to the deployer
The constructor mints the complete fixed supply to msg.sender in one transaction. This gives the deployment address complete initial control over token distribution and creates a material centralization and allocation risk, although the contract does not provide that address with ongoing administrative powers.
Evidence: In contracts/ETHV3.sol, the constructor executes _mint(msg.sender, 1000000000 * 10 ** decimals()). The inherited ERC20 implementation uses _update to credit the recipient and increase totalSupply. No later public or external mint function is defined.
Recommendation: Document the intended initial allocation and distribution process, and independently verify deployment and allocation records before relying on the token. If concentration risk is unacceptable, use a transparent distribution mechanism or vesting design in a future deployment.
medium finding: Standard ERC-20 allowance replacement race remains
The contract inherits the standard approve behavior, which allows a spender to potentially use an old allowance before a replacement allowance transaction is mined. This is an allowance-management risk for token holders and is not a token-specific privileged exploit.
Evidence: The inherited ERC20 approve(address spender, uint256 value) directly replaces _allowances[owner][spender]. The supplied OpenZeppelin source explicitly documents the transaction-ordering risk when changing an allowance from one nonzero value to another.
Recommendation: Token holders should set an allowance to zero before assigning a new nonzero allowance, or use an allowance-increase/decrease workflow where supported. Integrations should avoid relying on unsafe allowance replacement patterns.
medium finding: No contract-level recovery or administrative controls are available
The token exposes only the inherited ERC-20 interface and has no owner, pause, blacklist, fee, rescue, or upgrade functions. This is not an exploit in the token itself, but tokens or Ether accidentally sent to the contract cannot be recovered through a project-specific recovery function.
Evidence: The verified ABI contains only constructor, ERC-20 metadata, balance, allowance, approval, transfer, and transferFrom functions. The BUNKER contract source adds no payable function, receive function, owner state, or recovery method.
Recommendation: Treat transfers to the token contract address as potentially irrecoverable. If recovery functionality is required for a future version, implement narrowly scoped, documented recovery controls with appropriate authorization and event logging.