Reproduced Exploit

Megapot — LP pool cap may be exceeded on drawing settlement

processDrawingSettlement computes newLPValue without the same pool-cap clamp used on deposits

Nov 2025Otheruntagged2 min read

Chain

Other

Category

untagged

Date

Nov 2025

Source

AuditVault

EVM Playground

Source-level debugger — step opcodes and Solidity in sync

evm-hack-analyzer

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.

Loading fork state…

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-registry mirror.


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#

ImpactHIGH — newLPValue exceeds governancePoolCap after a no-winner draw, breaking Pool Cap Compliance and enabling later ticket bit-vector overflow DoS
ProtocolMegapot
Bug classprocessDrawingSettlement computes newLPValue without the same pool-cap clamp used on deposits
FindingCode4rena h2134 (H-03) · #64142
Reporthttps://code4rena.com/reports/2025-11-megapot
SourceAuditVault
StatusAudit 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#

flowchart TD A["LP at governancePoolCap"] --> B["No-winner draw with LP earnings"] B --> C["processDrawingSettlement"] C --> D{"newLPValue capped?"} D -->|"No - VULN"| E["newLPValue exceeds gov cap"] E --> F["bonusBallMax overflow risk / unfair betting"]

Impact#

newLPValue exceeds governancePoolCap after a no-winner draw, breaking Pool Cap Compliance and enabling later ticket bit-vector overflow DoS

Sources#


Sources & further analysis#

Reproductions & code

Alerts & third-party analyses

  • Web3Sec X hacked database: search.
  • Rekt leaderboard: search.
  • Solodit incident search: search.

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.