BMX Deli Swap — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for BMX Deli Swap, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 13
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 13 closed, publicly disclosed BMX Deli Swap 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 Integer overflow / underflow, Logic error, across EVM-Solidity, Move. 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
- Integer overflow / underflow findings disclosed against BMX Deli Swap
- Logic error findings disclosed against BMX Deli Swap
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
BMX Deli Swap: Attacker can swap wBTC in the DeliHook multiples times to not pay / pay less swap fees
DeliHook's fee conversion for swappable tokens rounds the computed baseFeeSpecified down instead of up, so on small wBTC-amount swaps the fee truncates to zero wei, letting an attacker swap repeatedly without paying LP fees. Because wBTC has a high USD value per wei while gas on Base is cheap, iterating many small swaps in a bundled loop makes the exploit economically self-sustaining. The protocol confirmed the finding as a legitimate fee-loss bug and fixed it by rounding fee computations up in a follow-up PR.
BMX Deli Swap: Users always pay fee on the full swapped amount in the `DeliHook`, even if the swap is smaller
BMX Deli Swap's DeliHook, a Uniswap v4-style hook, computes its swap fee on the full user-specified input amount instead of the amount the pool actually matched. Because a swap can stop early when a user-set sqrtPrice limit is hit or when one side of the pool is exhausted, only a fraction of the input may be exchanged while the fee is still charged on 100% of it. This systematically overcharges the user, and the overcharge grows proportionally with the unswapped portion of the intended input. The finding was recorded as a medium-severity logic error in the Sherlock contest.
BMX Deli Swap: `DeliHookConstantProduct` swapping `exactOutput` and `_feeFromOutput` is incorrect
DeliHookConstantProduct is a Uniswap v4 hook that preserves the invariant K across all swap types so that swap fees can be forwarded to a FeeProcessor. For exactOutput swaps in the oneForZero direction (zeroForOne == false), the hook computes _pendingFeeAmount as amountSpecified * fee / 1_000_000, charging the fee against the user's specified output amount rather than the actual input amount that drives the swap. Working through a 1000/1000 reserve pool with a 1% fee, a user swapping 90.08 token0 out pays 100.089 token1 in exactOutput mode versus exactly 100 token1 in the analogous exactInput mode, a fee overcharge of roughly 8.9%. Because the K equation still balances, the reserves stay consistent, which masks the error; the surplus is captured by the FeeProcessor at the user's expense. The report is a Sherlock Medium finding (issue M-5) that was upheld as valid.
BMX Deli Swap: In the `IncentiveGauge._upsertIncentive()` function, `_updatePoolByPid()` should be called outside the `if` statement
In BMX Deli Swap's IncentiveGauge, _upsertIncentive() only refreshes pool accounting when the pool already has an active reward rate, so applying a fresh incentive to a pool whose rewardRate is zero leaves the pool's lastUpdated timestamp stale even though the new reward begins releasing from the current timestamp. On the next accounting update, released rewards are computed over the overstated window between the stale pool timestamp and the update time, inflating the amount captured as released. That inflation leaves the pool short of real distributable reward balance, which can make reward claims fail and prevent position burning or liquidity removal. The protocol fixed this by moving _updatePoolByPid() outside the conditional so the pool is always refreshed before a new schedule is written (PR morphex-labs/deli-swap-contracts/pull/21).
BMX Deli Swap: Unconditional lastUpdated advance in RangePool.sync leads to loss of streamed BMX when pool liquidity == 0
BMX Deli Swap's concentrated-liquidity reward gauge can strand streamed BMX tokens when a pool has zero active liquidity at the moment of a sync. RangePool.sync updates lastUpdated before applying per-token accumulation, and accumulation is gated on liquidity > 0, so when liquidity is zero the elapsed-window amounts are skipped while lastUpdated still advances. The next sync therefore only credits amounts since the advanced timestamp, and the tokens that streamed during the zero-liquidity window remain trapped in the gauge balance, unreachable by any LP position even after liquidity returns. The correctness failure means protocol revenue intended for LPs is effectively sidelined, a lasting distribution impact rather than an immediate theft.
BMX Deli Swap: Finalize-window vote-changing vulnerability: auto-voters can alter choices post-epoch to manipulate results
BMX Deli Swap's Voter contract fails to freeze or snapshot auto-vote choices when an epoch ends, so auto-voters remain able to enable, switch, or re-weight their vote after the epoch is closed but before the admin runs the batched finalize. Because _tallyAutoVotes reads the live autoOption and SBF_BMX balance at tally time instead of state recorded at epoch end, a well-funded voter can retroactively rewrite the settled outcome for a past epoch, steering WETH allocation between the safety module and reward distributor and overriding honest voters' intended distribution.
All reports in this group
- BMX Deli Swap: Integer Truncation in Incentive Rate Permanently Locks Unstreamed RewardsLogic error$0
- BMX Deli Swap: Protocol fee conversion uses pre‑swap price snapshotLogic error$0
- BMX Deli Swap: Gas consumed in `notifyUnsubscribe` is underestimated during tests and is greater than 300,000 without pre-warmingLogic error$0
- BMX Deli Swap: Reward Token Loss for LPs During NFT Position TransferLogic error$0
- BMX Deli Swap: Users' voting weight can be double-counted when finalize epoch is processed in multiple stepsLogic error$0
- BMX Deli Swap: `Voter::finalize()` incorrect rewards distribution due to transfering WETH before calling `distributor::setTokensPerInterval()`Logic error$0
- BMX Deli Swap: DoSed `Voter::finalize()` due to unbounded pending removals lacking a batch argument variableLogic error$0