# Unoptimized subset matches counting implementation will exceed tx gas limit on base chain

Megapot's drawing settlement recomputes subset combinations bonusballMax times, exceeding Base's 25M gas limit and permanently blocking jackpot settlement.

- Payout: Contest reward
- Severity: high
- Program: Megapot
- Credited: montecristo
- Disclosed: 2026-01-05
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-11-megapot#h-02
- Library page: https://bugbountylibrary.com/r/c4%3A2025-11-megapot%3AH-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:dos

**Target:** Jackpot.sol entropy callback / TicketComboTracker library
**Root cause:** _countSubsetMatches regenerates Combinations.generateSubsets for each bonusball iteration instead of caching per-tier subsets, making cost scale with bonusballMax * normalTiers.
**Steps:**
1. Configure drawing with normalBallMax=30, bonusBallMax=129, poolCap=16M USDC.
2. Call `runJackpot` with entropy fee, then trigger `entropyProvider.randomnessCallback(winningNumbers)`.
3. Observe `scaledEntropyCallback` -> `_calculateDrawingUserWinnings` -> `countTierMatchesWithBonusball` -> `_countSubsetMatches` loop.
4. Gas estimate for randomnessCallback reaches 25,834,562, exceeding Base's 25M tx gas limit.
**How found:** Code reading of the settlement path traced the nested loop in _countSubsetMatches and noticed generateSubsets is recomputed inside the bonusball loop, then measured gas via a Hardhat PoC at realistic pool/bonusball parameters.
**Insight:** When a view helper is called inside a settlement callback, check whether inner loops recompute invariant data (subset generation) per iteration; gas ceilings on L2s like Base (25M) make such redundancy a liveness bug, not just inefficiency.
