Summary

The separation between the state-reading function (checkLiquidatableAccounts) and the state-altering liquidation function (liquidateAccounts) introduces a race condition. The list of liquidatable accounts obtained from checkLiquidatableAccounts can quickly become outdated if an account's collateral is modified before the actual liquidation call, leading to liquidators potentially incurring gas fees for accounts that are no longer eligible.

Vulnerability Details

The checkLiquidatableAccounts function scans a range of account IDs and returns those that appear to be below the maintenance margin at the time of the call:

However, between the time these account IDs are returned and when liquidateAccounts is executed, the on-chain state (e.g., user margin deposits or position modifications) may change. Consequently, by the time liquidation is attempted, some accounts might no longer meet the criteria. Although liquidateAccounts revalidates each account and skips non-liquidatable ones, liquidators still risk wasting transaction fees or experiencing operational confusion due to stale data.

Impact

• Wasted Gas Fees: Liquidators might incur unnecessary transaction costs by attempting to liquidate accounts that are no longer liquidatable.

• Operational Inefficiency: The discrepancy between the view call and the actual liquidation process may lead to confusion and reduce the reliability of automated liquidation mechanisms.

• User Experience: Liquidators relying on stale data may face challenges in timing their liquidation transactions, affecting overall market efficiency.

Tools Used

• Manual Code Review: Detailed analysis of the separation between state-reading and state-changing functions highlighted the potential race condition.

• Static Analysis Tools: Automated tools confirmed the non-atomic nature of the account selection and liquidation processes.

• Simulation Testing: Scenario-based simulations demonstrated how rapid state changes could lead to discrepancies between the data returned by checkLiquidatableAccounts and the actual conditions during liquidateAccounts.

Recommendations

• Atomic Liquidation Mechanism: Consider designing an atomic liquidation process where the selection and liquidation of accounts occur in a single transaction or under a single state snapshot.

• Timestamp or Nonce Inclusions: Include a timestamp or version number with the liquidation data from checkLiquidatableAccounts to help liquidators assess the freshness of the data.

• Enhanced Documentation: Clearly document the inherent race condition, advising liquidators to account for possible state changes and the associated risks.

• Off-Chain Coordination: Utilize off-chain monitoring and validation services that can provide more synchronized liquidation triggers, reducing the dependency on stale on-chain data.