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).
Chain
Other
Category
untagged
Date
Apr 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: 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-registrymirror.
Vulnerability classes: fee-accounting · reward-accounting · logic/fee-calculation
Reproduction: self-contained Foundry PoC, offline, forge-std only. Full trace: output.txt.
Key info#
| Impact | HIGH — single-sided tax diluted; existing LPs underpaid; excess stuck |
| Protocol | Burve Closure / ValueFacet |
| Vulnerable code | valueStaked += value before addEarnings(tax) |
| Bug class | Order-of-operations in reward index update |
| Finding | Sherlock 2025-04-burve · #56953 · H-4 · future et al. |
| Report | sherlock-audit/2025-04-burve-judging |
| Fix | itos-finance/Burve#76 |
| Compiler | ^0.8.24 (PoC) |
TL;DR#
- Single-sided adds charge a tax meant for existing LPs.
valueStakedis incremented before tax is written intoearningsPerValueX128.- New LP is already in the denominator and captures part of their own tax.
- HARM: material dilution of Alice's fair tax share (Bob accrues > 0 of own tax).
The vulnerable code#
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#
- Seed + Alice stake 200e18 total; Alice holds 100% of prior stake.
- Bob single-sides 500e18 with 1% tax (5e18).
- Index uses denom 700e18 → Alice gets ~200/700 of tax; Bob accrues the rest.
- HARM: Alice diluted by more than half of the tax she should fully receive.
Diagrams#
Impact#
Uneven fee distribution; disincentive to provide value; excess fee accounting stuck.
Sources#
- AuditVault finding #56953
- Sherlock issue #196
- Source:
sherlock-audit/2025-04-burve@44cba36Closure.sol
Sources & further analysis#
Reproductions & code
- Standalone PoC + full trace: 56953-h-4-incorrect-tax-distribution-when-adding-value-single-side_exp (evm-hack-registry mirror).
- AuditVault finding: 56953-h-4-incorrect-tax-distribution-when-adding-value-single-side.
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.