Introduction to Restaking Risk Framework

Restaking in presents unique opportunities and challenges. This article explores the risks involved in restaking, such as smart contract vulnerabilities, operator issues, and protocol flaws, and offers practical strategies to mitigate these risks. Whether you're an experienced investor or a newcomer, this guide provides essential insights for secure and profitable restaking. Equip yourself with the knowledge needed to navigate this complex landscape confidently.

Contents

• Intro
• Map of risks
  • EL smart contract risks
  • Operator risks
  • Protocol risks
  • Operational risks
• Risk mitigation

Intro

In April, EigenLayer restaking entered Stage 3 on the mainnet with an assortment of Actively Validated Services (AVS) becoming live and ready to be delegated. This marked the beginning of active restaking portfolio construction & management and refreshed the importance of restaking risk evaluation.

We at P2P.org take risk considerations carefully and are delighted to share our thoughts. This blog post aims to inform restakers of risks and risk mitigation measures. We will outline:

• the importance of building a risk framework
• risks that may exist in restaking
• risk mitigation strategies and why Operator choice is essential
• challenges in risk evaluation
  

We exclude LRTs and risks specific to liquid restaking. However, a reader can use the provided information to explore the risks of underlying LRT restaking portfolios.

We assume that a reader has an essential awareness of Ethereum, delegated proof of stake (DPoS) staking, and Eigenlayer restaking. For those who are not sure about that, we recommend checking out these resources:

• What is Ethereum
• What is Delegated PoS
• Intro to Eigenlayer
• You Could’ve Invented Eigenlayer
  

Background

In classic DPoS (Delegated Proof of Stake), a token holder who wants to stake chooses a staking service provider (SSP) who will operate nodes and perform protocol duties on the staker's behalf for some fee. This form of staker-SSP relationship is called a delegation. Delegations provide economic security to the protocol, require locking the funds, and are incentivized by reward earnings. A delegator is supposed to do their research on validators and decide who is the best in terms of yield & credibility.

Conceptually, the restaking process is similar to mere staking but introduces an additional layer of complexity. In addition to choosing an Operator, a delegator must now consider a set of protocols (AVSs).

We assume a case when a delegator has already settled with Ethereum - they run nodes themselves or stake via Ethereum staking service provider (SSP) or liquid staking protocol (LSP) and has yet to opt in restaking offered by Eigenlayer.

In Eigenlayer, a delegator (also referred to as a restaker) must choose a Strategy. The Strategy comprises an Operator and the set of AVSs supported by this Operator.

Operators are obliged to perform duties prescribed by AVS protocols. If they don't, they might be penalized, and the penalty is usually either slashing (burning a fraction of a stake) or jailing (de-registering, banning from operations).

Slashing events may occur due to Operator misbehavior, failure, or protocol flaws, which are sometimes induced by specific market conditions (e.g., high load due to market volatility) and massive technical collapses. Even though slashing is not currently enabled in Eigenlayer, it eventually will be, and it's about the right time to start thinking about it if you didn't before.

Since a restaking choice is narrowed down to choosing a single Operator (per the same capital), the choice of the Operator is critical, as in case of severe operator-related issues, there is a chance of being penalized on all AVS simultaneously—risks become correlated to some extent. The infrastructure automation, monitoring, and support of AVSs will likely be handled by dedicated DevOps engineers, who may share a common architecture and resources.

For example, the whole cluster of different AVS nodes may go down because they were hosted on the same cloud provider, which went offline in disaster cases.

Besides slashing risks, one could also think of Eigenlayer smart contract risks and operational risks.

All these risks can be loosely classified by fundamental sources:

• Eigenlayer Smart contract risk
• Strategy risk
  • Operator (validator) risk
  • Protocol (AVS) risk
  • Operational (delegators operations) risk

Let’s look into these categories in the next section.

EigenLayer Smart Contract risks

EigenLayer consists of a complex set of smart contracts. Here are the most important ones:

• EigenPod - verifies ETH Beacon deposits via Beacon chain oracle
• EigenPodManager - deploys pods, keeps track of pod shares (podOwnerShares)
• DelegationManager - registers operators
• StrategyManager - the primary entry- and exit point for funds into and out of EigenLayer
• Slasher - is attached to StrategyManager but does nothing at the moment

Although we won't delve into their details in this chapter (how they function is well described in this article), it still merits mentioning mechanics related to slashing and draining risks.

EigenLayer restakes shares, not the underlying assets (ETH, LSTs) directly. Shares only exist in EigenLayer contracts for accounting and are subject to slashing. They are not tokens and are not transferrable. That highlights the possible foundation for developing slashing cancelation mechanisms. In the previous version of Eigenlayer, the slashing of real assets could happen via asset locks during the withdrawal process.

The most significant risk in EigenLayer in the existing version (and potentially in the following versions) is the upgrade governance. Nine out of 13 community EOAs (P2P.org is one of the signers) can ruin the system if they coordinate or get hacked. Any malware code can be pushed to the mainnet smart contracts and drain the funds through them.

We will continue tracking the development and determine if additional jeopardizing features appear with new version releases.

Operators risks

Hardware

Under hardware, we understand the physical properties of infrastructure—location, CPU, bandwidth, power stability, etc. Operators can use various cloud providers and configure nodes that don't fully meet the requirements or face capacity problems over time. It won’t be clear until the protocol issues a penalty, and then it might be too late for a delegator as they lose funds.

Hardware issues usually lead to higher downtime risks (meaning losing rewards), but sometimes also to slashing.

As an abstract example, bad connectivity may lead to delays in the perceived state of the network; therefore, a node will attest to wrong data that does not fit the consensus.

Software

Software may include nodes’ clients, various plugins, and automatization and management solutions deployed by an Operator. Software problems can come from AVS developers and an Operator; sometimes, the node client might come from external developers, and an Operator may choose to use it. Bad, unaudited code and the absence of timely client updates may cause unexpected operational behavior and lead to downtime and slashing.

Hardware + Software = Setup

Technical issues related to hardware and software are not perfectly independent. Problems with one may reveal issues with another.

Consider an Operator who runs two nodes. The second one is a backup node in case the first one goes down. It is managed automatically. Imagine if the system wrongly decides that there’s a need to turn on the secondary node while the main one operates, maybe because of losing the connection to the primary node or for other reasons. This will then lead to double signing and, hence, slashing.

In this example, a minor hardware (connectivity) problem highlighted suboptimal software configuration, which resulted in a catastrophe. Thus, it is also reasonable to evaluate hardware and software as a whole system from the design perspective.

Security breaches

Poor security procedures, such as weak passwords, access management, and key management, put node operations at risk. This won’t necessarily lead to the total loss of the delegation funds unless the delegation is made in a custodial way. Still, it may expose a protocol to dishonesty/griefing attack vectors, resulting in slashing.

Bad actors & dishonesty

Generally, dishonesty is driven by two major factors: profit extraction and griefing. Dishonesty is intentional. For this to happen, there should be a condition satisfied: 

Value from the attack > Cost of the attack

The cost of the attack can be decomposed into a) financial cost and b) reputation cost.

Reputation cost is hard to denote in exact numbers but easy to grasp. If an Operator is caught doing dishonest actions, eventually, they will lose credibility and, consequently, delegations and future earnings. AVS operations do not limit the reputation damage and will spread across all Operator businesses. One can roughly say that reputation cost is the net present value of all future profits that an Operator can earn. The higher the TVL (as a proxy of profit), the higher the chance that the Operator will be honest. It merits mentioning that it is not essential that Operators are the only participants in the attack. They can be just members of the attack group and, in the end, bribed (or even hacked) by another party.

Financial costs will vary across AVSs depending on the protocol design. An abstract example would be network congestion or spamming to disable other Operators to take over a protocol for a short period. This may include fees, infrastructure, bribes to other Operators, etc. To determine the cost, one should inspect all possible attack vectors on AVSs, which is sometimes difficult.

The value from the attack will also depend on the AVS type and ecosystem around it — value locked, trading activity, etc.

Protocol risks

Protocol logic

Protocol logic resembles the set of rules, policies, and processes that govern the operations and, in particular, ensure that Operators are properly incentivized to perform duties well. Rules include consensus, slashing conditions, reward schemes, etc. Improper protocol logic design may cause unintended violations of slashing conditions.

Imagine an oracle that delivers an aggregated exchange rate for some asset pair. Let it be a median price. Oracles gather data from external providers like Coingecko or CMC, each has their own version of truth.

Let this oracle protocol pursue accuracy of the data, it should be gathered timely. So if some Operator posts the price that diverges from the resulting median too much, then they get slashed. For example, this might happen when an operator is lagging and delivers an “old price”, which is inaccurate, or the Operator might want to influence the result value to attack DeFi protocols. These are Operator side issues that should be disincentivized.

But what if there’s a problem with the external source? The Operator performs their duties well but gets slashed anyway because their truth source differs from others. This is exactly the case of bad protocol rules’ design. No bad intention, no bad performance, still slashed.

The example above may generally be applied to occasions when slashing cannot be organized purely based on on-chain data. However, such slashing conditions can be potentially mediated through $EIGEN token staking. Learn more in our blog post.

Software vulnerabilities

There is a chance of AVS having code flaws, which may then expose it to security vulnerabilities and operations breaks. The consequences can vary depending on the attack goal, making operators attest to malicious state transition (i.e., enabling double spending), Oracle price misreporting, etc.

Infrastructure Landscape

Even if everything is good with Operators and AVS, the infrastructure landscape itself can still present slashing risks. For instance, imagine something like the supermajority of Geth clients in Ethereum*. This particular case is a protocol-level risk, but it comes from the existing infrastructure landscape and sometimes can be managed by an Operator.

Centralization-led Risks

Depending on the protocol design, sometimes large stake centralization poses risks for the whole network. If operators possessing large amounts of stake go offline or experience bugs, they can affect the whole network and cause mass slashing events. The probability of such a risk is higher when some Operator has a critical amount of delegations requiring just this Operator to fail to initiate the issue.

Staking Derivatives Contagion

LRTs appeared to be an important market player and have attracted large amounts of ETH since the launch of Eigenlayer. Some AVSs softly deal with them to ensure the initial amounts of security delivered. At the same time, the limit on LST restaking has been removed recently; therefore, an additional inflow of LST restaking can be expected.

Therefore, there can be situations when liquid restaking and staking protocols provide most of the AVS stake.

In normal market conditions, it doesn't pose any significant risk, but in the case of LRT and LST depegging, the security of AVS might evaporate, exposing it to attacks and instability.

Operational Risks

Reward Management risks

Security provisions are supposed to be rewarded, and restaking is no exception. There will be a large variety of AVSs; some may pay in the native tokens, some may pay out in tokens of integrated protocols (i.e., roll-ups), and tokens can even be issued in the non-Ethereum ecosystem (i.e., in Ethos). Once a restaker is rewarded, they must decide what to do with rewards - sell or stake again, if AVS accepts this token for staking, or swap to ETH and (re)stake ETH (or LST). Additional actions can be taken to accomplish that, such as reward withdrawal, bridging, swapping, etc. Apparently, restaking on multiple (imagine 10+ or even 20+) AVS will result in a resource-consuming reward management process.

From a practical perspective, restakers can encounter the following:

In the most basic cases, rewards are paid in ETH and occur at predefined Ethereum addresses. There is no need to make any withdrawals or trade tokens. It's almost the same as Ethereum staking itself.

In a complicated dual staking case, rewards are paid in the AVS token on the external blockchain. AVS has a dual staking model, and rewards should be claimed. Then, they might be compounded or sold, bridged, and dispersed across different trading venues.

There can be so many actions and various data to track that the number of points of failure and reporting nuances is pretty high. Compared to mere ETH staking, restaking requires additional time and resources in rewards management; otherwise, stakers may miss rewards, not meet tax liabilities, and fail to realize the yield.

Regarding reward management procedures, restakers should consider market conditions for reward tokens. In particular, it is important to track the available liquidity on trading venues and choose an optimal execution strategy to preserve yield.

Additional unbonding period

Eigenlayer restaking increases the duration of ETH withdrawals as there’s the time of undbonding from AVSs. Therefore, additional opportunity costs can arise due to the inability to move ETH.

Currently, Eigenlayer unbonding period equals 7 days, but the period can change in the future.

Legal risks

A delegator should check whether the AVS and owning the AVS token or even restaking itself doesn’t violate legislation of the country of their residence.

Protocol risks: The devil is not so terrible as he is painted.

Mass slashing events caused by improper protocol functioning theoretically do not harm a restaker. Eigenlayer has a special committee that is expected to revert the consequences. Also, the protocols are examined and audited for such possibilities during the onboarding procedures. Therefore, without regulatory complications, a protocol risk is expected to be minimized to reward handling.

Nevertheless, it’s better to be aware of all kinds of scenarios, even if they can be managed post-factum. The odds are small, but can something go wrong? Keep that in mind while constructing a portfolio and checking for risks we outlined previously.

Choose a credible Operator

To minimize Operator risk (which seems to be the largest source of risks so far), delegating to Operators with a solid track record and large TVL, public recognition, or personal assurance is important. Before choosing between different Operators, it is worth building a checklist highlighting TVL in other networks, acknowledgment from Eigenlayer and AVSs’ foundations, availability of SOC certificates, and previous cases of dishonest & unprofessional behavior that led to the loss of funds.

Plan in advance how the reward monitoring and reporting will work

As we saw above, the variety of yield extraction paths is huge, so a delegator should carefully examine it and construct business/monitoring/reporting processes themselves or outsource it to a specialized third party. Doing it properly will help maximize yield and avoid unnecessary tax and legal pressure. Data services become crucial in this regard.

Role of data services

Besides helping operational functions, data services can be applied to operator and protocol risk evaluation. The qualitative approach determines the surface of possible slashing risks but cannot tell the probabilities of outcomes.

Practically, almost always, there will be no available data or method to predict slashing risks with verifiable accuracy. Most slashing events have an extremely low probability, making it almost impossible to figure out the exact exposure. Historically, there have been few slashing events in matured networks, all having diverse origins.

Nevertheless, we still want to have something that might indicate the issue.

Generally, we expect gathering data about AVS operators’ performance to be possible. It can still be used to rank Operators and spot signs of infrastructure disturbances, which then can be used as a proxy for downtimes & slashing risks. For example, if an Operator frequently (and recently) experiences spikes in attestation miss rates in some abstract protocol, they may face harsher problems in the future unless the problem is fixed. These algorithms and models based on performance data are yet to be developed, and their sensitivity must be fine-tuned.

About Lambda
Historically, P2P.org extensively uses data services for internal needs (i.e., business analysis & planning) and external reporting (clients & research). Now, we aim to build a new data product to cover new data domains introduced by restaking.

Lambda is a data product from P2P.org that originally stems from the staking data API for P2P clients. Lambda will offer pre-built real-time API endpoints for EigenLayer ecosystem builders, including:

- Operator performance metrics to monitor duties and slashing events for Beacon Chain, AVS, and Cosmos chains.
- Rewards and APRs to monitor profits from direct staking for each pair delegator-operator. It also includes rewards per re-staked ETH to measure the profit of re-staking.
- DeFi (DEX, Lend-borrow) reserves to manage liquidity for LRT.

The platform will also provide a customization engine for real-time APIs, allowing builders to integrate new endpoints without additional latency or loss in data quality. The Lambda team works with several AVS projects to explore integration methods.

Stay tuned for updates!

Conclusion

In this blog post, we discussed risks that restakers might face when they choose the strategy and shared high-level recommendations around risk mitigation. There are still many open questions: slashing conditions and amounts are not stated for most of the AVSs, and Eigenlayer slashing logic has not been released yet. The restaking market is young, and protocols are not battle-tested. No slashing phase will give some time to work through unknowns.

P2P.org aims to actively contribute to risk evaluation discussion and continue working on risk assessment methodologies from qualitative and quantitative perspectives. As an operator in Ethereum and AVSs, we aim to navigate our clients and partners in the Eigenlayer ecosystem.

P2P Validator is a world-leading non-custodial staking provider, securing over $7 billion from over 10,000 delegators/nominators across 40+ high-class networks.

Do not hesitate to ask questions in our Telegram chat or contact our team directly on X or LinkedIn. We are always open to communication.

Web: https://p2p.org

Twitter: @p2pvalidator

Telegram: https://t.me/P2Pstaking