For simplicity, "Network/AVS"—pertaining to the protocols deployed on and borrowing restaked security from restaking protocols (Networks on Symbiotic, Actively Validated Services on EigenLayer, Bitcoin Secured Networks on Babylon, etc.)—will be shortened herein to "N/AVS".

Index

1. Abstract

2. Restaking Network Slashing Risk Evaluation: Article Recap with P2P

3. Primer on Liquid Restaking Tokens

4. LRT Risk Framework

   1. Protocol Risks

      • Security Audits, Oracle Security, Withdrawal & Redemption Policies, Rewards Structure, Trust Root Dependency Health, Governance Health

   2. Operator Portfolio Risks

      • Number of Operators in Portfolio, Delegation-Weighted Operator Composite Risk, Aggregate Portfolio Risk As A Function Of Individual Operator Risk, Operator Infrastructure/Key Security, Operator Stake Concentration Index

   3. Network/AVS Portfolio Risks

      • Number of N/AVSs in Portfolio, Delegation-Weighted N/AVS Composite Risk, Aggregate Portfolio Risk As A Function Of Individual N/AVS Risk, N/AVS Slashing Overlap Risk

   4. Market Risks

      • Liquidity (DEX Liquidity, Liquidity Reserves, LP Concentration), Leverage (At-Risk Collateral / TVL Ratio, LTV / LT Threshold), Restaked Collateral Quality, Whale Concentration

   Additional Considerations on (Compounded) Slashing

5. Restaking Protocols Approaches toward Slashing

6. Conclusion

1. Abstract

Building upon our prior research with P2P on network-level slashing risk, with Ebisu Finance on LRT infra risk, and multiple N/AVS risk analysis, Tokensight now extends its framework to cover Liquid Restaking Tokens (LRTs) from the perspectives of the Protocol, the Operator and N/AVS portfolios, and DeFi market dynamics. As slashing enters the fold and the complexity of interdependencies of restaking architectures intensifies, a multifaceted risk evaluation methodology is increasingly critical.

This paper introduces a comprehensive scoring model that integrates qualitative protocol-level assessments with quantitative DeFi exposure metrics—capturing protocol fragility, operator behavior, slashing overlap, collateral quality, market-driven volatility, and more.

With restaking adoption accelerating, this work aims to support stakeholders—restakers, operators, N/AVS builders, risk managers, and LRTs themselves—in performing (hopefully) state-of-the-art due diligence and informed allocation decisions in this emerging yet still poorly understood restaking sector. While no present or future framework can fully capture the game-theoretic complexity inherent, this model provides a strong foundation to build upon and navigate the topic.

2. Restaking Networks Slashing Risk Evaluation: Article Recap with P2P

In collaboration with P2P—leading validator and staking infrastructure provider—, we outlined a foundational framework for evaluating N/AVS slashing risk, from the restaker perspective.

The article introduced a first-principles methodology to assess such risk, addressing limitations within purely market-focused, data-driven, and highly-assumptive models. It emphasized, among other metrics, architecture, slashing condition design, and protocol maturity, offering a more fundamental protocol approach on “black-swan” slashing scenarios. We covered that slashing could be triggered when an operator fails to meet an N/AVS’s service-level requirements, typically under faulty execution through the incorrect computation or output validation (e.g. misattestation or wrong data) and liveness failures through errors related to remaining online, or meeting uptime requirements. Regardless of operator intent, if the N/AVS’s functionality or security is undermined, slashing can be activated.

Seven weighted metrics formed the framework's backbone: Execution Architecture, Consensus Design, Slashing Conditions, Security Audits, Code Complexity, Maturity, and Reputation. For each N/AVS a risk score $R \in [0,10]$ is computed and categorized into risk tiers:

• Blue Chip N/AVSs $(R \in [0,5])$: Mature, well-audited, resilient systems with robust and clearly defined slashing parameters;

• Moderately Risky N/AVSs $(R \in [5,8])$: Architecturally sound but potentially untested or exposed to non-obvious edge cases;

• Extremely Risky N/AVSs $(R \in [8,10])$: Fragile or immature implementations with poorly scoped slashing conditions or incomplete designs.

The scoring methodology was designed to serve as a proxy for expected stake loss, enabling risk modeling, yield-adjusted strategy design, and restaking exposure management. Furthermore, it enables cross-category comparison by normalizing risk across heterogeneous N/AVS categories—whether DA, Oracles, ZK, or Interoperability protocols. The model incorporates both observable infrastructure and more subjective design properties, offering a composite, heuristically derived slashing risk score.

For the full deep-dive, refer to our research paper in collaboration with P2P:

Protocol risk evaluation: developing a fundamental approach - HackMD

Thanks to dapplion, Maxim Merkulov, Mikhail Kalinin, and P2P.org's Ethereum team for reviewing and providing valuable feedback.

https://hackmd.io

3. Primer on Liquid Restaking Tokens

Liquid restaking tokens (LRTs) are tokenized representations of restaked assets, enabling holders to earn L1 staking yields alongside N/AVS-level rewards and LRT points, all while retaining liquidity in their position. LRTs extend L1 consensus and cryptoeconomic trust to secure multiple protocols simultaneously, thereby abstracting validator operations, preserving DeFi composability, and optimizing capital allocation across restaking.

Unlike normal staking, slashing risk in LRTs is shaped by a complex interplay of protocol architecture, operator delegation, N/AVS topology exposure, and rehypothicated DeFi market dynamics.

Notable protocols include Ether.fi (eETH), Renzo (ezETH), Puffer (pufETH), Swell (rswETH), and Kelp (rsETH), interfacing with EigenLayer, Symbiotic, Babylon, Solayer, Kernel, and SatLayer, all building distinct frameworks with security and economic guarantees in mind.

4. LRT Risk Framework

Our LRT Risk Framework delivers a structured and comprehensive evaluation of key risk vectors—spanning protocol architecture, Operator and N/AVS risk exposures, and market lending and concentration dynamics. Departing from existing siloed approaches, the framework integrates these dimensions into a unified scoring system, enabling consistent comparability across LRTs.

The framework applies the below contextual piecewise transformation function at each risk category to map inputs into discrete risk intervals. Calibrated weights are then assigned to each category to produce a final composite LRT risk score. This structure captures both slashing activation triggers and compounding, correlated factors, offering a robust tool for protocol evaluation and risk-adjusted capital deployment.

Piecewise function:

$R_N = \{ R_{\text{Security Audits}}, R_{\text{Oracle Security}},... , R_{\text{Whale Concentration}}, R_{\text{LRT }\mathcal{L}} \}$

$R'_N =\begin{cases} x, & R_N > a, \quad \text{(High risk)} \\ y, & b \leq R_N \leq a, \quad \text{(Medium risk)} \\ z, & R_N < b, \quad \text{(Low risk)}\end{cases}$

$R'_N = \{ R'_{\text{Security Audits}}, R'_{\text{Oracle Security}}, ..., R'_{\text{Whale Concentration}}, R'_{\text{LRT }\mathcal{L}} \}$ or $R'_{\text{N}} = f_{\text{pw}}(R_{\text{N}})$

where:

• $R_N$ represents the risk set of all metrics ("Security Audits", "Oracle Security", etc.) across the four categories;

• $R'_N$ represents the updated risk set of the same metrics post-calibration, based on predefined contextual criteria;

• $a$, $b$ represent contextual threshold values that define risk classification per metric;

• $x, y, z \in [1,10]$ are numerical values, spanning 1 to 10, that represent categorical risk levels;

• $f_{\text{pw}}$ designates the transformative piecewise function.

Protocol Risks

Protocol-specific risks refer to vulnerabilities present within the foundational structure and implementation of the LRT protocol itself. These risks are largely upstream and impact all downstream security dynamics—from validator requirements to market integration.

They ought to include audit coverage, oracle robustness, withdrawal and redemption structuring, reward design, dependency on external trust roots, and governance mechanics. Failure in any of these components can increase the likelihood or severity of a slashing event and undermine protocol stability.

• Security Audits

  Signals vulnerabilities in the codebase or protocol design pre-deployment. A lack of sufficient audits—whether in quantity or quality—significantly increases the chance of validation errors and bugs, making operators more prone to slashing. In addition, an LRT offering no insurance protection, directly or through a third-party, against smart contract risks to users is a poor measure that could cause negative externalities.

  $R'_{\text{Security Audits}} = f_{\text{pw}}(R_{\text{Security Audits}})$

  ---

• Oracle Security

  A poorly-designed, centralized oracle can cause delayed price updates, incorrect penalty emissions, and data manipulation, leading to wrongful slashing or broader security failures. Integrating a robust oracle that ensures decentralization, security, and timely updates is critical to the integrity of the LRT protocol.

  $R'_{\text{Oracle Security}} = f_{\text{pw}}(R_{\text{Oracle Security}})$

  ---

• Withdrawal & Redemption Policies

  The absence of a withdrawal queue—or one lacking sufficient redemption liquidity—poses severe risks during periods of market stress. Without timely access to capital, restakers may resort to panic selling, destabilizing price parity and triggering liquidation cascades. Inadequate reserves force dependence on secondary markets, which can become strained, trapping capital and delaying recovery. Poorly designed or absent withdrawal mechanisms increase a protocol’s vulnerability to spiraling liquidity drain, systemic contagion, and prolonged instability.

  $R'_{\text{Withdrawal+Redemption Policies}} = f_{\text{pw}}(R_{\text{Withdrawal+Redemption Policies}})$

  ---

• Rewards Structure

  A comprehensive rewards structure must avoid over-incentivizing risky behavior, ensure timely and predictable payouts, incentivize market-making, and effectively attract liquidity providers. It should effectively balance risk and reward, promoting sustainable participation without encouraging excessive leverage or destabilizing strategies.

  $R'_{\text{Rewards Structure}} = f_{\text{pw}}(R_{\text{Rewards Structure}})$

  ---

• Trust Root Dependency Health

  Attests to the resilience and reliability of the fundamental infrastructure an LRT relies on—including the restaking protocol layer (e.g., EigenLayer), L1 chain (e.g., Ethereum, Solana), and potential execution layers or environments (e.g., L2s, appchains). It captures the relative decentralization, maturity, and security of each trust root; as weaknesses in any can compromise the protocol’s safety and performance.

  $R'_{\text{Trust Root Dependency Health}} = f_{\text{pw}}(R_{\text{Trust Root Dependency Health}})$

  ---

• Governance Health

  Evaluates the resilience and security of the LRT protocol’s governance model, assessing whether decision-making processes can be manipulated, compromised, or otherwise subverted, potentially undermining protocol stability and user trust—such submetrics can include distribution of voting power (e.g., token-weighted vs. multisig), upgradeability risks (e.g., emergency powers or centralized control), and responsiveness to critical events (e.g., slashing disputes or parameter updates).

  $R'_{\text{Governance Health}} = f_{\text{pw}}(R_{\text{Governance Health}})$

Protocol Risks Formula for LRT $\mathcal{L}$:

$R_{\text{Protocol},\mathcal{L}} = R'_{\text{Security Audits},\mathcal{L}} + R'_{\text{Oracle Security},\mathcal{L}} + R'_{\text{Withdrawal+Redemption Policies},\mathcal{L}} + R'_{\text{Rewards Structure},\mathcal{L}} + R'_{\text{Trust Root Dependency Health},\mathcal{L}} + R'_{\text{Governance Health},\mathcal{L}}$

Operator Portfolio Risks

These concern risks emerging from the Operator portfolio LRT protocols delegate capital to. As the validation agents of N/AVS requirements, Operators play a central role in determining slashing exposure. A misbehaving, unreliable, or overly centralized Operator can significantly increase downside risks for LRT holders, protocol, and DeFi health profile.

Security evaluations at this layer ought to include historical slashing frequency, historical penalty magnitude, delegation concentration, secure-key features, and aggregate portfolio risk. Operators with poor historical performance or excessive stake concentration should be reflected in an LRT's risk parameterization.

Operator Risk Profile $(R_o)$

• Historical Number of Times Slashed — risk thresholds should increase any time the number of times slashed is greater than 0;

• Total Penalties Accrued for Misbehaviour — risk thresholds should increase any time penalties surpass the 0 ETH mark;

• Nodes Geographical Distribution — risk thresholds should increase when node distribution is regionally concentrated.

• Number of Operators in Portfolio $(no)$

  A broad set of Operators enhances diversification and helps absorb slashing shocks. Still, risk hinges on which Operators are selected and how stake is distributed. Too few concentrates exposure; too many—without careful vetting—can introduce correlated slashing risk. Operator allocation must be risk-aware and carefully deliberated.

  $R'_{\text{no}} = f_{\text{pw}}(R_{\text{no}})$

  ---

• Delegation-Weighted Operator Composite Risk $(woc)$

  the Operator risk score $(R_o)$, we consider weights here to represent the relative delegation by LRT $\mathcal{L}$ to an Operator $o$, e.g. if LRT $\mathcal{L}$ has deployed a total of $100M within Operator portfolio $(O)$ and Operator $o$ has $10M delegated from that LRT, the weighted-average delegation risk $(w_{\text{woc},o})$ equals 10%.

  $R_{\text{woc}} = \sum_{o \in O} w_{\text{woc},o} . R_o$

  $R'_{\text{woc}} = f_{\text{pw}}(R_{\text{woc}})$

  ---

• Aggregate Portfolio Risk As A Function Of Individual Operator Risk $(aprio)$

  Again borrowing $R_o$, the composite portfolio risk $(woc)$ should amplify risk-wise if a significant portion (e.g., >50%) of Operators register a high risk score (e.g. $8 < R_o ≤ 10$, where $R_o \in [1,10]$). The piecewise function $f_{\text{pw}}$​ modulates this behavior—boosting scores when risk is concentrated, or suppressing when distributed.

  $R'_{\text{o}} = f_{\text{pw}}(R_{\text{o}})$

  $R_{\text{aprio}} = R'_{\text{woc}} \times R'_{\text{o}}$

  $R'_{\text{aprio}} = f_{\text{pw}}(R_{\text{aprio}})$

  ---

• Operator Infrastructure/Key Security $(oiks)$

  Assesses how securely validator keys are stored and managed. Risk increases when keys are self-managed or lack protections like Trusted Execution Environments (TEEs). Ether.fi uses app-based encryption with user responsibility, while Puffer employs SGX-based Secure-Signer for stronger slashing protection.

  $R'_{\text{oiks}} = f_{\text{pw}}(R_{\text{oiks}})$

  ---

• Operator Stake Concentration Index $(osci)$

  Measures the concentration of restaked TVL among top operators within a restaking protocol. Elevated risk emerges if a single operator holds over 33%, or if the top five collectively control more than 50%, as such scenarios undermines decentralization and increase vulnerability to correlated slashing events, single points of failure, or governance capture.

  $R_{\text{osci}} = \frac{\sum_{i=1}^{5} \Omega_i}{\Omega_{\text{total}}}$
  where:

  • $Ωi$​ = Stake held by the $i$-th largest holder;

  • $\Omega_{\text{total}}$​ = Total circulating supply of the LRT;

  • $R_{\text{osci}}$ ranges from 0 to 1, where higher values indicate stronger whale dominance.

  $R'_{\text{osci}} = f_{\text{pw}}(R_{\text{osci}})$

While a deeper Operator analysis—covering more extensive risk profile metrics, N/AVS portfolio composition, curator dynamics, and collateral quality—would add valuable insight, we defer this for a future piece to maintain focus on LRT risk.

Operator Portfolio Risk Formula for LRT $\mathcal{L}$:

$R_{\text{Operator},\mathcal{L}} = R'_{\text{no},\mathcal{L}} + R'_{\text{woc},\mathcal{L}} + R'_{\text{aprio},\mathcal{L}} + R'_{\text{oiks},\mathcal{L}} + R'_{\text{osci},\mathcal{L}}$

Network/AVS Portfolio Risks

The set of N/AVSs an LRT opts into constitutes another risk vector, where N/AVS portfolios ought to be assessed holistically—as interconnected bundles—rather than in isolation, as standalone evaluations may overlook correlated failure modes. Shared architectural traits, execution or consensus designs, and overlapping security assumptions can amplify systemic risk. The more homogenous, concentrated, or indiscriminately composed the N/AVS portfolio, the more vulnerable the LRT becomes to both isolated and cascading slashing events.

• Number of N/AVSs in Portfolio ($nap$)

  A broader set of N/AVSs improves diversification and helps absorb slashing shocks; however, risk ultimately depends on which N/AVSs are selected and how stake is allocated. Too few N/AVSs concentrate risk, while too many—poorly chosen—can still expose the LRT to correlated slashing. Diversification must be deliberate and risk-weighted.

  $R'_{\text{nap}} = f_{\text{pw}}(R_{\text{nap}})$

  ---

• Delegation-Weighted N/AVS Composite Risk $(wac)$

  Borrowing the N/AVS risk score $(R)$ logic built with P2P, we consider weights here to represent the relative delegation by an LRT $\mathcal{L}$ to an N/AVS $a$, e.g if LRT $\mathcal{L}$ has deployed a total of $100M within N/AVS portfolio $(A)$ and N/AVS $a$ has $10M delegated from that LRT, the weighted-delegation risk $(w_{\text{wac},a})$ equals 10%. N/AVS $a$'s risk is defined as $R_a$.

  $R_{\text{wac}} = \sum_{a \in A} w_{\text{wac},a} . R_a$

  $R'_{\text{wac}} = f_{\text{pw}}(R_{\text{wac}})$

  ---

• Aggregate Portfolio Risk As A Function Of Individual N/AVS Risk ($apria$)

  Borrowing the above $R_a$ value representing N/AVS $a$ risk score, the composite portfolio risk should amplify in case a significant portion (e.g. >50%) of N/AVSs register a high risk score (e.g. $8 < R_a ≤ 10$, where $R_a \in [1,10]$). The piecewise function $f_{\text{pw}}$​ adjusts for such thresholding—amplifying when risk is concentrated, or suppressing when risk is more evenly distributed.

  $R'_{\text{a}} = f_{\text{pw}}(R_{\text{a}})$

  $R_{\text{apria}} = R'_{\text{wac}} \times R'_{\text{a}}$

  $R'_{\text{apria}} = f_{\text{pw}}(R_{\text{apria}})$

  ---

• N/AVS Slashing Overlap Risk ($aso$)

  Quantifies a portfolio’s systemic exposure to shared faulty slashing conditions across its constituent N/AVSs. When N/AVSs belong to the same category (e.g., oracles, bridges, coprocessors), they often rely on quite similar infrastructure, architectures, tooling, and runtime environments.

  Overlapping faulty slashing rules, of a similar nature, would reduce the marginal cost for attackers attempting at executing a single exploit, reducing the operational overhead required to compromise a group of N/AVS. In contrast, attacking a diverse set of N/AVSs with dissimilar slashing rules and architectures would demand more resources and more-demanding technical capabilities, raising the cost and complexity of attack execution. As such, portfolios with overlapping and alike slashing misconfigurations present a broader, cheaper, and more profitable attack surface—warranting higher systemic risk penalties.

  $R_{\text{aso}} = \frac{1}{|A|} \sum_{\substack{a,b \in A \\ a \ne b}} \mathbf{1}\left(S_a^{\text{faulty}} \cap S_b^{\text{faulty}} \ne \emptyset\right) \cdot \mathcal{C}(a, b)$
  where:

  • $A$ → The set of N/AVSs in the LRT portfolio $A$;

  • $a,b \in A$ → Individual N/AVSs $a$ and $b$ in the N/AVS portfolio $A$; the sum evaluates all unique N/AVS pairs with $a \ne b$;

  • $S_a^{\text{faulty}}$​ → The set of faulty slashing conditions associated with N/AVS $a$;

  • $S_b^{\text{faulty}}$​ → The set of faulty slashing conditions associated with N/AVS $b$;

  • $\mathbf{1}\left(S_a^{\text{faulty}} \cap S_b^{\text{faulty}} \ne \emptyset\right)$​ → Indicator function that returns 1 if N/AVS $a$ and $b$ share any faulty slashing conditions, or 0 if otherwise;

  • $\mathcal{C}(a, b)$ → A N/AVS category similarity coefficient ranging from 0 to 1, representing how similar N/AVS $a$ and $b$ are in infrastructure and architectures (e.g., both being oracles, bridges, or coprocessors);

  • $\frac{1}{|A|}$ → Normalizes the sum by the number of N/AVSs to yield an average overlap risk per N/AVS.

  $R'_{\text{aso}} = f_{\text{pw}}(R_{\text{aso}})$
  

For a deeper read into N/AVS fundamental risks, we recommend checking our own research on the topic with P2P.

N/AVS Portfolio Risks Formula for LRT $\mathcal{L}$:

$R_{\text{AVS Portfolio},\mathcal{L}} = R'_{\text{nap},\mathcal{L}} + R'_{\text{wac},\mathcal{L}} + R'_{\text{apria},\mathcal{L}} + R'_{\text{aso},\mathcal{L}}$

Market Risks

The slashing of an Operator by an N/AVS for misbehaviour produces reverberating effects across the whole ecosystem stack, including market-wise. LRT(s) delegating capital to this Operator suffer partial slashing, diminishing their underlying stake value. As very in-demand collateral assets in DeFi markets (due to current attractive yields and recursive leveraging), LRTs with high-LTV positions can easily breach liquidation thresholds, initiating forced liquidations in DeFi lending markets. Moreover, slashing an Operator can adversely affect other N/AVSs that the same Operator has opted into, spreading risk across multiple and intertwined N/AVS and LRT protocols. The quality profile (liquidity, volatility, correlation between trust root dependencies, etc.) of an LRT's restaked collateral further modulates how severe or resilient the market response becomes.

Liquidated LRT collateral and initial sell pressure rapidly deplete (or worsen) on-chain liquidity, amplifying market stress. As discussed, inefficient withdrawal-queueing systems, lack of liquidity reserves, and strained liquidity pools accelerate secondary-market selling and liquidations, triggering cascading failures across interconnected LRT positions. Mimetic social contagion drives broader capital outflows, stake-collateral value compression, and subsequent liquidation rounds, destabilizing even unrelated LRTs.

Recovery times scale nonlinearly with larger slashes as liquidity constraints intensify. High whale and LP concentrations, limited market-making opportunities (relating to weak LRT reward structures), and validator exits exacerbate risks and compound delays. The slashing cascade may ultimately erode TVL and economic security for both restaking protocols and N/AVSs, undermining their stability and overall performance.

• Liquidity

  • DEX Liquidity measures the total value of assets available for trading on decentralized exchanges, indicating the market’s capacity to absorb large trades without significant price impact.

  • Liquidity Reserves represent the pool of assets held to facilitate withdrawals, trades, or lending, providing a buffer against sudden liquidity demands or protocol stress.

  • LP Concentration measures the distribution of liquidity provided by different liquidity providers, with higher concentration posing centralization risks and potential liquidity imbalances during volatile conditions.

  $R'_{\text{DEX Liq.}}, R'_{\text{Liquidity Res.}}, R'_{\text{LP Conc.}} = f_{\text{pw}}(R_{\text{DEX Liq.}}, R_{\text{Liquidity Res.}}, R_{\text{LP Conc.}})$

  $R_{\text{Liquidity}} = \ w_{\text{Liquidity}} . R'_{\text{DEX Liquidity}} + w_{\text{Liquidity}} . R'_{\text{Liquidity Reserves}} + w_{\text{Liquidity}} . R'_{\text{LP Concentration}}$

  $R'_{\text{Liquidity}} = f_{\text{pw}}(R_{\text{Liquidity}})$

  ---

• Leverage

  • ARC (At-Risk Collateral) / TVL Ratio measures the share of locked collateral prone to liquidation, indicating the protocol’s exposure to liquidation risk relative to its secured value.

  • LTV (Loan-to-Value) / LT (Liquidation Threshold) Threshold defines the point at which leveraged positions become undercollateralized, triggering liquidations that can intensify liquidity crises in DeFi markets.

  $R'_{\text{ARC} / \text{TVL Ratio}}, R'_{\text{LTV} / \text{LT Threshold}} = f_{\text{pw}} \left( R_{\text{ARC} / \text{TVL Ratio}}, R_{\text{LTV} / \text{LT Threshold}} \right)$

  $R_{\text{Leverage}} = w_{\text{Leverage}} . R'_{\text{ARC} / \text{TVL Ratio}} + w_{\text{Leverage}} . R'_{\text{LTV} / \text{LT Threshold}}$

  $R'_{\text{Leverage}} = f_{\text{pw}}(R_{\text{Leverage}})$

  ---

• Restaked Collateral Quality

  Collateral quality shapes an LRT’s resilience to volatility, liquidity suppression, and slashing shocks. Strong assets like ETH or stETH offer stability and reliable redemptions, but over-concentration in any single one can amplify correlated risk—highlighting the need for diversified, healthy collateral options.

  $R_{\text{Restaked Collateral Quality}} = \sum_{i=1}^{n} w_i \cdot q_i$

  where:

  • $w_i = \frac{\text{Value of Collateral } i}{\text{Total Restaked Collateral}}$ $-$ weight of each asset $i$ in the LRT;

  • $q_i \in [0, 1]$ — normalized quality score for each collateral type
    (e.g., ETH = 1, stETH = 0.90, volatile LST = 0.40, illiquid token = 0.20)

  $R'_{\text{Restaked Collateral Quality}} = f_{\text{pw}}(R_{\text{Restaked Collateral Quality}})$

  ---

• Whale Concentration

  Assesses the holder distribution of an LRT based on the amount of tokens held. For a more comprehensive view we could have used the Herfindahl-Hirschman Index, but for a more practical approach we've chosen the below formula instead, that focuses on the top 5 restakers.

  $R_{\text{Whale Concentration}} = \frac{\sum_{i=1}^{5} \Omega_i}{\Omega_{\text{total}}}$

  where:

  • $Ωi$​ = Stake held by the $i$-th largest holder;

  • $\Omega_{\text{total}}$​ = Total circulating supply of the LRT;

  • $R_{\text{Whale Concentration}} \in [0, 1]$, where higher values indicate stronger whale dominance.

  $R'_{\text{Whale Concentration}} = f_{\text{pw}}(R_{\text{Whale Concentration}})$

Market Risks Formula for LRT $\mathcal{L}$:

$R_{\text{Market},\mathcal{L}} = R'_{\text{Liquidity},\mathcal{L}} + R'_{\text{Leverage},\mathcal{L}} + R'_{\text{Restaked Collateral Quality},\mathcal{L}} + R'_{\text{Whale Concentration},\mathcal{L}}$

Final LRT $\mathcal{L}$ Risk Formula

$R_{\text{LRT}~\mathcal{L}} = w_{\text{Protocol}} .R_{\text{Protocol},\mathcal{L}} + w_{\text{Operator Portfolio}}. R_{\text{Operator Portfolio},\mathcal{L}} + w_{\text{N/AVS Portfolio}}. R_{\text{N/AVS Portfolio},\mathcal{L}} + w_{\text{Market}}. R_{\text{Market},\mathcal{L}}$

where:

• ${{w_{Protocol}, w_{Operator Portfolio}, w_{N/AVS Portfolio}, w_{Market}}}$ represent the assigned weighted-average values to be applied to each risk category for LRT ${\mathcal{L}}$: Protocol, Operator Portfolio, N/AVS Portfolio, and Market, per impact and likelihood toward slashing triggering or amplification.

Additional Considerations on (Compounded) Slashing

In modeling slashing risk across N/AVSs, it’s important to distinguish between isolated validator faults and correlated (and, as a result, compounded) fault scenarios. While the slashing mechanics of L1 chains (like Ethereum, Cosmos, and Polkadot) do not govern N/AVS-level slashing, they serve as useful benchmarks for estimating plausible penalty ranges. For individual validator misbehavior—such as downtime, missed attestations, or configuration errors—penalties typically fall within the 1–5% range. These are isolated events that pose minimal risk to network-wide consensus. For instance, Cosmos slashes 5% for equivocation, while Ethereum may penalize less than 1 ETH for a single double vote.

In contrast, correlated slashing events—arising from malicious collusion, exploits, client bugs, or shared infrastructure dependencies (e.g., common key management or cloud infra)—can escalate penalties toward 100% of a validator’s stake, theoretically. Ethereum’s correlation penalty grows quadratically with the number of validators slashed in the same window. Polkadot applies a graduated curve, increasing slashing severity with the size of the slashed cohort. Networks like Ethereum, Sui, Lava, Polkadot, and Kusama explicitly or via governance allow for slashing up to 100% in extreme cases. Such tail-risk scenarios should be modeled assuming total loss, especially when assessing newer or unproven N/AVSs that may expose validators to systemic vulnerabilities.

One should be wary of any hysteresis or anchoring bias toward the rarity of slashing events, and prepare accordingly by remaining cautious of possible scenarios.

Conditions That Trigger Compounded Slashing

A slash initiated by an N/AVS can extend well beyond the intended penalty, depending on the risk characteristics of the delegated LRTs and the Operator's aggregate exposure—amplifying loss through systemic correlations and recursive stake dependencies.

$R'_{\text{LRT } \mathcal{L}} = f_{\text{pw}}(R_{\text{LRT }\mathcal{L}} \times e^{\mathcal{S}. \lim\limits_{t \to t+n} \Lambda_{t,\mathcal{L}}})$

where:

• $R'_{\text{LRT } \mathcal{L}}$​ represents LRT $\mathcal{L}$'s compounded risk score;

• $e^{\mathcal{S}. \lim\limits_{t \to t+n} \Lambda_{t,\mathcal{L}}}$ is the exponential scaling factor which defines the amplified risk of an LRT based on the normalized baseline risk $R_{\text{LRT Risk}}$, ensuring smooth compounding growth. The sensitivity coefficient $\mathcal{S}$ determines the potential aggressiveness of the compounding, whereas $\Lambda$ represents the temporal scaling factor that controls for how long $\mathcal{S}$ extends over time.

  • $\mathcal{S} \in [0.1, 0.5]$, represents the Sensitivity coefficient, which tweaks how severely cascading effects can escalate beyond the initial shock. Lower bound values illustrate a battle-tested and resilient track record with low LRT covariance and an overall mature ecosystem; upper bound values suggest the opposite: perceived systemic stress due to high covariance, immaturity, volatility, and unaccounted risk vectors;

  • $\Lambda \in [0.5, 2]$, reflects the temporal extent a compounding event may last for, measured as time $t$ progresses $( \lim\limits_{t \to t+n} )$. Lower bound values represent systemic risk propagation only over a short period of time, whereas upper bound values illustrate the compounded risk extending over a long period of time, e.g. via weak multi-party coordination in the resolution phase, excessive leverage, liquidity constraints, governance failures, or entrenched cross-protocol dependencies.

Conditional Propagation Across LRTs

A slashing event likely will affect more than one LRT due to shared operators and interconnected N/AVS exposures, potentially triggering broader systemic consequences.

The below expression attempts to formalize a probabilistic link between slashing events and their expected propagation across correlated LRTs. We try and do so using a conditional expectation framework:

$\mathbb{E} \left[ R'_{\text{LRT } \mathcal{L2}} \mid \mathbb{S}_{\text{LRT } \mathcal{L1}} \right], \quad \mathbb{S}_{\text{LRT } \mathcal{L1}} \sim R'_{\text{LRT } \mathcal{L1}}$

where:

• $\mathbb{E} \left[ R'_{\text{LRT } \mathcal{L2}} \mid \mathbb{S}_{\text{LRT } \mathcal{L1}} \right]$ denotes the expected slashing risk for LRT $\mathcal{L}_2$​ given that LRT $\mathcal{L}_1$​ has been hypothetically slashed;

• $\mathbb{S}_{\text{LRT } \mathcal{L1}} \sim R'_{\text{LRT } \mathcal{L1}}$ implies that the slashing event observed on LRT $\mathcal{L}_1$​ is statistically consistent with its ex-ante assessed risk.

This formulation captures second-order effects, where slashing risk propagates beyond the initial LRT through shared infrastructure and Operator exposure. The amplification model $R'_{\text{LRT}}$​ instantiates this dependency, allowing conditional expectations to update risk downstream. If $\mathcal{L}_1$ is slashed and LRT $\mathcal{L}_2$​ shares validator or N/AVS overlap, $\mathcal{L}_2$​ inherits elevated risk.

These dynamics can escalate further: restaking protocol TVL may face drawdowns downstream as a slash is triggered and as trust erodes across LRTs and the wider ecosystem. In severe scenarios, the impact may ripple down to trust in ETH itself. All these interesting game-theoretic dynamics ought to be carefully considered and advised for on a future work, namely risk mitigation through safeguards over N/AVS overexposure, delegation caps per LRT and Operator, and dependency-aware allocation strategies.

5. Restaking Protocols Approaches toward Slashing

LRT slashing risk is inherently shaped by the architecture and slashing-enforcement model of their underlying restaking protocol(s). Protocols differ in how slashing is defined, triggered, isolated, and enforced—each introducing unique implications for fault containment and systemic risk. Understanding these distinctions is essential for evaluating LRT risk at the protocol level also.

To date, EigenLayer and Symbiotic are the only two platforms with slashing live on mainnet.

EigenLayer

EigenLayer’s newly-released slashing architecture centers around two core concepts: Unique Stake and Operator Sets. Operators explicitly delegate a fraction of their restaked capital to individual AVSs. If an AVS activates slashing only the slashable stake tied to that AVS is slashed, not the operator’s entire stake.

Operator Sets further isolate risk by allowing each AVS to define and enforce its own slashing logic on a dedicated validator set. The rules are executed through EigenLayer’s onchain slashing modules, strengthening cryptoeconomic accountability while minimizing systemic risk.

As of April 2025, slashing has officially gone live on mainnet via opt-in activation. It marks a significant milestone, positioning EigenLayer as a feature-complete restaking security platform, that verifiably enforces cryptoeconomic trust of both objective and intersubjective faults on-chain.

Symbiotic

Symbiotic implements a vault-based slashing architecture, governed by immutable smart contracts. Each vault encodes the networks it secures, the slashing conditions enforced, and the mechanics of penalty execution. These terms are defined at deployment, removing any possibility of governance intervention and guaranteeing protocol finality.

To guard against unfair enforcement, Symbiotic introduces an optional dispute resolution mechanism through pre-approved Resolvers—trusted entities that can veto slashing deemed unjustified.

Live since January 2025, slashing is executed via the onSlash() function, which permanently removes slashed assets by transferring them to a burn address. To date, only one Network (MEV-Commit) has activated slashing, with a penalty ceiling of 1 ETH.

EigenLayer and Symbiotic take distinct approaches at slashing design: one favors dynamic, operator-defined enforcement; the other enforces immutable vault-level rules. Both attempt at containing systemic propagation, by adopting differing trade-offs.

Another mitigation strategy worth exploring would be incentives toward stake collateral diversification. As discussed earlier, the concentration and quality of assets allowed to be deposited into a restaking protocol significantly influences its cryptoeconomic guarantees and exposure to stake-wide losses.

6. Conclusion

Despite their popularity as a collateral choice in DeFi, LRTs have lacked an extensive and rigorous framework for risk assessment. The rapid ecosystem expansion of restaking protocols and their respective slashing releases, have only increased the need for a structured evaluation of the risk multidimensionality of LRTs.

The present framework addressed that gap by providing a layered methodology to deconstruct, score, and contextualize these security concerns. By translating heterogeneous inputs into interoperable metrics, it enables more coherent comparisons across protocols and offers actionable insights into slashing sensitivity and systemic fragility.

Furthermore, LRT adoption imposes second-order consequences on DeFi risk management practices, that warrant first-order actions: lending protocols integrating LRTs ought to dynamically adapt economic safeguards, including stricter LTV thresholds and more conservative minimum collateralization ratios for higher-risk LRTs; finding a game theoretic equilibrium. Slashing events—if unanticipated or unmitigated—can amplify liquidation cascades and destabilize trust assumptions within many protocols, deterring both user participation and institutional capital inflows.

References

• LRT Risk Framework: https://paragraph.com/@tokensightxyz/lrt-risk-framework

• Restaking Protocols Risk Framework: https://paragraph.com/@tokensightxyz/restaking-prot-risk-framework

• Restaking Network Risk Evaluation: Developing a Fundamental Approach: https://hackmd.io/@lCkxYGq-RPqCfyHwdlrqbg/HymUqWD7Jx

• ELIP-002: Slashing via Unique Stake & Operator Sets: https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md

• Demystifying Slashing: https://blog.symbiotic.fi/demystifying-slashing/

• Robust Restaking Networks: https://arxiv.org/abs/2407.21785

• How much should you pay for restaking security?: https://arxiv.org/abs/2408.00928

• Liquid Restaking Token (LRT) Market Risk Framework: https://www.gauntlet.xyz/resources/liquid-restaking-token-lrt-market-risk-framework

• STAKESURE: Proof of Stake Mechanisms with Strong Cryptoeconomic Safety: https://arxiv.org/abs/2401.05797

• Ether.fi Whitepaper: https://etherfi.gitbook.io/etherfi/ether.fi-whitepaper/introduction

• Vault curation on Symbiotic: https://mevcapital.com/gauging-slashing-risks-of-symbiotic-networks/#:~:text=The%20Symbiotic%20ecosystem%20consists%20of,of%20collaterals%20across%20different%20vaults.

• u--1: LRTs: https://u--1.com/lrts

• Restake.Watch: https://restake.watch/

Subscribe and follow us on X!