# Juicebox project owner can create a honeypot to cause grief

Juicebox project owner sets ~389 tiny splits so distributeReservedTokensOf exceeds block gas limit, griefing callers who burn gas for nothing.

- Payout: Contest reward
- Severity: medium
- Program: Juicebox
- Disclosed: 2022-10-11
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-07-juicebox-findings/issues/170
- Library page: https://bugbountylibrary.com/r/c4%3A2022-07-juicebox%3AM-04
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** JBController.distributeReservedTokensOf / JBSplitsStore.set (Solidity contracts)
**Root cause:** SplitsStore allows arbitrarily many splits with percent as low as 1 (SPLITS_TOTAL_PERCENT=1e9), so a project owner can register enough splits that iterating them in distributeReservedTokensOf exceeds the block gas limit, while set() itself still succeeds.
**Steps:**
1. Owner sets MAX_RESERVED_RATE and configures ~389 splits, one large percent to msg.sender, rest percent=1.
2. Owner funds project with large payments to inflate reserved token pool.
3. Victim calls `distributeReservedTokensOf(projectId, token)` expecting the large split.
4. Loop over 389 splits exceeds block gas limit; tx reverts, victim loses gas.
**How found:** Reasoned about SPLITS_TOTAL_PERCENT allowing 1e9 splits of percent 1, then empirically tested with Hardhat that set() succeeds at 389 splits while distributeReservedTokensOf hits the block gas limit at the same count.
**Exploitation:** Owner lures a user into calling distributeReservedTokensOf by advertising a large reserved-token split; the call always reverts out-of-gas, burning the victim's ETH with no gain to them and no cost to the owner.
**Insight:** When a setter and a consumer iterate the same unbounded array, compare their gas costs at equal length: if the setter is cheaper, an attacker can configure a length that only bricks the consumer.