xiaoming90 - Inconsistent in the liquidation fee leads to unfairness in liquidation process #52
Labels
Sponsor Disputed
The sponsor disputed this issue's validity
Won't Fix
The sponsor confirmed this issue will not be fixed
xiaoming90
High
Inconsistent in the liquidation fee leads to unfairness in liquidation process
Summary
Reserve vault results in unfairness in the liquidation process. PartyA using force close mechanism to liquidate a position will receive more liquidation fees compared to normal liquidators as they have access to the funds in the reserve vault.
This creates unfairness to the protocol's liquidation process and to the existing liquidators, as they will receive lesser liquidation fees than Alice (PartyA). Without a fair and effective liquidation process, the protocol's solvent will be at risk, as bad positions will not be liquidated in a timely manner, and some liquidators might not want to participate in the process due to unfairness in the system.
Root Cause
Internal pre-conditions
No response
External pre-conditions
No response
Attack Path
Assume that PartyB's reserve vault has 1000 USD. During force closing, if PartyB's account is underwater, even with the additional support from its reserve vault, PartyB's account will be liquidated, as per Lines 127-138 below.
In Lines 128 and 129, the protocol transfers all the existing funds (1000 USD) from PartyB's reserve vault to PartyB's allocated balance. Thus, before the liquidation process is executed at Line 137 below, the PartyB's allocated balance will increase by 1000 USD.
https://github.com/sherlock-audit/2024-09-symmio-v0-8-4-update-contest/blob/main/protocol-core/contracts/facets/ForceActions/ForceActionsFacetImpl.sol#L127
As a result, when the
LibLiquidation.liquidatePartyB
is executed at Line 137 above, the computedavailableBalance
will be 1000 USD smaller when the liquidation process is triggered via theforceClosePosition
function compared to the standard liquidation process that is triggered viaLiquidationFacet.liquidatePartyB
by the liquidators, as shown below. This can be proven via the formula withinpartyBAvailableBalanceForLiquidation
function.Assume Alice is entitled to execute the force close function against PartyB, while Bob is a normal liquidator that can only liquidate PartyB via the standard
LiquidationFacet.liquidatePartyB
function.When Alice triggers the liquidation process, the
availableBalance
will be-100
instead of-1000
. Thus, when computing the liquidation fee that the liquidator is entitled to at Line 39 below, the computed liquidation fee (remainingLf
) will be higher. This means that if Alice triggered the liquidation process, she would receive more liquidation fees compared to Bob because she has access to funds within PartyB's reserve vault. In this case, Alice is the liquidator and will receive the liquidation fee.As a result, this creates unfairness within the system and to the existing liquidators as they (e.g., Bob) will receive lesser liquidation fees compared to Alice.
https://github.com/sherlock-audit/2024-09-symmio-v0-8-4-update-contest/blob/main/protocol-core/contracts/libraries/LibLiquidation.sol#L29
Impact
This creates unfairness to the protocol's liquidation process and to the existing liquidators, as they will receive lesser liquidation fees than Alice. Without a fair and effective liquidation process, the protocol's solvent will be at risk, as bad positions will not be liquidated in a timely manner, and some liquidators might not want to participate in the process due to unfairness in the system.
PoC
No response
Mitigation
The liquidation process for Alice and existing liquidators should be consistent to ensure fairness. In the above case, consider either of the following solutions:
forceClosePosition
function; ORLiquidationFacet.liquidatePartyB
for consistency.The text was updated successfully, but these errors were encountered: