Part 2

Summary

In the liquidation process, the protocol uses the absolute value of the account’s unrealized PnL when deducting margin. This causes accounts that are actually in profit to be overcharged—effectively confiscating their positive PnL—because the liquidation mechanism treats gains as losses.

Vulnerability Details

Inside the liquidateAccounts(...) function, the margin to deduct is calculated by adding the required maintenance margin to the absolute value of the unrealized PnL. Specifically, the snippet:

Impact

• Financial Loss for Users

• Unfair Liquidation

• Reputational Damage

Tools Used

• Manual Code Review: A detailed inspection of the liquidation logic in LiquidationBranch.sol.

• Static Analysis Tools: Identification and flagging of the misuse of the abs() function in financial computations.

• Unit Testing & Simulation: Simulated liquidation scenarios were used to evaluate how the margin deduction behaves when the unrealized PnL is positive.

Recommendations

• Conditional PnL Handling: Modify the margin deduction logic so that it conditionally handles PnL:

  • Apply the absolute value only for negative (loss) scenarios.

  • For positive PnL, do not add the profit to the maintenance margin, allowing the profit to offset the margin requirement.

• Reevaluate Margin Calculations: Review the liquidation requirements to ensure that the calculated margin properly reflects both losses and gains, avoiding the confiscation of positive PnL.

• Implement Comprehensive Tests: Introduce unit and integration tests that cover both profit and loss cases during liquidation to validate the corrected logic under various market conditions.

• Peer Audit: Once changes are implemented, have an external audit or peer review to verify that the new mechanism correctly handles the nuances of profit and loss during liquidation.