What is EigenLayer? Restaking ETH to Earn Rewards

EigenLayer is a protocol built on Ethereum that introduces restaking. This is a new onchain primitive similar to rehypothecation, allowing either natively staked ETH or Liquid Staking Tokens (LSTs) to be restaked in return for additional yield.

Rehypothecation involves a financial entity leveraging an asset for its own financial gain. Unlike rehypothecation, in crypto restaking the initial owner of the stake retains control, keeping with the self-custody ethos of blockchains. These restaked assets are used to extend cryptoeconomic security to applications on the EigenLayer network that wish to use this security, known as Actively Validated Services (AVS).

At a high level, EigenLayer facilitates a marketplace between restakers (users with staked assets interested in additional yield) and AVS (services looking for cryptoeconomic security). EigenLayer’s potential, therefore, lies in enhancing cryptoeconomic security by staking assets on Ethereum to validate applications not built directly on Ethereum.

Cryptoeconomic Security and Its Challenges

Since its inception, cryptoeconomic security has been a fundamental challenge of web3. Simply put, cryptoeconomic security measures the economic cost of corrupting a system. For instance, on a Proof of Work (PoW) blockchain like Bitcoin, the cryptoeconomic security is driven by the total hashrate, which makes it costly for an attacker to execute a 51% attack. Similarly, on a Proof of Stake (PoS) blockchain, security derives from the total value of staked tokens, since an attacker would have to own a large fraction of the total stake to execute an attack. A system with higher cryptoeconomic security is intuitively more trustworthy, since the cost to attack such a system is high. Therefore, such a system is more attractive for high-value use cases. 

Establishing robust cryptoeconomic security is challenging for any decentralized application (dapp). Bitcoin's security model pioneered one of the first successful iterations of decentralized trust and security. Users were empowered to send peer-to-peer payments in a secure manner without the need for a middle-party to coordinate. A major shortcoming, however, is that it was designed to be application-specific. This means that any new dapp that builds on top of the network also requires a new blockchain and its own trust network.

Ethereum introduced a new approach to security that significantly enhanced extensibility and overcame many of these challenges. The Ethereum Virtual Machine (EVM) enabled dapps (smart contracts) to build permissionlessly on top of the Ethereum network by leveraging the underlying security on the Ethereum blockchain itself. This is powerful because it allows developers to focus on building innovative applications rather than bootstrapping trust. Dapps deployed on Ethereum do not require any reputation themselves and instead can leverage the underlying blockchain's security for settlement.

However, this approach has limitations, particularly for services that cannot be deployed on the EVM and thus cannot utilize Ethereum's settlement layer. This applies to any application that requires its own AVS. Examples include alternative consensus protocols and virtual machines, but also infrastructure critical to the Ethereum ecosystem, such as bridges and data availability layers.

In principle, such services need staked capital to generate cryptoeconomic security. However, even beyond the usual problems of bootstrapping, attracting this capital is difficult due to the alternative investments available to potential stakers, like government bonds or Ethereum staking. To attract capital, therefore, a service needs to pay agents for the stake in a quantity that exceeds the opportunity cost of capital. These are generally in the form of staking rewards in the native token but could take other forms that the staker finds valuable (e.g., access to certain services). This presents two interrelated issues: 

  1. Limited Cryptoeconomic Security: For these rewards to be sustainable in the long run, a given service can only support a limited amount of stake. 

  2. Fragmentation: The total amount staked across various services is split between them. Compare this to smart contracts on Ethereum, where each smart contract inherits the full security of Ethereum. 

Enter EigenLayer and Restaking

EigenLayer's restaking mechanism leverages two fundamental ideas to overcome these challenges: pooled security and free-market dynamics. These mechanisms allow Ethereum's base layer security to extend to any AVS built on EigenLayer, overcoming previous inefficiencies and enhancing system robustness.

Currently, both natively staked $ETH and various Liquid Staked $ETH tokens can be restaked through an opt-in process on EigenLayer. For natively restaked $ETH, EigenLayer obtains the rights of the staked $ETH's withdrawal credentials, while LSTs are deposited into the EigenLayer smart contract. Users can then delegate their restake to an operator or run their own validator for specific AVSs on EigenLayer. This enables users to earn extra yield by validating selected AVSs in return for accepting increased slashing risks in case of faulty behavior by their validator.

Hence restaking generates pooled security, meaning the same restaked ETH can provide security to multiple Actively Validated Services. For instance, in principle, the entire ETH restaked on EigenLayer can lend cryptoeconomic security to all AVSs on EigenLayer, if the restakers choose so. 

Secondly, underlying EigenLayer is a marketplace. Restakers can choose an operator or choose to directly run a validator themselves. Operators/validators select which AVSs to validate for, earning yield and subjecting themselves to the slashing conditions associated with each. AVSs choose how much yield to offer, and operators can then choose which ones to validate based on the yield versus the underlying risk. 

This results in an open and competitive marketplace for pooled security, addressing inefficiencies within current security models. Specifically, it eases the challenge of bootstrapping security, as new protocols can purchase security on the EigenLayer open market rather than generating and maintaining it internally. Restaking also lowers the marginal capital costs of validator services since stakers can restake the same initial capital across many different protocols beyond native Ethereum. Consequently, an AVS can afford a much larger quantity of pooled security than without restaking.

Slashing and Potential Risk

Validating for a service is not risk-free. The cryptoeconomic security of a staked service comes from the ability to detect and penalize (slash) malicious actions, deterring such behavior. For example, Proof of Stake chains like Ethereum penalize validators for misconduct, with penalties ranging from minor (e.g., missed votes) to severe (e.g., prolonged inactivity or equivocation). Similar penalties apply to AVS operators to ensure service reliability and discourage malicious behavior.

Restakers trust their chosen operators for honesty (avoiding slashable offenses) and competence (avoiding inactivity penalties), similar to the concerns of individuals choosing between staking services on Ethereum. However, operators differ in terms of AVSs they validate for — each of these AVSs themselves may differ in terms of riskiness. Therefore, selecting appropriate operators to restake with is important to limit risk: just as yield is cumulative, so are the risks. 

Another potential issue with EigenLayer is protocol-level risk. Any individual AVS may be appropriately staked to the desired level of cryptoeconomic security. But if the same stake is restaked at several AVSs by the same validator, the cumulative gain from malicious behavior may exceed the loss from slashing. Preventing such network-level vulnerabilities is a critical challenge for EigenLayer. Additionally, if EigenLayer becomes very large, significant slashing events could trigger mass unstaking and destabilize Ethereum itself.

Additionally, EigenLayer slashing may also cause a version of Proof Of Stake’s nothing at stake problem. A validator on Ethereum who has restaked with EigenLayer and knows they will be slashed on EigenLayer may nevertheless continue validating on Ethereum, because the protocol is not immediately aware of slashes that occur on the application layer. During this period, they have no economic disincentive against malicious behavior at the protocol layer. 

Intersubjective Restaking

The current AVSs on EigenLayer are inherently ones with objectively attributable faults. These are ones where a given fault can be attributed to a validator or set of validators based purely on mathematics or cryptography. 

For instance, several scenarios can trigger challenges: an L2 sequencer pushing an invalid state transition; a validator equivocating by signing two different state transitions in the same slot; or a Data Availability layer distributing corrupted data. These actions can be objectively challenged and proven faulty, eliminating the need for subjective consensus or third-party opinions. Such faulty behavior can therefore be penalized programmatically via smart contracts and therefore disincentivized. 

An intriguing possibility for EigenLayer is that the platform can be used not just for AVSs of this type, but also for what it describes as intersubjectively attributable faults. These are faults for which there does not exist a mathematical or cryptographic proof but nevertheless reasonable observers of the system will agree that a particular operator is at fault. 

As an example, consider an oracle reporting a price that is highly unreasonable — to fix ideas, consider a reported price of 1 ETH = 1 US Dollar. At the time of writing this article, 1 ETH ~ 3000 US Dollars, so such a price is several orders of magnitude away from the “true” price that is observed by all observers. The reported price therefore is clearly faulty, nevertheless, there does not exist a mathematical or cryptographic proof of the fault (short of enshrining, e.g, a specific exchange as the arbiter of the true price). However, upon seeing such a faulty reported price, there would be consensus among all reasonable observers. 

Currently, such intersubjective faults are addressed in an ad hoc fashion. For example, Ethereum often considers a broader set of stakeholders, called social consensus, to recover from certain attacks that compromise a majority of the validators. 

EigenLayer proposes a separate mechanism to allow restaking in settings involving intersubjective faults, through a fork-aware token bEIGEN. Upon observing an intersubjective fault, users can initiate a fork of the bEIGEN token which punishes the claimed faulty operator. The idea is that reasonable observers of the system will all coordinate on the correct fork. This design, if successful, will allow extending cryptoeconomic security to tasks with intersubjectively attributable faults, an arguably vastly larger space.

Further Reading on EigenLayer

Found this research useful? Connect with the Consensys Cryptoeconomic Research team at [email protected].

Contributors to this article include Rob Dawson, Consensys CTO and Enrico Del Fante Staff Blockchain Protocol Engineer.

Disclaimer: Consensys Software Inc. is not a registered or licensed advisor or broker.  This report is for general informational purposes only.  It does not constitute or contain any individual investment advice and is made without any regard to the recipient’s objectives, financial situation, or means.  It is not an offer to buy or sell, or a solicitation of any offer to buy, any token or other investment, nor is it intended to be used for marketing purposes to anyone in any jurisdiction.  Consensys does not intend for any person or entity to rely on any facts, opinions, or ideas, and any financial or economic commentary expressed in this report may not be relied upon. Consensys makes no representations as to the accuracy, completeness, or timeliness of the information or opinions in this report and, along with its employees, does not assume any responsibility for any loss to any person or entity that may result from any act or omission based upon this report. This report is subject to correction, completion, and amendment without notice; however, Consensys has no obligation to do so.