Reproduced Exploit
Megapot — LP pool cap may be exceeded on drawing settlement
processDrawingSettlement computes newLPValue without the same pool-cap clamp used on deposits
Chain
Other
Category
untagged
Date
Nov 2025
Source
AuditVault
EVM Playground
Source-level debugger — step opcodes and Solidity in sync
The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.
Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 64142-h-03-lp-pool-cap-may-be-exceeded-on-drawing-settlement-code4. Standalone Foundry PoC and full write-up: 64142-h-03-lp-pool-cap-may-be-exceeded-on-drawing-settlement-code4_exp in the
evm-hack-registrymirror.
Reproduction: self-contained Foundry PoC (forge-std only) — no fork. Full trace: output.txt.
AuditVault taxonomy: lang/solidity · platform/code4rena · severity/high · sector/prediction · genome: frozen-funds · wrong-state · integer-bounds
Key info#
| Impact | HIGH — newLPValue exceeds governancePoolCap after a no-winner draw, breaking Pool Cap Compliance and enabling later ticket bit-vector overflow DoS |
| Protocol | Megapot |
| Bug class | processDrawingSettlement computes newLPValue without the same pool-cap clamp used on deposits |
| Finding | Code4rena h2134 (H-03) · #64142 |
| Report | https://code4rena.com/reports/2025-11-megapot |
| Source | AuditVault |
| Status | Audit finding — reproduced as a standalone local synthetic |
| Compiler | ^0.8.24 (PoC) |
TL;DR#
processDrawingSettlement computes newLPValue without the same pool-cap clamp used on deposits
HARM: newLPValue exceeds governancePoolCap after a no-winner draw, breaking Pool Cap Compliance and enabling later ticket bit-vector overflow DoS
Root cause#
processDrawingSettlement computes newLPValue without the same pool-cap clamp used on deposits
Preconditions#
Protocol-specific setup as described in the original finding (roles / managers / pending state in place).
Attack walkthrough#
See the synthetic test/64142-h-03-lp-pool-cap-may-be-exceeded-on-drawing-settlement-code4.sol and the Playground story beats. The @> VULN marker sits on the blamed executable line.
Diagrams#
Impact#
newLPValue exceeds governancePoolCap after a no-winner draw, breaking Pool Cap Compliance and enabling later ticket bit-vector overflow DoS
Sources#
- AuditVault finding
- Report: https://code4rena.com/reports/2025-11-megapot
- Reduced source provenance: github.com/code-423n4/2025-11-megapot@f0a7297 JackpotLPManager.sol
Sources & further analysis#
Reproductions & code
- Standalone PoC + full trace: 64142-h-03-lp-pool-cap-may-be-exceeded-on-drawing-settlement-code4_exp (evm-hack-registry mirror).
- AuditVault finding: 64142-h-03-lp-pool-cap-may-be-exceeded-on-drawing-settlement-code4.
Alerts & third-party analyses
These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.