Manipulating stake allocation between modules

[avsetsin]

The Staking Router relies on the targetShare of modules for distributing the stake between them and prioritizes staking to modules with a smaller amount of stake than others using the MinFirstAllocationStrategy. This algorithm is expected to allocate the stake evenly between the modules according to their limits.

On the other hand, ETH in the buffer can be locked to cover demand in the Withdrawal Queue, which can be exploited to manipulate the direction of deposits. The demand that appears between two deposit transactions to the modules reduces the amount of stake considered for allocation between modules during the first deposit.

Example

Let's take a look at the example below.

Module A

• Active validators: 5
• Depositable keys: 100
• Target share: unlimited

Module B

• Active validators: 1
• Depositable keys: 100
• Target share: unlimited

It is expected that the priority for allocating deposits should be given to module B until its share equals module A, after which the stake should be allocated evenly.

Thus, when allocating stake for 4 validators (4*32 ETH), it is expected:

• Module A: 5 -> 5 active validators
• Module B: 1 -> 5 active validators

And the further stake, for example, for 10 validators (10*32 ETH), will be allocated evenly:

• Module A: 5 -> 10 active validators
• Module B: 5 -> 10 active validators

If we attempt to allocate the stake for these 14 validators between the two modules at once, we will see the following allocation:

• Module A: 5 validators (5 -> 10)
• Module B: 9 validators (1 -> 10)

The current stake allocation algorithm in the Staking Router will allow a deposit in module A for 5 validators and a deposit in module B for 9 validators. If the first deposit goes to module A and then the demand in the Withdrawal Queue increases, there may no longer be enough eth in the buffer for a deposit to module B. The allocation would be:

• Module A: 10 active validators
• Module B: 1 active validator

(Note that DSM does not allow deposits to occur too frequently, explicitly forbidding deposits into two modules at once)

Exploitation

If signatures are publicly available, a sophisticated actor can manipulate the destination module, e.g. censor deposits to a specific module, redirecting them to others and locking usage of ETH in the buffer by creating a Withdrawal Request.

Mitigation

Currently, DSM mitigates the problem offchain. Guardians' signatures for deposits are sent to private data bus, and the depositor bot algorithm determines the order of deposits to the modules.

Expected behavior

Onchain algorithm for stake allocation takes into account possible available buffer reduction on allocation and asynchrony of deposits to different modules.