## Description The current design of Beraborrow allows redemption from dens with an ICR < MCR. This is done to accommodate the Brime Den, which is designed to have a lower MCR than other dens (unlike Prisma, which does not allow redemption from dens with an ICR < MCR). While an adjustment from the Prisma implementation is needed, allowing redemption from normal dens with an ICR < MCR can lead to a few problems. Liquidators are incentivized by receiving a percentage of the liquidated collateral plus debt gas compensation (constant value). By allowing redemption from a liquidatable den (ICR < MCR), the position’s collateral is reduced, and if the redemption does not bring the ICR above the MCR, the position remains liquidatable. By reducing the collateral, a liquidator who expects to receive percentage of `X` collateral may end up with only `X - n`(where `n` is the decreased collateral from redemption) if a redemption occurs right before the liquidation transaction is executed. This can happen unintentionally or maliciously by frontrunning liquidator's transaction. Another grief scenario is possible - once a den becomes liquidatable, it can always be redeemed from by anyone. This opens up a possibility for an off-chain bot to always frontrun liquidators by making the den to be liquidated healthy again. While this does not incur direct loss of funds for any interested party, it prevents all rewards expected from the liquidation (liquidator, sNectGauge, validatorPool benefit from the liquidation). ## Proof of Concept First, we need to take a look into `DenManager::redeemCollateral()` implementation to choose the den to redeem from: ```solidity if (_isValidFirstRedemptionHint(_sortedDensCached, _firstRedemptionHint, totals.price)) { currentBorrower = _firstRedemptionHint; } else { currentBorrower = _sortedDensCached.getLast(); // Find the first den with ICR >= MCR while (currentBorrower != address(0) && getCurrentICR(currentBorrower, totals.price) < _100pct) { currentBorrower = _sortedDensCached.getPrev(currentBorrower); } } ``` ```solidity function _isValidFirstRedemptionHint( ISortedDens _sortedDens, address _firstRedemptionHint, uint256 _price ) internal view returns (bool) { if ( _firstRedemptionHint == address(0) || !_sortedDens.contains(_firstRedemptionHint) || getCurrentICR(_firstRedemptionHint, _price) < _100pct ) { return false; } address nextDen = _sortedDens.getNext(_firstRedemptionHint); return nextDen == address(0) || getCurrentICR(nextDen, _price) < _100pct; } ``` We see that we always start with the den with lowest ICR and ICR > 100%. Same, except ICR > 100%, can be seen in Prisma's [implementation](https://github.com/prisma-fi/prisma-contracts/blob/63f3d08d6d7ae9fc74855a489eeae080b72a3f46/contracts/core/TroveManager.sol#L674C1-L682C10). I am not going to go through whole liquidation code flow, just the `DenManager::finalizeLiquidation()` part where compensations are send: ```solidity function finalizeLiquidation( address _liquidator, uint256 _debt, uint256 _coll, uint256 _collSurplus, uint256 _debtGasComp, uint256 _collGasComp ) external { ... // Split collateral and debt compensation between liquidator, sNect guage and validator pools. // Send compensation tokens to liquidator ILiquidationManager.LiquidationFeeData memory data = ILiquidationManager(liquidationManager).liquidationsFeeAndRecipients(); debtToken.returnFromPool(gasPoolAddress, _liquidator, _debtGasComp * data.liquidatorFee / DECIMAL_PRECISION); // Send compensation tokens to sNect Gauge debtToken.returnFromPool(gasPoolAddress, data.sNectGauge, _debtGasComp * data.sNectGaugeFee / DECIMAL_PRECISION); // Send compensation tokens to validator pool debtToken.returnFromPool(gasPoolAddress, data.validatorPool, _debtGasComp * data.poolFee / DECIMAL_PRECISION); _sendCollateral(_liquidator, _collGasComp * data.liquidatorFee / DECIMAL_PRECISION); _sendCollateral(data.sNectGauge, _collGasComp * data.sNectGaugeFee / DECIMAL_PRECISION); _sendCollateral(data.validatorPool, _collGasComp * data.poolFee / DECIMAL_PRECISION); } ``` In `LiquidationManager::_liquidateWithoutSP()` and `LiquidationManager::_liquidateNormalMode()` we can see that collateral compensation is calculated as follows: ```solidity singleLiquidation.collGasCompensation = _getCollGasCompensation(singleLiquidation.entireDenColl); ``` ```solidity function _getCollGasCompensation(uint256 _entireColl) internal pure returns (uint256) { return _entireColl / PERCENT_DIVISOR; } ``` Coded PoC: Add the following test in `LiquidationManager.t.sol`: ```solidity function test_liquidate_after_redeem() external { // Depositor's position with collateral 16e17 and debt amount 1e18, ICR = 160% _openDen(depositor); // Makes depositor's position ICR higher so that it wont be first redeemed den and if price drops TCR to be over CCR _addCollateralToDen(10e18); // Random's position with collateral 16e17 and debt amount 1e18, ICR = 160% _openDen(random); vm.warp(block.timestamp + 12 seconds); // Lowering wBera price to put random's position ICR < MCR _mockPriceFeed(beraFeed, 7e17, block.timestamp, 2); console2.log("DenManager MCR: %s", denManager.MCR()); console2.log("Random's position ICR: %s", denManager.getCurrentICR(random, 7e17)); address redeemer = makeAddr("redeemer"); deal(address(nectarToken), redeemer, 4e17); vm.prank(redeemer); uint256 partialRedemptionHintNICR = 170011805300799266360; // Redeemer makes the position healthier but with ICR still lower than MCR -> still liquidatable denManager.redeemCollateral(4e17, random, address(0), address(0), partialRedemptionHintNICR, 0, 1e18); console2.log("Random's position ICR after redemption: %s", denManager.getCurrentICR(random, 7e17)); uint256 liquidatorwBeraBalanceBefore = IERC20(wBERA).balanceOf(liquidator); liquidationManager.liquidate(denManager, random, liquidator); uint256 liquidatorwBeraBalanceAfter = IERC20(wBERA).balanceOf(liquidator); console2.log("Liquidator reward: %s", liquidatorwBeraBalanceAfter - liquidatorwBeraBalanceBefore); } ``` ```text Logs: DenManager MCR: 1200000000000000000 Random's position ICR: 1114427856455924352 Random's position ICR after redemption: 1190082637105594864 Liquidator reward: 514285714285714 ``` If you comment the part with redeeming, you get the following logs: ```text Logs: DenManager MCR: 1200000000000000000 Random's position ICR: 1114427856455924352 Liquidator reward: 800000000000000 ``` This makes ~ 35% difference than what the liquidator expects and what he gets. Based on Foundry execution, the gas cost for calling `liquidate()` is approximately 420,000. Under current gas prices on Berachain, given the price of the BERA token and a minimum debt amount of 100 (which means the collateral must be worth at least $100 in an overcollateralized position), liquidation gas costs cannot exceed the minimum liquidation reward. However, if Berachain’s usage grows—resulting in higher gas prices and an increased BERA token price—a liquidator could potentially receive less in liquidation rewards than the cost of execution. ## Recommendation Consider having a different branch in the code to handle Brime Den redemptions and disallow redeeming from a den when ICR < MCR. Brime Den will also not last forever, so I believe it is better to handle it separately than other dens and leave the ICR check to be < MCR.

Contest	Position	Date	Payout
liquity-bold	2 / 822	March 2025	$27,792
beraborrow-blockend	5 / 65	February 2025	$986
symbioticfi-core	11 / 417	September 2024	$212

vinicaboy

Top competitions