Yieldoor — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Yieldoor, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Yieldoor 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 Yieldoor
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Yieldoor: Incorrect modulo calculation in secondary position ticks leads to active position and division by zero
Yieldoor's Uniswap V3 strategy keeps a main liquidity position evenly balanced and a secondary position that must remain out-of-range holding just one token. In _setSecondaryPositionsTicks the code computes the tick remainder without correcting for negative ticks, unlike the main-position code that adds tickSpacing back when the modulo is negative. This miscalculation places the secondary position in-range when it should stay out-of-range, and under a specific combination of positionWidth, a negative current tick, and the balance branch can collapse tickLower and tickUpper to the same value, driving a division-by-zero revert in LiquidityAmounts#getLiquidityForAmounts that bricks rebalancing. The fix is a one-line adjustment reusing the same negative-modulo correction already present in _setMainTicks.
Yieldoor: Incorrect tick parameter in collectFees() function leads to loss of vesting position fees or possible complete protocol lockup
Yieldoor's Strategy.collectFees() mistakenly passes mainPosition.tickUpper instead of vestPosition.tickUpper when collecting fees for an ongoing vesting position. Since rebalance() rewrites the main position's ticks via _setMainTicks() while the vesting position keeps its original ticks, the two can diverge. When vestPosition.tickLower becomes greater than mainPosition.tickUpper, the underlying Uniswap V3 collect() call reverts with the TLU error, bricking collectFees() and everything built on it (deposit, withdraw, rebalance, compound). Because the vesting position can only be closed through _withdrawPartOfVestingPosition() called from collectFees(), the revert creates a permanent protocol lockup and loss of uncollected vesting fees.
Yieldoor: Strategy main ticks are not symmetric when the tick spacing is one due to incorrect isLowerSided inequality
Yieldoor's Strategy._setMainTicks computes whether the current tick rounds up or down using a strict less-than comparison `modulo < (tickSpacing / 2)`. When tickSpacing equals 1, this comparison always evaluates true, so the tickBorder is always rounded down to the current tick. Combined with a fixed halfWidth, the resulting main position range becomes asymmetric around the current price, e.g. price tick -1769 yields tickLower -1770 and tickUpper -1766. Because one side of the range is thinner than the other, the position allocates less liquidity on one flank and collects fewer swap fees whenever the price moves in that direction. The finding was upheld as medium by the Sherlock judge and is fixed by changing the comparison to `modulo <= (tickSpacing / 2)`.