The Rise of Restaking: In-Depth Analysis of Mainstream Project Risks and Best Practices

With the rise of the concept of Restaking, numerous projects based on Eigenlayer have emerged in the market. Restaking aims to share users' staked shares with other projects by leveraging the trust of the Ethereum Beacon staking layer, allowing users to earn more rewards while enabling other projects to enjoy the same level of consensus trust and security as the ETH Beacon layer.

In order to help everyone better understand the interaction risks between different Restaking projects, we have conducted research on mainstream Restaking protocols and mainstream LST assets in the market, and organized the related risks so that everyone can better control the corresponding risks while enjoying the benefits.

Risk Point Overview

Currently, the Restaking protocols on the market are basically built on EigenLayer. For users, participating in Restaking means exposing themselves to the following risks:

Contract Risk

1. Participating in Restaking requires interaction with the project's contract, and users must bear the risk of the contract being attacked.
2. The funds of projects built on EigenLayer will ultimately be stored in the contracts of the EigenLayer protocol. If the EigenLayer contract is attacked, the relevant project funds will also be at risk.
3. There are two types of Restaking in EigenLayer: native ETH Restaking and LST Restaking. Funds for LST Restaking are directly stored in the EigenLayer contract, while funds for Native ETH Restaking are stored in the ETH Beacon chain. This means that users engaging in LST Restaking may suffer losses due to risks associated with the EigenLayer contract.
4. The project party has high-risk permissions, which may, in certain situations, misuse user funds through sensitive permissions.

LST Risk

The LST token has the possibility of decoupling, or LST contract upgrades/attacks may cause deviations and losses in the value of LST.

Exit Risk

Currently, apart from EigenLayer, mainstream Restaking protocols in the market do not support withdrawals. If the project team does not upgrade the corresponding withdrawal logic through a contract, users may not be able to retrieve their assets directly and will need to obtain liquidity from the secondary market to exit.

Based on the above risk points, we conducted a systematic survey of some mainstream Restaking protocols currently available on the market and organized our findings. The main ones include:

1. Low project completion rate, most projects have not implemented withdrawal logic;
2. Centralized Risk: User assets are ultimately controlled by a multi-signature wallet. The project team has a certain ability for Rug Pull;
3. Based on the second point, in the case of internal malicious behavior or the loss of multi-signature private keys, asset loss may occur.

Since EigenLayer is the cornerstone of all projects, in addition to the points mentioned above, there are a few more things that users need to pay attention to:

1. EigenLayer is currently deployed in the mainnet contracts, and has not fully implemented all the functions described in its white paper (AVS, slash ). Among them, the slash function has only implemented the relevant interfaces, and there is no specific complete logic yet. According to the contract code, the current slash is triggered through the owner ( project admin permissions of the StrategyManager contract ), making the execution method relatively centralized;
2. When performing EigenLayer native ETH Restaking, in addition to creating an EigenPod contract for Restaking fund management, you also need to run your own Beacon chain node service and bear the risk of being slashed by the Beacon chain. Users are advised to choose a reliable node service provider when conducting native ETH Restaking. Additionally, since ETH is stored in the Beacon chain, the withdrawal process requires users to initiate it and the node service provider to assist in withdrawing the relevant funds from the Beacon chain.
3. Since EigenLayer has not yet implemented a complete AVS and Slash mechanism, it is recommended that users do not enable the deleGate function in the EigenLayer protocol without fully understanding the associated risks, as this may lead to certain financial losses.

How to effectively reduce the risks of participating in Restaking?

Restaking is an emerging concept that has not been tested over time at either the contract level or the protocol level. In addition to the risks outlined above, there may be other unknown risks. Based on the current research conclusions, we have compiled a relatively safe interaction path for everyone.

Fund Allocation

For users participating in Restaking with larger amounts of capital, directly engaging in EigenLayer's Native ETH restaking is a good choice. The reason is that for Native ETH restaking, the deposited ETH assets are not stored in the EigenLayer contract, but rather in the Beacon chain contract. Even in the worst-case scenario of a contract attack, the attacker cannot immediately access the user's assets.

For users who want to participate with large funds but are unwilling to endure a long redemption period, a relatively stable asset like stETH can be chosen to directly participate in EigenLayer.

For users looking to earn additional returns, they can appropriately select a portion of their funds to participate in projects such as Puffer, KelpDAO, Eigenpie, and Renzo, which are built on EigenLayer, according to their risk tolerance. However, it is important to note that since the aforementioned projects currently do not have corresponding withdrawal logic implemented, users participating in such protocols need to simultaneously consider the associated exit risks and should also take into account the liquidity of the related LRT in the secondary market during the investment process.

Monitoring Configuration

Currently, the projects listed in the text all have the ability to upgrade and pause contracts, and the project party's multi-signature can also execute high-risk operations for the project. For advanced users, relevant contract monitoring can be configured to monitor contract upgrades and the execution of sensitive operations by the project party.

At the same time, we hope that teams and users who wish to invest in ETH to participate in the project can use automation tools to configure conditional triggers for multi-signature wallets and single-signature authorizations. This can be based on changes in the pool's TVL, fluctuations in ETH prices, and the actions of whales, to set up automatic deposit functions to EigenLayer and various re-staking protocols.