Burve — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Burve, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 12
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 12 closed, publicly disclosed Burve reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Integer overflow / underflow, Reentrancy, Front-running / MEV, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Burve
- Integer overflow / underflow findings disclosed against Burve
- Reentrancy findings disclosed against Burve
- Front-running / MEV findings disclosed against Burve
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Burve: Incorrect handling of ERC4626 vaults with fees
Burve's multi-token pool routes user liquidity through underlying ERC4626 vaults, but credits users the full raw token value while the vault may mint fewer shares because of deposit or withdrawal fees. The fee is never deducted from the credited value, so a user can deposit and withdraw at the same nominal amount while the pool's real asset balance shrinks by the fee. Repeatedly this lets users sidestep vault fees at the pool's expense, and the last withdrawers bear the shortfall when actual assets fall short of accounted assets. The team fixed it by pulling additional tokens from users to cover the vault fee.
Burve: User can backrun an admin calling `setEX128` and steal the difference in tokens
Burve's bonding-curve pricing derives each token's value from an efficiency factor eX128, with the pool invariant that the summed token value equals target*n. When the pool owner alters eX128 for a token via setEX128, the contract never recomputes targetX128, leaving the pool internally mispriced against its own invariant. An attacker who backruns the owner's parameter change can call removeTokenForValue (or addTokenForValue) with a crafted amount such that the internally recalculated newTargetX128 equals the stored targetX128, spending only dust value while sweeping out excess tokens that should have gone to the reserve. Sherlock ruled the finding valid at medium severity, and the protocol fixed it by rebalancing balances atomically inside setEX128 to preserve targetX128.
Burve: Protocol fee resides in the diamond contract can be wrongly sent to users if the underlying vault temporarily disables withdrawal
During a user's collectEarnings() call, Burve's trimBalance() attempts to net out an internal withdrawal and re-deposit to the underlying ERC4626 vault. If the vault temporarily disables withdrawal, VaultProxy queries maxWithdraw() which returns 0, causing the internal withdrawal to be skipped without updating the pending withdrawal counter. When commit() runs, the assets-to-deposit is no longer offset by assets-to-withdraw, so the diamond contract's actual token balance — which holds accumulated protocol fees — gets deposited into the vault instead of being reserved. ReserveLib.withdraw() then also no-ops against the disabled vault, and collectEarnings() transfers tokens held in the diamond to the user, effectively paying out the protocol's fee balance. The impact is that protocol fees held in the diamond contract are wrongly distributed to users during a temporary vault withdrawal freeze.
Burve: Incorrect implementation of `ERC4626ViewAdjustor`
Burve's ERC4626ViewAdjustor, used to convert between real and nominal token values when integrating liquid staking tokens like stETH into multi-token pools, implements its two conversion functions backwards. toNominal calls convertToShares while toReal calls convertToAssets, so the amounts each direction compute are inverted. In a pool pairing stETH with WETH, this miscalculation causes depositors to put in more stETH than required, overpaying their deposits and losing funds. The protocol fixed it by swapping the implementations in a follow-up commit.
Burve: Incorrect earnings calculation in `removeValueSingle()` function causes partial user losses
In Burve's `removeValueSingle()` path, the asset-level `remove()`/`collect()` runs before the closure's `removeValueSingle()`/`trimBalance()` updates the earnings-per-value accumulator. The removal therefore computes the user's collected earnings from a stale per-value price, so in an inactive pool the user can forfeit more than 1% of their accrued rewards. A two-branch PoC shows the discrepancy between a direct removal and one preceded by a third-party `addValue()` that refreshes `trimBalances()`. The protocol team acknowledged and fixed the ordering by moving the asset `remove()` after the closure call.
Burve: Reserve Share Overflows Due to Too Strict Reward Calculation Mechanism
Burve's vertex-balancing flow routes surplus vault balances into a global reserve that mints per-token shares proportionally to deposited value. ReserveLib.deposit() computes shares as (amount * reserve.shares)/balance, so when the deposited residual is tiny relative to a near-zero recorded balance, each mint over-states shares and silently inflates the share counter. An attacker who can trigger many small trim deposits — by cycling removeValue() with dust amounts against a vertex containing a large whale position — amplifies this rounding until the share counter overflows (panic 0x11), corrupting reserve accounting across closures and permanently bricking deposit functionality. The protocol acknowledged the flaw and shipped a fix in Burve pull request 78.
All reports in this group
- Burve: Simplex ownership cannot be transferredLogic error$0
- Burve: Attacker captures unclaimed fees by timing deposit with range re-entry and price manipulationLogic error$0
- Burve: The value of each closure is not the same, and the same ValueToken cannot be used for all cidsLogic error$0
- Burve: Incorrect tax distribution when adding value single-sidedReentrancy$0
- Burve: Incorrect Netting Logic Leads to Excessive Withdrawal AmountsLogic error$0
- Burve: An attacker can drain assets from a Closure by exploiting the NoopVault via a donation attackFront-running / MEV$0