Direct-like Deposits proposal for a 3rd-party Vault

Overview

With the increase in the share of the SimpleDVT module and the demand for more targeted allocation of stake into the module, the question arises about the existence of a mechanism ensuring the deposit of user ETH into a specific staking module of the protocol.

However, the current protocol lacks a mechanism to facilitate this because all incoming stake is automatically allocated across modules according to the MinFirstAllocationStrategy. This means that new stake will be directed to the module with the smallest share of allocated stake until a certain module has the smallest share. Additionally, it's important to note that ETH from the buffer can be used to fulfill withdrawal requests (also check the code of Lido.getDepositableEther())

One possible solution to the problem at hand, without making changes to the Lido core protocol smart contracts, is simply to wait for an opportune moment when there are no outstanding withdrawals in the protocol. Subsequently, one can sequentially call the submit method (to place ETH in the buffer) and the deposit method (to allocate stake to the module). Thus, as long as the module's share of allocated stake remains minimal, it can be asserted that newly staked Ether will be allocated to this module.

The technical implementation of this approach involves using an external smart contract, capable of submitting Ether and simultaneously depositing it within a single transaction. However, this approach will also require adjustments to off-chain tooling, particularly minor changes to the logic of the depositor bot to ensure conditions for optimal timing and the invocation of methods on the external contract.

On-chain implemenatation's interface

External vault design assumptions

• The external vault collects user-submitted ether on the owned balance
• The external vaults allow users redeeming back their positions nominated in wstETH

Description

As stated in the deposit process flow, the depositor bot must gather guardian messages and other parameters to pass them to the invoked depositBufferedEther method in the DSM contract. Because the method in the DSM contract is permissionless, any caller with a full set of parameters can invoke it.

Therefore, when implementing the combined method in the third patry contract, it must also accept these parameters for subsequent passing to the DSM contract. Additionally, it can be assumed that the external contract will target only a specific staking module. Therefore, it can define the module ID it is intended for, excluding the need to transmit this parameter as redundant. (In case of SimpleDVT module this id would be SIMPLE_DVT_MODULE_ID=2)

Suggested interface for 3rd-party deposit method

function stakingModuleId() external view returns(uint256);

function submitAndDeposit( // the name of the method can be changed by agreement
    uint256 blockNumber,
    bytes32 blockHash,
    bytes32 depositRoot,
    uint256 nonce,
    bytes calldata depositCalldata,
    IDepositSecurityModule.Signature[] calldata sortedGuardianSignatures
) external;

The stakingModuleId() value must be passed to call DSM.depositBufferedEther(...)

Suggested flow and checks inside the method (to be executed in a single tx)

• check that lido_buffered_eth >= lido_withdrawal_demand_eth
• calculate total depositable ETH as lido_buffered_eth + vault_avail_eth - lido_withdrawal_demand_eth
• check depositable amount of ETH that could be deposited to the module
• submit depositable amount of ETH to lido getting wstETH minted in return
• call DSM deposit method (passing through guardian messages)

Deposit mechanism

Now let's describe the current logic of the depositor bot and the proposed changes.

Tl;dr

In brief, the following changes are made to the bot logic:

• when iterating over Lido staking modules (Curated and SimpleDVT modules as of now), a condition is added that if the module id matches the stakingModuleId() value from the 3rd-party contract (e.g., contract behind Distributed Validator Vault), then in addition to the Lido buffer, the bot will take the balanceOf ether of the external vault holding deposited ether
• if the total amount of available ether results in increse of the number of the to be deposited keys, and the externally available new ether on the vault wouldn't be used to fulfill the Lido withdrawal queue, then the vault-related deposit method is called, otherwise vanila DSM deposit is used.

Current Lido off-chain deposit algorithm:

1. Every new block Depositor bot wakes up
2. Get modules list from Staking Router
3. Checks the status of each module and prepares a ordering by smallest stake list of modules to deposit
4. Iterates over every module from the list
    4.1. Gathers guardian messages for this module
    4.2. Checks if there is enough ETH in the buffer and gas price is good for deposit taking into account the withdrawal demand
    4.3. If so, calls the `depositBufferedEther` methond on DSM contract

Deposit off-chain algorithm using Distributed Validator Vault (DVV) contract:

1. With every new block the Depositor bot wakes up
2. Gets modules list from Staking Router
3. Checks the status of each module and prepares a ordering by smallest stake list of modules to deposit
4. Iterates over every module from the list
    4.1. Gathers guardian messages for this module
    4.2. Compares the ID of the current module with the value of `stakingModuleId()` via the external contract
    4.3. If ID matches
        4.3.1 Checks if there is enough ETH in the buffer and gas price is good for deposit taking into account the withdrawal demand (calling `WQ.unfinalizedStETH()`), 
        4.3.2 Takes into account the amount of ETH on the DVV contract, which will potentially increase the buffer at the time of calling the `submit` method just before calling `depositBufferedEther`
        4.3.3 Calls `submitAndDeposit` method of the 3rd-party DVV contract
    4.4. If ID DOESN'T match
        4.4.1 The previous logic is used: checks if there is enough ETH in the buffer and gas price is good for deposit taking into account the withdrawal demand 
        4.4.2 If able to deposit, calls the `depositBufferedEther` methond on DSM contract

Off-chain implementation

The above-described approach to modifying the depositor bot can be implemented by any third party. However, to minimize resources and time spent, it would be logical for the modification and maintenance of the offchain bot to be carried out by Lido contributors.

Security considerations

The proposed approach has the following limitations and risks:

• This method of direct-like deposits will only work for the module with the smallest stake in the protocol. Appending a new staking module (CSM) would result in altering stake distribution (see Deposit algorithm, step 3)
• Deposits may be stuck indefinitely if there is a large withdrawal queue in the protocol. This means the external vault participants will bear opportunity costs for idling ether till the moment of deposit or withdrawing from the external vault
• Making deposits in this way will increase transaction costs for depositor bot's operator.
• The DSM contract address may change in the future, requiring monitoring and corresponding changes in third-party contracts