bunkerpad.fun (BUNKER) security report
Radar by SecureChain AI scanned bunkerpad.fun on Ethereum. The source review found high-severity launchpad control over arbitrary token transfers, bunker reserve accounting exposure, and medium-severity verifier and vault-key risks.
The contract has a material centralized-control risk. The launchpad can transfer tokens from arbitrary addresses without approval, and it can drain the token contract’s ERC20 balance without updating bunker accounting. Bunker deposits also require careful key compatibility because only values with zeroed upper 128 bits pass validation.
Trust score: 35/100. Source verified: Yes. Chain: ethereum. Contract: 0x4dcb4f94601e99621531ba002a09dfb1f580b123.
This report was last modified on 2026-10-07 and contains 4 material findings.
high finding: Launchpad can seize arbitrary token balances without allowance
The immutable launchpad address is authorized to call pullFor, which invokes _move directly and does not check allowance or ownership. This permits the launchpad to transfer tokens from any address to any destination, creating a powerful custodial or compromised-router theft path.
Evidence: pullFor checks only `if (msg.sender != launchpad) revert NotLaunchpad();` and then calls `_move(from, to, amount)`. `_move` checks only the source balance and performs no allowance check. The constructor sets `launchpad = msg.sender`.
Recommendation: Restrict pullFor to an explicitly authorized, audited router with narrowly scoped allowances or signed user authorizations. Prefer removing arbitrary `from` and `to` parameters or require an allowance for the source address. Document and monitor the immutable launchpad trust assumption.
high finding: Launchpad can drain bunker backing while leaving bunker accounting unchanged
Because pullFor can use address(this) as the source, the launchpad can move the ERC20 balance that backs bunker vaults without decreasing bunkerBalance or totalBunkered. This can leave recorded vault balances undercollateralized and cause later withdrawals to fail or become insolvent.
Evidence: `pullFor` calls `_move(from, to, amount)` with no restriction on `from`. The bunker system stores deposited tokens in `balanceOf[address(this)]`, while `bunkerBalance` and `totalBunkered` are updated separately by bunkerDeposit. A launchpad call using `from = address(this)` changes the token balance but does not update either bunker accounting variable.
Recommendation: Prevent pullFor from operating on address(this), and ensure every movement of bunker-backed tokens updates bunker accounting atomically. Add invariant tests requiring the token contract balance to remain at least totalBunkered after every externally callable operation.
medium finding: Immutable external verifier is a deployment-time trust dependency
All bunker exits and vault moves depend on the externally supplied verifier address. The verifier is immutable, so a faulty, malicious, incompatible, or unavailable verifier cannot be replaced after deployment and may approve unauthorized signatures, reject valid signatures, or make bunker operations unusable.
Evidence: The constructor assigns `verifier = ISphincsVerifier(_verifier)`. bunkerWithdraw and bunkerMove call `verifier.verify(...)`, while no verifier source or implementation behavior is included in the supplied contract source. The verifier address cannot be changed.
Recommendation: Audit and pin the verifier implementation and deployment address before use. Add integration tests for valid, invalid, replayed, expired, and malformed signatures, and consider a recovery or migration design for verifier failure if the product requires long-term access to bunkered assets.
medium finding: Non-canonical key validation can make deposited vaults inaccessible
The bunker accepts deposits into any bytes32 vault identifier, but exits and moves require both key components to have their upper 128 bits cleared. A deposit associated with a vault ID derived from a key that fails this restriction cannot be accessed through bunkerWithdraw or bunkerMove using that key format, creating an irreversible-loss risk for incompatible or incorrectly generated vaults.
Evidence: bunkerDeposit accepts any `vaultId` without validating a key. `_checkKey` reverts with NonCanonicalKey when `(pkSeed & N_MASK) != pkSeed` or `(pkRoot & N_MASK) != pkRoot`; N_MASK has ones in the upper 128 bits and zeros in the lower 128 bits, so the upper 128 bits of both inputs must be zero.
Recommendation: Validate key canonicality at the point of deposit or provide a safe, documented vault-registration flow. Confirm that the intended SPHINCS key format is compatible with the mask, and add tests proving that every accepted deposit can be recovered through a valid withdrawal path.