Leveraging staked ETH, the good, the bad, and the EigenLayer

Introduction

EigenLayer, and staked ETH rehypothecation in general, have been getting a lot of attention lately, and for good reason. Although the idea is basic — how can we leverage the security of Ethereum for other things — an application of it hasn’t ever been tried at this scale until now. So, what makes EigenLayer tick, how does it take advantage of Proof of Stake (PoS), and most importantly, what can go wrong and how can we think through these issues? We’ll explore the math and economics behind what will definitely become the most controversial and widely anticipated launch related to Ethereum’s security since PoS went live.

Background

Before we go into the meat of staked ETH rehypothecation, let’s get a quick refresher on Ethereum’s PoS consensus mechanism, where validators secure the network by staking their precious ETH. Also, we’ll touch on rehypothecation in traditional finance, where assets are reused as collateral for multiple loans.

Ethereum’s Proof of Stake (PoS) Consensus Mechanism:

Ethereum’s PoS consensus mechanism, known as Ethereum 2.0 or Eth2, is an upgrade from the existing Proof of Work (PoW) model. In PoS, validators are chosen to propose and validate new blocks based on the amount of cryptocurrency (ETH, in this case) they hold and are willing to “stake” as collateral. Validators lock up their staked ETH, which serves as a security deposit, and they are rewarded with newly minted ETH and transaction fees for their honest participation in the network.

The PoS mechanism is designed to be more energy-efficient, secure, and decentralized compared to PoW. However, it also introduces new complexities and potential risks, such as the risk of losing staked ETH due to malicious behavior or technical issues.

Rehypothecation in Traditional Finance:

Rehypothecation is a practice in traditional finance where a financial institution reuses collateral posted by clients as collateral for its own borrowing or lending activities. For example, when a client deposits securities with a bank or brokerage firm, the institution may use those securities as collateral to obtain a loan from another party. This practice allows financial institutions to generate additional revenue and improve their balance sheets, but it can also introduce systemic risk, as multiple parties become interconnected through the same collateral (FYI this is why almost every systemic banking crisis ever has happened).

EigenLayer: An Overview

EigenLayer is a restaking collective for Ethereum that leverages staked ETH. By opting into EigenLayer, validators can secure various software modules built atop Ethereum, like consensus protocols, oracle networks, bridges, and more. This creates a shared security pool, boosting the value of ETH and promoting permissionless innovation.

In the context of EigenLayer and staking ETH, rehypothecation refers to the process of leveraging staked ETH to secure multiple layers, modules, or applications within the Ethereum ecosystem (or beyond). You may be wondering how these software modules or protocols are secured today, and the answer is very simple: they need to create their own economic security from scratch, almost always with a native token. This has created a lot of fragmentation and exploits as often these models are either unsound or just not able to scale enough. By allowing the same staked ETH to provide security for various applications, rehypothecation can lead to an aggregation of security, benefiting the entire ecosystem.

Basically, validators that use their ETH to secure the Ethereum network by proposing/validating blocks can now take that same staked ETH (details on exactly how TBD but will most likely involve pointing the withdrawal address to a smart contract) and use it to secure something else which may or may not be related to Ethereum at all. In doing so, those validators will get a boost to their earnings, and other ecosystems/protocols can leverage ETH security instead of having to bootstrap their own. This is definitely a powerful concept; when done correctly.

The Economics of Rehypothecation:

The end goal of rehypothecation as we just said is to increase the utility of that staked ETH as much as we can until any more would be unsafe to do so. Luckily for us it’s actually pretty easy to figure out what that theoretical limit is. The harder part comes in trying to figure out how to price those rewards and risks, as often these will be relatively amorphous and dynamic.

Essentially, we want to find the right balance between rehypothecation’s benefits, like better security and additional revenue opportunities, and its risks, such as potential losses or increased dependency on other parties. With that in mind, the optimal rehypothecation rate becomes a measure of how much staked ETH is used as collateral for other financial activities. By analyzing this rate and the factors that influence it, we can find the sweet spot where the benefits are maximized while the risks are kept at a manageable level.

Consider a model where R represents the amount of staked ETH rehypothecated, and let S be the total staked ETH in the system. We can define the rehypothecation rate r as:

The objective function U(r) represents the overall utility of the system, which takes into account the benefits and risks of rehypothecation. We aim to maximize U(r) subject to the constraints 0 ≤ r ≤ 1, ensuring the security and stability of the system. We can model U(r) as:

where B(r) represents the benefits of rehypothecation, such as increased security and fee-sharing opportunities, and C(r) represents the costs or risks associated with rehypothecation, such as counterparty risk, dependency risk, and leverage risk.

We can represent the benefits and costs as functions of r:

where α, β, γ, and δ are positive parameters that capture the magnitude and sensitivity of benefits and costs to the rehypothecation rate r.

To find the optimal rehypothecation rate r*, we need to solve the following optimization problem:

To find the optimal rehypothecation rate r*, we can set the first derivative of U(r) with respect to r equal to zero:

Calculating the first derivatives, we get:

Setting the derivatives equal to each other:

Solving this equation for r* will give us the optimal rehypothecation rate that maximizes the overall utility of the system while balancing the benefits and risks. But, this information is meaningless unless we can get into the real stuff (aka the α, β, γ, and δ). Unfortunately as we mentioned this is where things become more complicated, and where some serious mistakes could be made.

Advantages of Rehypothecating Staked ETH in EigenLayer:

Now that we’ve proven there’s a way to know if you’re maximizing your utility as a leveraging validator, why should you even bother doing this? And why should anyone else even care about it as well? The use cases are infinite, you could reuse ETH security to secure a bridge, a decentralized sequencer, or even an entirely new chain. In the brave new world of EigenLayer, rehypothecating staked ETH comes with some serious perks:

• Amped-up security for software modules and DApps: By pooling security resources across multiple modules, EigenLayer elevates the level of protection for all the software modules and decentralized applications (DApps) that rely on them. As long as you model out where your security is coming from correctly, you end up with more security than relying on a single validator set, especially as you introduce varying security measures for each layer.
• More money for validators: When stakers validate multiple modules, they can rake in fees from various sources, not just the original staking yield provided from Ethereum. While it’s unclear what that additional revenue will look like, this is where the assumption on the loan “returns” are, as by delegating to and EigenLayer operator to run a service, you will get rewarded with additional yield.
• Ethereum as a staging ground for next-gen innovations: With EigenLayer, cutting-edge innovations like Danksharding and proposer/builder separation can be battle-tested in real-world scenarios before they’re integrated into the Ethereum mainnet. This makes Ethereum a living lab for the future of blockchain tech.

Disadvantages and Risks of Rehypothecating Staked ETH:

We won’t go too much into this here as that’s what the next section will be on, but there are certainly some negatives involved with rehypothecating staked ETH, as you’re essentially selling (and reselling) the excess security that has accumulated on the native PoS consensus. Your ability to do that is capped by how well you (in this case EigenLayer protocol) can diversify that risk.

• Counterparty risk: defaulting borrowers bringing the pain: If a borrower defaults on their obligations, it can trigger a cascade of losses for everyone involved. When you’re playing with rehypothecated staked ETH, you’re always exposed to the risk of counterparty default, which could from OG Ethereum PoS validator exposure, but also from whatever new form of risk these modules take on (securing new chains, DeFi protocols, etc). Keep your eyes peeled for red flags!
• Dependency risk: domino effect in interconnected modules: With staked ETH securing multiple layers and modules, a single point of failure could cause a devastating domino effect. If one module goes down, it could drag others along with it, potentially inflicting massive losses and destabilizing the whole system.
• Leverage risk, market volatility going turbo: Rehypothecation can lead to increased leverage in the system, making it more susceptible to market volatility. When the markets take a nosedive, highly leveraged positions can get liquidated, causing a chain reaction that could wipe out even the most HODLer portfolios.
• Dilution of security, spreading ETH security thin: Rehypothecating staked ETH means using the same collateral to secure multiple layers and modules. While this can be efficient, it also stretches the security provided by staked ETH, potentially weakening the overall stability and safety of the network.

Risk and More Risk, Especially Dependency Risk

Similar to how we modeled out rehypothecation, let’s see if we can similarly dive a bit deeper into what risk means for EigenLayer, specifically for validators who will use it, and also theoretically Ethereum’s security at large if Eigenlayer becomes big enough, and what are the levers used to change it to better understand the potential pitfalls.

To model the risks, we’ll use the following notation:

Rslashing: The risk of slashing due to participation in the Ethereum consensus layer.

RiEigenLayer: The additional slashing risk for the i-th validator introduced by EigenLayer.

Rtotal: The total risk of slashing for the i-th participant.

β: The risk sensitivity parameter.

The risk of slashing in the Ethereum consensus layer for a participant can be quantified using a utility function, U(Pi), where Pi is the percentage of ETH staked by the i-th participant (as each staker’s risk is directly correlated to their probability of being selected):

Here, Cslashing is the cost of slashing per unit of staked ETH, and the utility function U(Pi) models the risk aversion of the participant. An important point to note is that this is not the actual risk of slashing, but the perceived risk of slashing for each participant. This becomes equal to the utility function as each validator models the risk/reward tradeoff (utility function) based on your own risk exposure. These factors could include the participant’s staking history, the performance of the validator they are associated with, and their overall network behavior.

Now, let’s calculate the additional slashing risk introduced by EigenLayer for the i-th participant. We can use a similar utility function, U(PiEigenLayer), where PiEigenLayer is the percentage of ETH restaked by the i-th participant in EigenLayer:

Here, CiEigenLayer is the additional cost of slashing per unit of restaked ETH for that participant, which depends on the specific modules they validate and the interconnected risk associated with those modules.

To calculate the total risk of slashing for the i-th participant, taking into account both the Ethereum consensus layer and EigenLayer, we can use a combination of the risks and a risk sensitivity parameter, β, which captures the participant’s risk tolerance:

The risk sensitivity parameter, β, ranges between 0 and 1. A higher β value indicates greater sensitivity to the additional risks introduced by EigenLayer, while a lower β value suggests a higher risk tolerance.

Dependency as a Graph:

EigenLayer can best be thought of as an interwoven graph of modules, leverage, and utility, each pooling from the same stream of native Staked ETH (although technically this isn’t true, as validation is not a strictly homogeneous activity!). Within that graph, we have different vectors of dependency risk:

• In-degree centrality: The number of incoming edges to a node, indicating the number of modules that depend on a specific module. A higher in-degree centrality implies that more modules depend on this module, increasing the overall dependency risk.
• Out-degree centrality: The number of outgoing edges from a node, indicating the number of modules a specific module depends on. A higher out-degree centrality implies that the module depends on more modules, increasing its exposure to dependency risk.
• Betweenness centrality: A measure of the extent to which a node lies on the shortest paths between other nodes in the graph. A higher betweenness centrality indicates that the module plays a more critical role in the flow of dependencies between modules, increasing the overall dependency risk.
• Eigenvector centrality: A measure of the importance of a node in the network, taking into account not only its direct connections but also the connections of its neighbors. A higher eigenvector centrality implies that the module and its neighboring modules are highly interconnected and play a significant role in the overall dependency structure, increasing the dependency risk.

Let’s start by representing the modules as nodes in a directed graph G = (V, E), where V is the set of nodes (modules) and E is the set of directed edges (dependencies). We can define a dependency matrix D, where Dij represents the degree of rehypothecation dependency of module i on module j.

Using a risk propagation formula, we’re now able to get deeper into some of these characteristics. Let Ri be the initial rehypothecation risk associated with module i, and let R’i be the propagated risk after accounting for dependencies. We can then compute R’i using the following formula:

where the summation is over all modules j that module i depends on.

To analyze the overall dependency risk in the network, we can compute the total risk Rtotal as:

We can further examine the network structure by calculating various graph metrics, such as in-degree centrality and betweenness centrality. In-degree centrality Cin(i) for module i can be calculated as:

Betweenness centrality CB(i) for module i is given by:

where σst is the total number of shortest paths between nodes s and t, and σst(i) is the number of shortest paths between nodes s and t that pass through node i. High betweenness centrality values indicate that a module plays a critical role in the network.

Finally, we go to the aptly named eigenvector and its centrality risk. Let A be the adjacency matrix of the network, where Aij represents the connection between nodes i and j, and let xi be the eigenvector centrality of node i. Then, the eigenvector centrality can be defined by the eigenvector equation:

Here, λ is the eigenvalue corresponding to the eigenvector x. The eigenvector centrality is the eigenvector associated with the largest eigenvalue of the adjacency matrix A. It can be found using the power iteration method or other eigenvalue decomposition techniques.

The eigenvector centrality xi of node i represents its importance within the network, taking into account the connectivity of its neighbors. In the context of EigenLayer, a higher eigenvector centrality implies that the module and its neighboring modules are highly interconnected in the rehypothecation process and play a significant role in the overall dependency structure, increasing the dependency risk.

Dependency by Example, Why This Can Go Wrong Very Quickly:

Going through the abstract of dependency risk is one thing, but it’s another entirely to see just how easy it would be for this to happen with real ETH. Assume that the EigenLayer network has three participants: A, B, and C. Initially, all participants have 100% of their staked ETH as collateral. Assume that the EigenLayer network has three participants: A,B, and C, and 2 services/middleware running strategies: Y and Z. Let’s assume that each participant has staked 10,000 ETH.

1. Participant A is an operator, and borrows 5,000 ETH from Participant B, collateralizing it with another asset, Asset X, and uses the borrowed ETH to stake in module Y. Now, Participant A has 15,000 ETH in staked assets and owes 5,000 ETH to Participant B, while Participant B has only 5,000 ETH in staked assets but holds a claim on Participant A for 5,000 ETH.
2. Participant A then lends 3,000 ETH to Participant C, who uses the asset for strategy Z. Now, Participant A has 12,000 ETH in staked assets and owes 5,000 ETH to Participant B, Participant B still has 5,000 ETH in staked assets and a 5,000 ETH claim on Participant A, and Participant C has 13,000 ETH in staked assets but owes 3,000 ETH to Participant A.

Let’s say that, somehow, Module Y, where Participant A staked the borrowed ETH, experiences a severe fault in its operation and gets slashed by 40%. This would have a cascading effect on the other participants in the rehypothecation chain:

1. Module Y’s staked ETH drops from 5,000 to 3,000 (40% slashed).
2. Participant A had borrowed 5,000 ETH from Participant B and staked it in Module Y. Since the total of the staked ETH in Module Y has dropped, Participant A’s “loan” is now “under-collateralized” to what it is supposed to secure and Participant B has lost a piece of their stake. To maintain the required collateralization ratio, Participant A must either provide additional staked ETH or reduce the exposure of what it is securing. In this case, let’s assume they increase staked ETH to make up for the lost amount.
3. Participant C had borrowed 3,000 ETH from Participant A. With the need for further staked ETH, there is a high chance that Participant A will require Participant C to repay some or all of the borrowed ETH. Let’s say Participant A demands 1,000 ETH back, reducing Participant C’s borrowed amount to 2,000 ETH. Now Participant C also faces a difficult decision: they must either provide additional collateral (staked ETH) or reduce their exposed security in the service.

In this scenario, the slashing of staked ETH in Module D has a cascading effect on the rehypothecation chain. The consequences of the slashing are felt not only by the module directly affected (Module Y) but also by other modules that depend on it (Participants A, B, and C). It may seem impossible practically for such an event to occur, but remember that this is the world of crypto, where things move fast, and everything is connected. The modules and participants in the real environment will be much more convoluted and leveraged, and these events could happen without anyone realizing. We also could theorize that eventually there will be incentive structures created for getting the most staked ETH into a service, which will further compound areas of attack.

Ways to Stop This:

So now that you know it’s really easy for something to go wrong in the world of leveraging staked ETH, let’s talk about what we can actually do to mitigate all of these issues.

• Diversifying dependencies: Reducing the reliance on a single module by connecting to multiple, independent modules that provide similar functionality. This approach distributes the risk across various components, making it less likely that a single point of failure will lead to catastrophic consequences.
• Monitoring and assessing risks: Continuously evaluating the risk levels of individual modules and their dependencies using real-time monitoring tools, data analysis, and stress testing. By proactively identifying potential issues, participants can take preventive measures, such as reallocating resources or adjusting their staking strategies, to minimize exposure.
• Implementing redundancy measures: Building in redundancies within the system, such as alternative data sources or backup validation processes, to provide a fallback in case a primary module fails or experiences issues. This ensures that the system can continue to function even when faced with unexpected challenges.
• Encouraging responsible rehypothecation practices: Ensuring that the rehypothecation of staked ETH is conducted responsibly and within acceptable risk parameters. This may involve setting limits on the amount of staked ETH that can be rehypothecated or implementing strict requirements for validators to participate in EigenLayer.
• Establishing a robust governance model: Implementing a well-designed governance structure that allows for efficient decision-making, promotes transparency, and fosters collaboration among participants. This can help the community respond effectively to emerging risks and maintain the integrity of the system.

As you can tell, all of this becomes a lot more of an art than science, and there will surely be a lot of hiccups along the way as people start to test the boundaries of restaking ETH. As a safe approach, it’ll be critical to not overexpose yourself too much to modules that are taking on a high amount of leveraged risk to volatile or new protocols, and to be proactive with managing specific positions.

Eigenlayer has already made some commentary on what their approach will be in protecting against some of these risk vectors, including creating a “reputation-based committee” to act as a backstop of last resort if things go awry. This would be done by vetoing a slash on a module’s staked ETH if there was some anomalous activity that was not the fault of the restakers. There is certainly more to explore though and a lot of education will need to be done in order to make people fully aware of the risks attached. As a next step for research, it could be useful to map out a stochastic model of the system’s behavior, where the state transitions reflect the different states of each network (essentially their “health”). It could create a stronger theoretical structure for how to manage risk.

Conclusion

EigenLayer, an innovative approach to rehypothecating staked ETH, offers significant potential benefits for validators, developers, and the broader Ethereum ecosystem. By leveraging the security resources of multiple modules, EigenLayer can amplify security, increase profits for validators, foster innovation, and create a surge of novel protocols and applications in the DeFi space.

However, leveraging staked ETH also introduces new risks and challenges that must be carefully managed to ensure the long-term stability and security of the network. These risks include counterparty risk, dependency risk, leverage risk, and the dilution of security. It is crucial for participants to understand these risks and take appropriate steps to mitigate them.

To minimize the risks associated with restaked ETH, participants should diversify dependencies, monitor and assess risks, implement redundancy measures, encourage responsible rehypothecation practices, and establish a robust governance model. By adopting these strategies, the EigenLayer community can effectively navigate the complex world of leveraging staked ETH and unlock its full potential in the Ethereum ecosystem.