Jackpot enforces pool cap as the following:
This is to ensure the following:
- bonusBallMax + normalBallMax <= MAX_BIT_VECTOR_SIZE
- Pool cap does not exceed governance pool cap
Otherwise, TicketComboTracker cannot properly store purchased Ticket on max bonus ball, since the following will revert with overflow:
However, LP pool cap can be exceeded on drawing settlement, because new LP value calculation does not enforce the same pool cap logic:
Since LP value can grow by up to lpEdgeTarget = 30% on every draw without any jackpot winner, governance cap or calculated limit can be exceeded, if previous total pool was just below the surface.
Impact
Important invariants can be broken on settlement drawing:
- Pool Cap Compliance: Total pool never exceeds governance limits
- // Pool cap enforcement: lpPoolTotal + pendingDeposits <= governancePoolCap
- Is all the bitpacking logic sound? Are there any potential boundary errors that could arise either between the lower bits where the normals are or the higher bits where bonusball must be less than 255 - normalBall Max?
Especially, when new pool cap exceeds calculated safe limit, bonusBallMax can be greater than 255 - normalBallMax.
This will lead to DOS on normalBallMax betting and ultimately lead to unfair betting.
Alpha: make sure to read all invariants and that they are never broken. In this case, a by variable analysis can be carried to out check all the updates and if they are all capped.
Conclusion
This finding would earn you $9542, requiring just looking for this invariant being broken.