Restaking Protocols Infra Risk Framework V2

This post builds upon our initial risk framework for assessing the infrastructure risks of restaking protocols. Developing such robust framework is essential for underwriting risk and understanding these complex protocols, given the numerous complexities and interdependencies that make a thorough risk evaluation quite challenging.

For this upgraded analysis, we have considered the restaking protocols: EigenLayer, Symbiotic, Babylon, SatLayer, Kernel, Solayer, Jito, and Karak.

The introductory framework published last year can be found at:

Restaking Protocols Infra Risk Framework

Introducing a foundational risk framework for assessing the infrastructure risks of restaking protocols.

https://paragraph.com

Restaking Protocols Infra Risk Framework

TL;DR of V2 Risk Framework

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
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
Types of Collateral Assets Accepted
Support for Endogenous and/or Exogenous Applications
Protocol Ecosystem Integration and Compatibility
- Protocol Alignment with Core Trust Root
- Compatibility with Foreign Consensus and Services Infra
- Reliance on External Service Providers
Protocol Design Complexity & Security Audits
Multisig Governance Consensus Risk
Restaker & Validator Escrow Periods (Unbonding/Withdrawal Delays)
Reward Incentives Alignment Risk Profile
Slashing Process Efficacy
- Fault Scope
- Execution Design
- Governance Adjudication
- Withdrawal Latency
- Resilience to Adversarial Scenarios
- Interoperability
- Slashed Stake Aftermath
- Modularity & Customization
- Auditability & Transparency

Restaking Protocols Overview

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 eight protocols:

EigenLayer

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

Symbiotic is a modular, permissionless shared security protocol on Ethereum that introduces a "Universal Staking" market. It allows networks—such as rollups, appchains, oracles, and other decentralized services—to design custom staking architectures by defining their own slashing logic, operator selection criteria, reward distribution, and collateral types. This flexibility enables each network to retain sovereignty over its security model while accessing pooled capital and trust from Ethereum-based collateral.

The protocol uses ERC-20 collateral tokens deposited into vaults, which delegate stake to operators that run infrastructure across networks. Resolvers act as decentralized arbitrators with the power to validate or veto slashing actions during a dispute window, enabling localized and network-specific slashing enforcement. By reducing coordination overhead and supporting deep composability, Symbiotic creates a programmable trust layer for decentralized ecosystems to evolve securely and atomically.

Babylon

Babylon is a Cosmos SDK-based chain that anchors Bitcoin’s Proof-of-Work (PoW) security to support Proof-of-Stake (PoS) systems. It enables BTC holders to economically commit native Bitcoin through timestamp-verified transactions, which Babylon interprets as restaking commitments. This architecture allows PoS chains to inherit Bitcoin’s security guarantees without requiring their own validator sets.

Networks that integrate with Babylon—Bitcoin Secured Networks (BSNs)—PoS chains or applications that externalize their security to Bitcoin via Babylon’s coordination layer. By combining Bitcoin’s censorship-resistant finality with Babylon’s programmable PoS environment, BSNs gain access to a hybrid trust model that enables secure scaling and innovation. Babylon thus provides a pathway for chains to harness Bitcoin’s economic credibility while benefiting from the efficiency and flexibility of PoS architecture.

SatLayer

SatLayer is a Bitcoin-native restaking protocol that allows BTC holders to secure decentralized applications—Bitcoin Validated Services (BVSs)—without altering Bitcoin’s consensus. Deployed as a smart contract suite on Babylon, a Cosmos SDK-based chain, SatLayer leverages non-interactive timestamp proofs to verify Bitcoin transactions and anchor restaking commitments, eliminating the need for bridges, wrapped assets, or custodians.

BTC restakers lock Bitcoin in base-layer transactions that Babylon can cryptographically verify and interpret as collateral commitments. All staking logic—rewards, penalties, and service validation—is enforced on Babylon, while the BTC itself remains on Bitcoin L1. This setup extends Bitcoin’s utility as a decentralized trust root for programmable services like oracles, sequencers, and data availability layers, while preserving its native security guarantees. SatLayer builds on this foundation to streamline and accelerate the onboarding of BVSs, expanding Bitcoin’s utility as a base-layer of decentralized trust.

Kernel

Kernel is a modular restaking framework that allows developers to deploy customizable staking environments—Dynamic Validation Networks (DVNs)—each with its own validator set, staking rules, slashing logic, and governance. Deployed on Binance Smart Chain, Kernel leverages the Binance Smart Chain validator set as a default operator pool, but DVNs define their own validator registries by selecting subsets or imposing custom admission criteria. There is no global validator coordination or shared enforcement layer.

Each DVN operates in isolation, using open-source kernel templates to define its economic logic, governance structure, and dispute mechanisms. This architecture supports domain-specific staking environments across multiple chains while minimizing systemic coupling and correlated slashing risks. Kernel prioritizes validator-level accountability and composable design over unified protocol governance.

Solayer

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

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.

Karak

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.

Restaking Protocols Introductory Infra Risk Framework

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.

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

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. EigenLayer, Symbiotic, Solayer, and Jito, however, benefit from a single trust root tied to their respective L1s. Kernel and Karak, while deployed on BNB Chain and Ethereum respectively, both enable DVN or DSS deployment across multiple networks. However, only Karak interlinks these deployments through shared vault infrastructure, introducing complex inter-chain dependencies and potential security fragmentation. In contrast, Kernel isolates each DVN, minimizing systemic coupling but sacrificing shared composability. SatLayer introduces a new trust root into the stack by building entirely on Babylon, which itself anchors trust in both the Bitcoin and Ethereum networks. 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.

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

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, LRT Slashing Risk: Protocol, Portfolios & Market Forces, and LRT Infra Risk Framework, joint paper with P2P on Network Slashing Risk, and an 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 posts LRT Slashing Risk: Protocol, Portfolios & Market Forces and 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.

3. Types of Collateral Assets Accepted

The type of collateral accepted by a protocol impacts its security and economic stability, in terms of volatility, liquidity, and depeg risks. Babylon and SatLayer only accept BTC and wBTC as collateral guaranteeing robust security tied to Bitcoin's network value and straightforward alignment with its PoW consensus. However, protocols like EigenLayer, Symbiotic, Kernel, 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. Although there's the trade-off of a well-designed collateral diversification strategy being an important condition to mitigate the risk of runaway slashing contagion.

Symbiotic goes further by supporting collateral abstraction, allowing any ERC-20 token to be used as collateral without being held directly in Symbiotic's core contracts. In these cases, slashing enforcement depends entirely on a correctly implemented and rigorously tested Burner contracts, which must reliably handle asset burning when faults occur.

4. Support for Endogenous and/or Exogenous Applications

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, Symbiotic, and most other protocols, support for exogenous services (AVSs and Networks) may introduce complexities, 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.

5. Protocol Ecosystem Integration and Compatibility

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 and SatLayer'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, SatLayer highly reliant on Babylon itself, or EigenLayer using EigenCert and EigenBus, could inherit vulnerabilities from these providers. Evaluating their security and reliability is essential.

6. Protocol Design Complexity & Security Audits

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 and Kernel being protocols 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.

7. Multisig Governance Consensus Risk

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.

Symbiotic and Kernel both delegate governance entirely to local instances—Vaults and DVNs respectively—without any protocol-wide upgrade multisig or emergency control. Symbiotic provides built-in resolver and veto mechanisms per vault, offering lightweight governance scaffolding, while Kernel leaves all governance and slashing logic fully up to each DVN with no standardized tooling. The result is a tradeoff between structured modularity (Symbiotic) and sovereign autonomy (Kernel), each exposing different risks and flexibility profiles.

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.

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

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.

9. Reward Incentives Alignment Risk Profile

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. More on EigenLayer rewards on ELIP-001. 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. Kernel delegates reward design decisions to individual DVNs, each free to define its own payout structure, funding source, and operator incentives. While this enables customization, the absence of protocol-level standards can lead to inconsistent compensation models, misaligned incentives, and uneven validator participation—potentially raising the overall reward alignment risk profile.

At an infrastructure level, the design of these reward systems is crucial for ensuring both economic sustainability, decentralization, and clear, predictable participation dynamics for operators. 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.

10. Slashing Process Efficacy

The credibility of restaking protocols depends on whether slashing mechanisms are not only defined, but enforceable in practice with precision and consistency. Effective enforcement requires clear fault definitions, deterministic execution, and robust governance. Without it, misbehavior can persist unpunished, weakening the security guarantees of the entire validator set—especially when shared across multiple services. To ensure credible enforcement, protocols must support mechanisms that are unambiguous, time-bounded, and resistant to manipulation.

Fault Scope defines how clearly a protocol distinguishes and handles objective vs. subjective faults.
- Best case: Both fault types are explicitly defined and verifiable, with objective faults tied to mathematically-verifiable proofs and subjective ones governed by clear, transparent criteria and accountable review mechanisms.
Execution Design specifies how and where slashing is executed—covering finality, determinism, and settlement-layer guarantees—including any challenge mechanisms, veto periods, and execution windows.
- Best case: Slashing is finalized on a credibly neutral, censorship-resistant base layer with atomic, irreversible execution paths. Ideally, the lifecycle is deterministic, time-bounded, and governed by immutable on-chain logic, ensuring procedural clarity and preventing execution conflicts or inconsistent outcomes.
Governance Adjudication identifies the decision-making authority behind slashing: protocol, multisig-gated, DAO-controlled, or modular (e.g., resolvers).
- Best case: Slashing is governed by a transparent, decentralized process and entity with accountable actors, fallback protections, and auditable logic paths.
Withdrawal Latency measures how quickly and reliably slashing can be executed after a fault is detected, especially in relation to the unbonding period during which stake remains locked and slashable.
- Best case: Slashability is preserved during a fixed unbonding window; execution happens within a short, predictable time frame even under partial system failure.
Resilience to Adversarial Scenarios assesses the protocol’s ability to maintain slashing integrity under voluntarily or involuntary errors and misbehaviours.
- Best case: System includes redundant review paths, isolation mechanisms, and economic/game-theoretic incentives that deter adversarial behavior.
Interoperability examines how easily slashing logic is applied locally or cross-chain, and whether slashing relies on finality from a specific settlement layer.
- Best case: Protocol supports modular slashing enforcement either locally or cross-chain via verifiable cross-domain proofs, without reliance on centralized relayers or fixed trust assumptions.
Slashed Stake Aftermath defines whether wrongly slashed or disputed stake can be recovered and whether protocols allow flexible redistribution logic.
- Best case: While enforcement is final, configurable paths (e.g., dispute windows, escrow buffers, reversible flags) allow valid slashing to settle while supporting appeals or error rectification.
Modularity & Customization assesses the protocol’s support for defining custom slashing logic—fault types, penalties, veto mechanics, and collateral handling—on a per-service or per-vault basis.
- Best case: Services can tailor slashing conditions via composable, audited modules, while inheriting secure defaults to reduce misconfiguration risk.
Auditability & Transparency evaluates whether slashing actions and logic are observable, queryable, and attributable to specific governance or protocol actors.
- Best case: All slashing triggers, vetoes, and executions are recorded onchain, indexed, and accessible through public logs and APIs.

We'll focus the analysis on the two protocols with slashing methodologies live on mainnet to date: EigenLayer and Symbiotic.

Metric \ Protocol	EigenLayer	Symbiotic
1. Fault Scope	Slashing conditions are defined by AVSs, supporting objective (deterministic) and subjective faults (challenge-based or consensus-based).	Slashing conditions are defined within Vaults by Networks, supporting objective (deterministic) and subjective faults (challenge-based or consensus-based).
2. Execution Design	Standardized lifecycle defined in ELIP-002: proposal (→ challenge) → finalization Only AVSs with delegated slashable stake can activate slashing procedures. While slashing can occur immediately upon AVS submission, AVSs may implement their own arbitration logic (e.g., fraud proofs or veto periods). EigenLayer protocol itself does not enforce delays or intervention. All slashing events finalize on Ethereum L1, ensuring canonical execution and immutable state transitions. The system guarantees determinism and settlement trust, with no protocol-level veto or override once submitted on-chain.	Execution lifecycle is modular and vault-specific: proposal (→ Resolver review) → finalization Networks submit slash requests per epoch (configurable, often 1–7 days), and Vaults process them via either instant execution (`Slasher`) or delayed review (`VetoSlasher`). Latency depends on the Vault’s veto window and Resolver responsiveness and review time. Slash proposals must finalize before the end of the current epoch or they expire. Symbiotic protocol itself does not enforce delays or intervention. Vault contracts enforce timing and validity, while optional Resolvers can veto invalid or malicious slash attempts. Slashing is typically executed on Ethereum, though alternative EVM-compatible chains (L1/L2) may be supported depending on the vault’s deployment.
3. Governance Adjudication	Slashing rules are defined, governed and triggered by AVSs. Subjective faults are mediated by a (still unclear) on-chain or off-chain group of external attesters or observers. No protocol-wide veto committee as slashing is localized to individual AVSs via Unique Stake. AVSs are encouraged to build-in veto mechanisms.	Slashing rules are defined by Networks but governed and triggered by Vaults, which constitute smart contracts and/or third-party entities. No protocol-wide veto committee, although possible to setup veto-capable quorums of Resolvers. Resolvers act as dispute arbitrators at the protocol level and can veto slashes during the review window.
4. Withdrawal Latency	Withdrawals follow a fixed unbonding delay of 14 days, during which the stake remains locked and slashable. Validators initiate the process, and after the delay, funds become withdrawable.	Withdrawals are epoch-based (customizable) and defined per Vault. When a validator requests a withdrawal, it becomes effective at the end of the ongoing epoch. Until then, the stake remains slashable.
5. Resilience to Adversarial Scenarios	Ethereum L1 settlement ensures strong rollback resistance and finality. Ethereum’s security assumptions fundamentally underpin the integrity of the system. AVS-defined intersubjective slashing introduces risks of off-chain collusion or inactivity but applies only per AVS. The Unique Stake model isolates slashing, preventing cross-AVS contagion and containing and disincentivizing faults economically. Collateral diversification is supported via any ERC-20 token.	Resilience depends on Vault design and fallback mechanisms. Shared Vaults may expose stake to cross-Network risk. Resolvers, as entities, can collude, be bribed, or fail. Governance controls, smart-contract only Resolvers, and Vault Curators potentially mitigate misbehaviours, if well configured. Collateral diversification is supported via any ERC-20 token, including assets held outside Symbiotic’s core contracts through collateral abstraction. In such cases, properly configured and battle-tested custom `Burner` contracts are essential to ensure effective slashing.
6. Interoperability	Execution native to Ethereum. All slashing actions finalize on Ethereum L1, leveraging its security and economic finality, but limits native cross-chain interoperability.	Vaults can be deployed on any EVM-compatible chain. Slashing is enforced per Vault on the chain it resides, enabling localized enforcement and flexible multi-chain deployments. This enhances composability but decentralizes finality and may fragment security guarantees across chains.
7. Slashed Stake Aftermath	No recovery mechanism exists for wrongful slashing. Once executed, slashed funds are irreversibly burned (post-Pectra). AVSs are responsible for maintaining slashing integrity and can implement dispute resolution or veto mechanisms, but post-slash rollback is not possible. Slashed stake redistribution is not supported.	No recovery mechanism exists for wrongful slashing. Once executed, slashed funds are irreversibly burned. Vaults can implement dispute resolution or veto mechanisms via Resolvers, but post-slash rollback is not possible. Slashed stake redistribution is not native, but could be added through custom vault logic using modular hooks.
8. Modularity & Customization	AVSs define slashing terms and organize roles through Operator Sets, while operators allocate slashable stake via Unique Stake per AVS. Slashing logic is not modular at the protocol level—each AVS builds custom logic off-chain. Unique Stake and Operator Sets introduce configurability: an AVS can define multiple task-specific sets, each with isolated slashing pools, enabling tailored security per task type.	Slashing modules are fully modular, composable, and defined per Network. Networks are also capable of configuring their own valsets for validation. Vaults configure the `Slasher` type (instant or veto), collateral backing, govern slashing logic, set Resolver roles, and plug in optional modules like burners, governance hooks, or veto mechanisms.
9. Auditability & Transparency	All slashing phases—proposal, validation, and execution—are recorded on-chain and verifiable via AVS-integrated contracts. AVS configurations, governance roles, and deterministic slashing logic are transparent and auditable. Fault conditions can reside on-chain or off-chain depending on AVS design and fault type: deterministic faults enforce on-chain verification, while intersubjective faults require off-chain observer consensus before slashing and `EIGEN` token forking are authorized on-chain.	All slashing phases—proposal, validation, and execution—are on-chain and verifiable via Network and Vault contracts. Network's deterministic slashing logic and Vault configurations and governance roles are transparent and auditable. Fault conditions can reside on-chain or off-chain based on Resolver design and fault type: deterministic faults can be verified by Vaults and smart contract-based Resolvers, while subjective faults may rely on off-chain evaluation by third-party Resolvers who then authorize on-chain slashing.

Sources: EigenLayer (EigenLayer Docs – Slashing, EigenLayer Blog – Slashing, ELIP-002); Symbiotic (Symbiotic Blog – Demystifying Slashing, Symbiotic Docs)

Conclusion

Restaking protocols are revolutionizing blockchain security by enabling validators to extend their influence and capabilities beyond their native chains. However, each protocol carries unique infrastructure risks that must be considered. By applying such a comprehensive risk framework that examines trust roots, services, liquid restaking, collateral types, design complexity, operator networks, multisig governance, rewards, ecosystem integration, and slashing mechanics 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 keep researching in great detail all the risk metrics outlined, applying them specifically to each protocol, and announcing further partnerships to this effect.

References

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

Disclaimer: This content is presented to the reader on an “as is” basis for general information and educational purposes only, without representation or warranty of any kind. It should not be construed as financial, legal or other professional advice, nor is it intended to recommend the purchase or investment of any specific product or service.

Follow us on X!