## Liquid Restaking Tokens Demystified

*Authored by [Bobby Bola](https://twitter.com/bobbay_b) and [Swapnil Raj](https://twitter.com/swp0x0)*

With the recent launch of EigenLayer, we have now entered the restaking renaissance. This has led to the creation of Liquid Restaking Tokens (LRTs), which, since their inception in the fourth quarter of 2023, have amassed a staggering $9.9 billion as of April 30, 2024, and make up a majority of EigenLayer Deposits.

Subsequently, there has been a noticeable surge in capital withdrawals from renowned Liquid Staking Tokens (LSTs) like Lido and RocketPool.

This trend can be expected from users' eagerness to deposit into LRTs in anticipation of the projected high APYs, EigenLayer points, and LRT tokens. We can expect a continued uptick in investments into LRTs going forward, with a significant portion of these funds being redirected from LST investors.


Considering the substantial inflow, we believe a post is required delve into the intricacies of the LRT design space. This post aims to enlighten LRT depositors about the potential underlying mechanisms at play, as this is much more complex than LSTs.


# LRT Basics

Similar to Liquid Staking Tokens (LSTs) like Lido, stakers avoid the necessity of operating their own validators. Instead, stakers entrust the responsibility of managing validators to the restaking protocol on their behalf.

Liquid Restaking Tokens are token representations that are created when a user deposits ETH for restaking, LRT protocols are the natural successor for LST protocols.

The introduction of LRTs, while furthering the Ethereum network's security, also introduces the added obligation of selecting AVSs for safeguarding with the staked ETH. Committing ETH to an LRT protocol entails placing trust in the protocol's capacity to choose the appropriate AVSs and Operators to act on the staker’s behalf. In reciprocation, the staker is awarded a LRT, which represents entitlement to rewards derived from the security of those AVSs. These incentives are distributed between the staker and the LRT protocol.

As a brief refresher, an Actively Validated Service is a system that requires active validation from operators to securely provide its services to the ecosystem. AVSs leverage the security of ETH through restaking to bolster security measures and curtail operational expenses.

Mirroring LSTs, the proliferation of LRT protocols signifies a streamlined mechanism for stakers to contribute to the security of AVSs without the burden of managing their own validators. Building upon the collective experience gained with LSTs, the emergence of various iterations of LRT protocols is unsuprising. Despite their superficial resemblances, these protocols operate with distinct underpinnings.

# LRT Stakeholders

Similar to LSTs, LRTs rely on external stakeholders in order to operate. However, AVSs require involving additional stakeholders, specifically bringing in risk providers.

| LST | LRT |
| --- | --- |
| Staker | Staker |
| Operator | Operator |
| | Risk provider |

Let’s recap some of the overlapping roles before we examine the additional role, a risk provider.

## Stakers

Stakers occupy similar roles in the frameworks of both LSTs and LRTs. By staking their ETH, stakers are compensated with a tokenized representation of their deposits, which represents their share within the protocol.

The primary distinction lies in the scope of security provided. Depositing into an LST means staking solely for the purpose of securing ETH. In contrast, depositing in LRTs not only involves securing ETH but also extends to securing AVSs. This introduces a wider spectrum of AVS strategies from which a staker may select, thereby adding further difficulty to the decision-making process.

Faced with this scenario, a staker is met with confusing decisions: Does one opt for the strategy offering the highest yield? Is a more conservative approach ideal? Or lean towards a strategy involving blue-chip AVSs? These questions underscore the various considerations intrinsic to engaging with LRTs as opposed to LSTs.

## Operator

Operators within LSTs and LRTs perform similar network security operations. The fundamental difference between the two lies in the scope of their security obligations: LST operators are dedicated to safeguarding the Ethereum network, whereas LRT operators extend their protective measures to Actively Validated Services (AVSs) as well.

Eigenlayer documentation explains this succinctly, so I’ll share their description below.

> Operators, who can be either individuals or organizations, play an active role in the EigenLayer protocol. By registering within EigenLayer, they enable ETH stakers to delegate their staked assets, whether in the form of native ETH or LSTs. The Node Operators then opt-in to provide a range of services to AVSs, enhancing the overall security and functionality of their networks.
>

Parallel to the operational models in LSTs, each LRT protocol adopts its unique procedure for the incorporation of new operators into its system, a topic to be delved into further within this post.

It is important to note an added layer of complexity for operators engaging with LRTs: each AVS comes with its unique set of slashing rules. This diversification in slashing frameworks not only complicates the operational landscape for operators but also escalates the risk of incurring penalties, given the multiplicity of AVSs, each governed by distinct slashing protocols.

## Risk Providers

For LSTs, the absence of a risk provider was expected, as the process was straightforwardly centered around the staking of ETH.

LRTs introduce a paradigm where the staked ETH is leveraged to bolster the security of AVSs, with the aim of generating yield. This innovation prompts a critical deliberation for LRT DAOs: the selection of AVSs for securing. The choice of an unsuitable AVS could affect the DAO, potentially leading to the slashing of staked ETH. On the other hand, an overly conservative strategy in AVS selection may render an LRT less competitive relative to its peers.

LRTs find themselves at a crossroads, necessitating a delicate balance between revenue maximization and the maintenance of security. The introduction of risk providers becomes a natural progression. Risk providers will be tasked with aiding the LRT DAOs in the assessment of AVSs to either incorporate or exclude from their strategies, contingent upon the strategy's risk tolerance.

**Risk providers**

Currently, the most prominent risk providers in the ecosystem are focused on the Lending/Borrowing market sector, exemplified by Aave and Compound, benefit from the expertise of Chaos at Aave and Gauntlet at Compound, respectively. These risk providers are instrumental in adjusting risk parameters for assets, thus enabling the DAO to navigate the tightrope between minimizing the emergence of bad debt and capitalizing on opportunities to enhance their yield.


Risk providers are expected to assume a comparable function within this context; however, their focus will pivot from the onboarding of assets and the adjustment of asset parameters to the formulation and phasing out of AVS Strategies. They will be responsible for the inclusion or exclusion of AVSs from strategies, grounded in the economic analyses conducted by the risk provider.

Each LRT may adopt either a singular or a multitude of strategies, contingent upon their risk tolerance. It is anticipated that LRTs will incorporate a variety of strategies, as this diversification offers a broader array of options for stakers, thereby enhancing their competitiveness. A myriad of strategies could emerge, and we have delineated a few of the fundamental approaches below.

| Risk | Low | Medium | High | Degen |
| --- | --- | --- | --- | --- |
| APY | 6% | 8% | 12% | 15% |

The array of strategies available to liquid LRT stakers affords them the flexibility to choose among low, medium, or high-risk yield strategies, catering to their individual risk preferences. Regardless of whether LRT DAOs implement a single strategy or a diverse portfolio of strategies, the management of these strategies is comparable to the oversight of index funds. The graphic below illustrates how each strategy is distinct, being composed of varying AVSs, underscoring the tailored approach adopted in strategy composition.


As previously highlighted, risk providers are expected to play a significant role in the formulation of AVS strategies within the LRT ecosystem, as well as in making any requisite adjustments to these strategies. These adjustments will be predicated on a multitude of factors that ascertain the safety factor of an AVS. It is probable that each risk provider will employ their unique methodology to evaluate the suitability of an AVS for inclusion in a strategy. There is an anticipation that some of these methodologies will be disclosed to the public, fostering transparency and understanding in the strategies' formation and adjustment processes.

As mentioned earlier, the fundamental role of AVS Risk providers is to guarantee that LRTs align with the most suitable selection of AVSs that correspond to their risk tolerance. These providers will offer counsel to DAOs regarding the AVSs they ought to secure, which encompasses recommendations for both the inclusion and exclusion of AVSs in their strategies, as illustrated below.


This process will necessitate LRTs to establish whitelisted contracts for AVSs that have received DAO approval and are supported by operators. If an AVS is not listed in the whitelist contract, it will not be eligible for use within a strategy unless it undergoes and is approved by a governance process initiated by the DAO. This ensures a structured and secure approach to integrating AVSs into LRT strategies, underpinning the governance and operational framework of the LRT ecosystem.

| LRT DAO Whitelist |
| --- |
| EigenDA |
| Aethos |
| Anzen |

In practical terms, if an LRT DAO were to approve the three specified AVSs, operators would then be confined to supporting only these AVSs through the staked deposits accrued via the LRT protocol. The introduction of an additional AVS would require its inclusion in the whitelist (WL) contract prior to its integration into operator activities. This mechanism serves as a protective measure, preventing operators from engaging with unapproved AVSs that could potentially expose depositors to excessive risk.

This arrangement necessitates ongoing dialogue between the DAO and the operators to foster a sustainable and productive relationship, further complicated by the dynamics of adding or removing AVSs. It is important to note that each AVS comes with its own specific set of slashing conditions, adding another layer of complexity to their management.

# LRT Structure Design

Each LRT protocol exhibits distinct characteristics across several dimensions, including the onboarding processes for AVSs and operators, the appointment of risk curators, strategy selection, and the governance processes. In this section, we will delve into the various approaches that LRTs may adopt in integrating AVSs and operators into the DAO.

## DAO Design

### Onboarding AVSs

Due to the permissionless nature of Eigenlayer, anyone can develop an AVS. However, the inclusion of an AVS within a Liquid Restaking Token (LRT) strategy requires a governance procedure to confirm its compatibility and alignment with the specific objectives and risk parameters of the LRT.

Each LRT employs a unique methodology for incorporating an AVS strategy, a reflection of their individual governance frameworks. In the forthcoming sections, we will explore a variety of these methods to gain insights into the diverse approaches that may be anticipated across the LRT ecosystem.

**DAO Vote**

1. A risk provider submits a recommendation to either add or remove AVS X from Strategy 1, which is then posted on the discussion forum.
2. The recommendation is subsequently escalated to a snapshot vote.
3. The result of the snapshot vote determines the next steps:
1. If the vote passes, AVS X is either added to or removed from the Strategy 1 Whitelist (WL) Contract.
2. If the vote fails, no changes are made to the current strategy.
4. Following the update to the WL Contract, operators begin or cease securing AVS X based on the voting outcome.

**Note:** Any changes to an operator have a 7-day delay period; acting as an escape hatch.

This pathway is also explained in the diagram below.


**Risk Provider Committee**

The DAO establishes a risk provider committee empowered with the authority to modify the WL AVS contract on behalf of the DAO. This involves the following process:

1. The risk provider committee announces their planned adjustments to AVSs on the forum.
2. Should these proposals remain unchallenged, they are implemented by the committee after a predetermined number of days, leading to modifications in the WL contract.
3. Operators then adapt their activities in accordance with these changes.

While this approach allows for swift and efficient decision-making within the DAO, it represents a move towards a more centralized and trust-dependent method. Such centralization is often viewed unfavorably because it diverges from the principles of decentralization and transparency that are core to the ethos of DAOs and the broader decentralized community. Emphasizing transparency is crucial for LRT DAOs; it ensures that all decisions and actions are conducted openly, which builds trust and encourages active participation from the community. This commitment to open governance is essential to uphold the values of decentralization.

**Decentralized Verification**

The trend towards minimal or even non-existent governance within the space marks a critical transition, sparking a dialogue around **decentralized verification** as a feasible model for LRTs.

Decentralized verification equips a DAO with the ability to enforce a system that minimizes trust reliance while maximizing efficiency and transparency. This framework supports the optimistic validation of rules concerning the proposal and execution of changes to AVS strategies, based on the risk provider's established methods. It democratizes the entire process, allowing any participant to propose or challenge adjustments, thus broadening transparency throughout the system.

**Within the sphere of decentralized verification,** the strategy rules, as prescribed by the risk methodology, are subjected to optimistic validation against these predefined standards. This approach not only heightens the level of decentralization but also strengthens the sustainability of LRT strategies.

A constraint of this model is the need for the methodology to remain fixed, limiting adaptability compared to other models. However, it serves as an ideal solution for strategies that rely on simpler, more straightforward methodologies.

For example, a strategy utilizing decentralized verification might focus exclusively on a portfolio of “extremely low-risk” AVSs or “Blue-Chip AVSs,” showcasing an uncomplicated and cautious method. This approach exemplifies how decentralized verification can be effectively implemented to maintain stringent control over the portfolio's risk exposure.

Index Coop currently uses this method to reweight their dsETH index token.


Index Coop has adopted decentralized verification method via UMA’s Optimistic Oracle (OO) to validate and enforce the methodologies for its products. This integration facilitates the automatic execution of reweighting and rebalancing actions in a manner that minimizes reliance on trust, maximizes efficiency, and ensures transparency.

The OO allows the DAO to optimistically validate rules concerning the proposal and implementation of token reweights and rebalances. This system enables anyone to propose or dispute rebalances, significantly enhancing the transparency of the process. This showcases the flexibility of the OO and its increasing role in helping top DAOs navigate towards more decentralized governance frameworks.

This movement aligns well with the broader DeFi ethos of promoting transparency, reducing trust dependencies, and empowering community involvement in decision-making processes.

### Onboarding Operators

The process of onboarding operators is a critical aspect of LRT design, as it directly impacts the security, decentralization, and performance of the restaking protocol. Different LRTs may adopt various approaches to operator onboarding, depending on their governance structure and design philosophy. Let's explore a few examples:

### Lido - Proof of Governance (PoG)

Lido, a leading Liquid Staking Token (LST) protocol, employs a Proof of Governance (PoG) mechanism for onboarding new operators. In this model, the Lido DAO is responsible for vetting and approving new operators through a governance process. Prospective operators must demonstrate their technical capabilities, security practices, and commitment to the network. Once approved by the DAO, the new operator is added to the Lido protocol and can start validating on behalf of stakers.

### RocketPool - Permissionless Onboarding

RocketPool, another prominent LST protocol, takes a permissionless approach to operator onboarding. In this model, anyone can become an operator by meeting certain technical requirements and staking a minimum amount of RPL tokens as collateral. This permissionless approach lowers the barrier to entry for operators and promotes decentralization. However, it also places more responsibility on individual operators to ensure their own security and reliability.

### Byzantine - Auction System

Byzantine, a novel LRT protocol, implements an auction-based system for operator onboarding. Prospective operators participate in a sealed-bid auction, where they specify the amount of ETH they are willing to stake and the percentage of rewards they will share with the protocol. The Byzantine DAO then selects operators based on their bids, favoring those who offer the most competitive terms. This auction mechanism aims to create a market-driven approach to operator selection, incentivizing operators to provide the best possible service to the protocol.

### Considerations for LRT Operator Onboarding

When designing an operator onboarding process for LRTs, several key considerations come into play:

1. **Security**: The onboarding process should ensure that operators meet high standards of security, including secure key management, infrastructure redundancy, and protection against various attack vectors.
2. **Decentralization**: The onboarding process should promote decentralization by allowing a diverse set of operators to participate, preventing concentration of power among a few large operators.
3. **Alignment of Incentives**: The onboarding process should create alignment between the interests of operators and the protocol, encouraging operators to act in the best interest of the network and its users.
4. **Flexibility**: As the LRT ecosystem evolves, the onboarding process should be flexible enough to adapt to changing requirements and incorporate new best practices.

LRT DAOs must carefully consider these factors when designing their operator onboarding processes, striking a balance between security, decentralization, and efficiency. As the LRT landscape matures, we can expect to see further innovations in operator onboarding, drawing from the lessons learned in the LST space and adapting to the unique challenges of restaking.

# Reward Share

When discussing how LRTs share rewards with their stakers, the first crucial aspect to consider is how the LRTs choose which Actively Validated Services (AVSs) to stake with. There are several approaches that LRTs can adopt for this decision-making process:

### Centralized Approach

In a centralized approach, the LRT protocol's internal team is responsible for selecting the AVSs to stake with. This method allows for quick decision-making and adaptability to market conditions. However, it also introduces a level of centralization and trust in the LRT team, which may not align with the decentralized ethos of the broader ecosystem.

### Decentralized Approach

A decentralized approach involves the LRT DAO (Decentralized Autonomous Organization) choosing which AVSs to stake with through a governance process. This method ensures that the decision-making power is distributed among the LRT token holders, promoting decentralization and community involvement. However, it may result in slower decision-making and potential challenges in reaching consensus.

### Automated Risk Program

In this approach, either a centralized or decentralized entity selects a program responsible for choosing the AVSs based on their risk factor. The program is designed to assess the risk profile of each AVS and make staking decisions accordingly. This method aims to provide an objective and data-driven approach to AVS selection, reducing the reliance on human judgment.

## Diversifying AVS Risk

Stakers in LRT protocols may desire diversification across different AVSs to mitigate risk and optimize their returns. By spreading their stake across multiple AVSs, stakers can reduce their exposure to any single AVS and potentially benefit from the combined rewards of various services. Diversification helps to protect stakers from the potential failure or underperformance of individual AVSs, ensuring a more stable and resilient staking portfolio.

### Multiple Strategy LRTs

Some LRTs may offer multiple staking strategies to cater to the diverse risk preferences of their stakers. In this model, the LRT protocol creates different vaults, each with varying levels of risk exposure. Each vault has its own liquid representation, allowing stakers to choose the strategy that aligns with their risk tolerance. However, this approach introduces complexity, as stakers need to convert their vault tokens into a single liquid token to maximize liquidity and composability.


## Reward Token

The choice of reward token is another essential consideration in the LRT ecosystem. LRTs can opt to distribute rewards to stakers in various forms, each with its own implications for stakers and the broader ecosystem.

### AVS Tokens

By default, staking rewards in LRTs are paid out in the native tokens of the AVSs being secured. This means that stakers receive a share of the AVS tokens proportional to their stake in the LRT protocol. While this approach is straightforward, it exposes stakers to the price volatility of the AVS tokens and may require them to manage multiple token positions.

### Ether-based Rewards

An alternative approach is to pay out staking rewards in Ether (ETH) instead of AVS tokens. This can be achieved through various mechanisms, such as an auction-based reward share system.

In an auction-based reward share model, the LRT protocol conducts an auction where AVSs bid for the staked assets. The stakers are paid from the proceeds of the auction in ETH, while the operators keep the AVS tokens. This approach shields stakers from direct exposure to AVS tokens, which can be beneficial in mitigating sell pressure.

Since stakers may be less informed about the AVS token's value, they are more likely to sell, leading to increased sell pressure on the AVS token's price. By keeping the AVS tokens with the operators, who are more informed and invested in the long-term success of the AVS, the auction-based model can help stabilize the AVS token's price.

## Reward Share Percentage

Another critical aspect of the reward share mechanism is determining the percentage of rewards that are distributed to stakers and the LRT protocol. Different LRTs may adopt varying reward share percentages based on their tokenomics and business model.

For example, an LRT protocol may opt for a 90/10 split, where 90% of the staking rewards are distributed to the stakers, and 10% are retained by the protocol to cover operational costs, fund development, and incentivize the team. Other protocols may choose different ratios, such as 80/20 or 95/5, depending on their specific goals and requirements.

It is essential for LRTs to strike a balance between incentivizing stakers and ensuring the long-term sustainability of the protocol. A well-designed reward share mechanism should align the interests of all stakeholders, including stakers, operators, and the LRT protocol itself.

# Conclusion

The landscape of Ethereum staking is evolving with the introduction of LRTs, which have seen a rapid accumulation of funds, however this development necessitates a deeper understanding of the complex mechanisms underlying LRTs compared to LSTs, particularly concerning the role of risk providers and the strategic selection of AVSs.

This post hopes to show the reader various ways in which LRTs may approach designing their protocol from various aspects: on/offboarding operators, on/offboarding AVSs, and reward shares. We have been ideating on many ways to streamline the above process at Nethermind and UMA. If interested, please reach out to learn more.