Liquid Staking

Here

Description:
The current withdrawal mechanism in the Priority Pool (PP) processes immediate withdrawals without following the First-In-First-Out (FIFO) principle, which can lead to unfair queue jumping or front-running opportunities. In the PP, users can withdraw directly if liquidity is available, but the system reduces the global totalQueued value without tracking which user's tokens were queued first. This allows newer withdrawal requests to potentially be processed before older ones, breaking the expected fairness of a queue.

It is important to note that, after the PP withdrawal is executed, if there is not enough liquidity to satisfy all queued withdrawals, the system transfers remaining withdrawal requests to the Withdrawal Pool, which does follow the FIFO principle. This means the issue primarily concerns withdrawals processed directly from the PP before liquidity runs out. However, this inconsistency in queue handling between the PP and WP could still lead to unfair treatment in certain cases, especially if large withdrawals from newer users deplete liquidity before older requests are processed.

Impact:

1. Queue Jumping in Immediate Withdrawals: Users who queue withdrawals later can have their requests processed before users who have been waiting longer, causing unfair outcomes.

2. Front-running Risk: Malicious actors could monitor liquidity and strategically initiate their withdrawal calls before older requests, potentially receiving their funds first by front-running the queue, which undermines the fairness of the withdrawal system.

3. Inconsistent Queue Handling: The fact that the WP follows FIFO while the PP does not creates a disparity in how withdrawal fairness is handled across the system. Users may perceive this inconsistency as unfair, as some users could benefit from immediate withdrawals while others must wait in the WP queue.

4. User Trust Degradation: In decentralized protocols, fairness is crucial for maintaining trust. Users who see their withdrawals delayed while newer requests are processed may lose confidence in the system's fairness, even though the WP eventually enforces FIFO order.

Proof of Concept:
Consider this scenario:

• User A requests a withdrawal of 100 tokens at time T1 and is queued in the PP.

• User B requests a withdrawal of 50 tokens at time T2 (after User A).

If User B triggers a withdrawal from the PP and there is enough liquidity, User B's request will be satisfied before User A's, despite User A being first in the queue. If liquidity runs out during User B's withdrawal, User A will be moved to the WP, where FIFO order will eventually ensure they are processed first. However, this does not prevent User B from receiving their withdrawal earlier due to immediate liquidity availability in the PP.

For example, the following part of the _withdraw function processes queued tokens without ensuring FIFO order:

This process treats all queued tokens equally and does not respect the order in which they were added to the queue. As a result, users who call the withdrawal function first (e.g., User B) could have their requests fulfilled before those who queued earlier (e.g., User A), which violates the FIFO principle.

Recommended Mitigation:
To resolve this issue and ensure fairness in all stages of withdrawal, the following steps are recommended:

1. Implement FIFO in PP for Immediate Withdrawals:
   Introduce a queue structure within the PP itself to ensure that even immediate withdrawals follow a FIFO order. This could involve tracking individual user withdrawal requests in a data structure such as a mapping or array that preserves the order of requests:

1. Track Queued Withdrawals by User:
   When a user queues their withdrawal request in the PP, their request should be added to the pendingWithdrawals array in the order it was made. When liquidity becomes available, withdrawals should be processed from the earliest request first, ensuring fair execution based on queue position.

2. Consistent Queue Handling Between PP and WP:
   Ensure that the same FIFO logic applies consistently in both the PP and WP. This could be achieved by integrating similar queue management systems between the two pools, avoiding discrepancies in how withdrawals are processed across different parts of the system.

3. Fair Processing of Withdrawal Requests:
   Modify the withdrawal logic in the PP so that liquidity is allocated to the oldest withdrawal requests first, before processing newer requests. This prevents queue jumping and ensures that users are treated fairly, regardless of whether they withdraw directly from the PP or are moved to the WP.