The Liquidate::liquidatorProfitCollateralToken function currently over-rewards liquidators due to combining collateral and borrow tokens, resulting in consistently high liquidator reward.
Audit: 2024-06-size-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/actions/Liquidate.sol#L95-#L100


# Vulnerability details

## Impact

The Liquidate::liquidatorProfitCollateralToken value should be in collateral tokens, not borrow tokens. Therefore, debtPosition.futureValue must be changed to debtInCollateralToken to prevent combining collateral and borrow tokens when the second option in liquidatorReward is chosen.

```javascript
    if (assignedCollateral > debtInCollateralToken) {
        uint256 liquidatorReward = Math.min(
            assignedCollateral - debtInCollateralToken,
            Math.mulDivUp(debtPosition.futureValue, state.feeConfig.liquidationRewardPercent, PERCENT)
        );
    liquidatorProfitCollateralToken = debtInCollateralToken + liquidatorReward;
```

This combination can result in an incorrect calculation of the `liquidatorProfitCollateralToken` value. In its present form, this calculation method provides the liquidator with a higher reward than necessary. Specifically, the calculation `(Math.mulDivUp(debtPosition.futureValue, state.feeConfig.liquidationRewardPercent, PERCENT))` produces a larger amount compared to the other calculation `(assignedCollateral - debtInCollateralToken)`.

This discrepancy occurs because the amount derived from `debtPosition.futureValue` is typically greater than `debtInCollateralToken`. If `debtPosition.futureValue` is replaced with `debtInCollateralToken`, the resulting fee would be significantly smaller than the first option. The protocol ends up consistently over-rewarding liquidators, impacting the overall financial efficiency and fairness of the liquidation process. Addressing this issue is crucial to ensure accurate and fair profit calculations for liquidators while maintaining balanced and equitable fees for the protocol.

## Proof of Concept

Consider following scenario:

- ETH price: $2000
- assignedCollateral - debtInCollateralToken = 3e18 - 2.3e18 = 0.7e18
- (Math.mulDivUp(debtPosition.futureValue, state.feeConfig.liquidationRewardPercent, PERCENT))
  - (Math.mulDivUp(4600e18 \* 0.05e18 / 1e18)
  - 230e18
- (Math.mulDivUp(debtInCollateralToken, state.feeConfig.liquidationRewardPercent, PERCENT))
  - (Math.mulDivUp(2.3e18 \* 0.05e18 / 1e18)
  - 0.115e18

1. The `assignedCollateral` is 3e18 and the `debtInCollateralToken` is 2.3e18 (reflecting a 130% collateral ratio).
2. Since `assignedCollateral` is greater than `debtInCollateralToken`.
3. The `liquidatorReward` is determined by choosing the lower value between 0.7e18 and 230e18.
4. Consequently, the `liquidatorReward` always selects 0.7e18 (the first option).
5. However, since the `liquidatorReward` is calculated in collateral tokens, 0.7e18 amounts to about 30% of the `debtInCollateralToken`.
6. If `debtPosition.futureValue` were changed to `debtInCollateralToken`, the `liquidatorReward` would be 0.115e18, which is 5% of the `debtInCollateralToken`.
7. This miscalculation results in financial losses for the