---
tags: ADR, LIP, research, upgrade, ethereum
---

# ADR #3: Rewards distribution after The Merge

* Status: RFC
* Deciders: Lido dev team, Lido DAO <!-- optional -->
* Date: 2021-12-29

## Context and Problem Statement

Lido has started a technical process to integrate into the new Ethereum hardfork [The Merge](https://ethereum.org/en/eth2/merge/). The merge event is expected to happen in March-April 2022. We have to have a working, tested, and audited solution by the 15th of March 2022.

At the moment the Lido protocol collects only Beacon chain staking rewards (i.e. ETH2-side rewards) and pays protocol fee (10%) by [minting new `stETH` token shares](https://github.com/lidofinance/lido-dao/blob/816bf1d0995ba5cfdfc264de4acda34a7fe93eba/contracts/0.4.24/Lido.sol#L553). After the mainnet merge activation, validators will start receiving another two types of the rewards: transaction priority fees and an extracted [MEV](https://ethereum.org/en/developers/docs/mev/) which would be paid on the execution layer (ex. ETH1-side) while staking rewards still would be collected on the consensus layer (ex. ETH2-side). The new rewards would be initially gained directly by validators and nominated in ether.

How can we distribute the new execution level rewards after the merge?

## Decision Drivers <!-- optional -->

Primary:
* capital efficiency of the new reward distribution scheme (better APR and TVL values)
* delivery time — we have to perform Lido migration before or just after the first bunch of the merge hardfork blocks appears

Secondary:
* the current contracts codebase shouldn't change much
* the new scheme should work even if the merge would be postponed further
* there may be only implicit and automated motivation/demotivation levers (with a minimum amount of governance interrogation and dispute resolution)
* it's better to keep the existing stETH rebase period (~24h) as it is, due to integrations that rely on it

## Considered Options

- should we continue to pay the stakeholders' rewards and protocol fee to NOs and Lido DAO only in `stETH` or switch to ether for the new rewards branch
- should we distribute the protocol fee (to Lido and NOs) under the slashing conditions or not
- should we implement an ETH-stETH auction to restore the stETH/ETH exchange rate when it's changed

## Decision Outcome

*The currently selected* options group:
- re-stake all collected on a dedicated vault contract ether-nominated EL rewards to Lido while minting new stETH only for the protocol fee (10% currently: 5% for NOs and 5% for the Lido insurance fund)
- re-staking and protocol fee minting are performed as part of the beacon chain rewards distribution run (with an oracle beacon report).
- don't mint/distribute any protocol fee on the non-profitable Lido oracle report (when beacon chain balance delta is zero or negative).

Primary support points: the selected options provide compounding and have a fast shipment time due to little impact on the existing distribution scheme.

Secondary support points: the proposed decision reasonably automated and self-governed, and fallbacks to the already adopted solution in case of some frictions with the Merge hardfork schedule.

### Positive Consequences <!-- optional -->

* boosts capital efficiency by achieving compounding (increase the APR and TVL values)
* only the one core contract changes (`Lido.sol`, ~100 LOC), and another vault contract adds (~100 LOC)
* almost automated solution without the need for manual governance intervention
* can work in a fallback mode before The Merge hardfork will arise
* stakers gain all possible rewards (excluding fees), and in the day of slashings/penalties protocol fee doesn't distribute to NOs and Lido DAO
* preserves an existing ~24h rebase period

### Negative Consequences <!-- optional -->

* relies on the new (to be developed ⚠️) [off-chain monitoring solution](https://hackmd.io/@george-avs/rJ14Rv7qF) to mitigate incorrect NOs' setup and misbehavior
* under the mass slashing events well-behaving NOs and the Lido DAO loose protocol fee cause we check beacon chain balance delta and not the whole rewards sum to make a decision on protocol fee minting
* stETH/ETH exchange rate restoration would be slower than with a market-buy & burn stETH strategy after the mass slashing events cause `stETH` is a [rebasing token](https://docs.lido.fi/contracts/lido#rebasing) and total circulating shares amount decreases immediately by burning discounted `stETH`
* coupled with the entry queue health state: we expect entry queue would be crowded with staking requests after the Merge will happen, so by re-staking rewards we make additional load on the queue, though, the impact should be not be significant

## Pros and Cons of the Options <!-- optional -->

### Stakeholder's rewards and protocol fee nomination

#### Option 1. Nominate protocol fees in ether

There are two suboptions that exist:
* use ether to distribute both the new rewards and the protocol fee
* use ether only for the protocol fee while distributing rewards with re-staking.

##### Pros
* the logic is easy: no need to mint stETH while distributing new rewards
* partially lowers the staking entry queue forecast issues

##### Cons
* reduces capital efficiency: even the NOs decide to re-stake with Lido, the customers gain less cause NOs would act simultaneously like a customer and a fee recipient.
* the NOs can have a market motivation to withdraw fee and re-stake without Lido (e.g. bearing more risks)

#### Option 2. Nominate protocol fees in stETH

We propose to setup a dedicated vault contract to collect the new rewards (tx priority fees and extracted MEV). NOs should use its address as a coinbase for the EL-collected rewards. Then we could withdraw all ether from the vault contract as part of the Lido oracle report to perform re-staking keeping the established ~24h rebase period.

##### Pros
* boosts the capital efficiency
* aligns NOs to the Lido protocol
* falls into the existing rewards distribution scheme

##### Cons
* explicit dependency on the entry queue health state which could lower the compounding value
* need to change at least the one core contract (`Lido.sol`)

### Protocol fee distribution under the slashing conditions

📝 Due to the possible controversies in the discussion stage we leave possibility to re-stake with or without minting the protocol fee `stETH` with a minimal contract code impact.

#### Don't mint protocol fee when the consensus layer (conventional Beacon Chain) reward base becomes negative
* motivates NOs and Lido to overcome slashing losses asap
* demotivates well-behaving NOs

#### Points on interruptless distribution (mint the protocol fee if execution layer rewards cover consensus layer losses)
* could automatically smoothen the stETH/ETH exchange rate losses
* fair to the well-behaving NOs
* it could be over-permissible if validation quality degraded

### ETH-stETH auction option to restore the exchange rate when it's lowered for stETH

Pre-withdrawals (between the Ethereum phases 1.5 and 2.0), we could also consider complementing a re-staking (i.e. compounding) mechanism with a mechanism to help stabilize the stETH-to-ETH exchange rate. A portion of extracted MEV and tx fee rewards could be used to purchase `stETH` from the market (and potentially burn it) instead of using those rewards for re-staking. This would have a restorative effect on the exchange rate if it's >1:1, and would potentially reduce the liquidity mining necessary for exchange rate stabilization. In the event that the exchange rate would not need restoration, then the amount that would otherwise be used for this could be used in the compounding mechanism instead. The DAO could control parameters on e.g. what percentage of MEV+tx fee rewards would be used in this way.

##### Pros
* could restore exchange rate much quicker and more efficiently than other options
* gives opportunity to use new rewards as an explicit cover option

##### Cons
* making it trustless and accurately governed by the Lido DAO will require further research and separate design decisions
* the cover implementation mechanism should be already well-defined and deployed by the moment of application (WIP, see the [LIP-6](https://research.lido.fi/t/lip-6-in-protocol-coverage-proposal/1468)) to correctly handle cover-incurred stETH rebase by the 3rd party integrated protocols (e.g. Anchor Protocol)

📝 This option could be implemented at the next iteration after the Merge adoption completes successfully. For example, we could withdraw EL-rewards from a vault contract somewhere before the next oracle report will happen and use it on a money market.

------
##### UPDATES

*18-05-2022*: 'exchange rate' term is used to represent stETH/ETH relative price