Integrating EigenLayer through the Contract Layer

Governance
1

Background

The community previously proposed a bounty for integrating EigenLayer through the hybrid restaking. Integrating EigenLayer would allow node operators to participate in restaking with their 8 ETH node operator bond, which would generate additional rewards for node operators. Based on this, we propose another way to integrate EigenLayer, which is to allow node operators to participate in restaking through rETH. This method is mainly implemented through contracts and can also increase the supply of rETH.

Abstract

This proposal presents a method for node operators to participate in EigenLayer restaking and earn restaking rewards through rETH. The method is mainly implemented through contracts, with minimal reliance on centralized services and no reliance on EIP-7002. Some modifications are required for oDAO nodes. The potential security risks include the addition of new mint and burn permissions, which could be abused.

Specification

Overview

Node operators can participate in EigenLayer restaking and earn restaking rewards through contracts and rETH.

Benefits

  • Node operators do not have the additional burden of operation and maintenance or AVS selection.
  • The method is mainly implemented through contracts, with minimal reliance on centralized services.
  • No reliance on EIP-7002

Trade-offs

The main concern is contract security, which requires evaluation and auditing by the core team.

  • The new mint and burn permissions pose potential risks of abuse.
  • The rETH owner belongs to the restaking contract, which is vulnerable to hacking

Flow

Restake

sequenceDiagram
Node Operator->>Restake Contract(RP): restake on behalf of node
Restake Contract(RP)->>rETH Contract(RP): call to mint
rETH Contract(RP)->>Restake Contract(RP): mint and transfer rETH
Restake Contract(RP)->>rETH Strategies Contract(EL): deposit rETH
Restake Contract(RP)-->>rETH Strategies Contract(EL): delegate operator

image
image734Ă—324 17.3 KB

The delegate-to-operator earnings feature will be implemented in Eigenlayer M2 and is not included in the current M1 version.

Unrestake

sequenceDiagram
Node Operator->>Restake Contract(RP): unstake on behalf of node
Restake Contract(RP)->>rETH Strategies Contract(EL): withdraw rETH
rETH Strategies Contract(EL)->>Restake Contract(RP): transfer rETH + restake rewards
Restake Contract(RP)->>rETH Contract(RP): burn rETH
Restake Contract(RP)->>Node Operator: restake rewards

image
image726Ă—325 15.8 KB

Detail

Node Operator

Restake & rETH Mint

  • Grant the restaking contract permission to call the rETH mint function.
  • Node operators can participate in restaking on behalf of their nodes.

Unstake

  • Node operators can participate in unstaking on behalf of their nodes.
  • rETH participating in restaking needs to be burned. A dedicated rETH burn function for restaking is required, as the current rETH burn function and does not involve operations such as ETH withdrawal.
  • Node operators must unstake before exiting a node. Smartnode needs to add this check.

rETH Rate

  • totalEthBalance: Needs to include the 8 ETH that nodes have already staked in restaking.
  • rethSupply: Increase the rETH minted when nodes participate in restaking.
  • oDAO Node: When calculating validator balance, include the 8 ETH of nodes that have participated in restaking. If oDAO node can’t get the restaked validator info, we can also just store and calculate it in the contracts.

Rewards Distribution

  • Restake rewards belong to the node operator.
  • The ETH burned from rETH - 8 ETH belongs to the deposit pool. This is because this part is considered interest income, and the node operator has already calculated it once. However, in the contract processing, there is actually no additional operation for this part.

Security

  • The addition of new mint and burn permissions could be abused.
  • The rETH owner belongs to the restaking contract, which is vulnerable to hacking.

The current design needs to be reviewed by the core team. After the contract is developed, it needs to undergo a security audit.

Plan

  • Integration research
  • Community review
  • Core team review
  • Operator delegate research
  • Slash analytics
  • Contract development
  • Fe development
2

Unclear what the proposed changes are, if they are technically possible, or if they make sense.

4

The original bounty proposal for integrating Eigenlayer involved using a combination of 8 ETH and rETH (24 ETH) to run an avs with registering as an EL restaking operator.

The proposal suggested that NOs could participate in restaking through rETH. I have already proposed a possible implementation, and I am posting this thread to encourage community review and discussion to further improve the proposal.

5

Why would minting a liquid token be useful for this purpose? By definition, that stake could not leave the contract as it needs to act as collateral for both rocket pool and EigenLayer. It would also make more rETH without increasing the number of RP validators, so also wouldn’t be useful for decentralizing Ethereum, while diluting the rewards of other rETH holders…

7

Node operators can use the 8ETH bond to decide whether to participate in restaking. If they choose to participate, they will generate a corresponding amount of rETH. This will impact the rETH rate, so it’s mentioned that this factor needs to be considered when calculating the exchange rate.

The reason for this idea is twofold: on one hand, node operators can more easily participate in restaking to earn rewards, while also increasing the rETH supply, and there’s no need to modify withdrawal addresses.

However, while replying to you, I thought of a few issues. One is that if the value of slash exceeds the 8ETH bond of the node operator, there may be a problem. Second, the profits from restaking may need to be shared with the staker because, as you mentioned, it occupies a portion of the staker’s rewards.

8

This is definitely not a possible implementation. The rETH smart contract can not be altered.

9

Essentially this double counts stuff and is broken. Can’t have two representations of the same thing be slashable.

10

Thanks for pointing it.

If it is not upgradeable, it will indeed be impossible to implement in terms of exchange rate calculation and other aspects.

11

Thank you for pointing that out.

Upon reflection, I realized that there could indeed be an issue when both sides experience slash liquidation.

12

Anyone researching this integration?

13

u can check this: rocketpool-gmc/bounties/BA082401.md at main · shfryn/rocketpool-gmc · GitHub

1 Like