The initiateLiquidation function in the LendingPool contract is designed to begin the liquidation process if a user's health factor falls below a specified threshold. However, the function currently reverts with the error HealthFactorTooLow() when the user's health factor is above the liquidation threshold. This is incorrect according to the intended design; it should instead revert with NotUnderLiquidation(). As a result, callers receive misleading error messages, leading to confusion and potential mis-handling of error cases in the system.
Current Logic:
The function first checks if the user is already under liquidation, then updates the reserve state and calculates the user's health factor. If the health factor is above the liquidation threshold, it reverts with HealthFactorTooLow().
Intended Behavior:
When a user’s health factor is above the threshold, the function should revert with NotUnderLiquidation(), signaling that the user is not eligible for liquidation. The current implementation incorrectly uses HealthFactorTooLow(), which misleadingly suggests that the health factor is too low when it is, in fact, healthy.
Setup:
A user (e.g., Alice) deposits collateral and borrows funds such that her health factor remains above the liquidation threshold.
Liquidation Initiation Attempt:
Bob attempts to initiate liquidation on Alice by calling initiateLiquidation(ALICE).
Since Alice's health factor is above the threshold, the function should revert with NotUnderLiquidation().
Instead, it reverts with HealthFactorTooLow(), which is misleading and does not correctly communicate the true state of Alice’s account.
Test Suite Verification:
A test case confirms that when a healthy user is targeted for liquidation, the revert error emitted is HealthFactorTooLow(). The expected behavior is for the function to revert with NotUnderLiquidation(), indicating that liquidation should not be initiated.
Create a Foundry Project:
Open your terminal and run:
Place Contract Files:
Place all relevant contract files (e.g., LendingPool.sol, RAACNFT.sol, RAACHousePrices.sol, etc.) into the src directory of your project.
Create Test Directory:
Create a directory named test adjacent to the src directory, and add the test file (e.g., PoolsTest.t.sol) containing the test suite code provided above.
Run the Test:
Execute the following command in your terminal:
This command will run the specific test case with verbose output, allowing you to verify that the correct error (NotUnderLiquidation()) is not being emitted when the user's health factor is above the liquidation threshold.
Misleading Error Handling:
The incorrect error emission (HealthFactorTooLow() instead of NotUnderLiquidation()) leads to confusion for integrators and users, as the error message does not accurately reflect the user’s actual liquidation status.
Incorrect System Behavior:
Downstream systems or automated monitoring tools that depend on specific error codes for handling liquidation logic might misinterpret the state, potentially leading to incorrect responses or failed error handling.
Operational Inefficiency:
Developers and auditors may waste time troubleshooting this misleading error, impacting the overall reliability and maintainability of the protocol.
Manual Review
Foundry (Forge)
Update the error check in the initiateLiquidation function to revert with NotUnderLiquidation() when the user's health factor is above the liquidation threshold. This change will ensure that the error message accurately reflects that the user is not eligible for liquidation.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.