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
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Burve reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, 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
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 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: Simplex ownership cannot be transferred
Burve's SimplexDiamond is an EIP-2535 diamond proxy whose constructor registers the BaseAdminFacet's transferOwnership, owner and adminRights selectors in the admin facet cut, but omits the acceptOwnership selector. Because ownership transfer follows a two-step pending/accept pattern, the intended new owner can never call acceptOwnership through the proxy, so ownership cannot actually be transferred. The fix, which Burve confirmed in a PR, adds the missing acceptOwnership selector to the admin cut.
Burve: The value of each closure is not the same, and the same ValueToken cannot be used for all cids
Burve's ValueTokenFacet mints and burns a single, cid-agnostic ValueToken, meaning a user who adds liquidity to one closure can burn the resulting ValueToken to withdraw the liquidity of a different closure. Because pool values drift apart under normal volatility, an attacker can add value into a cheaper closure and redeem it against a richer one, extracting more tokens than they supplied. This also breaks the protocol's intent that a token's crash in one pool should not expose LPs in unrelated closures, since other users can route their burn through the affected closure to offload losses onto its LPs.
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.