Risks and Practices in the Wave of Restaking

With the rise of the concept of Restaking, several related projects based on Eigenlayer have emerged in the market. Restaking aims to allow users to share their staking shares with other projects to obtain higher returns by leveraging the trust of the Ethereum Beacon staking layer, while also providing other projects with consensus trust and security comparable to the ETH Beacon layer.

To help users better understand the interaction risks between different Restaking projects, a security team conducted research on mainstream Restaking protocols and LST assets, and outlined the related risks so that users can better control risks while pursuing profits.

Main Risk Points

Most of the Restaking protocols on the market are built on EigenLayer. Users may face the following risks when participating in Restaking:

Contract Risk

1. Users need to interact with the project party's contract and bear the risk of the contract being attacked.
2. The project funds based on EigenLayer are ultimately stored in the EigenLayer protocol contract. If this contract is attacked, the related project funds will also suffer losses.
3. There are two types of Restaking in EigenLayer: native ETH Restaking and LST Restaking. Funds for LST Restaking are directly held in the EigenLayer contract, while funds for Native ETH Restaking are held in the ETH Beacon chain. This means that users participating in LST Restaking may incur losses due to risks associated with the EigenLayer contract.
4. Some project teams have high-risk permissions and may misappropriate user funds through sensitive permissions under specific circumstances.

LST risk

There is a possibility of LST tokens becoming unpegged, or the value of LST may deviate and incur losses due to LST contract upgrades or attacks.

exit risk

Except for EigenLayer, most of the mainstream Restaking protocols in the current market do not support withdrawals. If the project party does not upgrade the corresponding withdrawal logic through the contract, users may not be able to directly retrieve their assets and need to obtain liquidity through the secondary market to exit.

Mainstream Restaking Protocol Risk Analysis

The security team conducted a systematic study of some mainstream Restaking protocols currently available in the market and mainly found the following issues:

1. The project completion rate is low, and most projects have not implemented the withdrawal logic.
2. Centralization risk: User assets are ultimately controlled by a multi-signature wallet, and there is a certain possibility of a Rug Pull by the project party.
3. Based on the above situation, when internal malfeasance occurs or multi-signature private keys are lost, it may result in asset losses.

EigenLayer Special Risk Points

As the cornerstone of all projects, EigenLayer also has the following risk points that need to be noted:

1. The contracts currently deployed on the mainnet have not fully implemented all the functions outlined in their white papers (such as AVS, slash). Among them, the slash function has only implemented the related interfaces and does not yet have a complete specific logic. Currently, slash is triggered by the owner of the StrategyManager contract (project admin privileges), and the execution method is relatively centralized.

2. When performing EigenLayer native ETH Restaking, in addition to creating an EigenPod contract for fund management, you also need to run a Beacon chain node service on your own and bear the risk of being slashed by the Beacon chain. It is advisable to choose a reliable node service provider. Additionally, the withdrawal process requires the user to initiate and the node service provider to assist in withdrawing funds from the Beacon chain, meaning the exit process requires mutual agreement from both parties.

3. Since EigenLayer has not fully implemented the AVS and Slash mechanisms, it is recommended that users do not enable the deleGate function before fully understanding the associated risks to avoid potential financial losses.

Specific Project Risk Points

Through code review, it was found that certain projects have code risks that may affect the security of user funds. Below are some of the risk points and the project team's responses:

EigenPie

Currently, all contracts are upgradeable contracts, with upgrade permissions set to 3/6 Gnosis Safe. However, the upgrade permissions for the MLRT token contracts of cbETH, ethX, and ankrETH are held by an EOA address.

The project team stated that within 24 hours, they will transfer all upgrade rights of MLRT tokens to a multi-signature wallet.

KelpDAO

During the recharge process, calculating the share allocation for users requires assessing the value of shares, but the rsETHPrice in the calculation formula needs to be manually updated with the corresponding oracle. For tokens other than stETH, the share price from the corresponding contract is used as the price source. stETH is directly converted at a 1:1 ratio, and when stETH is trading at a discount in the secondary market, there may be arbitrage opportunities during the recharge process.

The project party responded that the exchange rate for the Lido contract is set at 1 stETH = 1 ETH. Since the withdrawal function is not yet open, arbitrageurs cannot utilize this strategy. When withdrawals are launched in the future, a circuit breaker mechanism will be added to check the market price of stETH, compare it with the contract price, and apply necessary safeguards when there are significant deviations.

Renzo

OperatorDelegator is responsible for routing protocol funds to EigenLayer and corresponds to different deposit ratios. However, during the configuration process of OperatorDelegator, the protocol did not check whether all OperatorDelegator ratios exceed 100%, which may result in the situation of OperatorDelegator-1 (70%) and OperatorDelegator-2 (70%). This mainly affects user fund withdrawals, but due to the incomplete withdrawal logic, it is not possible to assess the specific impact on the principal.

The project party stated that in this specific case, funds will be transferred to the incorrect OperatorDelegator contract for deposits or withdrawals. Although this will lead to a mismatch in the expected allocations to different operators, it will not affect the calculation of the Total Value Locked (TVL) or the safety of the funds. The team will address this technical issue in future contract upgrades.

LST Risk Analysis

The risks of LST should not be ignored during the Restaking process. The security team conducted research on the mainstream LST tokens in the market, and the results showed that there are differences in contract risk, centralization risk, and liquidity risk among different LST tokens.

Best Practices for Reducing Restaking Risks

Considering that Restaking is an emerging concept that has not yet been fully time-tested at both the contract and protocol levels, in addition to the risks mentioned above, there may be other unknown risks. Here are some relatively safe interaction suggestions:

Fund Allocation

1. For users participating in Restaking with large amounts of capital, directly engaging in EigenLayer's Native ETH restaking is a better choice. This is because the ETH assets in Native ETH restaking are stored in the Beacon chain contract, rather than the EigenLayer contract, so even in the event of a contract attack, the attacker cannot immediately access user assets.

2. For users who wish to participate with a large amount of funds but are unwilling to endure a long redemption period, they can choose the relatively stable stETH as the participating asset to directly engage with EigenLayer.

3. For users seeking additional returns, it is advisable to selectively use a portion of their funds to participate in projects built on EigenLayer, such as Puffer, KelpDAO, Eigenpie, and Renzo, based on their own risk tolerance. It should be noted that most of these projects have not yet implemented withdrawal logic, so participants need to consider exit risks and pay attention to the liquidity of related LRT in the secondary market.

Monitoring Configuration

1. For advanced users, contract monitoring can be configured to pay attention to related contract upgrades and sensitive operations executed by the project party.

2. Teams and users who wish to invest in ETH to participate in the project can configure multi-signature wallet conditions to trigger automated bots and single-signature authorization, based on changes in the pool's TVL, fluctuations in ETH prices, and the trends of large transactions, to set up automatic deposit functions to EigenLayer and various re-staking protocols.

By taking these measures, users can better manage risks while participating in Restaking, protecting their asset security while pursuing returns.