Restaking Protocols Infra Risk Framework

This post introduces a foundational risk framework for assessing the infrastructure risks of restaking protocols. Developing such framework is essential for underwriting risk and understanding these complex protocols, given the numerous complexities and interdependencies that make a thorough risk evaluation very challenging.

For this analysis, we have considered the most popular restaking protocols: EigenLayer, Symbiotic, Babylon, Karak, Solayer, and Jito.

1. Risk Profile of the Verifiable Trust Root(s)

   • Trust Root(s) Architecture, Economics, & Consensus Risk Profile(s)

   • Efficacy of Core Trust Root Slashing Conditions

   • Cross-Chain Trust Management Solutions

   • Interdependencies with Multiple Trust Roots

2. Overall Risk Profiles of Services, LRTs, and Operators Deployed

   • Services' Individual & Pooled Risks and Efficacy of Slashing Conditions

   • Liquid Restaking Protocols Portfolio Risks

   • Operator Network Risk Metrics

3. Types of Collateral Assets Accepted

4. Support for Endogenous and/or Exogenous Applications

5. Protocol Ecosystem Integration and Compatibility

   • Protocol Alignment with Core Trust Root

   • Compatibility with Foreign Consensus and Services Infra

   • Reliance on External Service Providers

6. Protocol Design Complexity & Security Audits

7. Multisig Governance Consensus Risk

8. Restaker & Validator Escrow Periods (Unbonding/Withdrawal Delays)

9. Reward Incentives Alignment Risk Profile

Restaking protocols allow stakers and validators to reuse their staked assets to secure additional services, offering new layers of security, and reward incentives. Here's a quick overview of the six protocols:

EigenLayer is a restaking protocol on Ethereum that allows validators to "restake" their ETH and derivatives to secure additional services called Actively Validated Services (AVSs). By utilizing Ethereum's robust security framework, EigenLayer extends its trust model to L2s and other networks, enabling new services to benefit from Ethereum’s validator set without needing to bootstrap their own. This approach maximizes Ethereum’s security reach, allowing projects to build with strong security guarantees while operating across multiple layers and chains.

EigenLayer integrates closely with Ethereum’s ecosystem, ensuring that all services built on it inherit Ethereum's L1 security. It also employs cross-chain trust tools like EigenCert and EigenBus to maintain secure and reliable operations across different networks, making it ideal for developers seeking to expand on Ethereum’s trusted network while exploring cross-chain capabilities.

Symbiotic is a shared security protocol, also built on Ethereum, that serves as a modular coordination layer, enabling network builders to customize and control their restaking implementations in a permissionless manner. It allows participants to manage key elements, like node operator selection, collateral management, rewards, and slashing mechanisms, providing flexibility across various networks.

The protocol’s components include ERC-20 collateral tokens and vaults that delegate that collateral to operators. Operators run infrastructure across networks (or AVSs when comparing with EigenLayer), while resolvers validate or veto slashing penalties for those operators. Symbiotic supports a variety of networks, such as appchains or rollups, allowing services to leverage its trust-minimized architecture for decentralized operations like data oracles and availability or transaction sequencing.

Babylon leverages Bitcoin's Proof-of-Work (PoW) security and enables Bitcoin staking to support Proof-of-Stake (PoS) chains through its dedicated chain (Babylon Chain), built on the Cosmos SDK. As a result, PoS chains can tap into Bitcoin’s security without needing their own validator set, creating a hybrid model that combines Bitcoin’s robustness and censorship-resistant blockspace with PoS benefits like lower energy use and faster finality.

By integrating Bitcoin’s security, Babylon allows PoS networks to scale securely and innovate without the need to bootstrap their own security, making it a compelling solution for chains seeking to leverage Bitcoin's established network.

Karak is a universal restaking protocol designed to support multi-asset restaking across Ethereum and other blockchains. Built on a modular architecture, it allows stakers to allocate a variety of assets—ranging from ETH and liquid staking tokens to stablecoins—into Distributed Secure Services (DSS). DSSs utilize these staked assets to enhance the security of decentralized services without relying on inflationary reward mechanisms, thereby offering a capital-efficient model for security provisioning.

Karak’s infrastructure is chain-agnostic, allowing for the deployment of restaking infrastructure across different blockchains. Its architecture includes ERC-4626 tokenized vaults, where operators manage staked assets and allocate them to DSSs. It also supports custom vaults, where developers can design tailored economic and slashing models for different asset types. This flexibility allows Karak to secure a wide range of applications enabling developers to tap into the security of multiple networks while minimizing overhead and complexity.

Solayer is a restaking protocol built on Solana, leveraging its high throughput and low-latency performance to secure both endogenous (native Solana dApps) and exogenous (external) services, with a focus on native applications. Validators can restake assets to secure various services, optimizing Solana’s Proof-of-History (PoH) and Tower BFT consensus for high performance and scalability. Solayer is ideal for fast, cost-efficient applications that fully align with Solana’s strengths.

Solayer tightly integrates with Solana’s runtime, enabling seamless interaction between native dApps and the validation framework. Validators can restake assets to validator-specific vaults, securing a wide range of decentralized services. By supporting both native and cross-chain projects, Solayer provides robust security and scalability, allowing developers to fully leverage Solana's infrastructure for diverse use cases.

Jito is also a Solana-based restaking protocol focused on flexible staking and liquidity management through liquid restaking tokens (VRTs) and customizable slashing conditions. Its architecture allows validators and stakers to dynamically manage risk and rewards, enhancing economic security while maintaining liquidity for DeFi. Jito is particularly suited for high-frequency trading and other fast-paced applications, leveraging Solana’s high throughput and low-latency capabilities.

Jito’s infrastructure enables diverse staking strategies, where validators can restake assets to multiple services while fine-tuning slashing conditions to specific needs. The protocol’s VRTs allow users to stake while preserving liquidity, offering efficient capital utilization.

The promise of restaking protocols comes with untapped risk vectors. To evaluate their infrastructure risks, we propose multiple dimensions impacting security, economics, and operational stability.

It's useful to precede the below explanation by defining the term "trust root":

• The trust root of a protocol/service is the foundational network where it's deployed, where assets are staked, rewards earned, and penalties adjudicated; establishing the core security and trust for that protocol/service.

• Trust Root(s) Architecture, Economics, & Consensus Risk Profile(s): The underlying trust root’s (typically L1s or L2s) architecture, economics, and consensus models define the protocol's foundational security. Karak, by allowing DSS deployment across multiple networks, splits its trust root, adding complex inter-chain dependencies and economic dynamics, and potential security fragmentation. EigenLayer, Symbiotic, Solayer, and Jito, however, benefit from a single trust root tied to their respective L1s. While a historically-improbable event, if the validators of these L1s are compromised, the entire protocol's security could be impacted.

• Efficacy of Core Trust Root Slashing Conditions: The ability to enforce penalties effectively is crucial. For example, Babylon relies on Bitcoin’s network (core trust root) security to enforce slashing, but this adds complexity due to the coordination needed between Bitcoin and PoS chains, which could lead to delays or inaccuracies in slashing enforcement. EigenLayer, Symbiotic, and Karak potentially pose less risk in this metric as Ethereum L1 (core trust root) slashing conditions are well-documented and proven reliable.

• Cross-Chain Trust Management Solutions: EigenLayer uses canonical service tools like EigenCert and EigenBus to maintain cross-chain end-to-end deployment trust, from trust root to applications. Other protocols lacking such solutions may face challenges in maintaining trust, particularly if they possess multiple trust roots.

• Interdependencies with Multiple Trust Roots: In protocols like Karak and Babylon, which span multiple networks and consensus trust roots, inter-chain dependencies introduce vulnerabilities. Karak allows for chain-agnostic DSS deployment and custom vaults, which are attached to any given operator. Babylon's PoW-to-PoS relationship creates interdependencies across potentially several PoS chains. If security is compromised in one place, it could affect the entire network of services and protocols themselves.

• Services' Individual & Pooled Risks and Efficacy of Slashing Conditions: Services must implement effective slashing (considering both objective and intersubjective) to ensure both their own security and that of the protocol. Inadequate slashing could fail to address faults, potentially compromising a service and triggering cascading effects across other services, the restaking protocol, and even the L1. Furthermore, thorough assessments of infrastructure risks—both in isolation and pooled—are crucial. Tokensight has taken on this endeavor, with examples on u--1's platform, blog posts such as EigenDA: AVS Cryptoeconomic Risk Analysis and LRT Infra Risk Framework, and AVS Risk sample dashboard.

• Liquid Restaking Protocols Portfolio Risks: Liquid restaking protocols (LRPs) represent a portfolio of services, balancing yields, risk appetites, and the underlying infrastructure security of each service. Tokensight has developed a framework for LRPs, focusing on AVS selection based on both isolated and ecosystem-wide infrastructure risks, on the post LRT Infra Risk Framework. While specific to EigenLayer's ecosystem dynamics, we plan on following a similar structure and logic for other protocols.

• Operator Network Risk Metrics: A protocol’s reliance on a decentralized, reputable operator network with strong and unique trust roots and sensible validator lock-up/withdrawal periods significantly boosts resilience. Similarly to LRPs, operators' risk profiles must also be assessed based on the portfolio of services they validate. On a trust root dimension, Karak may have a decentralized operator network on one root and a more centralized one on another, while Babylon's PoW/PoS consensus shock introduces risks to distinct sets of operators; both leading to inconsistent security.

The type of collateral accepted by a protocol impacts its security and economic stability, in terms of volatility, liquidity, and depeg risks. Babylon only accepts BTC as collateral guaranteeing robust security tied to Bitcoin's network value and straightforward alignment with its PoW consensus. However, protocols like EigenLayer, Symbiotic, Karak, Solayer, and Jito accept a wide range of ERC-20 and SPL (Solana's native token standard) tokens, with varying risk profiles and potential alignment shocks, as collateral.

Supporting both native (endogenous) and external (exogenous) applications adds flexibility but also distinct risks, particularly from the exogenous side. Solayer’s focus on native Solana dApps allows for seamless integration with Solana’s infrastructure, reducing attack vectors and enhancing security within a single trust root. In contrast, EigenLayer’s and Symbiotic’s support for exogenous services (AVSs and Networks) introduces complexity, as they must handle and accommodate different security standards, consensus mechanisms, and infrastructures of external applications. These differences can increase potential vulnerabilities and require careful management to prevent security breaches from impacting the broader restaking network and compromising overall protocol integrity.

• Protocol Alignment with Core Trust Root: In the restaking space, key questions remain about how well EigenLayer will align with Ethereum in the medium to long term. Ethereum Foundation members, including Vitalik Buterin and Justin Drake, have raised concerns about potential consensus overload and centralization pressures on Ethereum’s L1 validators. The same applies to other restaking protocols and how effectively they harmonize with the core trust root their infrastructure is deployed on.

• Compatibility with Foreign Consensus and Services Infra: Compatibility with external ecosystems can drive innovation and new adoption but also increases dependency risks. Babylon’s reliance on PoW (Bitcoin) versus PoS (Ethereum or other L1s) can pose challenges in integrating foreign consensus models, which could impact security. EigenLayer or Symbiotic, at the protocol consensus level, are fundamentally more stable—only interact with PoS consensus—, although supporting various other consensus profiles for their services (e.g., DPoS, BFT, CometBFT, Hybrid Consensus, etc) can introduce alignment risks and vulnerabilities. Certain restaking protocols may be more appropriate than others given the nature and goal of a service: the Solana ecosystem (Solayer and Jito) may tailor more closely, in terms of target audiences and economics, than the Ethereum one (EigenLayer and Symbiotic).

• Reliance on External Service Providers: Protocols that depend on integrated external service providers, like Babylon using the Cosmos SDK or EigenLayer using EigenCert and EigenBus, could inherit vulnerabilities from these providers. Evaluating their security and reliability is essential.

Complex designs are more likely to introduce bug risks, misconfigurations, or unforeseen attack vectors. Babylon can face risks associated with the dependencies on Cosmos SDK modules and the intricacies of coordinating between Bitcoin and PoS chains. Symbiotic being a protocol with highly customizable modules and parameters may also face unforeseen vulnerabilities and developers choice overload. EigenLayer with the introduction of the universal intersubjective work token, EIGEN, has enabled intersubjective slashing, requiring consensus agreement from observers along with potential disputes.

Such complexities can make it harder to ensure all parts of the protocol are secure and operate as intended. Considering the number of security audits performed and the soundness and efficacy of slashing conditions native per protocol are equally important.

EigenLayer employs a multisig governance system with three committees: Operations (3-of-6), Pauser (1-of-14), and Community (9-of-13). The Operations Multisig handles upgrades with a 10-day timelock for safety, while the Pauser Multisig focuses solely on pausing functions during emergencies. The Community Multisig monitors and intervenes in critical situations, ensuring checks and balances as governance evolves. Karak's governance is managed by a 4-of-7 multisig for upgrades, with a 2-day timelock, while four managers have emergency pausing powers to ensure quick responses without compromising security. Solayer’s governance revolves around a 3-of-5 multisig overseeing upgrades and emergency changes, with a focus on community involvement, as trusted leaders guide decision-making through a decentralized process.

While multisigs provide significant security and utility, reaching consensus can be problematic at times (particularly with multiple signers and >50% consensus required). If signers are misaligned, critical protocol functions may face delays or even temporary halts.

EigenLayer implements a 7-day withdrawal delay for tokens and native restaking, providing crucial time to detect and mitigate potential attacks before operators or stakers can withdraw. Symbiotic takes a modular approach with customizable epochs and veto durations to balance flexibility and security, ensuring slashing requests are processed efficiently, avoiding delays or high gas costs. Proper configuration of these durations is vital to ensuring stakers can effectively slash misbehaving operators. Karak enforces a 9-day stake update delay to prevent front-running slashing events, with a 7-day withdrawal period, allowing enough time to handle any malicious behavior before assets can be withdrawn. Solayer allows AVSs to design custom unbonding processes with a 2-day unbonding period and an emergency exit mechanism for AVS failures, balancing operator flexibility with security.

Escrow periods of many types enhance security by allowing time to detect and address vulnerabilities before funds are withdrawn. While they reduce risks like malicious exits and front-running, they can introduce complexity and, if mismanaged, lead to potential exploits or post-delay issues for users.

On EigenLayer, operators earn a flat 10% commission on rewards, with the remainder distributed to delegated stakers. Rewards are proportional to the amount staked and the AVS's relative weighting of strategies submitted by operators. Calculations occur off-chain, and a Merkle root is posted weekly to represent the cumulative rewards across all participants. On Symbiotic, operator rewards are calculated both off-chain and on-chain, with batch transfers or Merkle trees facilitating distribution. On-chain reward calculations use operator registration data, such as commission rates and fixed payments, to ensure accuracy. Staker rewards are based on active share data tracked through the vault, with external contracts managing their distribution across networks. Solayer focuses more on offline reward calculation, tracking deposits and withdrawals with state watchers, and provides real-time additional rewards based on invite relationships.

At an infrastructure level, the design of these reward systems is crucial for ensuring both economic sustainability and decentralization. Well-architected reward mechanisms contribute to network security by aligning economic incentives, while minimizing potential risks in infrastructure. This is a complex topic in active development in the space; Tokensight will be updating this subsection continuously as more details are released.

Restaking protocols are revolutionizing blockchain security by enabling validators to extend their influence beyond their native chains. However, each protocol carries unique infrastructure risks that must be considered. By applying a comprehensive risk framework that examines trust roots, services, liquid restaking, collateral types, design complexity, operator networks, multisig governance, rewards, and ecosystem integration, we can better gauge the security and reliability of these innovative solutions. As these protocols and space evolve, the above framework will also evolve and become more robust, to ensure that the restaking ecosystem prospers and remains secure and resilient.

Tokensight will be researching in greater detail all the risk metrics outlined, applying them specifically to each protocol, and announcing upcoming partnerships to this effect.

• EigenLayer: https://docs.eigenlayer.xyz/eigenlayer/risk/risk-faq, https://docs.eigenlayer.xyz/eigenlayer/overview/whitepaper, https://docs.eigenlayer.xyz/eigenlayer/security/withdrawal-delay, https://docs.eigenlayer.xyz/eigenlayer/avs-guides/rewards#overview

• Symbiotic: https://docs.symbiotic.fi/, https://naruto11.substack.com/p/gmbiotic, https://docs.symbiotic.fi/core-modules/networks#rewards

• Babylon: https://www.bedlamresear.ch/posts/babylon/, https://docs.babylonchain.io/docs/introduction/babylon-overview, https://babylonlabs.io/blog

• Karak: https://docs.karak.network/, https://blog.karak.network/, https://docs.karak.network/security/governance#operations

• Solayer: https://docs.solayer.org/getting-started/introduction, https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/solayer-litepaper-v0.pdf, https://docs.solayer.org/security/multisig-committee#multisigature-committees, https://docs.solayer.org/developers/for-builders/architecture#rewards-and-accounting

• Jito: https://www.jito.network/blog/announcing-jito-restaking/

Follow us on X!