# Deliberately increasing liquidity can DoS updates to the protocol’s governance parameters.

LPs can front-run governance parameter updates with a deposit to make lpPoolTotal exceed the new cap, causing setLPPoolCap to revert and delaying updates.

- Payout: Contest reward
- Severity: medium
- Program: Megapot
- Credited: BengalCatBalu
- Disclosed: 2026-01-05
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-11-megapot#m-03
- Library page: https://bugbountylibrary.com/r/c4%3A2025-11-megapot%3AM-03
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium vuln:dos vuln:governance

**Target:** JackpotLPManager smart contract
**Root cause:** setLPPoolCap reverts if the new cap is less than current lpPoolTotal + pendingDeposits, allowing LPs to block cap reductions by depositing.
**Steps:**
1. LP observes a pending governance transaction that would reduce lpPoolCap (e.g., setGovernancePoolCap).
2. LP front-runs with `lpDeposit(amount)` such that lpPoolTotal + pendingDeposits exceeds the new cap.
3. Governance transaction calls `setLPPoolCap` with new cap, which reverts due to `InvalidLPPoolCap`.
4. Update is postponed until next drawing when lpPoolTotal resets.
**How found:** Code review of setLPPoolCap and its callers revealed that the cap check uses current pool state, which LPs can manipulate via deposits.
**Exploitation:** An LP monitors the mempool for governance calls that reduce lpPoolCap (e.g., lowering ticketPrice or lpEdgeTarget). They submit a deposit transaction with a higher gas price to be mined first, increasing the pool total above the new cap. The governance transaction then reverts, delaying the parameter change.
**Insight:** When a setter validates against a dynamic state that users can inflate permissionlessly, consider front-running to block parameter changes; look for governance functions that revert based on user-controlled totals.