Reproduced Exploit

GTE — burn over-estimates LP distribution when launchpad fees accrued

1. Accrued launchpad fees sit in pair balances but are excluded from reserves. 2. mint prices LP against reserves; burn pays out against full balances. 3. Mint + burn captures a slice of fees that belong to the distributor. 4. HARM: positive token0 profit stolen from fee accrual (~9.09e21 units in…

Aug 2025Otheruntagged2 min read

Chain

Other

Category

untagged

Date

Aug 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: 64851-h-03-gtelaunchpadv2pairburn-over-estimates-distribution-amou. Standalone Foundry PoC and full write-up: 64851-h-03-gtelaunchpadv2pairburn-over-estimates-distribution-amou_exp in the evm-hack-registry mirror.


Vulnerability classes: fee-calculation · direct-drain · fee-accounting

Reproduction: self-contained Foundry PoC with only forge-std. Full trace: output.txt. PoC: test/64851-h-03-gtelaunchpadv2pairburn-over-estimates-distribution-amou_exp.sol.

AuditVault taxonomy: lang/solidity · platform/code4rena · has/github · has/poc · severity/high · sector/dex · sector/launchpad · genome: fee-calculation · direct-drain · fee-accounting


Key info#

ImpactHIGH — LP burn claims a share of accrued launchpad fees; repeatable drain
ProtocolGTE
Vulnerable codeGTELaunchpadV2Pair.burn amounts from balances
Bug classFee-inclusive pro-rata on burn
FindingCode4rena 2025-08 GTE · #64851 · H-03 · AvantGard
ReportCode4rena report
SourceAuditVault
Compiler^0.8.24 (PoC)

TL;DR#

  1. Accrued launchpad fees sit in pair balances but are excluded from reserves.
  2. mint prices LP against reserves; burn pays out against full balances.
  3. Mint + burn captures a slice of fees that belong to the distributor.
  4. HARM: positive token0 profit stolen from fee accrual (~9.09e21 units in the synthetic).

The vulnerable code#

SOLIDITY
amount0 = liquidity.mul(balance0) / _totalSupply; // @> VULN
amount1 = liquidity.mul(balance1) / _totalSupply; // @> VULN

Fix: subtract accruedLaunchpadFee{0,1} from balances before pro-rata.


Root cause#

Reserves = balances − accrued launchpad fees. Burn ignores that split and treats fee inventory as LP-claimable.


Preconditions#

  • Non-zero accruedLaunchpadFee0 or accruedLaunchpadFee1 (prior swaps, same block so fees not yet distributed).
  • Attacker can mint and burn LP.

Attack walkthrough#

  1. Seed pool with liquidity and token0 fee accrual.
  2. Deposit proportional amounts; mint LP.
  3. Transfer LP to pair and burn.
  4. Receive more token0 than deposited — the fee over-claim.

Diagrams#

flowchart TD A["Swaps accrue launchpad fees"] --> B["balances = reserves + fees"] B --> C["Attacker mints LP vs reserves"] C --> D["Attacker burns LP vs balances"] D --> E["Profit = fee share stolen"]

Impact#

Direct drain of launchpad fee inventory; repeatable same-block until fees are cleared.


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.