Curves Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Curves Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 11
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 11 closed, publicly disclosed Curves Protocol 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, Front-running / MEV, Reentrancy, Access control, 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 Curves Protocol
- Front-running / MEV findings disclosed against Curves Protocol
- Reentrancy findings disclosed against Curves Protocol
- Access control findings disclosed against Curves Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Curves Protocol: Theft of holder fees when `holderFeePercent` was positive and is set to zero
Curves Protocol routes a holder fee from every buy/sell to a FeeSplitter contract, which distributes the accrued balance to current token holders proportionally to their share snapshots. The _transferFees() function only invokes FeeSplitter.onBalanceChange() and addFees() while holdersFeePercent is non-zero. When the DAO later lowers the holder fee to zero, the already-collected fees remain stranded in FeeSplitter with no updated shareholder tracking, so a new shareholder who buys shares afterward can claim those fees at the expense of the holders who earned them, while the rightful holders' claims revert for lack of funds. The flaw was confirmed by the protocol and upheld as Medium by the judge, with the accepted fix being to always call onBalanceChange() irrespective of the current fee percentage.
Curves Protocol: `Curves::_buyCurvesToken()`, Excess of Eth received is not refunded back to the user.
Curves' buy flow validates that the incoming `msg.value` covers at least `price + totalFee` but never returns surplus ETH to the caller, so any overpayment (such as when the displayed price slips between the user's estimate and execution) is permanently trapped in the contract. The Curves team confirmed the finding but disputed it as high severity, and the judge downgraded it to medium — partly because friend.tech's reference implementation also does not refund. Economically this is a loss-of-funds for buyers who overpay rather than a theft vector, consistent with its medium classification. The fix is to compute and return the excess after a successful purchase.
Curves Protocol: Single token purchase restriction on curve creation enables sniping
Curves' getPrice() pricing formula contains an argument-order bug in the sum2 term: with the expression (supply - 1 + amount), Solidity evaluates left-to-right so that when supply is 1 and amount exceeds 1, the subtraction underflows and reverts. This forces a curve subject to buy only a single token on initialization when creating a curve directly (without a presale). Because the subject cannot lock in more tokens at the initial price, automated sniping bots can front-run the first purchase on social-token curves, forcing the subject to buy at inflated prices or lose out. Reordering the expression to (supply + amount - 1) eliminates the revert while preserving the intended price.
Curves Protocol: A subject creator within a single block can claim holder fees without holding due to unprotected reentrancy path
In Curves, the subject-fee transfer during buy/sell executes a full-gas low-level `call` to the subject before the holder-fee bookkeeping (`onBalanceChange`/`addFees`) runs. A subject creator who has minted wrapped external tokens and locked them on a bridge or AMM can reenter from their `receive()` hook on that fee transfer, deposit the locked tokens to restore their Curves balance, claim the newly-updated holder fees, and re-lock. Because the fee credits update only after the transfer, the subject collects holder fees roughly once per two buy/sell cycles despite not holding the balance outright. The judge confirmed the finding as Medium (loss of fees, not principal), corroborated by a foundry PoC and numerous duplicate submissions.
Curves Protocol: Protocol and referral fee would be permanently stuck in the Curves contract when selling a token
In Curves' bonding-curve token contract, the `_transferFee` sell path subtracts the protocol fee, subject fee, referral fee and holder fee from the sale proceeds but forwards only the net `sellValue` to the seller. Neither the deducted protocol fee nor the referral fee (when no referral address is configured) is subsequently paid out to its intended destination, so those sums remain permanently trapped in the contract with no withdrawal path. The Code4rena judge downgraded the finding from its initial severity to Medium — funds are stuck rather than stolen — and the Curves team acknowledged the issue. This affects every ordinary sell transaction, so the locked value grows in proportion to trading volume. A consolidated fix sends the combined protocol and referral fees to the protocol fee destination for both buy and sell flows.
Curves Protocol: Unauthorized Access to `setCurves` Function
Curves Protocol's FeeSplitter contract exposes a public `setCurves` function with no access control, allowing any caller to repoint the fee-splitter's reference to the Curves contract at an arbitrary address. Because the fee-splitter computes `getClaimableFees` by reading `curvesTokenBalance` and `curvesTokenSupply` from the referenced contract, an attacker can substitute a fake Curves implementation returning inflated balances and supplies, inflating their claimable fees and extracting value destined for legitimate token holders. The sponsor (andresaiello) confirmed the issue and recommended restricting `setCurves` to the owner or a trusted manager via the `onlyOwner`/`onlyManager` modifier. A brownie-style PoC demonstrates claimable fees jumping from 0 to roughly 1 ETH after the swap.
All reports in this group
- Curves Protocol: `onBalanceChange` causes previously unclaimed rewards to be clearedLogic error$0
- Curves Protocol: Stuck rewards in `FeeSplitter` contractLogic error$0
- Curves Protocol: Withdrawing with amount `= 0` will forcefully set name and symbol to default and disable some functions for token subjectFront-running / MEV$0
- Curves Protocol: If a user sets their curve token symbol as the default one plus the next token counter instance it will render the whole default naming functionality obsoleteLogic error$0
- Curves Protocol: Unrestricted claiming of fees due to missing balance updates in `FeeSplitter`Logic error$0