bunker (bunker) security report
Radar by SecureChain.ai independently reviewed bunker’s verified source on BNB Smart Chain. Material findings include owner-controlled pool activation, a dividend callback that can block transfers, and tax processor fallback exposure.
The contract has material centralized and integration risks. The owner controls when pool transfers become possible, and a configured dividend contract can make ordinary transfers revert. The token has no post-initialization mint function, but initialization mints the full maxSupply to the initializer.
Trust score: 42/100. Source verified: Yes. Chain: bsc. Contract: 0x2ec1e08c2c6343671728ef7c6e7fde0bd6f07777.
This report was last modified on 2026-10-15 and contains 4 material findings.
high finding: Owner can keep pool transfers disabled during BondingCurve state
While the pool state is BondingCurve, every transfer involving any configured pool reverts. Only the owner can call startMigration, and only the owner can then call finalizeMigration. Until those actions occur, pool buys and sells cannot execute through the token contract.
Evidence: In _transfer, the BondingCurve branch requires !pools[from] && !pools[to], reverting with "Transfers to/from pools are restricted in BondingCurve state". startMigration and finalizeMigration are both external onlyOwner functions, and initialize sets the initial state to PoolState.BondingCurve.
Recommendation: Use an independently governed or time-bounded launch transition, validate the intended pool addresses before initialization, and publish the migration conditions. Consider removing unilateral owner control over the transition or enforcing an automatic transition deadline.
medium finding: Configured dividend contract can block token transfers
When dividendContract is nonzero, transfers call setShare for eligible sender and recipient addresses. Any revert from either call is converted into DividendShareUpdateFailed and reverts the entire token transfer, creating a material transfer-lock dependency on an external contract.
Evidence: _afterTokenTransfer calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) inside try/catch blocks. The catch blocks execute revert DividendShareUpdateFailed(...), so a failing dividend integration prevents the originating transfer from completing.
Recommendation: Do not make core ERC20 transfers depend on a reverting external dividend call. Use a non-blocking update pattern, bounded failure handling, an operator-controlled recovery path, and strict validation of the dividend contract during initialization.
medium finding: Tax processor failure forwards the full contract token balance
If the external tax processor call fails, the fallback path transfers the entire token balance held by the token contract to taxProcessor, rather than only the taxAmount being processed. A malicious, compromised, or misconfigured processor can therefore cause accumulated tax reserves held by the token contract to be forwarded to itself by intentionally reverting.
Evidence: _processTax approves taxProcessor for type(uint256).max when needed, calls processTaxTokens(taxAmount), and in the catch block reads balanceOf(address(this)) and calls _plainTransfer(address(this), taxProcessor, remainingBalance).
Recommendation: Limit fallback transfers to the specific tax amount, avoid unlimited approvals where practical, validate the processor implementation, and add governance or timelock controls for processor configuration at the deployment layer.
medium finding: Initializer assigns the entire maximum supply to the initializer caller
The one-time initializer mints maxSupply directly to msg.sender. There is no vesting, distribution constraint, or supply allocation check in this contract, so the account or deployment component that invokes initialize receives the entire initial token supply.
Evidence: initialize executes _mint(msg.sender, maxSupply), and maxSupply is defined as 1e9 ether. No later mint function exists, but the initial allocation is entirely determined by the initializer caller.
Recommendation: Use an explicit treasury or distribution address instead of msg.sender, document the allocation authority, and apply vesting or multisignature controls outside this token contract where appropriate.