Digital Ceramic Ape
Medium
The mintSellFarm() function is designed to help rebalance the BOOST price while simultaneously growing the size of the liquidity pool. However, in certain scenarios, the addLiquidity component of the function can fail, leaving USDC in the contract and preventing the liquidity pool from growing as intended. By making the addLiquidity function public, this process could be retriggered publicly, ensuring that the USDC is properly utilized for farming, in line with the protocol’s documentation.
The mintSellFarm() function has two components: mintAndSell and addLiquidity. While the mintAndSell function can succeed, addLiquidity may revert if the price of BOOST falls outside of the allowed range (based on the range width). Because addLiquidity is not a public function, it cannot be triggered again directly to farm the remaining USDC, resulting in stuck collateral and failure to grow the pool.
Failure of private bot automation (e.g., a bot that triggers mintSellFarm) and a need to rely on public functions to trigger pool rebalancing manually.
Failure to add liquidity when mintSellFarm is triggered — this could occur if rebalancing is too partial or excessive, as seen in the issue regarding "Incorrect Pool Math in _mintSellFarm". External factors such as incorrect BOOST price ranges or rapidly changing pool conditions may also lead to failed liquidity addition.
This scenario can arise naturally without any malicious actors. However, when mintSellFarm and addLiquidity are not atomic, an attacker may be able to exploit the situation by manipulating the price or range width:
- At cost when the pool is small: By selling BOOST at a high price just before mintSellFarm is triggered, an attacker can manipulate the price to be out of the allowed range, causing addLiquidity to revert.
- At zero cost when the pool is large: If the pool is large enough, attackers could profit from selling BOOST at a high price before mintSellFarm is triggered, then use the profits to spam the addLiquidity conditions, effectively blocking the liquidity addition process.
The failure to grow the size of the liquidity pool automatically hinders the protocol’s ability to maintain a healthy and balanced liquidity pool, which could result in instability in the price of BOOST. This is a medium severity issue, as it does not immediately break the system but leads to inefficiencies that could affect long-term stability and liquidity.
No response
Make the addLiquidity function public, making it possible to call it manually when both automation fails and addliquidity in public mintsellfarm initially fails.
This ensures that any leftover USDC in the contract can still be used to grow the pool, preventing stuck liquidity and maintaining alignment with the protocol’s goals.
Alternatively, a check could be added to retry addLiquidity with all USDC in the contract at a later point if it initially fails due to range issues, ensuring that all collateral is eventually deployed as intended.