Rewards distribution after The Merge: architecture decision record

Preface

Lido dev team would like to share an architecture decision record on rewards distribution after The Merge (i.e. ‘Ethereum phase 1.5’) to shed a little light on the considered options publicity and get community feedback.

Context and Problem Statement

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. After the mainnet merge activation, validators will start receiving another two types of the rewards: transaction priority fees and an extracted 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

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 peg when it’s down

Decision Outcome

The currently selected options: “re-stake all collected on a dedicated vault contract ether-nominated EL rewards to Lido while minting only the protocol fee (10%) stETH as part of the beacon chain rewards distribution run, and don’t mint/distribute any protocol fee on the non-profitable Lido oracle report”.

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.

Further reading

Full ADR text (with decision consequences, notes, links, pros/cons of the considered options) is available here.

8 Likes

I really like the ADR format for this. I want to highlight that feedback is appreciated and is incorporated into development roadmaps and decision-making process.

3 Likes

I just want to point out that you can use the RANDOM (formerly DIFFICULTY) opcode to tell if the merge has happened on chain. (see here. So you might consider integrating that logic to trigger the upgrade premised upon the merge.

2 Likes

It’s a possibility; with current design there’s no pressing need to upgrade right after the merge happens, we’ll have leeway of weeks if need be, and will only lose on miniscule amount of staking rewards. I think we won’t need to use this leeway though.

I think that re-staking the execution level rewards is the best way to go. Compounding those rewards daily will lead to a higher annual reward for stETH holders and will help set Lido further ahead in the staking market. Even with the 10% fees to NOs, reinvesting the priority fees/MEV on a daily basis may lead to a better return compared to most other staking options, including running your own validator. This would be a tremendous competitive advantage for Lido and stETH.

1 Like

Thanks for sharing your explicit opinion supporting the proposed solution. I believe we have chosen a proper track for making a better customer-friendly staking product.

UPD. I’ve slightly changed the ‘Decision outcome’ section in the Full ADR text to make it more clear and readable (as it was requested on hackmd inside the comments block by external reviewers)