Unraveling the Intricacies of Restaking: Insights from the Restaking Roundtable

Introduction

Ion Protocol recently had the opportunity to be a part of The Restaking Roundtable, featuring insights from leaders in the space such as Swell Network, Renzo Protocol, Ankr, and CubistDev just after this year’s Dev Connect in Istanbul. In this AMA we shed new light on how restaking is evolving, particularly in the context of Liquid Restaking Tokens (LRTs), Actively Validated Services (AVS), and broader adoption trends.

This blog post delves into the three major takeaways from this enlightening discussion.

The Essence of Restaking in Ethereum’s Landscape

Restaking, a novel concept in Ethereum’s Proof of Stake (PoS) ecosystem, allows for the expansion of security services beyond the Beacon Chain. It enables anyone to build on Ethereum without using it’s primitives, all the while inheriting security from Ethereum’s PoS via stakers who opt in to additional validation rules and slashing conditions. These are the credible commitments of a restaker.

At the foundation of any restaking position are staked assets, which already secure the Ethereum network. By opting in to provide security to an AVS, stakers deposit their assets and subject them to additional credible commitments. In doing so restakers play a role in scaling the security of the Ethereum network while gaining the ability to express their beliefs and earn greater yield.

Takeaway #1: The Open Questions and Challenges in Restaking

One of the primary concerns discussed was the complexity surrounding node operator support for AVSs. Key questions include understanding the rules and risk appetites of restakers, and the development of optimal risk-reward strategies.

This is closely tied to the additional slashing conditions that each new AVS introduces, creating a stream of new risks. Riad, co-founder of Cubist, emphasized the importance of designing AVSs with clear, followable rulesets that minimize the chance of accidental violations while maintaining necessary security standards.

Takeaway #2: Safety in Node Operation

Due to the benefits of simple ruleset design, AVSs will most likely concentrate into generalizable verticals over time to further simplify the security and risk assumptions respective to different services. This will help streamline and generalize node operator set-ups and risk management for these specific verticals.

Essentially, the risk of an AVS and its node operators needs to be properly underwritten. More on this later…

To ease the operational burden on node operators AVSs can implement a standard set of rules within each respective vertical of AVSs such as BFT and DA. Setting a standard set of rules for node operators to follow while providing security to the AVS will lighten the overhead of integration for them. This lowers certain barriers to adoption and makes it easier to attract more node operators, restakers, and integration partners.

Node operators can further help themselves by using key management systems like the ones being developed by CubistDev. These systems aim to provide a trustless security mechanism to mitigate slashing.

An endgame goal here could be to implement standardized antislashers for each popular product vertical; pieces of software with modular designs that could support the rules and slashing conditions defined by the most popular AVSs. These would minimize slashing risk immensely, derisking the most sticky AVS implementations.

Speculations and the Path to Restaking Adoption

Despite various innovative developments, there remains speculation regarding the extent of restaking adoption. Following the resounding message throughout the development of the discussion the panelists agreed that building the necessary infrastructure and designing AVSs with clear rules are critical steps to facilitate wider adoption among regular DeFi participants.

LRTs – as exemplified by Renzo Protocol – and other DeFi applications like Ion are crucial for enabling broader participation in restaking. They allow users to maintain their restaking positions, and participate in the broader DeFi ecosystem.

Focusing on supporting the safest AVSs through governance or automated credit ratings ensures that economic incentives align with a security-first approach. This alignment is key to providing less technical users with access to restaking opportunities that offer a well-defined risk-reward payoff. By collaborating to better make these technical innovations more transparent, we’re presented with a plethora of potential implementations. At the bare minimum we believe that quantifying the risk to reward tradeoff of opting in to different sets of node operators for LRTs is extremely necessary. In doing so we’ll be able to more easily identify creditworthy LRTs which have comprehensible credible commitments and security measures well established.

In short, we’re trying to make it clear that if an AVS wants a large set of node operators which require restakers, it will have to design an easily integrable set of credible commitments. This is because restakers will be economically incentivized to prefer the integrable and safer option by way of the LRTs and the DeFi protocols supporting them.

Ion Protocol: A Case Study in Restaking Integration

Ion Protocol stands at the convergence of these key insights for several reasons:

• Its inception was driven by the lack of support for restaking positions in DeFi.
• The development of primitives to underwrite restaking positions – based on ETH reserves – enhances capital efficiency.
• Ion’s design involves each Validator and AVS having staked collateral subject to slashing conditions, primarily focused on ETH.

Notably, the collateral staked and backstopping these assets are foundational to the design of Ion Protocol. We’ve developed a zero-knowledge proof of reserve primitive to verify the redeemable ETH in the reserves of staking and restaking positions. We’ve also developed a zero-knowledge machine learning application to reliably predict the propensity of slashing and score entities by the risk they impose. Currently the ubiquitous collateral type is ETH, so we’ve made it our north star. In the future we can expect restaking positions to accept any variety of collateral types other than staked ETH. For the time being, we’ll focus on optimizing the methods we’ve developed for staked ETH and then look to extend our systems to quantify additional collateral types and sources of risk.

Conclusion

We’re extremely grateful to have been able to contribute to The Restaking Roundtable. We believe this conversation singlehandedly opened up new avenues of understanding with regards to restaking and the risks associated. As the ecosystem evolves, focusing on security, proper underwriting methods, and alignment of incentives will be crucial for the sustainable growth and adoption of restaking practices. The protocols that can design reliable, transparent, and sustainable mechanisms will drive adoption by means of a lower overhead of integration.

Since the beginning it’s been our goal to be at the cutting edge of innovation and contribute to supporting the newest frontier of builders looking to inherit Ethereum’s security. We want to make it easier for people to restake and participate in DeFi.

It’s easy to say, but in practice very nuanced. That’s what Ion Protocol is here for.