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
- 12
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 12 closed, publicly disclosed Yieldoor 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, Oracle manipulation, 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
- Integer overflow / underflow findings disclosed against Yieldoor
- Logic error findings disclosed against Yieldoor
- Oracle manipulation 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: `Vault::_calcDeposit()` will overflow for low priced tokens
Yieldoor's Vault._calcDeposit() computes minted shares as the product depositAmount * bal * totalSupply in one un-downscaled numerator. Because each operand carries 18 decimals, the intermediate already occupies ~1e54 of the 256-bit range, leaving only about 1e23 headroom; once balance and total supply each reach ~1e9, headroom collapses to ~1e5, so any deposit beyond roughly 100,000 units overflows and reverts. For tokens priced at 0.01 USD or less, ordinary user deposits routinely exceed that limit, making deposits fail and users miss yield and favorable pool entry prices. The overflow keeps failing until a withdrawal shrinks balances, and for very large balances and supplies of low-priced tokens depositing can become impossible entirely. The proposed fix is to downscale precision between the intermediate multiplication steps.
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)`.
Yieldoor: `Vault::withdraw()` withdraws too much liquidity leading to idle capital and loss of fees
Yieldoor's Vault.withdraw() computes a redeemer's owed amount as a proportional slice of the strategy's total balance and, whenever the idle balance is insufficient, unwinds that full amount from the LP position. It fails to subtract the idle capital already available, so it withdraws more liquidity than needed and leaves the excess dormant. Because idle capital earns no fees, every partial withdrawal that is partially covered by idle funds permanently forfeits yield on the unnecessarily unwound liquidity. The report supplies the verbatim withdraw() code and a one-line mitigation to net idle balances into the share computation.
Yieldoor: `Strategy::checkPoolActivity()` does not look as far back as it should
Yieldoor's Strategy::checkPoolActivity() contains an off-by-one error in its TWAP-based price sanity check used before rebalancing. The function is designed to inspect observations back past a lookAgo timestamp, but because it compares the lookAgo timestamp against the second-most-recent observation while evaluating the tick of the most-recent one, it halts one observation early. This makes the rebalance-time price validation incomplete, allowing a position to be deployed at a stale or manipulated price. The mis-priced deposit is then arbitraged away, causing a loss of funds for the protocol. No external preconditions are required for the flaw to manifest.
Yieldoor: Locked funds due to underflow in withdrawal
Yieldoor's Leverager.withdraw contains a copy-paste error in the branch where the borrowed asset equals token1: the ternary that caps the repaid amount references amountOut0 (the token0 balance) instead of amountOut1 (the token1 balance). When a borrower's token1 withdrawal proceeds are smaller than the owed amount while the token0 balance is larger, the repayment amount exceeds owedAmount, so the subsequent subtraction underflows and reverts under Solidity 0.8 checked arithmetic. This denies withdrawals and can lock funds for token1 borrowers, and could in principle be repeatedly induced as a denial-of-service. The finding was confirmed as a Medium in Sherlock contest 791.
Yieldoor: Liquidation fee will not be claimed due to incorrect decimal handling
Yieldoor's Leverager contract computes the USD value of a position's debt by dividing by ERC20(denomination).decimals() instead of 10 ** decimals(), inflating borrowedValue by many orders of magnitude. Because the liquidation-fee branch only triggers when totalValueUSD exceeds borrowedValue, the inflated debt value makes that branch unreachable in genuinely profitable liquidations, so the configured liquidation fee is silently never paid to the feeRecipient. A mainnet-fork PoC demonstrates the failure: with position value ~90k USD and true debt ~88.8k USD the code computed borrowedValue at ~4.93e21, and the fee recipient received zero. The one-line fix restores correct power-of-ten scaling.
All reports in this group
- Yieldoor: Integer overflow in observation index calculation leads to denial of serviceInteger overflow/underflow$0
- Yieldoor: `Strategy::checkPoolActivity()` incorrect check leads to vulnerable priceOracle manipulation$0
- Yieldoor: `Leverager::deposit`, does not support multi-hop swaps with `exactOutput`Logic error$0
- Yieldoor: Incorrect modulo calculation in secondary position ticks leads to active position and division by zeroLogic error$0
- Yieldoor: Incorrect tick parameter in collectFees() function leads to loss of vesting position fees or possible complete protocol lockupLogic error$0
- Yieldoor: Strategy main ticks are set according to the tick in slot0, leading to incorrect allocation and loss of fundsLogic error$0