6.1 Users may receive slightly more tokens than intended due to rounding in borrow
When a user borrows USDS, the MonoCooler contract invokes the borrow(...) function in CoolerTreasuryBorrower. To facilitate the transfer of the requested USDS amount, the contract first calls SUSDS.previewWithdraw(amountInWad) to calculate the equivalent amount of sUSDS to withdraw from the treasury's reserves. This value is rounded up by previewWithdraw(...) to ensure that at least the requested USDS amount is covered.
After withdrawing the calculated sUSDS amount, the contract calls SUSDS.redeem(...), which transfers the corresponding USDS to the user:
function borrow(
uint256 amountInWad,
address recipient
) external override onlyEnabled onlyRole(COOLER_ROLE) {
// ...
// Since TRSRY holds sUSDS, a conversion must be done before funding.
// Withdraw that sUSDS amount locally and then redeem to USDS sending to the recipient
uint256 susdsAmount = SUSDS.previewWithdraw(amountInWad);
TRSRY.increaseWithdrawApproval(address(this), SUSDS, susdsAmount);
TRSRY.withdrawReserves(address(this), SUSDS, susdsAmount);
SUSDS.redeem(susdsAmount, recipient, address(this));
}
The issue arises because redeem(...) returns all USDS corresponding to the rounded-up sUSDS amount, potentially resulting in the user receiving slightly more than the intended amount of USDS. This excess is not accounted for in MonoCooler's internal records, introducing minor discrepancies.
While the dust amount is negligible under normal conditions (as the sUSDS price closely tracks USDS at 1:1), the discrepancy could become more significant if the sUSDS price deviates from USDS.
Recommendation
Consider using sUSDS.withdraw(...) instead of sUSDS.redeem(...) which will transfer the exact amount of USDS back to the user.
6.2 Borrowing doesn't always increase debt
Calculation of debt is always done by rounding up except when borrowed. This results in the scenario where someone can borrow 1 wei without increasing their debt.
function borrow(
uint128 borrowAmount,
address onBehalfOf,
address recipient
) external override returns (uint128 amountBorrowed) {
// ...
// Sync global debt state when borrowing
...
// @audit debt is calculated by rounding down
// don't round up the debt when borrowing.
uint128 currentDebt = _currentAccountDebt(
_accountDebtCheckpoint,
aState.interestAccumulatorRay,
gStateCache.interestAccumulatorRay,
false
);
// ...
}
Recommendation
Consider rounding up when calculating current debt in the borrow(...) function.
6.3 Debt with Treasury is not updated on liquidation
The MonoCooler contract facilitates lending of assets sourced from the Olympus Treasury. The CoolerTreasuryBorrower contract interacts with the treasury to withdraw assets during borrowing and return them during repayment. In both the borrow and repay operations, the CoolerTreasuryBorrower updates its recorded debt with the treasury accordingly.
However, when a liquidation occurs, the user’s debt is cleared within MonoCooler, but the corresponding debt recorded in the treasury remains unchanged. This creates an inconsistency between the actual state of loans and the debt values tracked by the treasury.
Such inconsistencies may lead to accounting discrepancies and could affect any processes or policies that rely on the accuracy of debt data maintained by the treasury.
Recommendation
Consider implementing a mechanism to update the treasury's debt records when a liquidation occurs.
6.4 Liquidation can be delayed by front running call to applyUnhealthyDelegations(...)
To liquidate an unhealthy position, the undelegated assets should be enough to cover the collateral to liquidate. The batchLiquidate(...) calls DLGTE.withdrawUndelegatedGohm(...) with autoRescindDelegations as true which will loop through the delegations and undelegate assets if required. Although the default value for the maximum number of delegations that can be done at a time is 10, admin can allow someone to have more than that. This means that if number of delegations is large enough such that looping through all the delegations and undelegating required assets can't be done in a single transaction, the applyUnhealthyDelegations(...) can be used to do this manually in multiple calls before calling batchLiquidate(...). The issue is that if the user front runs the call to applyUnhealthyDelegations(...) by changing their delegations then the call to applyUnhealthyDelegations(...) would revert. This allows to delay liquidating the position.
Recommendation
Consider adding a mechanism to not allow users with unhealthy positions to change their delegations such that to avoid getting liquidated.
6.5 Olympus Treasury may lose value due to rounding in SUSDS.deposit(...)
When a user repays their debt, the CoolerTreasuryBorrower contract deposits the repaid USDS into the SUSDS vault and sends the resulting SUSDS tokens to the treasury.
function repay() external override onlyEnabled onlyRole(COOLER_ROLE) {
uint256 debtTokenAmount = _USDS.balanceOf(address(this));
if (debtTokenAmount == 0) revert ExpectedNonZero();
// This policy is allowed to overpay TRSRY, in which case it's debt is set to zero
// and any future repayments are just deposited. There are no 'credits' for overpaying
uint256 outstandingDebt = TRSRY.reserveDebt(_USDS, address(this));
uint256 delta;
if (outstandingDebt > debtTokenAmount) {
unchecked {
delta = outstandingDebt - debtTokenAmount;
}
}
TRSRY.setDebt({
debtor_: address(this),
token_: _USDS,
amount_: delta
});
_USDS.safeApprove(address(SUSDS), debtTokenAmount);
// @audit - This function will round down the amount of `SUSDS` to deposit
SUSDS.deposit(debtTokenAmount, address(TRSRY));
}
The SUSDS.deposit(...) function calculates the number of shares based on the deposited amount but rounds down when issuing shares. This can result in a small loss of value for the receiver (the treasury) when the deposited amount is not perfectly divisible by the share price.
A malicious user could exploit this behavior by borrowing from MonoCooler and repaying their debt in multiple small transactions, each causing the treasury to lose up to 1 wei worth of SUSDS per repayment due to rounding. Over a large number of repayments, this could accumulate to a measurable value loss for the treasury.
However, the attacker does not directly benefit from this behavior. Borrowers must be gOHM holders, and diminishing the treasury's assets could negatively affect the value of gOHM, harming the attacker’s own position. Additionally, the treasury’s yield-generating strategies are likely to offset such minor losses.
Consider implementing monitoring or rate-limiting mechanisms on MonoCooler repayments to detect or mitigate repeated small repayments that could exploit rounding behavior.
Recommendation
Consider implementing monitoring mechanisms on MonoCooler repayments to detect repeated small repayments that could exploit rounding behavior.
