- Published:
- Last updated:
EigenLayer History and Founding
EigenLayer and its parent entity Eigen Labs were founded in early 2021 by engineering and computer science expert Sreeram Kannan.
Prior to founding EigenLayer, Kannan studied at the College of Engineering, Guindy, the Indian Institute of Science (IISc), and the University of Illinois Urbana-Champaign in the fields of mathematics, telecommunications, information theory and wireless networks, and electronics and communications engineering.
Soon after completing his PhD at the University of Illinois Urbana-Champaign, Sreeram became a postdoctoral researcher at the University of California, Berkeley before becoming an associate professor at the University of Washington and heading the UW Blockchain Lab focusing on blockchain protocol development and research.
The majority of the EigenLayer’s staff lives and works on-site in Seattle, Washington. In addition, most of the EigenLayer team have been close colleagues with Kannan and have worked with him for many years at the University of Washington conducting research, protocol development, and related disciplines.
Many of EigenLayer’s core team members possess extensive expertise in engineering and software development and similar fields and hail from some of the most well-known universities in the US and around the world. Moreover, much of the team holds a plethora of experience at major tech firms including Amazon, Apple, Google, Microsoft, Coinbase, ConsenSys, Facebook, Protocol Labs, Celestia, IBM, Ericsson, Alibaba, and others.
In addition to CEO and founder Sreeram Kannan, the core team behind the development of EigenLayer includes Head of Protocol Research Soubhik Deb, Director of Protocol Development Scott Conner, Smart Contracts Architect Jeffrey Commons, engineer Robert Raynor, Chief Operating Officer Chris Dury, Chief Strategy Officer Calvin Liu, Director of Developer Relations Nader Dabit, Strategy Lead Brianna Montgomery, Principal Engineer Bowen Li, Head of Product Design Jon Yan, Chief of Staff Grace Hartley, VP of Engineering Sid Sanyal, strategy/product Vyas Krishnan, and many others.
Analyzing EigenLayer Staking Types
Although EigenLayer is multifaceted with a plethora of uses, the central foundation of the platform revolves around staking. More precisely, EigenLayer makes use of several related staking paradigms including: liquid staking, superfluid staking, and restaking.
- Liquid staking: Through liquid staking protocols on EigenLayer such as Lido, RocketPool, and Swell Network users are able to deposit their ETH within a staking pool to receive a liquid staking token (LST) that acts as a claim to their ETH and its staking yield. Inside the staking pool, the ETH is delegated to one of a large number of network validators participating in the network’s consensus. LSTs are fully redeemable for their underlying ETH value but are subject to a waiting period equivalent to the ETH staking withdrawal period. LST are also fully tradable within the Ethereum DeFi ecosystem through exchanges such as Uniswap and Curve.
- Superfluid staking: Superfluid staking is realized by modifying the consensus protocol to enable the staking of liquidity provider (LP) tokens. LP tokens represent a share of the total liquidity contained within a DeFi exchange such as Uniswap or Curve.
As is shown in section B in the below diagram, EigenLayer enables a host of pathways for yield stacking (i.e., to earn staking yields in multiple ways simultaneously) that allow stakers to earn additional yield by securing new Actively Validated Services (AVSs).
Broadly speaking, there are three distinct layers that make up the EigenLayer blockchain: the core protocol, AVSs, and DeFi. Liquid staking is a mechanism that allows users to stack additional yield via the core protocol and then the DeFi layer, while superfluid staking first goes through the DeFi layer prior to the core protocol layer (i.e., it is the opposite of liquid staking).
In addition to liquid staking and superfluid staking, EigenLayer leverages restaking. Specifically, EigenLayer makes use of several distinct variations of restaking, including:
- Native restaking: Validators are able to restake their staked ETH natively by designating their withdrawal credentials to EigenLayer smart contracts. That is, native restaking is equivalent to L1 → EigenLayer yield stacking.
- LST restaking: Validators are able to restake by staking their LSTs, ETH already restaked and held within protocols such as Lido, Swell, and Rocketpool by transferring their LSTs into EigenLayer smart contracts. Precisely, LST restaking is equivalent to DeFi → EigenLayer yield stacking.
- ETH LP restaking: Validators stake their LP tokens paired with their ETH. ETH LP restaking is equivalent to DeFi → EL yield stacking.
- LST LP restaking: Validators stake their LP tokens paired with a liquid staking Ethereum token such as Curve’s stETH-ETH LP token, therefore utilizing the L1 → DeFi → EL yield stacking route.
It should be understood that each of these distinct staking mechanisms comes with a predetermined set of risks. In continuing with the tenet of opt-in governance, EigenLayer outsources the management of these risks to module (AVS) developers.
As an example, developers are tasked with determining which tokens to accept as stake within their AVS. They may also determine whether or not preferential reward weighting is used for tokenized reward distribution for different types of stake tokens. For instance, a module focused primarily on decentralization may choose to explicitly accept restake only in natively restaked ETH.
EigenLayer’s Three Layers of Programmable Trust
Today, if a developer wishes to build a smart contract protocol like a DEX, money market, or the like on Ethereum, they leverage the security from Ethereum's larger trust network by deploying their contracts on top of the Ethereum blockchain.
This has brought with it the massive proliferation of cutting-edge smart contract protocols focused on DeFi, NFTs, and more that leverage the robust security guarantees of Ethereum.
Nonetheless, until recently, Ethereum’s security has only been realized on smart contract protocols, meaning it has been extremely difficult to provide security to distributed systems such as bridges, sidechains, oracle networks, sequencers, data availability (DA) layers, and others. Unfortunately, this has typically led developers having to undertake the complexities involved with bootstrapping their own trust network to acquire the security they need.
This cumbersome bootstrapping requirement is perhaps the most substantial obstacle limiting innovation in distributed systems from achieving comparable variety, scale, and speed typically seen in smart contract protocols.
This has so far been one of the greatest limitations in the development of decentralized networks. Thankfully, EigenLayer solves this issue.
Imagine if developers the world over were able to tap into a massive network with billions of total value locked (TVL) and hundreds of thousands of validators instead of building their own network from scratch by utilizing the security and trust guarantees of Ethereum programmability based on the requirements of the platforms they’re developing.
This would eliminate the need for developers to bootstrap their own trust network, allowing them to focus on building systems that pay fees to the programmable network to use its underlying security, bringing with it the ability to develop distributed systems to help realize a freer, more democratic internet.
The Basics of EigenLayer
EigenLayer is the first universal network that furnishes programmable trust from Ethereum. More precisely, EigenLayer is an interconnected set of smart contracts on Ethereum and a set of off-chain node software that enables solo stakers, LST stakers, and staking service providers, to opt-in and run independent offchain distributed systems.
Typically, Ethereum validators stake ETH to make capital-based commitments to prove their loyalty to the Ethereum protocol.
EigenLayer is built to expand the commitments stakers make to include the ability to opt-in (by supporting the platform of their choice) to actively participate and fulfill a variety of tasks that support new use cases and distributed systems. To opt into these systems, stakers run supplementary node software (called operators) and allow EigenLayer smart contracts to enforce additional programmable slashing (penalization) conditions on their staked ETH or liquid staking tokens as predetermined by these distributed systems.
On EigenLayer these distributed systems furnishing a plethora of new use cases are called Actively Validated Services or AVSs. AVSs come in many forms including data availability layers, bridges, oracle networks, virtual machines, keeper networks, fast finality layers, AI inference/training systems, trusted execution environments (TEEs), threshold cryptography schemes, secure multi-party computation (MPC) frameworks, and many more.
An extremely powerful characteristic of EigenLayer is that the system allows block producers to make commitments complementary to Ethereum software in a manner that allows new ideas related to block construction, ordering, and on-chain activation to be experimented with without conducting in-protocol upgrades.
To read more about how operators and AVSs work together to form a mutually beneficial relationship, have a look at our deep dive on this topic in article two of our larger EigenLayer series.
Unboxing Programmable Trust
EigenLayer is based on the premise of programmable trust. Specifically, there are three distinguishable layers of trust that can be programmatically acquired from Ethereum via EigenLayer, including:
- Economic trust - trust from individuals making a commitment to support the EigenLayer network and support their pledges with financial capital (i.e., the total amount of capital staked on the platform).
- Decentralized trust - trust provisioned via the presence of a decentralized network of node operators in geographically isolated independent locations (i.e., the total number of validators and their distribution).
- Ethereum inclusion trust - trust that Ethereum validators (operators) will create and amend a user’s blocks in the same manner it made promises to the user adjacent to the consensus software they are running (i.e., the percentage of Ethereum validator opt-in).
In some instances, an AVS may require an amalgamation of different types of trust. EigenLayer is a network that enables AVS developers to assemble the above points of trust in different ways to create an appropriate trust model for their specific service.
To obtain a better understanding of the different types of trust under the programmable trust umbrella, let's have look at each one in more detail:
Economic Trust
On EigenLayer, economic trust is trust based on capital. Guarantees of this nature are accepted when specific commitments are backed by financial stake that makes it unreasonable for a rational economic actor to behave maliciously. The primary feature of economic trust is that an AVSs validation semantics are impartial in nature.
Precisely, impartiality means that if an operator malevolently deviates from the specific validation semantics while responding to the AVSs task, then the possibility exists that an observer can create an objective on-chain proof used to slash (penalize) the dishonest validator.
As an example, a chain is able to adopt reorganization resistance via EigenLayer nodes if the nodes have allocated assets behind the sequence it is committing to, which will then be slashed if reorganization occurred.
Additional applications of economic trust include:
- Optimistic claims: Provided that there is enough economic value staked on EigenLayer to ascertain a set of impartially verifiable claims, then those claims can be instantly considered correct, acted on, and subsequently slashed if violated. For example, let’s consider light client bridges, whereby light clients are run on numerous additional chains of-chain while making claims about the canonical fork of the other chain on Ethereum. In this circumstance, the input requires immediate action without latency and is subsequently slashed if deemed incorrect.
- Arbitrary slashing conditions: Rollups are typically thought to only support fraud proofs for state execution. On EigenLayer, all slashable violations (such as double signing) are susceptible to penalization, meaning EigenLayer can be used to broaden functionality beyond state execution. By way of illustration, it is possible to construct an ETH-staked oracle that is slashed in proportion to a more expensive trusted input (e.g., soliciting inputs via well trusted sources or individuals). Despite the fact that the second committee isn’t cryptoeconomic, EigenLayer’s power lies in its ability to let different stakers only opt-in to trust assumptions they are comfortable with.
- Latency improvement: Because Ethereum is considered to be a single processor, its clock speed is restricted by its finality period of a minimum of 2 epochs (~12mins). In the event there is adequate ETH or LST restaking on EigenLayer, it is conceivable to enhance the clock speed to achieve a considerably larger amount of full economic security at native network latency. For instance, a primitive where overclocking is required results in super fast finality. Leveraging EigenLayer, it is possible to run a superfast finality chain atop Ethereum which allows for fast economic finality while settling optimistically on Ethereum. This superfast finality chain employs ZK proof verification and typically achieves consensus in seconds.
Decentralized Trust
On EigenLayer, decentralized trust is trust based on decentralization. The realization of this guarantee is derived via the presence of a sufficiently distributed validator set (validators in different geographical locations run by independent entities/individuals) that largely eliminates the possibility of malicious validator collusion.
Many AVSs operating on EigenLayer make use of failure modes that are not objectively verifiable, easily identifiable, or penalized on-chain. Therefore, they cannot rely solely on a system of economic trust.
To combat these challenges, they can be developed on top of a system of decentralized trust, whereby the transparency of the AVS remains sufficient as long as enough validator nodes act independently without collusion. One of the main ways to prevent collusion is to leverage a large decentralized validator set that makes collusion challenging and easily identifiable.
In addition, AVSs are able to set predefined validator entry conditions via subjective oracles that only authorize the participation of nodes configured in a specific way, thus ensuring maximum validator decentralization.
By identifying and incentivizing decentralized validators through the accrual of additional fees, the rewards allocation given to decentralized validators is oftentimes more than their centralized counterparts. This framework of admitting only decentralized validators potentially represents the formation of a true market value for decentralization.
Examples of AVSs that can be built with decentralized trust include:
Secure Multiparty Computation: A basic example is Shamir secret sharing whereby a network participant requires a secret to be partitioned into shards and stored within the greatest number of non-colluding nodes as possible. In this instance, collusion presents as non-attributable. Therefore, the AVS is able to rely on decentralized trust instead.
EigenDA: Within EigenLayer, economic trust and decentralized trust are often combined to create new services atop the network. For example, EigenDA depends on decentralization to eliminate collusion (while ensuring data remains available) and economic trust to penalize equilibrium discrepancies (if a node isn’t storing data they will be slashed via a proof of custody system). This model combines decentralized trust (collusion impediment) and economic trust (having ETH slashed).
In the event an AVS requires decentralized trust, as an AVS developer it is critical that the node software needed to execute AVS validator semantics is as lightweight as possible. This will ensure a significantly lower resource cost for stakers within an AVS’s decentralized quorum (consensus), incentivizing more stakers to participate, therefore ultimately providing more decentralized trust.
Ethereum Inclusion Trust
Although the first and second trust models absorb the decentralization and economics of the Ethereum trust network, Ethereum validators taking part in restaking enable an entirely new suite of advanced features that allow for the experimentation of new opt-in features within the Ethereum protocol without modifying its core. These specific opt-in features open up the possibility of new proposer commitments in addition to existing proposer commitments from the consensus protocol.
Let’s discuss some applications of Ethereum inclusion trust:
MEV Management: As it relates to MEV management, Ethereum block proposers are able to construct legitimate commitments to order blocks using different rule sets, producing an all-encompassing MEV toolkit: 1.) producers choosing to commit to selling portions of blocks in the MEV market that they have yet to propose in the future, and 2.) producers agreeing to take part in event-driven actions. As an example, proposers that agree to include specific transaction types (e.g. collateral refueling) in their block and execute this mechanism when certain events take place.
Single-slot-finality: While the interaction with Ethereum’s Gasper consensus protocol needs to be carefully considered, when a sufficient number of block producers opt-in to carry out new EigenLayer tasks when it is agreed that a block will not be forked, single-slot economic finality is achieved.
AVS Development and Programmable Trust
To inherit programmable trust as an AVS developer, several main considerations must be analyzed:
- What types of trust (i.e., economic trust, decentralized trust, Ethereum inclusion trust) are most suitable for your AVS and its underlying business model? And how would penalization parameters for this specific service be instituted in the event this trust is broken?
- How much trust (amount of capital staked, number of distinct distributed validators, and number of Ethereum validators required to carry out an Ethereum inclusion commitment) does your AVS need to operate in a balanced and equitable manner long term? And how would you incentivize this model?
It is important to understand that there is no one-size-fits-all approach to these questions and realizing programmable trust, as it’s fully dependent on the design of the AVS and its required security parameters.
