Liquid Staking

Summary

The PriorityPool contract allows an unlimited number of accounts to be added to the accounts array, potentially leading to scalability issues and increased vulnerability to DoS attacks.

Impact

• High gas costs for operations that iterate over all accounts

• Potential DoS vulnerability

• Increased storage costs

• Scalability challenges for off-chain processes dealing with Merkle tree generation

Where is the issue and what causes it?

The issue is in the _deposit function:

This function adds new accounts to the accounts array without any upper limit. The root cause is the lack of a maximum cap on the number of accounts that can be added to the pool.

Proof of concept

An attacker could create numerous small deposits from different addresses:

This would add 1000 new accounts to the accounts array, potentially making operations like getAccountData() prohibitively expensive.

Recommendations

1. Implement a maximum limit on the number of accounts:

1. Introduce a minimum deposit amount to discourage creation of many small deposits.

2. Implement a mechanism to remove inactive accounts periodically, freeing up space for new active users.

3. Consider using a more gas-efficient data structure for managing accounts, such as a mapping with a separate array for active account addresses.