# User can grief bootstrap process by sending the cap amount of unlocked tokens to it.

Cap check in BlastOnboarding counts unlocked deposits, so a griefer fills the cap with unlocked tokens, leaving zero locked tokens and blocking bootstrap.

- Payout: Contest reward
- Severity: medium
- Program: Abracadabra Money
- Credited: DarkTower
- Disclosed: 2024-05-03
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-03-abracadabra-money-findings/issues/7
- Library page: https://bugbountylibrary.com/r/c4%3A2024-03-abracadabra-money%3AM-16
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** BlastOnboarding/BlastOnboardingBoot deposit cap and bootstrap
**Root cause:** caps[token] is checked against totals[token].total instead of totals[token].locked, so unlocked deposits consume the cap; bootstrap reads only totals[token].locked, which can be zero.
**Steps:**
1. Deposit MIM and USDB with `lock_ = false` up to `caps[token]` via `deposit(token, amount, false)`.
2. Cap is reached because check uses `totals[token].total`, blocking all further deposits.
3. Owner calls `bootstrap(minAmountOut)`; `baseAmount = totals[MIM].locked` and `quoteAmount = totals[USDB].locked` are 0.
4. Pool is created with zero liquidity / bootstrap fails, griefing the launch.
**How found:** Code reading: noticed bootstrap uses only `totals[token].locked` while the cap check in `deposit` uses `totals[token].total`, a mismatch allowing unlocked deposits to exhaust the cap.
**Exploitation:** Attacker deposits unlocked tokens to fill the cap, preventing legitimate locked deposits and forcing bootstrap to use zero locked amounts.
**Insight:** When a cap or accounting check uses a total that includes a different bucket than the one consumed downstream, look for ways to fill the wrong bucket to starve the real one.