Reproduced Exploit

Burve — Incorrect tax distribution when adding value single-sided

1. Single-sided adds charge a tax meant for existing LPs. 2. valueStaked is incremented before tax is written into earningsPerValueX128. 3. New LP is already in the denominator and captures part of their own tax. 4. HARM: material dilution of Alice's fair tax share (Bob accrues > 0 of own tax).

Apr 2025Otheruntagged2 min read

Chain

Other

Category

untagged

Date

Apr 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: 56953-h-4-incorrect-tax-distribution-when-adding-value-single-side. Standalone Foundry PoC and full write-up: 56953-h-4-incorrect-tax-distribution-when-adding-value-single-side_exp in the evm-hack-registry mirror.


Vulnerability classes: fee-accounting · reward-accounting · logic/fee-calculation

Reproduction: self-contained Foundry PoC, offline, forge-std only. Full trace: output.txt.


Key info#

ImpactHIGH — single-sided tax diluted; existing LPs underpaid; excess stuck
ProtocolBurve Closure / ValueFacet
Vulnerable codevalueStaked += value before addEarnings(tax)
Bug classOrder-of-operations in reward index update
FindingSherlock 2025-04-burve · #56953 · H-4 · future et al.
Reportsherlock-audit/2025-04-burve-judging
Fixitos-finance/Burve#76
Compiler^0.8.24 (PoC)

TL;DR#

  1. Single-sided adds charge a tax meant for existing LPs.
  2. valueStaked is incremented before tax is written into earningsPerValueX128.
  3. New LP is already in the denominator and captures part of their own tax.
  4. HARM: material dilution of Alice's fair tax share (Bob accrues > 0 of own tax).

The vulnerable code#

SOLIDITY
valueOf[recipient] += value;
valueStaked += value; // @> VULN: updated BEFORE tax distribution
_addEarnings(tax);
// ...
earningsPerValueX128 += (tax << 128) / valueStaked; // @> VULN: includes new LP

Fix: distribute tax against previous valueStaked, then increment.


Attack walkthrough#

  1. Seed + Alice stake 200e18 total; Alice holds 100% of prior stake.
  2. Bob single-sides 500e18 with 1% tax (5e18).
  3. Index uses denom 700e18 → Alice gets ~200/700 of tax; Bob accrues the rest.
  4. HARM: Alice diluted by more than half of the tax she should fully receive.

Diagrams#

sequenceDiagram participant Alice participant Closure participant Bob Alice->>Closure: seed + addValue 200e18 Bob->>Closure: addValueSingle 500e18 + tax 5e18 Note over Closure: valueStaked updated first Note over Closure: tax index uses new denom Alice->>Closure: collectEarnings Note over Alice: underpaid vs full tax

Impact#

Uneven fee distribution; disincentive to provide value; excess fee accounting stuck.

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.