Recently, our founder joined João Simões, Swell’s Head of Growth, on the Restaked podcast to unpack his crypto journey, the origins of Tokensight, and why the next cycle will be driven by a new wave of applications that use restaked collateral, slashing mechanics, and redistribution in innovative ways.

The conversation unfolded in three parts:
First, we revisited Bernardo's path from traditional finance to fintech and finally to crypto, where Tokensight was founded to address a persistent gap in restaking risk research.
Second, we examined how most analytical frameworks still mischaracterize restaking as a static yield multiplier instead of a dynamic coordination layer. In practice, each restaked position carries multidimensional exposures—spanning operators, AVSs, slashing correlations, and collateral health. Tokensight’s work centers on translating this complexity into structured, data-driven risk signals and technical risk reports that help curators, protocols, and operators allocate capital efficiently and intelligently.
Finally, we explored how the next phase of the ecosystem will be defined by application-level innovation. Protocols such as Cap and Catalysis illustrate, and arguably pioneer, this transition: Cap leverages restaked collateral to underwrite loans, while Catalysis extends it to insurance guarantees, both enforced through verifiable slashing conditions that anchor economic security to real-world utility.

Restaking, at its core, represents the convergence of verifiable security provisioning, the point where validator behavior, protocol design, and incentive architecture intersect. It is not merely a new yield source but a new launchpad economy, one that transforms staked capital into programmable, productive collateral powering the next generation of decentralized systems.

Swell 🌊⛓️

@swellnetworkio

What's next for restaking?

Bernardo from @tokensightxyz covers this and more in the latest episode of Restaked with host @0xjnsimoes.

Listen on Spotify, Youtube, or Apple Podcasts:
restakingpodcast.com/e/x8vlyzq8-why…

36

10:44 AM • Aug 21, 2025

Listen to the full episode at: https://restakingpodcast.com/e/x8vlyzq8-why-90-of-restaking-risk-analysis-is-wrong-and-how-to-fix-it-with-bernardo-vicente

Index

1. Abstract

2. Primer

3. Coverage Lifecycle

4. Stakeholder Interactions: Coverage Across the Stack

   1. Catalysis <> SSPs

   2. Catalysis <> CoverPool Curators (Llamarisk, Chaos Labs, etc)

   3. Catalysis <> Delegators (Restakers, LRTs)

   4. Catalysis <> Coverage Clients/Policy Holders (eg. DeFi Protocols)

   5. Delegators <> Curators

5. Examples: Lending, Yield-Bearing Stablecoins, & Vaults

   1. Reaching Equilibrium

6. Risks & Paths to Mitigation

7. Comparison to Legacy Onchain Insurance

8. Conclusion

Abstract

DeFi has scaled into a global financial substrate, yet its insurance infrastructure remains weak and fragmented. Stablecoins, now exceeding $250B (mid-2025) with ~50% YoY growth, have become the de facto settlement layer across exchanges and payments, surpassing Visa and Mastercard in on-chain settlement volume. Tether ranks among the world’s top holders of U.S. Treasuries (around 7th globally by early 2025), while fintechs such as Stripe and Robinhood are standardizing on-chain dollar rails for payouts and wallets. This marks a durable shift toward programmable finance and with it, growing demand for programmable risk coverage. In this research piece, we will take an in-depth look at the Catalysis Coverage protocol, how it works, and its promise in rearchitecting onchain insurance.

Existing models rely on gated underwriting, idle and thin capital pools, and governance-driven claims, leaving systemic risks like smart contract exploits, oracle failures, stablecoin depegs, or liquidity spirals largely unprotected. Catalysis Coverage introduces a new design: restaked collateral, already abundant and slashable, is routed into curator-run CoverPools where premiums are competitively priced and claims (of any size) are settled deterministically through slashing. Thereby turning insurance from a static, governance-heavy process into a programmable market. Delegators look to earn yield for underwriting real protocol risk, curators monetize actuarial expertise, and protocols secure transparent, enforceable protection at lower cost than existing insurance solutions. The result is a scalable and permissionless coverage layer: auditable, composable, and capable of supporting not only DeFi protocols but the broader financial stack they anchor.

Since 2020, crypto platforms have lost an estimated $6–8B to exploits, according to a Chainalysis’ report. Over the same period, Nexus Mutual, by far the largest on-chain insurance protocol, has paid out just ~$18M in valid claims. That equates to a coverage ratio of roughly 0.2–0.3%, meaning over >99% of realized losses went uninsured. The gap underscores how marginal the on-chain insurance footprint remains relative to the scale of systemic risk.

Primer

DeFi has grown, beyond crypto, into a cornerstone of the financial economy, with billions locked across lending, stablecoins, and trading platforms. However, its insurance rails remain primitive and stuck: underwriting is gated, capital sits idle, pricing is static, and claims depend on slow governance procedures. The result is thin coverage, delayed payouts, and little confidence in protection, leaving systemic risks like liquidation spirals, exploits, stablecoin or derivative depegs, and oracle failures largely unaddressed.

Catalysis Coverage introduces an alternative. It channels restaked collateral into pools run by curators, where premiums are set competitively and faults trigger slashing to deliver fast, claimable protection. Instead of the current slow, shallow, and gated procedures, coverage becomes a highly-composable and programmable market: modular, auditable, and aligned with the needs of both protocols and underwriters.

The shared-security layer supplies deep collateral, Catalysis Core orchestrates premium flows and slashing execution, and independent curators design policies, set claim conditions, and split risk into junior and senior tranches. Delegators turn their capital more efficient by earning extra yield by underwriting real protocol risk, while protocols gain predictable, enforceable protection. The result is a friendly coverage layer—robust enough to insure a wide range of protocols in crypto.

System Model: The Three-Layer Stack

Coverage Lifecycle

Catalysis Coverage achieves optimized insurance through a structured worflow: buyers (policy holders) request cover, curators assess and price risk, delegators signal capacity, and premiums are escrowed with optional buffer deposits. Tranching aligns risk and returns, and, at maturity, premiums flow to delegators or are refunded if no claim is activated. If a claim is flagged and valid, the system executes slashing, swaps collateral into payout tokens, and pays the policyholder—seamlessly, in a single transaction.

• Request: A buyer-protocol requests cover from one or more CoverPools for protection, specifying how much coverage they want, for how long, and under what terms.

• Risk Assessment: The CoverPool Curator evaluates the request, models the risk, and sets the premium rate, coverage limits, and clear claim conditions.

• Capacity Signalling: After Curators request delegations from Catalysis Core, willing delegators back the policy by committing stake in advance, but funds do not move yet.

• Quote Publication: CoverPools publish quotes with rates, capacity, and expiry dates for the buyer to choose from.

• Binding: The buyer-protocol accepts a quote. The system validates all commitments and issues a Policy token, locking the agreement in place. This happens atomically: either all conditions are met, or nothing goes through.

• Premium & Escrow: When a policy binds, the buyer pays the premium upfront plus a refundable buffer deposit (RBD); platform and pool fees are taken immediately, and the remainder sits in escrow within Catalysis Core until maturity.

• Tranching: Coverage is split into junior (first-loss, higher return) and senior (protected, lower return but larger capacity) layers, by curators. Delegators choose which tranche to back, based on risk appetites.

• Maturity: If no claim occurs, the buffer deposit is refunded to the buyer and premiums are paid out to delegatos relative to their stake commitment.

• Claims: If the covered event occurs, the claim conditions are checked automatically. If valid, the buffer deposit is tapped first toward the payout as buyer skin-in the-game (deterring frivolous claims and abuse of coverage); then delegator stake is slashed according to tranche composition (junior first, senior later), converted into the payout token, and sent directly to the buyer, in a single transaction.

Stakeholder Interactions: Coverage Across the Stack

Catalysis Coverage introduces a coordination layer where four sets of actors—Shared Security Protocols (SSPs), Delegators, CoverPool Curators, and Coverage Clients—interact around the conversion of restaked collateral into structured insurance vehicle. The governing element is economics: premiums, yields, fees, and the credible guarantee of slashing. Coverage works only if these incentives balance into a sustainable, capital-efficient equilibrium.

Catalysis <> SSPs

Catalysis → SSPs

SSPs such as EigenLayer, Symbiotic, and SatLayer act as capital reservoirs and slashing executors. Catalysis relies on these marketplaces to source collateral, attract delegators, and enforce objective claim payouts via deterministic slashing. The selection decision should hinge on carefully-considered SSP parameters, such as:

• Withdrawal latency → defines how quickly delegators can reclaim their stake once a policy term ends. Long withdrawal epochs introduce liquidity risk for delegators, shorter ones make coverage more attractive by lowering capital lock-in costs, while mismatched withdrawal epochs across SSPs add operational complexity and potential confusion.

• Collateral type → different collateral asset types carry different volatility and liquidity profiles. Volatile assets increase the tail-risk of undercollateralization, whereas stable collateral supports more predictable coverage economics. Protocols may favor or reject coverage depending on the mix.

• Slashing determinism → the credibility of Catalysis rests on the guarantee that valid claims are enforced without delay or governance disputes. SSPs with clear, automatic, and verifiable slashing logic ensure that premiums correspond to real protection, not discretionary promises.

For an extensive read of SSPs’ risk-profiling metrics, refer to:

Restaking Protocols Infra Risk Framework V2

Tokensight Research Hub

May 9, 2025

Expanding upon our initial risk framework for assessing the infrastructure risks of restaking protocols.

0 collected

Collect

SSPs → Catalysis

By engaging with Catalysis Coverage and directing idle restaked assets into CoverPools, SSPs unlock additional yield channels to themselves and their users: estimated to translate into 5–7% APY in senior tranches or 10–12%+ in junior tranches. The trade-off is duration risk: capital is to be locked through both policy term and SSP exit epochs. SSPs therefore earn not just fees, but also systemic utility and capital efficiency as the entities whose liquidity mechanics directly shape the economics of coverage.

Catalysis <> Curators

Catalysis → Curators

By tapping into this system, curators further monetize their skills through fees and premium volume, but healthy returns depend entirely on performance. Their economics are shaped by both upside and downside dynamics:

• Low loss ratios → consistent underwriting discipline in defining the risks, the correct terms, and setting proper pricing builds trust with delegators, attracting more delegations and expanding pool capacity.

• Reputation effects → a strong record compounds into higher premium inflows, as protocols prefer curators with proven prudence and transparent claim handling.

• Mispricing risk → underpriced coverage exposes delegators to uncompensated slashing and triggers capital flight; overpriced coverage drives protocols away, collapsing demand.

Economically, curators face asymmetric incentives: the upside is persistent fee revenue from premium volume, while the downside includes fee clawbacks, bonding penalties, and reputational damage that can permanently impair their ability to attract delegations. This dynamic ensures that actuarial competence is continuously tested in an open market. Over time, Catalysis evolves into a coverage market for actuarial reputation, where only curators who consistently align delegator returns with sustainable premium levels thrive.

Curators → Catalysis

While Catalysis provides the middleware, curators supply the actuarial judgment and market differentiation that make coverage viable. Each CoverPool is stewarded by a single curator, responsible for the economic design of policies across three dimensions:

• Premium calibration → setting rates that balance attractive APY for delegators with affordable protection for clients, ensuring pools remain competitive while solvent.

• Tranche design → structuring junior (first-loss, higher yield) and senior (protected, lower yield) layers to attract different risk appetites and manage capital efficiency.

• Claim specifications → defining clear and objective terms that minimize disputes, enable instant settlement, and build trust. Well-designed specs not only protect delegators from ambiguous slashing but also attract demand from clients who value transparent, automated coverage over discretionary governance votes.

For Catalysis, attracting strong curators is central: they expand the breadth of coverage offerings, bring actuarial credibility, and generate premium volume that sustains the entire system. The more curators with differentiated expertise join, the more diverse the insurance market becomes, which increases adoption, deepens delegator yield opportunities, and entrenches Catalysis as the neutral coordination layer for on-chain insurance.

Catalysis <> Delegators (Restakers / LRTs)

Catalysis → Delegators

Delegators convert passive stake into programmable underwriting capital. They choose pools and tranches aligned with their risk tolerance:

• Junior tranches absorb first-loss exposure and target double-digit APY, but are most exposed to slashing.

• Senior tranches sit above junior buffers, earning lower but steadier yields (low- to mid-single digits).

Because premiums are escrowed at bind, yields are predictable if no claim is triggered. The fundamental inequality guiding delegation is:

$$\text{Premium Yield} > \Pr[\text{Claim}] \times \text{Expected Loss}$$

If this inequality holds, delegators participate; if not, they rotate capital out. This equation possibly stands as the most important to get right within Catalysis’ ecosystem.

Delegators → Catalysis

Delegators have the crucial role of liquidity providers for Catalysis’ system, that enforce pricing discipline through capital rotation. If risk is overpriced, clients exit; if it’s underpriced, delegators exit after suffering slashing losses. Their movement between pools creates a self-correcting filter: only CoverPools with sustainable economics retain capital. LRT protocols (Ether.fi, Renzo, Swell), acting as delegators, amplify this dynamic by routing restaked capital into diversified pools, pushing delegators toward risk-adjusted equilibrium across the system. The more pools with favourable economics, the more stake capacity Catalysis is able to source.

Catalysis <> Coverage Clients (DeFi Protocols/Policy Holders)

Catalysis → Coverage Clients

Protocols buy coverage to protect against explicit loss scenarios—such as depegs, bad debt, or liquidity shortfalls—by paying upfront premiums priced more competitively than legacy insurance models. Instead of locking capital in idle reserves, they pay only for the risk they request and might face. Pricing competition between curators pushes premiums lower, while transparency of claim specs and deterministic slashing by SSPs ensures that when coverage is needed, payouts are both credible and automatic.

The economic proposition is twofold:

• Capital efficiency → premiums replace large idle buffers, allowing balance-sheet capital to reallocate to productive activities across lending, liquidity provision, or growth.

• Credible protection → claim payouts are guaranteed on-chain through slashing, avoiding governance delays, subjective votes, or underfunded pools from existing, sub-optimal solutions.

Coverage Clients → Catalysis

From the demand side, premiums form the revenue stream sustaining the whole system. Market competition ensures differentiation:

• Well-audited and transparent protocols enjoy lower premiums, as curators perceive lower default or claim probability.

• Opaque or fragile protocols pay more, reflecting higher underwriting risk.

The disincentive is straightforward: if Catalysis premiums exceed the cost of simply holding excess reserves, protocols will walk away. Equilibrium demand therefore hinges on Catalysis consistently offering better economics and execution than alternatives. Self-insurance locks capital in idle buffers; legacy insurance exposes protocols to governance delays and disputed claims. Catalysis instead delivers deterministic enforcement, transparent pricing, and capital efficiency, making it the rational choice for Coverage clients as long as its premiums remain anchored to economic reality.

Delegators <> Curators

Delegators → Curators

Delegators delegate capital only if curators demonstrate credible risk-return economics. They monitor loss ratios, claim histories, and fee structures. The ability to exit and redelegate is the ultimate equilibrium mechanism: if a curator misprices risk or fails to deliver sustainable returns, capital drains away regardless of reputation.

Curators → Delegators

Curators take raw collateral and shape it into structured insurance products. Leveraging their expertise, they define policy scope, premium levels, tranche mechanics, and exclusions, abstracting such hurdles away from delegators. Their revenue depends on delegator trust and retention, making their performance inseparable from delegator profitability.

Examples: Lending, Yield-Bearing Stablecoins, & Vaults

To illustrate how Catalysis Coverage functions in practice, we examine three archetypal DeFi settings: lending, yield-bearing stablecoins, and vaults. Each example highlights how coverage absorbs specific risks, enhances capital efficiency, and aligns incentives across protocols, delegators, and clients under different stress scenarios.

Lending

The lending visualization shows a stacked blue bar of collateral and Catalysis Coverage, and in green, the borrower’s loan amount and outstanding debt at three stages: T1 at loan inception, T2 midway into repayment, and T3 closer to maturity. The figure illustrates the sequence in which protection operates: collateral being the first-loss buffer liquidated in default, while Coverage activates only if liquidation proceeds fall short of the outstanding balance. This ensures that even in undercollateralized or volatile scenarios, lenders’ effective protection remains above the required threshold ($130M).

In lending, defaults unfold in two stages: the borrower’s collateral is liquidated to repay debt; if insufficient, a shortfall occurs leaving bad debt to be dealt with by the protocol. Catalysis Coverage does not substitute this process, as it is only activated if liquidation proceeds fall short of the outstanding balance, filling the residual gap to ensure lenders are repaid in full. Collateral remains the primary buffer, while coverage serves as a conditional shortfall backstop. Looking ahead, coverage could also be extended to smooth liquidation risk itself (e.g. auction underperformance or cascade dynamics), but its current scope is solely focused on shortfall absorption.

The visualization depicts this dynamic across three repayment timeframes. At T1, the borrower owes $100M with $90M of collateral posted, and purchases $50M of coverage to remain above the liquidation threshold ($140M > $130M). In case a default occurs, collateral liquidates for $90M and coverage pays the $10M shortfall. At T2 (after a $10M repayment), outstanding debt falls to $90M while collateral remains $90M. In this case, default would be fully covered by collateral, and coverage is not triggered. At T3, after another $10M repayment, debt is $80M but collateral’s NAV drops to $75M, due to liquidity stress or price volatility. The previously “overcollateralized” position now sits below the $130M threshold (75 + 50 = 125). Collateral is sold, a $5M shortfall surfaces, and Coverage absorbs that amount.

This sequencing highlights the efficiency gains of combining collateral and Coverage. Borrowers can post leaner collateral ratios (e.g. 90% instead of 140%) while still meeting lenders’ risk thresholds through conditional coverage. Claims can also be structured to vary across the loan term, aligning payout probabilities with amortization and market risk. When defaults occur, slashing fills the shortfall, converting delegator stake into payouts for lenders. Over time, this equilibrium reduces idle collateral requirements, preserves safety, and yields delegators a return commensurate with shortfall risk; thereby creating a lending system that is both more capital-efficient and more resilient.

Yield-Bearing Stablecoins

The stablecoin visualization compares, in blue colours, asset-side protection (NAV plus reserves, topped with Coverage) against the constant liability of redeemable supply at $1, in green. The three scenarios T1 (Normal), T2 (Stress), and T3 (Near-Depeg) show how coverage operates as a safety buffer when asset backing falls toward or below liabilities.

On the asset side, NAV and reserves fluctuate with market conditions. At T1, NAV plus reserves comfortably exceed liabilities, so coverage remains unused. At T2, sharp market stress cuts NAV by 20%, and reserves help absorb part of the shock and coverage stands ready to activate if liabilities are threatened. At T3, as NAV continues falling, additional coverage is purchased: slashable delegated collateral is requested to restore balance and preserve the peg. This dynamic allows stablecoin issuers to run leaner reserves and earn peace of mind, relying on coverage for tail scenarios, while delegators earn premiums for underwriting systemic stability.

The overall economic balance is therefore strengthened. Issuers gain capital efficiency by reducing non-yielding reserve buffers, now supporting growth and yield generation. Holders gain confidence that the peg is protected even under stress. Delegators also see an increase in capital efficiency, however, may face correlated tail risk: slashing occuring in periods of systemic stress, when stablecoin liquidity wobbles. Premiums must therefore compensate adequately for rare but severe events. Across scenarios, the visualization shows how coverage smooths volatility in asset backing, ensuring withdrawals remain whole and transforming restaked collateral into a programmable peg backstop.

Vaults

The vaults visualization places available liquidity (undeployed capital plus coverage) alongside outstanding withdrawal requests across three scenarios: T1 (Calm) under normal flows, T2 (Spike) during a sudden redemption surge and emergency coverage top-up, and T3 (Settle) when requests normalize but additional coverage is still drawn to restore balance. The bars illustrate how coverage supplements liquidity whenever user redemptions exceed what the vault can supply natively.

Vaults naturally suffer from liquidity mismatch: capital is often deployed into staked or longer-term strategies, yet users expect near-instant withdrawals. At T1, liquidity comfortably exceeds requests, so coverage remains unused. At T2, a market shock drives redemptions sharply higher while undeployed buffers are thin; here, coverage is activated, slashing delegator collateral and converting it into stable payouts to meet withdrawals. This mechanism prevents long queues, gated exits, or fire-sale liquidations of underlying positions. At T3, withdrawal pressure subsides, but coverage is again requested to refill liquidity to safe operating levels—ensuring vault confidence even after stress.

For vault operators, coverage substitutes for costly idle reserves: instead of holding excess liquidity that drags down yield, they pay predictable premiums to backstop spikes. For users, coverage guarantees timely redemptions and protects against the systemic risk of locked exits. For delegators, premiums generate steady yield, though exposure clusters in moments of correlated stress when multiple vaults may request payouts at once. Over time, equilibrium forms where vaults weigh the cost of premiums against the opportunity cost of holding idle liquidity, while delegators demand sufficient compensation for underwriting these redemption shocks.

Reaching Equilibrium

At the core of Catalysis Coverage is the delegator’s calculus: does the premium yield earned from underwriting exceed the expected slashing loss from claims? This decision is captured by:

$$\text{Expected Yield} = \text{Premium Income} - \Pr[\text{Claim}] \times \text{Expected Slashing Loss}$$

Delegators will only allocate to CoverPools when expected yield clears this hurdle, ensuring that premiums earned consistently outweigh the tail risk of slashing. To make this concrete: if the probability of a claim during a coverage term is 3% and the expected slashing loss is $5k, then the premium must be at least $150 for delegators to break even. Anything above that threshold produces net positive yield; anything below it makes participation irrational.

The case studies on lending, stablecoins, and vaults illustrate how this balance plays out in practice:

• Lending showed how coverage fills the shortfall gap between collateral liquidation and outstanding debt. The premium must price in the probability and severity of borrower default and of collateral health drawdown. Delegators gain only if yield exceeds the expected loss from such shortfalls, and protocols and borrowers buy coverage when the premium is cheaper than overcollateralizing or holding larger reserves.

• Yield-Bearing Stablecoins illustrated peg defense. NAV erosion under stress is offset by reserves and coverage top-ups. Premiums here must capture both the frequency and depth of stress scenarios. Delegators accept low but non-zero claim probabilities as long as premium flows cover the tail-risk of depegs, while issuers save versus hoarding idle reserves.

• Vaults highlighted liquidity mismatches, where withdrawal spikes exceed liquid assets and coverage bridges the gap. Premiums must track the likelihood of these sudden stresses. Delegators are safe only if the premium more than offsets expected payouts, while vaults benefit by reducing idle buffers without sacrificing user confidence.

Together, these cases converge on a single insight: equilibrium exists only when premiums accurately reflect both the frequency and severity of loss events. If premiums understate risk, delegators suffer uncompensated slashing; if they overshoot, protocols abandon coverage. The balance holds when (i) premium income scales with genuine protocol demand for solvency protection, and (ii) expected slashing losses remain contained through curator quality, diversification, and tranche structuring. When these two conditions align, delegators achieve net APY above alternatives, protocols secure cheaper protection than idle reserves, and curators sustain fee income without mispricing risk.

Risks & Paths to Mitigation

Along with the innovation unlocked, a few new risks emerge that must be addressed with thoughtful mitigation paths. These risks range from principal–agent misalignments between curators and delegators, to correlated exposure across pools, to oracle vulnerabilities. Managing them is essential for ensuring that the economics remain sustainable for every party.

• Principal–Agent Problem (curators vs. delegators): Curators set premiums and claim specs on behalf of delegators, while delegators ultimately bear the slashing risk. Misaligned incentives can push curators towards reckless underwriting in pursuit of yields.
  → Mitigations can include curator bonding (posting slashable collateral as skin-in-the-game), clawbacks or variable fee structures tied to pool loss ratios, and transparent on-chain audit trails and logs of quotes, exclusions, and claims.

• Delegator Economics: The system only works if premiums outweigh expected slashing losses from claims paid out. Delegators need both sustainable yield and confidence that their capital won’t be eroded by systemic mispricing.
  → Transparent modelling of claim probabilities, curator quality, vault isolation, and diversified delegation strategies are critical.

• Inter-SSP correlation: When operators or capital overlap across multiple SSPs, correlated failures can trigger systemic slashing, such as collateral devaluation or liquidation stemming from DeFi.
  → Exposing overlaps through metadata, setting concentration caps, rigorous risk evaluations, and monitoring cross-protocol price and collateral correlation are necessary safeguards.

• Vault overlap exposure: More than one vault may insure the same protocol or depend on the same oracle, creating hidden redundancy.
  → Dependency graphs, canonical pools, and automated alerts can reduce this double-counting risk.

• Systemic Correlation: Coverage pools may face simultaneous claims across distinct domains. If a stablecoin depegs, lending defaults spike, and vault redemptions surge at the same time, correlated stress can overwhelm coverage capacity and drain delegator collateral.
  → Mitigations might include cross-pool correlation modelling, capital buffers sized for tail-risk clustering, and dynamic tranche repricing that accounts for multi-domain stress exposure.

• Pricing failure: Underpriced coverage threatens solvency, overpriced coverage deters adoption.
  → Curator baselines for minimum loss ratios, fee back-pressure when vaults underperform, and curator fee deduction could help enforce pricing discipline.

• Trigger abuse / oracle faults: Claims triggered by manipulated data/parameters or faulty oracles undermine trust.
  → Mitigations include specs from multi-source oracles, circuit breakers, formal verification, and time-bound review windows.

• Exit liquidity: Delegators must be able to exit safely, even under stress conditions.
  → Epoch withdrawals, redemption queues, and optional backstop reinsurance smooth liquidity shocks and prevent bank-run dynamics.

• Fee fragmentation: With premiums distributed across curators, SSPs, Catalysis, and delegators, net yields can shrink considerably.
  → Dynamic fee compression and supply-side optimization ensure every stakeholder remain properly compensated.

Comparison to Legacy Onchain Insurance

As covered in the beginning of this piece, legacy DeFi insurance protocols like Nexus Mutual, Sherlock, and Aave’s Safety Module laid the initial groundwork but remain constrained: gated access, slow governance-based payouts, heavy underwriter whitelisting, and limited capital efficiency and availability.

Succinctly, Catalysis Coverage embeds insurance principles directly into the restaking stack by using multi-SSP collateral, slashing enforceability upon claim activation, atomic one-transaction claims, and non-custodial stake, Catalysis Coverage ensures faster execution, curation, transparent risk attribution, and competitive pricing and buying powers; thereby evolving insurance from static, inefficient solutions into a dynamic, seamless market.

Below we presented a comprehensive breakdown of the working components of legacy insurance protocols, against Catalysis Coverage:

Conclusion

Catalysis Coverage shows that on-chain insurance can move beyond governance delays and vague guarantees to a disciplined equilibrium: premiums aligned with real risks, delegators earning sustainable yield, and protocols securing their solvency (and reputation) without idle funds. The examples of lending, stablecoins, and vaults reveal the same principle: coverage works only when yield, cost, and risk converge in balance. By thinking insurance anew and embedding this logic into the restaking stack, Catalysis turns insurance from a fragile add-on into a durable financial primitive, one that can scale resilience across DeFi.

Learn More on Catalysis

Check Catalysis website and Twitter.

Follow us on X!

Index

1. Abstract

2. Framing RWA Risk Domains

   1. Infrastructure Risk

   2. Counterparty risk

   3. Yield & Financial risk

   4. Liquidity & Access risk

   5. Legal & Regulatory risk

   6. Transparency & Auditability risk

3. Case Study: OUSG (Ondo Short-Term Tokenized U.S. Government Treasuries)

4. Conclusion

Abstract

The present research piece introduces a structured, multi-dimensional framework for evaluating the risk profile of tokenized real-world assets (RWAs). It draws on institutional stablecoin frameworks such as Circle's Token Capital Adequacy Framework (TCAF), S&P's Stablecoin Stability Assessment, real-world asset public disclosures like Ondo's OUSG documentation, and cryptoeconomic risk frameworks originally developed in restaking ecosystems by Tokensight. As RWAs continue to proliferate across onchain finance, credible risk assessments must reconcile offchain legal enforceability with onchain transparency, collateralization, market access, and issuer behavior. This framework formalizes those concerns across six core dimensions (with 32 sub-dimensions) and proposes a unified scoring methodology applicable to diverse RWA instruments, including stablecoins, ETFs, T-bills, private credit, and real estate.

Framing RWA Risk Domains

RWAs are tokenized representations of offchain assets and rights brought onto blockchain rails, namely financial instruments like T-bills and credit, real-world property such as real estate and commodities, and increasingly, physical goods, legal claims, and supply-chain assets. Their promise lies in merging the transparency, composability, and settlement efficiency of DeFi with the regulatory clarity and yield potential of traditional finance. This convergence offers a powerful innovation thesis: global 24/7 markets for traditionally illiquid assets, programmable ownership, and reduced friction for cross-border capital flows.

However, the hybrid nature of RWAs introduces a fundamentally new risk surface. Unlike traditional financial instruments, these assets must reconcile offchain enforceability with onchain guarantees; also, unlike DeFi-native primitives, they rely on legal rights and real-world entities for value preservation. As a result, RWAs sit at the intersection of two trust models: one governed by smart contracts, the other by legal entities and infrastructure counterparties.

Despite the rapid growth of RWAs in onchain finance, robust tooling or even simple frameworking for systematic risk evaluation remain limited. Most available frameworks target only stablecoins, offering narrow insight into the broader and more complex RWA landscape. Risk remains highly fragmented, product disclosures vary wildly, and end-users (whether retail or institutional) are often left without a clear understanding of the assets they're holding. Prominent RWA reports, such as RedStone’s, have echoed this concern: while market capitalization rises, credible frameworks for evaluating issuer integrity, collateral security, legal enforceability, or liquidity access remain scarce.

This framework formalizes that gap into a modular evaluation method across six primary domains:

• Infrastructure risk: Oracle resilience, Smart contract maturity, Composability and transferability, Base chain assumptions

• Counterparty risk: Issuer dependency, Custodial setup, Governance structure, Oracle-provider conflict of interest

• Yield & Financial risk: Nominal yield, Risk premium adequacy, Duration and credit risk profile, Inflation sensitivity, Yield sourcing clarity, Operational hurdles

• Liquidity & Access risk: Transferability constraints, Whitelisting restrictions, Peg stability, Redemption accessibility, Secondary market liquidity, Holder concentration, FX volatility exposure

• Legal & Regulatory risk: Bankruptcy remoteness, Jurisdictional robustness, Legal claims and redemption rights, Issuer’s legal profile, Event stress test

• Transparency & Auditability risk: Proof-of-reserves, NAV disclosures, Peg deviation monitoring, Redemption details, Issuer communication and disclosures, Jurisdictional transparency

I. Infrastructure Risk

Infrastructure risk encompasses the technical foundations underpinning the tokenized asset. It includes the reliability, composability, and security of the smart contract infrastructure and base chain environment.

• Oracle resilience: Valuation integrity often depends on the quality of NAV or pricing oracles. Feeds that update infrequently, pull from a single source, or lack manipulation resistance introduce systemic risks. Integration with trusted oracle networks (e.g., Chainlink, Redstone) or publication of timestamped NAVs can strengthen transparency and mitigate this vulnerability.

• Smart contract maturity: Audit history, code modularity, the presence (or absence) of upgradeable logic, and the usage of well-established libraries like OpenZeppelin. Protocols with audited, non-upgradeable smart contracts (or those protected by multisigs and timelocks) tend to exhibit stronger resilience against exploits and unauthorized changes.

• Composability and transferability: Token design has to align with ERC standards like ERC-20 or ERC-4626. However, tokens that restrict transferability (e.g., via whitelists or permissions) or lack integration with DeFi building blocks (e.g., lending markets, LPs, or structured products) significantly reduce user optionality and market utility. Siloed RWAs tend to become stranded from the broader DeFi ecosystem.

• Base chain assumptions: The security model of the underlying chain cannot be ignored. Ethereum mainnet provides a robust consensus and uptime guarantee, while newer L2s, sidechains, or app-chains may introduce additional bridge, validator, or uptime fragility. Bridge design, rollup security, and uptime monitoring all influence RWA reliability.

II. Counterparty Risk

This dimension addresses the offchain institutions responsible for custody, issuance, and redemption of the tokenized asset.

• Issuer dependency: RWAs generally rely on a centralized issuer to manage minting, redemptions, NAV updates, and token supply adjustments. The greater the operational reliance on a single issuer—especially one without a strong legal or regulatory footprint—the higher the systemic exposure to both internal failure and external enforcement actions.

• Custodial setup: Strong custody standards involve bankruptcy-remote SPVs (Special Purpose Vehicles) or statutory trusts that separate user assets from company balance sheets. Regulated custodians (e.g., BlackRock, Coinbase Custody) that operate within recognized jurisdictions are far safer than unknown or offshore actors without insurance or audit obligations.

• Governance structure: The protocol’s admin controls should be safeguarded with a transparent governance model. Multisig wallets with distributed signers, public disclosures of key holders, and time-locked upgrades reduce manipulation risk. Conversely, single-signer admin wallets or opaque upgrade logic invite governance capture.

• Oracle-provider conflict of interest: If NAV pricing or valuation feeds are controlled by the issuer or custodian, manipulation risk rises. Independent third-party oracle providers and published NAV methodologies reduce this asymmetry.

III. Yield & Financial Risk

This category assesses whether the yield offered by a token adequately compensates for embedded risks like duration, liquidity, and inflation.

• Nominal yield: RWA tokens often mirror benchmark rates (e.g., ~5% from T-bills), but headline APY ignores inflation and hidden risks like FX exposure or poor liquidity. Real yield and risk-adjusted return can be far lower once these frictions are factored in.

• Risk premium adequacy: Yields should be evaluated against the frictions and risks introduced by tokenization, including redemption gating, access restrictions, oracle opacity, or legal uncertainty. If these risks are non-trivial but the yield remains flat, the product is underpricing risk.

• Duration and credit risk profile: Treasuries represent low duration, high-credit (low default risk) assets but RWAs that wrap private credit, SME lending, or real estate may face long lockups or inferior creditworthiness. Hidden mismatches between redemption terms and underlying asset liquidity (e.g., daily liquidity on 1-year notes) create latent fragility.

• Inflation sensitivity: Fixed-rate RWAs can lose purchasing power during inflationary periods unless linked to floating-rate benchmarks or CPI adjustments. Instruments with flexible rates or SOFR-indexed (Secured Overnight Financing Rate) resets offer better inflation protection.

• Yield sourcing clarity: Yield may stem from offchain ETF yield passthrough (Ondo's OUSG), onchain rebasing mechanisms (Ondo's rOUSG), or synthetic tracking (Ethena's USDe). Lack of clarity around how yield is generated or distributed can obscure actual risk/return tradeoffs.

• Operational hurdles: Minimum redemption thresholds, slow processing times, and offchain KYC requirements reduce capital efficiency and degrade realized returns, particularly for smaller or non-institutional users. These frictions reduce composability and limit integration with automated vaults, rebalancing strategies, or real-time DeFi mechanisms.

IV. Liquidity & Access Risk

This category addresses tradability and usability. Even if an RWA is technically sound, usability bottlenecks impair smooth market functioning.

• Transferability constraints: Some RWA tokens enforce non-transferability or restrict transfers via smart contract rules (e.g., ERC-1404, allowlists). While this satisfies regulatory needs, it fragments liquidity, prevents secondary market formation, and blocks integration with permissionless DeFi primitives.

• Whitelisting requirements: Token issuance and wallet eligibility are often limited to KYC’d, accredited participants. With that, the holder base narrows, global access restricts, and exposure concentrates among a small set of institutional actors, exacerbating redemption queue risks and limiting broader utility.

• Peg stability: In stablecoins, peg stability relies on DEX/CEX arbitrage dynamics and timely redemption mechanisms. Pegs may slip during volatility or market stress if arbitrage pathways are weak, redemption windows are delayed, or reserve data is opaque. A resilient peg demands deep liquidity, arbitrage incentives, and real-time redemption assurance.

• Redemption accessibility: Redemption privileges are often limited to accredited U.S. institutions. This prevents broader participation, introduces geographic concentration, and cuts off global capital from accessing or exiting these instruments.

• Secondary market liquidity: Tokens lacking Uniswap pairs, Curve pools, or institutional OTC desks suffer from liquidity fragmentation. The absence of active, liquid markets leads to wide bid-ask spreads, long exit times, and poor price discovery.

• Holder concentration: A token dominated by a few whale wallets faces elevated redemption volatility, governance capture, and exit queue risk during stress periods. Diverse holder bases lead to healthier market behavior.

• FX volatility exposure: USD-denominated RWAs expose non-USD investors to currency risk, especially in macro cycles where the dollar strengthens. Unless explicitly hedged or paired with FX instruments, these risks go unmanaged.

V. Legal & Regulatory Risk

Legal risk examines the enforceability of investor rights, bankruptcy protections, and jurisdictional clarity.

• Bankruptcy remoteness: The strongest RWA structures use SPVs or statutory trusts to separate onchain claims from issuer liabilities. This ensures that tokenholders can access the underlying assets even in issuer bankruptcy scenarios.

• Jurisdictional robustness: Tokens issued under U.S. law, or within European legal regimes, typically enjoy stronger legal defensibility and regulatory oversight than those structured via offshore entities (e.g., BVI, Cayman).

• Legal claims and redemption rights: The presence of formal claim rights, asset pledging, or clearly defined pro-rata redemption mechanics creates stronger enforceability. These features distinguish “real” RWAs from synthetic or wrapped instruments.

• Issuer’s legal profile: There’s a material difference between a registered broker-dealer, a public trust, or a Delaware corporation, versus a non-domiciled foundation. The legal structure of the issuer affects what recourse holders have during litigation or liquidation events.

• Event stress test: In adversarial cases (e.g., lawsuits, insolvency, or regulatory shutdown), the ability for tokenholders to assert standing and claim collateral is the ultimate test of legal security.

VI. Transparency & Auditability Risk

This dimension focuses on whether users and regulators can verify the backing, health, and mechanics of the asset on a continuous basis.

• Proof-of-reserves: The gold standard is daily, cryptographically provable attestations from trusted third parties. Alternatives include real-time Chainlink PoR feeds or manual audit trails with verifiable documentation.

• NAV disclosures: RWAs that publish consistent NAV data via tamper-proof oracles, or timestamped feeds (mirroring ETF disclosures), enable transparent valuation.

• Peg deviation monitoring: In stablecoin systems, transparency must extend beyond reserve snapshots to include real-time deviation monitoring across major DEXs/CEXs. The goal is to enable early detection of depegging events and enhances trust in collateral sufficiency and redemption timing.

• Redemption details: Clear, public documentation outlining minimums, timelines, eligible wallets, and processing fees reduces ambiguity and improves UX.

• Issuer communication and disclosures: Frequent reporting, open documentation, third-party audits, and financial statements contribute to trustworthiness. Issuers that remain silent or obfuscate core parameters weaken user confidence and institutional adoption.

• Jurisdictional transparency: Products domiciled in jurisdictions requiring regular filings, financial audits, or regulatory registration (e.g., SEC, BaFin) offer stronger visibility than those structured offshore with no reporting mandates.

Case Study: OUSG (Ondo Short-Term Tokenized U.S. Government Treasuries)

OUSG represents tokenized exposure to short-term U.S. Treasuries via a Delaware-domiciled, bankruptcy-remote SPV administered by Ondo Finance. The SPV invests primarily in institutional-grade money market funds (e.g., BlackRock’s BUIDL, Fidelity’s FYHXX, Franklin FOBXX), backed by U.S. Treasury securities. Investors acquire OUSG tokens by depositing USDC or PYUSD, which are exchanged offchain through Coinbase or Circle before being allocated into the underlying fund holdings. Each OUSG token reflects a limited partnership interest in the fund.

Two versions of the token exist: OUSG (accumulating), which reflects yield via increasing NAV, and rOUSG (rebasing), which keeps a fixed $1 price and distributes yield as additional tokens. Conversions between OUSG and rOUSG are supported natively via wrapper contracts, allowing for composable representations of yield-accruing collateral. While redemptions above instant thresholds are subject to offchain processing and business-day constraints, smaller transactions (≥$5K) can be executed instantly, depending on available daily limits.

Infrastructure

OUSG contracts are deployed on Ethereum using OpenZeppelin standards, audited by Zellic, and governed by a time-locked multisig. Daily NAVs are computed offchain and pushed onchain via a non-real-time oracle, introducing mild price latency. The rebasing logic for rOUSG reflects NAV increases through automatic token supply adjustments. Smart contract design is robust, but programmability remains limited: OUSG itself is non-transferable and excluded from DeFi rails, and only rOUSG (held by eligible wallets) may be composable in controlled contexts.

Counterparty

Underlying asset custody is handled by top-tier TradFi institutions (BlackRock, Fidelity, Franklin, etc.), while fund administration is retained by Ondo Capital Management. Token issuance, redemption, and NAV mechanics remain under Ondo’s operational control. While the architecture is legally sound and custody partner quality is high, ultimate execution (minting, NAV sync, redemption) depends on Ondo's offchain processes. In a failure scenario—such as operational downtime or misreporting—there are no automated recovery paths, multisig-controlled overrides, or independent oracles to resume NAV servicing or redemption.

Yield & Financial

OUSG passively tracks the blended yield of its Treasury-backed fund portfolio, with current APYs near 5% depending on market rates. Yield flows from the underlying ETF portfolio into the NAV of OUSG, which then increases rOUSG balances through rebasing. Manual redemption processing may lower effective yields for small or delayed exits due to offchain friction. Instant redemption is limited to predefined caps, while larger withdrawals require 1–3 business days. Realized returns may be affected by offchain frictions and minimum redemption thresholds ($100K non-instant). FX exposure exists for non-USD investors, as the instrument is not hedged. Management fees (0.15%) are currently waived through 2026.

Liquidity & Access

OUSG tokens are non-transferable and permissioned, available only to accredited U.S. investors who pass KYC/AML verification. No DEX or CEX integration exists. rOUSG tokens can be transferred between whitelisted wallets within Ondo’s Qualified Access Fund network, but neither version can be held or interacted with by non-KYC’d wallets. Economic exposure for non-whitelisted entities may be facilitated indirectly via OTC arrangements or wrapped fund structures, but such holders lack direct redemption rights. Exit friction remains high for any holders outside the compliance perimeter.

Legal & Regulatory

The fund operates under Section 3(c)(7) of the Investment Company Act and Rule 506(c) of Reg D, restricting access to verified accredited investors. Legal protections and redemption rights are clearly articulated in public documents, but only enforceable by onboarded LPs. Assets are bankruptcy-remote and segregated from Ondo’s balance sheet. There is no FDIC/SIPC (Federal Deposit Insurance Corporation/Securities Investor Protection Corporation) insurance, but legal clarity and structural safeguards significantly exceed industry norms for tokenized RWA instruments.

Transparency & Auditability

Ondo provides detailed disclosures on fund mechanics, legal terms, partner relationships, and several smart contract audits performed. Daily NAV updates are verifiable and accompanied by rebasing events in rOUSG. However, no cryptographic proof-of-reserves system exists presently. NAV attestations rely on administrative reporting and fund disclosures, not zero-knowledge proofs or trust-minimized onchain attestations. As such, reserve verification depends on offchain institutional trust rather than immutable onchain guarantees. Transparency remains strong relative to peers, but is ultimately constrained by the limitations of the offchain legal and operational architecture.

Evaluation & Risk Assessment

OUSG is one of the most legally and operationally robust tokenized Treasury products on the market. Structured through a Delaware SPV and backed by top-tier custodians (BlackRock, Coinbase, Circle), it offers strong guarantees on legal recourse, yield transparency, and investor protections. Its dual-token design (OUSG/rOUSG) supports institutional use cases like cash management and fund representation, with daily NAV updates and clear redemption mechanics.

That said, OUSG reflects the tradeoffs of compliance-first architecture: permissioned access, non-transferability, and U.S.-only investor eligibility severely restrict composability, liquidity, and global accessibility. The product lacks a fallback oracle or multisig-neutral redemption route, and indirect holders (those gaining exposure via feeder funds, wrappers, or OTC intermediaries) have no legal standing. Proof-of-reserves are not cryptographic. In effect, OUSG behaves less like a DeFi-native asset and more like a secure, digitized LP share optimized for institutional use under U.S. law.

Overall Risk Assessment

• Legal, Custody, and Counterparty Risk: Low – Bankruptcy-remote SPV, regulated custodians, and full disclosures provide a strong legal base.

• Infrastructure & Composability Risk: Medium‑Low – Audited contracts and multisig governance enhance execution integrity, but permissioning and oracle centralization (offchain NAV feed) limit programmability.

• Access & Redemption Risk: Medium – Only whitelisted accredited investors can mint/redeem; all redemptions are routed offchain, and indirect holders lack enforceable access.

• Liquidity & Exit Risk: Medium‑High – No onchain liquidity venues (DEXs/AMMs) for OUSG (nor rOUSG); both tokens are non-transferable, and there is no secondary market. Redemption is the sole exit path, gated by KYC compliance and processed offchain with delay.

Risk Rating: Low‑Medium (3.5/10)
Owing to its bankruptcy‑remote structure, institutional‑grade custody, and transparent yield mechanics, OUSG is one of the lower‑risk tokenized RWA products. It loses points on composability, global access, and indirect holder protections, functioning as a permissioned digitized fund rather than a permissionless onchain asset: secure and transparent, yet siloed.

Conclusion

Tokenized RWAs blend traditional assets with onchain programmability, but beneath their compliant architectures lie varied and often underexplored risk exposures. This framework introduces a structured method to evaluate those risks across infrastructure, counterparty, yield, liquidity, access, and legal enforceability. To fully demonstrate its value, the framework should be applied across diverse RWA categories, such as tokenized equities, gold, real estate, or private credit where design constraints differ but core risk vectors persist. Long-term RWA growth will require not only attractive yields but rigorous, comparable, and transparent risk assessments.

References

• Tokensight's restaking risk methodology: https://paragraph.com/@tokensightxyz, https://u--1.com/avs/0x870679e138bcdf293b7ff14dd44b70fc97e12fc0

• AVS Risk Evaluation Report, Tokensight & P2P: https://hackmd.io/0JLYtkeLQg-Bt7vq3YHG0A?view

• The RWA Handbook (Part 1), Minerva: https://minervacrypto.substack.com/p/the-rwa-handbook-part-1?utm_source=activity_item

• Real-World Assets in Onchain Finance Report, RedStone, RWA.xyz & Gauntlet: https://blog.redstone.finance/2025/06/26/real-world-assets-in-onchain-finance-report/

• Beyond Basel: A New Capital-Risk Framework for Stablecoins, Circle: https://www.circle.com/blog/beyond-basel-a-new-capital-risk-framework-for-stablecoins

• Stablecoin Stability Assessment, S&P Global: https://www.spglobal.com/ratings/en/products/stablecoin-stability-assessment

• Stablecoin Infrastructure Wars, stablewatch: https://app.stablewatch.io/blog/stablecoin-chains?utm_source=tldrcrypto

• Stablecoins: Going Beyond the Basics, Minerva: https://minervacrypto.substack.com/p/stablecoins-going-beyond-the-basics

• Ondo Finance docs: https://docs.ondo.finance/

• Ondo Finance docs, OUSG subsections: https://docs.ondo.finance/qualified-access-products/ousg

• Ondo Finance's OUSG page: https://ondo.finance/ousg

• RWA.xyz's OUSG page: https://app.rwa.xyz/assets/OUSG

Learn More on Ondo Finance

Check Ondo Finance's website and Twitter.

Follow us on X and subscribe!

Index

1. Abstract

2. Protocol Workflow

3. Risk Scenarios

4. Cap Risk Profile

   1. AVS Risk Dimensions

   2. Credit-Based Cryptoeconomic Security

5. Stakeholder Interactions: Cap Across the Stack

6. Conclusion

Disclaimer:

The term “AVS” (Actively Validated Service) will be used here to refer to Cap as any protocol (AVS, Network, BSN, etc.) that leverages restaked collateral from restaking marketplaces to enforce its validation needs. The term "SSP" (Shared Security Protocols) will be used here to represent the restaking marketplaces (EigenLayer, Symbiotic, Babylon, SatLayer, etc.) that aggregate this demand and supply security and validation to AVSs.

Abstract

The Covered Agent Protocol (CAP) is an AVS protocol that extends restaking to credit-backed stablecoin issuance, replacing traditional infra and consensus validation risks with credit, market, and counterparty exposure. It issues two assets: cUSD, a fully redeemable dollar-pegged stablecoin backed by a reserve of blue-chip stablecoins; and stcUSD, a yield-bearing savings instrument created by staking cUSD. Accredited financial institutions (Operators) borrow these stablecoins against restaker-pledged collateral and deploy them in pre-approved DeFi strategies.

Restakers earn a fixed rate negotiated with operators, while stcUSD holders earn a variable, stable-denominated fee. Operators retain any surplus yield after repayment as compensation for strategy execution. The protocol is underpinned by deterministic slashing and legal enforceability: repayment defaults or collateral-health breaches trigger automated liquidation and redistribution of collateral to the reserve, with legal recourse ensuring restakers are covered, thereby preserving cUSD’s peg integrity.

This risk report evaluates Cap’s risk profile, covering its architecture, dependencies, and enforcement mechanisms. It analyzes capital efficiency, liquidity constraints, and incentive alignment between restakers and operators, and examines how credit and market events can propagate through the protocol. We also model its credit-backed cryptoeconomic security framework and detail the system-level interactions between Cap and its key stakeholders.

Protocol Workflow

Cap’s slashing-secured lending architecture enables restakers to act as underwriters for stablecoin loans issued to whitelisted regulated financial institutions, such as banks, market makers, HFT firms, or private equity funds. Unlike traditional DeFi lending markets where borrowers post their own collateral, Cap inverts the model: restakers pledge collateral, allowing whitelisted operators to borrow directly from Cap’s reserve pool of whitelisted stablecoins. In return, restakers earn a fixed restaking fee, while the protocol enforces safety through liquidation thresholds and slashing mechanisms, through restaking marketplaces, tied to objective health metrics.

Each loan is structured as an overcollateralized, one-to-one credit relationship between a restaker and an operator (agent), governed and enforced by off-chain legal agreements, and its repayment directly accrues to the stcUSD yield stream. These agreements define collateral amounts, loan duration, restaking fee (interest), maximum borrow limits, among other relevant terms. Cap overlays this relationship with purely on-chain enforcement logic—setting protocol-wide liquidation thresholds (akin to Aave), and configuring borrow interest rates based on a base rate plus a utilization-based spread. These borrow rates directly translate into the stablecoin yield paid to stcUSD holders.

Restakers not only accept slashing risk, but also assume responsibility for counterparty evaluation, ongoing monitoring, and agreement enforcement. The result is a high-agency, high-responsibility model that ties yield more explicitly to trust and underwriting performance than in passive AVS architectures.

The workflow can be divided into the following stages:

Standard Workflow

• User mints cUSD: A user deposits ~$1 worth of a trusted, Cap-whitelisted stablecoin (e.g., USDC, USDT) into Cap’s reserve vault, receiving 1 cUSD in return—a fungible token redeemable against the pool.

• User stakes cUSD to earn yield: Users stake cUSD into the stcUSD contract, receiving transferable and fungible stcUSD that accrues protocol fees over time and is redeemable only by the original depositor.

• Restaker delegates stake to operator: A restaker selects a specific operator and delegates restaked collateral (via Symbiotic or EigenLayer), creating a dedicated credit line that can be borrowed against up to a restaker-defined maximum.

• Off-chain credit agreement signed: The restaker and operator execute a bilateral legal agreement defining loan terms, restaking fee, max borrow amount, and repayment obligations.

• Operator borrows stablecoin from reserve: Once delegation is active and the agreement confirmed, the operator borrows stablecoins from Cap’s reserve and deploys them in yield strategies. Cap sets the borrow interest rate, which compounds over time and contributes to stcUSD yield.

 Happy Path: Operator Repays Loan

• Yield strategy executed successfully: The operator earns yield using borrowed capital (e.g., through arbitrage, basis trades, or credit strategies) and prepares for repayment.

• Operator repays loan + interest + restaking fee: At maturity, the operator returns the borrowed stablecoin to the reserve, pays interest to the protocol (which accrues to stcUSD holders), and the restaking fee to the underwriting restaker.

• Fees distributed to restakers: Restaking fees accrue and can be claimed periodically by the restaker or upon loan completion, paid in the same asset as the borrowed principal.

• Reserve fully replenished: Loan repayment refills the reserve in full (similarly to Aave USDC deposit pools). stcUSD remains redeemable for cUSD at any time, subject to any queueing mechanics.

• Operator retains excess yield: Any surplus yield (after covering borrow interest and restaker fees) remaining after repayment is kept by the operator as compensation for strategy execution and risk-taking.

Unhappy Path: Operator Defaults & Gets Slashed

• Health factor falls below threshold: Loan safety deteriorates due to collateral value drop, strategy underperformance, or missed repayments.

• Grace period initiated: A short window allows the operator to repay the full loan or the restaker to increase delegation to restore solvency. If neither act, liquidation proceeds.

• Liquidation event triggered: Cap initiates a Dutch auction mechanism to alleviate the operator’s debt, where liquidators cover the debt using the restaker’s slashed funds.

• Slashing executed: The slashed funds are sold to liquidators at a discount, serving as the liquidation bonus incentive (which is larger for faster bids).

• Funds redistributed to reserve: The stablecoin provided by liquidators is routed back into Cap’s reserve pool, ensuring full coverage of the restaker’s debt and protecting stcUSD holders from losses.

• Redistribution to restaker, operator offboarded: The restaker receives their funds directly from the respective operator, by enforcing their legal agreement. The operator is removed from eligibility, and the restaker reassesses future delegations.

The dual-path ensures that operators remain accountable for the capital they deploy while enabling restakers to earn yield tied to real-world counterparty risk. Cap’s workflow is inspired by protocol parameters from Aave-style lending practices (e.g., health factors, liquidation thresholds, etc.) but introduces a novel trust-based underwriting marketplace—where productive delegation replaces passive validation, and risk is tightly scoped to bilateral agreements.

Risk Scenarios

Cap shifts restakers from passive security providers to active credit underwriters, with delegated stake directly exposed to operator-specific credit, execution, and liquidation outcomes. This transforms slashing from a probabilistic penalty on missed validator duties into a deterministic, principal-sized loss tied to loan performance.

Two objective health-factor breaches trigger enforcement:

1. Collateral value falling below protocol thresholds;

2. Failure to meet repayment obligations.

Both lead to Dutch auction liquidations to restore solvency. These are exogenous, credit-driven triggers, moving the risk scope away from cryptographic correctness and into market volatility, counterparty solvency, and credit execution.

Cap operates within a layered dependency stack: execution and liveness layer (Ethereum), restaking middleware (EigenLayer, Symbiotic), oracles (Chainlink), bridges (LayerZero), and DeFi settings (e.g credit health and collateral liquidity). Its risk surface extends beyond the direct restaker–operator relationship. Failures in any upstream component can impair liquidations, liveness, or collateral recovery. In parallel, correlated strategy choices or market-wide liquidity shocks can trigger multiple operator defaults at once, amplifying the slashing impact across the system.

Credit & Duration Risks

• High Slashable Ceiling
  Cap differs from most AVSs in that slashing is fully deterministic and can extend up to the operator’s full outstanding debt at default. Instead of a partial slashing, the result can be an immediate loss of a large portion, or even all, of the delegated stake, depending on the credit shortfall. From a VaR perspective, this produces a nontrivial tail-loss profile where allocation size directly determines loss severity. Because slashing is triggered by repayment failure rather than on-chain misconduct, common containment mechanisms in validator-based AVSs offer limited protection. Effective mitigation relies on a different set of parameters: prudent liquidation thresholds, exposure limits, and diversification across uncorrelated credit lines.

• Liquidation-Linked Slashing
  Every operator position is continuously monitored via its health factor (debt-to-collateral ratio). Breaches trigger a short grace period, followed by collateral liquidation and, if undercollateralized, slashing of the delegated stake. Because the trigger is mechanical, even brief drawdowns, liquidity gaps, or momentary execution failures can crystallize losses for restakers. This coupling of slashing to liquidation mechanics creates a tight feedback loop between market volatility and credit enforcement, where adverse price action or auction underperformance can convert unrealized risk into permanent capital loss.

• Restaked Capital Lock-In Risk
  Delegated collateral is contractually locked for the loan term plus any withdrawal latency, creating a fixed illiquidity period that cannot be shortened without forfeiting fees. This structural constraint limits restaker flexibility to reprice risk, reallocate to safer operators, or respond to macro shocks until the position reaches maturity.

DeFi Market Risks

• Covariance Risk in DeFi Strategies
  While designed for per-operator isolation, risk can synchronize if multiple operators crowd into the same high-risk venues or strategies (e.g., a failing bridge, overleveraged derivatives pool, thin-liquidity MEV arb). Such event would produce narrowly-correlated slashing at the DeFi—not restaking—layer, where multiple defaults emerge from a single market shock. Mimetic strategy adoption, where operators chase short-lived high yields, only amplifies this effect.

• Stablecoins Depeg Risk (incl. cUSD)
  While loans are issued in trusted stablecoins, the system remains exposed to depeg events. Loans in USDC or USDT inherit the redemption, liquidity, and solvency risks of those assets. A severe or prolonged depeg during liquidations could depress auction proceeds, impair reserve recapitalization, and trigger redemption delays. If cUSD itself trades at a discount—whether from bridge failures, liquidity drains, or loss of confidence—the impact compounds, potentially stressing both restaker recoveries and stablecoin holder redemptions.

• Liquidity Risk
  Even after a position unlocks, practical access to funds can be delayed by market and infrastructure factors. Liquidation-related auction mechanics, collateral market depth, and dependencies on upstream systems (e.g., SSP withdrawal epochs) can slow payout or capital rotation. These constraints are situational and variable, requiring real-time liquidity risk models.

• Price Volatility Risk
  ETH or LST collateral drawdowns can trigger liquidations and slashing purely from adverse price action, without any operator misconduct, closely mirroring CDP dynamics. Rapid market swings—especially in thin LST liquidity conditions—can exacerbate undercollateralization risk, forcing fire-sale auctions that crystallize losses for restakers.

Protocol Operational Risks

• Slashing Execution Risk
  Cap’s slashing is executed on Ethereum through EigenLayer or Symbiotic, which route restaker delegations and trigger enforcement when an operator defaults, while collateral liquidations are handled internally via Cap’s auction system. Both systems provide deterministic execution, transparent governance hooks, and strong settlement guarantees, supporting reliable fault enforcement. It is critical to closely assess the slashing process efficacy of SSPs like EigenLayer and Symbiotic—our own research Restaking Protocols Infra Risk Framework V2 offers a structured basis for such evaluation. However, failure or delays in auction execution, withdrawals, oracle communication, or stake redistribution could impair enforcement, leaving restakers temporarily or permanently undercompensated.

• Active Risk Monitoring Requirements
  Cap’s design assumes restakers (or LRT vault managers) will actively monitor operator credit health, tracking LTV ratios, yield performance, repayment discipline, and macro risk factors. This represents a material shift from pooled-validator models where monitoring is collective and risk is diffuse; in Cap, inattentive oversight can allow deterioration to cross liquidation thresholds before corrective action is possible.

• Parameter Governance Uncertainty
  Key enforcement variables, such as liquidation bonus percentage, grace period duration, and liquidation window length, are not yet fully specified by the protocol. Future governance changes to these parameters could materially change risk dynamics, affecting both operator incentives and restaker protections.

• Loan Repayment Volatility
  Operators may repay early to redeploy capital to higher-yield opportunities elsewhere, ending restaker yield flows abruptly. While capital is returned, fee predictability is reduced, and frequent turnover can impair reinvestment timing, expose idle capital, and erode restaker APY targets.

• Opaque Whitelisting
  Without transparent criteria for operator onboarding, low-quality or high-risk actors could be admitted, concentrating credit exposure and weakening underwriting discipline. While the risk is mitigated by the institutional DeFi background of Cap’s core team, which increases the likelihood of prudent operator selection, it remains essential to formalize and disclose onboarding standards to maintain market confidence.

• Restaker & Operator Concentration
  If a small number of restakers underwrite most operator credit lines, correlated defaults or strategic exits (e.g., after slashing losses) can sharply reduce available delegations. Similarly, if loan origination is concentrated among a few operators, underperformance or defaults by them could significantly impair revenue flow and borrower diversity. Both forms of concentration can indirectly constrain protocol activity even without direct reserve losses, amplifying systemic fragility during stressed markets.

• Hurdle Rate Calibration
  Cap requires operators to exceed a minimum hurdle rate to retain yield. Poor calibration risks two extremes: pushing operators into unsustainable yield strategies or tolerating chronic underperformance. Rates should adjust dynamically based on operator history, strategy risk profile, and overall portfolio mix to balance competitiveness with sustainable credit underwriting.

• Redemption & Reserve Drain
  Cap enforces a 90% maximum utilization of its reserve, similar to Aave’s liquidity constraints, to preserve healthy and immediate redemption capacity. If utilization approaches 100% (e.g. through clustered operator defaults or debt value increases) forced liquidations are triggered to restore reserve liquidity health. Persistent high utilization or thin liquidator participation could still impair redemptions, introduce queues, and, in severe cases, erode market confidence in cUSD and extend payout cycles for stcUSD holders.

• Oracle and Bridge Risks
  Cap relies on Chainlink oracles for external pricing and AaveAdapter rates. While considered robust, oracle liveness, data latency, and manipulation resistance remain important vectors to monitor. If cUSD is bridged to other chains, users face third-party bridge risks, including smart contract exploits, validator collusion, or liquidity shortages on the destination chain. Bridge failures or oracle anomalies during liquidations could impair pricing accuracy, delay auctions, or introduce losses to both restakers and stablecoin holders.

• Operator Insolvency
  While direct insolvency of whitelisted agents is considered improbable given their institutional profiles, it cannot be ruled out. Defaults by highly-reputable operators could have outsized reputational and liquidity effects. Operator diversity, reputation-weighted delegation models, and optional default insurance should be actively explored to reduce tail dependencies and prevent systemic fallout.

• Principal-Agent Alignment
  Legal agreements between restakers and operators significantly mitigate but do not eliminate incentive drift. Misalignment can arise if operators overreach for yield in pursuit of higher returns or if restakers underprice credit risk to secure allocations. Enforcement quality is jurisdiction-dependent and hinges on contract strength, legal recourse efficiency, and the operational will to pursue claims.

Cap’s architecture opens high-yield opportunities for restakers but also concentrates non-trivial credit, operational, and structural risks that diverge from traditional AVS profiles. Sustaining performance in this model demands institutional-grade due diligence, continuous real-time monitoring, adaptive hurdle rate governance, and liquidity/risk modeling frameworks that integrate both credit and DeFi-specific tail risks.

Cap Risk Profile

To accurately assess Cap’s risk profile and calibrate appropriate security thresholds, we parse the protocol’s design into key execution, security, and reputation vectors, then apply a credit-based target stake model.

AVS Risk Profile Dimensions

Execution Architecture

→ Evaluates whether the protocol reliably enforces intended outcomes via its operational layer — in Cap’s case, whether liquidation logic, credit terms, and restaker protections are mechanistically executed through DeFi primitives.

Cap’s model replaces validator consensus with objective enforcement of bilateral credit agreements. Operator behavior is bounded by fixed KPIs—timely repayment and LTV maintenance—enforced through automated liquidation triggers and deterministic slashing. Execution integrity depends on precise parameterization and the reliability of price oracles and health factor calculations; failures here propagate directly to reserve solvency and restaker losses.

Consensus Design

→ Assesses how state agreement and enforcement guarantees are established. For AVSs without internal consensus, this captures the sufficiency of external networks and deterministic logic in replacing native fault-tolerant coordination.

Cap has no internal consensus. State enforcement is handled by deterministic slashing and liquidation logic, with liveness and security inherited from its securing networks: EigenLayer, Symbiotic, Ethereum, and MegaETH. This shifts execution risk outward: disruptions or failures in these networks could stall or block enforcement during operator defaults.

Slashing Conditions

→ Measures how clearly slashing is defined, how deterministically it is triggered, and whether it protects restakers proportionally.

Cap defines slashing deterministically: repayment failure or a breached collateral NAV health factor automatically triggers penalties. Attribution is objective, and slashing may be absolute, as the delegated amount can be fully liquidated, which raises fault severity and incentivizes conservative vault design. The structure aligns Cap with Type III “self-enforcing” stablecoins, where enforcement and yield-generation are embedded in protocol logic rather than dependent on governance discretion.

Security Audits & Codebase Complexity

→ Captures the security audit status, transparency, and structural complexity of the codebase.

Cap has announced five completed audits, and its codebase has been made publicly available. The architecture falls in the medium-to-high complexity range: a moderate number of contracts with clear separation of concerns (vault, reserve, delegation, rate models, liquidation). The interactions between modules are non-trivial due to on-chain/off-chain dependencies, auction mechanics, and dynamic rate logic, yet the structure remains cohesive and avoids deep inheritance or excessive dependency chains. Integration points with Symbiotic/EigenLayer and external yield sources add operational complexity.

Maturity & Reputation

→ Surfaces long-term execution risk by gauging operational history, governance quality, and the founding team’s track record.

Even though it is early-stage, Cap is led by reputed builders with prior DeFi and stablecoin experience at Beefy Finance, Frax, and QiDAO. While the architecture is sound in principle and reputation benefits from the team’s track record, operational resilience and liquidation mechanics remain untested under scale or stress.

For a deeper, more technical read on AVS risk, refer to our research paper written in collaboration with P2P.org.

Credit-Based Cryptoeconomic Security

In security terms, Cap’s design also distances from traditional AVSs: operators do not commit bonded stake to a validator set, but instead secure restaker delegations and borrow capital against which they generate yield. The new paradigm shifts our original Target Stake concept from a validator-level stake threshold to a DeFi-native security bound. The delegated loan principal can be liquidated and slashed in full at any time, instantly collapsing the operator’s open positions and erasing any meaningful yield retention.

Target Stake represents the amount of stake (or collateral) required by an AVS to make corruption economically irrational (cost > profit) and operate securely.

Learn more here.

Cap is a natively exogenous AVS, in that operators operate purely within DeFi by earning yield entirely outside the protocol through strategies, and security depends solely on repayment of borrowed stablecoins.

Profit-from-Corruption (PfC)

In this structure, PfC is not generated by endogenous manipulation (e.g. MEV, token minting through bug exploits, consensus faults) but by exogenous credit risk—the potential misappropriation or loss of delegated collateral via corruption.

For an operator $$O$$:

$$ \text{PfC}_O = D_O(t) $$

Where:

• $$\text{PfC}_O$$: Maximum profit attainable from corrupting

• $$D_O(t)$$: Delegated collateral at time $$t$$

The $$ \text{PfC}_O$$ metric is bounded by the maximum delegation an operator controls at any point in time. In Cap, liquidation to recover the principal unwinds the operator’s positions, so the generated yield evaporates, preventing undue seizure.

Cost-of-Corruption (CoC)

The CoC is the total economic position forfeited upon default:

$$ \text{CoC}_O = D_O(t) + Q $$

Where:

• $$D_O(t)$$: Delegated collateral at time $$t$$

• $$Q$$: Qualitative deterrents — credit-risk profile of restakers, reputational cost, legal liabilities, and opportunity cost (lost future income)

Both PfC and CoC share $$D_O(t)$$, which is sufficient to deter an attack; the additional deterrents $$Q$$ represents only reinforce the gap, making $$CoC > PfC$$ unquestionable.

Anchoring $$Q$$ in Credit-Risk Data

Institutional borrowers maintain records with default probabilities and credit spreads from sources such as FRED and S&P. Cap uses these to set baseline delegation pricing, aligning operator borrowing costs with market underwriting standards. Restaker risk appetite directly shapes $$Q$$ by adjusting delegation size, fee demands, and exposure preferences: Cautious restakers may limit allocations, demand higher fees from lower-rated operators, or avoid correlated exposures entirely—reducing the size of profitable defaults while raising the cost of capital for riskier borrowers.

Monitoring how delegations diverge from credit-spread benchmarks provides insight into delegation health. Over-allocation to CCC-rated operators, concentration in a single tier, or preference for low return-per-unit-of-risk exposures all signal shifts in discipline.

Cap’s baseline framework for restaker allocations, derived from credit spreads and default probabilities:

Learn more here.

Note: We strongly advise conducting dedicated credit-risk evaluations from specialists to fully inform underwriting decisions and ensure thorough due diligence before committing any stake to Cap.

These considerations allows $$Q$$ to capture not only static deterrents like reputational or legal liabilities, but also the dynamic enforcement applied by restakers in response to fast-pacing credit conditions.

Security Condition

Credit-based cryptoeconomic security against intentional default requires:

$$ \text{CoC}_O > \text{PfC}_O $$

Cap’s system ensures this inequality holds. Cryptoeconomic security is anchored at the DeFi credit-allocation layer rather than the validator-bonding restaking layer. Such distinction, coupled with the protocol’s ability to liquidate the entire delegated loan principal instantly, collapses any open positions and erases potential profit extraction. The result is a design that is inherently resistant to corruption-driven attacks by eliminating the feasibility of retaining gains from malicious behavior, and not by increasing “Target Stake” requirements.

Stakeholder Interactions: Cap Across the Stack

This section maps Cap’s integration points across the DeFi and restaking stacks: SSPs, Restakers/LRTs, and Operators, focusing on capital flows, incentive design, and risk propagation. Cap’s robust use of off-chain legal enforcements, deterministic on-chain slashing, and delegated-collateral underwriting alters conventional assumptions about AVS risk delegation and alignment.

Cap <> SSP

Cap → SSP

Cap leverages EigenLayer and Symbiotic not only for capital provisioning but as slashing enforcement backbones. SSPs route restaker delegations, execute deterministic on-chain slashing on Ethereum upon a Cap operator default, and, in a slashing event, redistribute proceeds to Cap’s reserve and restakers, preserving cUSD peg integrity. Prior to redistribution, Cap’s own contracts execute in-protocol Dutch auctions of liquidated collateral.

SSP selection by Cap should weigh collateral health, slashing determinism, latency, and observability, alongside withdrawal-epoch flexibility that supports restaker liquidity needs. SSP integrations should prioritize modularity, so that stake sourcing, governance exposure, and slashing semantics remain separated and customizable by Cap.

For in-depth due diligence on SSPs slashing execution mechanisms, refer to the Slashing Process Efficacy metric on our Restaking Protocols Infra Risk Framework V2 report

SSP → Cap

By integrating Cap, SSPs convert idle restaked assets into credit-backed collateral, unlocking yield potential and improving stake productivity while increasing TVL stickiness. The trade-off being duration-locked delegations (loan term plus any SSP withdrawal latency) which can add liquidity stress.

SSPs must monitor delegation concentration, withdrawal queue congestion, and slashing throughput to ensure that Cap-linked collateral sourcing does not impair network-level liquidity guarantees. Importantly, restaked capital supporting Cap loans is never idle on aggregate: when loan proceeds are held in reserve rather than deployed in DeFi strategies, Cap can route associated stablecoin liquidity into fractional reserve strategies, enabling yield capture while preserving redeployment optionality for restakers.

Cap <> Operator

Cap → Operator

Cap’s whitelisting process should prioritize operator reputation, robust financial records (including PnL transparency), and proven on-chain liquidity management. Slashing is triggered by repayment failure or collateral value breaches below safety thresholds, making collateral volatility a first-order risk parameter.

Cap should calibrate hurdle rates conservatively, track loan repayment volatility, and monitor insolvency indicators such as NAV-to-loan deterioration, liquidity coverage shortfalls, and correlated drawdowns across operator strategies. Delegation caps and a diversified operator base help curb centralization and systemic risk.

Operator → Cap

With Cap, Operators access a zero-cost-basis credit line, effectively amplifying leverage beyond their own equity and retaining any surplus yield after hurdle rate and restaker fees. This structure can significantly enhance returns, but also magnifies tail risk when strategy margins are thin or collateral prices volatile. Borrowing capacity hinges on active restaker delegations, with Cap applying a grace period for replacing withdrawn delegations mid-loan to avoid forced unwinds.

Operators must meet hurdle rates and restaker fees, actively manage mark-to-market exposures, and maintain liquidity buffers. While surplus yield after obligations can incentivize performance, poorly set hurdles risk driving excessive leverage. Operators should internalize Cap’s systemic risk profile as an AVS and protocol (including slashing propagation scenarios) and avoid clustering in the same high-yield strategies as their peers.

Cap <> Restaker/LRT

Cap → Restaker/LRT

Cap must make onboarding seamless yet protective, providing comprehensive legal templates that embed restaker safeguards, collateral rights, operator recourse provisions, and redemption and service-level guarantees. These agreements should be comprehensive and extensible, giving restakers a standardized but customizable foundation for risk control. Cap should also actively advise restakers on monitoring requirements, including concrete metrics for operator health, collateral liquidity, and slashing exposure, so that oversight is continuous, not reactive.

Cap must remain conscious of restaker concentration levels and communicate the slashing covariance risk inherent in correlated DeFi strategies (covered above in Covariance Risk in DeFi Strategies), reinforcing the need for operator diversification and mitigation of principal–agent misalignments. Restakers should be explicitly warned of capital lock-in through the combined loan term and withdrawal latency, as well as the full-loan slashing risk, including liquidations triggered by declines in restaked collateral value. A severe credit event can wipe principal entirely, making it imperative for LRTs to underwrite operator performance rigorously, maintain liquidity buffers, and size Cap allocations conservatively to protect vault stability.

Attracting and retaining a diversified base of restakers is the core engine of Cap’s recurring-yield flywheel and the foundation for sustaining durable, scalable returns.

Restaker/LRT → Cap

Restakers and LRTs, including Swell, Ether.fi, and Renzo, gain diversified yield streams and exposure to non-infra AVS risk, improving portfolio balance. However, potential full-loan slashing means they must independently monitor Cap’s redemption reserves (that honor withdrawals), price-volatility exposure, cUSD peg integrity, and assess Cap’s choices on operator whitelisting, oracles, and bridges—especially in cross-chain contexts.

Position sizing should be counseled and stress-tested against adverse credit and market scenarios to safeguard vault or operator solvency. Even when not deployed into active DeFi strategies, capital custodied in Cap’s reserves can be routed into fractional reserve lending, allowing idle stablecoins to earn yield while remaining immediately available for withdrawal or DeFi reallocation—an added layer of capital productivity.

Restaker/LRT <> Operator

Restaker/LRT → Operator

Delegated capital in Cap functions as underwritten credit, not passive stake. Any principal–agent issue is essentially mitigated through robust bilateral legal agreements that formalize loan terms, recourse provisions, borrowing limits, and redemption rights. Restakers/LRTs should conduct thorough vetting and diversify operator exposure to reduce correlated loss potential.

Operator → Restaker/LRT

Operators must recognize that defaults, underperformance, or slashing events can impact multiple restakers and LRTs simultaneously. Strategy concentration risk escalates when operators converge on similar high-yield trades, creating dangerous covariance clusters. To mitigate, operators should diversify across instruments, maturities, and markets to limit both single-point and correlated failure modes.

Succinctly, the durability of the system depends on disciplined underwriting, vigilant monitoring, and deliberate diversification at every link in the chain. When one participant underestimates these dynamics, the impact can cascade across the entire stack.

Conclusion

Cap shifts the foundation of AVS design from on-chain validation to securing credit agreements. Its model blends on-chain liquidation rules with market-based credit pricing, binding restakers, institutional operators, and stablecoin users in a single system of incentives and enforcement. The appeal is straightforward: high capital efficiency and stable yields delivered through programmable, verifiable guarantees. The risk is equally objective: exposure to credit defaults, liquidity stresses, and operator underperformance.

The system’s durability rests on cUSD demand, credit discipline, and delegation diversification. Restakers must calibrate delegation to operator creditworthiness, operators must manage strategies within risk thresholds, and the protocol must enforce parameters that ensure demand and prevent concentrated exposures.

Cap’s robust, innovative design as a restaking-backed credit protocol positions it as a strong candidate for a yield-bearing stablecoin system with scalable adoption potential.

Learn More on Cap

Check Cap's website and Twitter.

Follow us on X and subscribe!

Index

1. Abstract

2. The Problem of Cascaded Slashing

3. Cascading Modes

4. Restaking Equilibrium

5. Modelling Cascades

Abstract

This research investigates how slashing events in restaked ecosystems can propagate across networks due to shared validator sets, shared LRT portfolios, and overlapping slashing conditions. It introduces a framework for quantifying slashing overlap risk and modeling the amplification and conditional propagation of slashing across networks. The analysis formalizes how correlated validator faults, misaligned delegation strategies, and supermodular attacker incentives can trigger cascading penalties that extend beyond the original fault domain. It also considers how collateral health and LRT portfolio composition influences validator overlap and amplifies cross-network slashing exposure. The framework aims to guide more resilient network design, operator diversification, and risk-aware delegation strategies in restaking-based networks.

The Problem of Cascaded Slashing

Restaking reuses operator stake across multiple networks, improving capital efficiency but also entangling risk. When LRTs or operators serve overlapping networks, a single slashing event can propagate beyond its origin through “contagious” collateral, shared infrastructure, or slashing semantics.

Some cascades remain localized, contained within slash-isolated vaults or delegation boundaries. Others become correlated, spreading systemically through covariant validator sets, portfolios, or dependencies. Furthermore, as stake reuse deepens, so does the covariance potential across participants, raising the probability that a localized fault escalates into a system-wide cascade.

Cascading Modes

Restaking architectures vary in how they contain or propagate slashing risk. Inspired by the modularity of the Rainbow Staking concept, designs can be broadly classified by their fault containment properties: whether slashing propagates locally or systemically.

Localized Slashing

In slash-isolated models, each vault is explicitly partitioned to be slashable by individual networks. As a result, faults remain bounded, such that a validator slashed on one network does not automatically trigger slashes to covariant networks and operators.

Yet, even under localized cascades, second-order effects can emerge:

• Collateral contagion: Slashed LRTs used as collateral in lending markets can cause mass liquidations through a decline in NAV, especially in high-LTV or thin-liquidity environments;

• Multi-network operator overlap: A single operator slashed across multiple networks simultaneously (e.g. through a downtime incident) triggers multi-network stake drawdown;

• Shared infrastructure faults: A shared infrastructure failure or corruption in common RPC endpoints, signing keys, or oracle dependencies can lead to simultaneous localized slashes.

Correlated Slashing

Correlated slashing refers to scenarios where a single validator fault propagates across multiple networks and portfolios due to interdependent stake reuse. Unlike localized slashing — where shared infrastructure may lead to concurrent but contained penalties — correlated slashing arises from a lack of stake isolation, enabling systemic propagation.

At the core is covariance across participants: when networks, validators, or LRTs share validator sets, slashing semantics, infrastructure, or collateral sources, one fault can cascade through all dependent systems. In these architectures, the entire Operator–Network vault is slashable (not just a dedicated portion), removing containment boundaries and heightening contagion risk.

Covariant propagation channels include:

• Network A slashed → shared across LRTs X/Z and Operators T/U

• LRTs X/Z and Operators T/U service Networks B and C

• Slash propagates into Networks B/C, compounding system-wide cascading

The deeper the interdependence, the higher and more durable the slashing severity —extending further into the same second-order effects observed in localized slashing, such as collateral contagion in DeFi, multi-network operator drawdown, and shared infrastructure faults. Each participant’s exposure depends on portfolio overlap, validator reuse, and the strength of emergency containment mechanisms.

Correlated slashing can be further bifurcated into supermodular and submodular attack regimes. In supermodular cases, the attacker’s payoff increases with each additional affected network, as similar infrastructure and slashing conditions or shared validator sets and collateral sources reduce the cost and complexity of executing multi-network attacks. In submodular regimes, the marginal gain from attacking multiple networks decreases as containment strategies enforce differentiation across slashing logic, infrastructure, and stake. Designing for submodularity is essential to suppress attacker incentives and contain systemic fragility.

Restaking Equilibrium

To help assess the nature of a potential slashing event, we introduce a restaking ratio, which measures how much active stake is reused across networks relative to the underlying vault or restaking protocol TVL.

$$ \text{Restaking Ratio} = \frac{\text{Total Active Stake Delegated}}{\text{TVL}} $$

If network A sources 100% of TVL, network B 50%, and network C 70%, the total stake sourced equals 220%, meaning each unit of collateral is reused 2.2 times across the network portfolio.

Higher restaking ratios improve capital efficiency but increase exposure to correlated slashing. Vaults/protocols exceeding a balanced range (e.g., ratio = 2.5–3.5) are penalized with lower restaking scores, reflecting elevated systemic risk.

Effective curation depends on evaluating three dimensions: network risk profiles, collateral quality, and target stake sizing. These metrics help networks determine how much TVL to source, preventing overcommitment that exceeds restaking ratio thresholds and introducing unnecessary systemic risk.

To carefully evaluate each metric refer to:

• Restaking Network Risk Evaluation: Developing a Fundamental Approach for network risk profiling;

• LRT Slashing Risk’s “Restaked Collateral Quality” metric for collateral health evaluation;

• Modeling Target Stake Requirements for assessing appropriate target stakes per network.

Modelling Cascades

To quantify how slashing exposure escalates under shared conditions, let’s define the amplified risk function:

$$R'_{\text{Network} \ A} = R_{\text{Network} \ A} \cdot e^{\mathcal{S} \cdot \Lambda_{t}}$$

Where:

• $$R_{\text{Network} \ A}$$ is the baseline risk profile score for Network A;

• $$e^{\mathcal{S} \cdot \Lambda_{t}}$$ is an exponential expression using the Nepper coefficient $$e$$, which models how baseline risk scales under compounding and continuous exposure:

  • $$\mathcal{S}$$ represents the sensitivity coefficient, capturing exposure to covariance, collateral quality, and operator risk;

    → Lower values suggest localized containment and reduced correlation risk; higher values indicate systemic fragility from greater overlapping exposure

  • $$\Lambda_{t}$$ designates the temporal propagation amplifier;

    → Lower values indicate rapid containment, as in localized cascades; higher values reflect prolonged propagation typical in correlated cascades

• $$R'_{\text{Network} \ A}$$  is the amplified risk score result, which reflects correlated propagation effects for Network A.

The expression showcases how slashing risk escalates with overlapping exposure and time-sensitive propagation. Jumping to some practical examples:

Network A is the safest and Network D the riskiest, both in isolation and in correlation-adjusted terms. Network B shows how moderate baseline risk, when paired with high sensitivity and temporal amplification, can produce a higher systemic risk than a higher baseline score with better containment. Despite scoring lower than Network C in baseline terms (4 vs. 6), Network B’s amplified risk (8.552) exceeds that of Network C (6.765) due to stronger covariance and propagation coefficients. This highlights that baseline risk alone is insufficient and true risk is shaped by how correlated, sensitive, and time-exposed a network is.

Networks A and C exhibit profiles typical of localized slashing, where contagion is limited. Networks B and C, by contrast, reflect contexts of correlated slashing, where covariance amplifies slashing impact.

Let’s now define conditional risk propagation as:

$$\mathbb{E}\left[ \mathbb{S}_{\text{Network} \ B} \mid \mathbb{S}_{\text{Network} \ A} \right], \quad \mathbb{S}_{\text{Network} \ A} \sim R'_{\text{Network} \ A}$$

The expression captures the expected slashing impact on Network B given the covariant Network A has been slashed.

This formula captures second-order propagation, where correlations emerge from LRT and validators portfolios overlap, or entangled slashing conditions.

Curators and risk managers must minimize these correlations across portfolios to reduce the likelihood of conditional propagation. Achieving a low $$\mathbb{E}\left[ \mathbb{S}_{\text{Network} \ B} \right]$$ requires proactive containment design, including:

• Risk profiling participants;

• Cap restaking ratios per vault;

• Collateral diversification buffers;

• Clustering validator sets by exposure severity;

• Modeling and simulating potential propagation paths.

Follow us on X and subscribe!

We are thrilled to announce our partnership with Swell to provide in-depth AVS research and strategic allocation recommendations across restaking protocols!

Swell: Next-Generation Liquid Staking & Restaking Protocol

Swell is a non-custodial staking protocol on a mission to deliver the world’s best liquid staking and restaking experience, simplify access to DeFi, and help secure Ethereum and next-gen restaking services. Users can stake or restake ETH to earn both consensus and AVS rewards, receiving yield-bearing liquid tokens (LSTs or LRTs) that can be held or deployed across the broader DeFi ecosystem for additional yield.

Within restaking, Swell offers a growing suite of LRT-related vault products including rswETH, swBTC, and rSWELL, allowing users to restake ETH and WBTC across networks like EigenLayer, Symbiotic, and Karak. These vaults abstract complexity while optimizing yield and managing slashing risk through curated strategies. Swell’s seamless integration with leading restaking protocols positions it as a user-friendly gateway for maximizing restaked yield while supporting network security.

Strategic Partnership Motivation

AVS are protocols with deployed infrastructure on restaking protocols, like EigenLayer and Symbiotic, seeking shared security provided by a network of slashable Operators that validate tasks. Particularly with the introduction of Slashing, it becomes imperative for LRTs like Swell to understand and be advised on:

• Protocol-level understanding of AVS risk and reward profiles, to maintain security while boosting liquidity, TVL, and overall capital efficiency
  Based on prior research: https://hackmd.io/0JLYtkeLQg-Bt7vq3YHG0A?view

• Ways to minimize portfolio-level correlated slashing and other risks
  Based on prior research: https://paragraph.com/@tokensightxyz/lrt-slashing-risk

• Strategic allocation decisions through modeling and agentic simulations, within the context of different restaking protocols
  Based on prior research: https://paragraph.com/@tokensightxyz/restaking-protocols-infra-risk-framework-v2

Learn More

Learn more about Swell on their Website, Blog, and Twitter.

Stay tuned for new developments from our partnership with Swell!

Follow us on X and subscribe!

Index

1. Abstract

2. Catalysis Overview on SSNs: First Article Recap

   1. Aggregated Security Through Unified Abstraction

   2. Key Benefits to SSNs

   3. Reframing the SSN Security Stack

   4. Economic & Game-Theoretic Flows

3. SSN Cryptoeconomic Security

   1. The Four Types of Security Costs

   2. Reducing the Cost of Security Acquisition

   3. Raising the Cost of Corruption

4. Finding Equilibrium in SSP Allocations

   1. Modelling SSN-to-SSP Allocations Based on Perceived Utility, via QRE

   2. Calculating SSN-to-SSP Allocations Based Required Target Stake

   3. Additional Target Stake Considerations

5. Localized vs. Correlated SSN Slashing Modes

   1. Localized Slashing

   2. Correlated Slashing

   3. Modelling Localized & Correlated Slashing Modes

   4. Calculating Localized & Correlated Slashing Modes

6. Catalysis Rebalancing Feedback Engine

7. Conclusion

Note: The term “Shared Security Networks” will be used herein to represent the networks/services (AVSs, Networks, BSNs, etc.) that leverage restaked collateral to validate their infrastructure needs. And the term “Shared Security Protocols” will be used herein to represent the restaking marketplaces (EigenLayer, Symbiotic, Babylon, SatLayer, etc.) that aggregate this demand and supply security and validation to Shared Security Networks.

Abstract

Catalysis is the first Security Abstraction Layer that unlocks unified access to $20B+ of ETH, BTC & SOL economic security for institutions & developers to tap into. It introduces a modular and programmable coordination layer for Shared Security Networks (SSNs), enabling them to flexibly source, rebalance, and optimize economic security across multiple restaking ecosystems.

Rather than anchoring SSNs to a single protocol, Catalysis aggregates validator sets, standardizes slashing semantics, and surfaces utility signals to guide stake allocation based on risk and yield tradeoffs. This paper presents a stake allocation simulation illustrating how utility asymmetries and correlated exposures create systemic inefficiencies, and how Catalysis enables SSNs to converge toward allocation equilibrium across SSPs through real-time routing and dynamic feedback. It concludes by formalizing two core slashing modes—localized and correlated—and modeling how their containment or propagation depends on system architecture.

Catalysis Overview on SSNs: First Article Recap

Aggregated Security Through Unified Abstraction

Shared Security Networks (SSNs) such as Omni, Redstone, Cap, Ditto, and Hyperlane are progressively integrating with multiple Shared Security Protocols (SSPs)—including EigenLayer, Symbiotic, and SatLayer—to enhance their economic security base. This multi-platform restaking strategy adds distinct trust domains, increasing security robustness. However, it also introduces complexity: validator sets, slashing semantics, fault adjudication, and delegation infrastructure vary widely across SSPs.

Catalysis abstracts this fragmentation through a unified interface. Instead of integrating with each SSP individually, SSNs can source restaked security through a single validator set and programmable slashing layer. Such modular structure allows SSNs to retain uptime and security continuity, even when one or more SSPs experience validator degradation, slashing events, or yield volatility.

Key Benefits to SSNs

Catalysis introduces structural flexibility to SSN design and operations, allowing SSNs to function as modular market participants within a programmable security economy. It enables cross-platform validator coordination, customizable slashing semantics, and partial execution across SSPs—maximizing security configurability and fault isolation.

• Unified Integration & Validator Abstraction

  A single Catalyst SDK layer handles integration across all supported SSPs. Validator management is abstracted, enabling cross-SSP coordination while customizing slashing logic and failure domains—reducing launch time and complexity for new SSNs;

• Dynamic Stake & Risk-Aware Rebalancing

  Stake allocation adapts in real-time to operator performance, pricing, and slashing history. SSNs can proactively or reactively shift stake across SSPs to isolate faults, mitigate underperformance, and improve capital efficiency;

• Programmable Reward Distribution

  Rewards are routed directly across SSPs without cross-chain wrappers or bridges, minimizing slippage, simplifies flow logic, and reduces fragmentation by consolidating delegation, slashing, and payout mechanisms;

• Partial Execution & Custom Trust Models

  SSNs can selectively deploy logic across multiple SSPs, enabling hybrid trust models and fault-resilient execution. This facilitates experimentation with differentiated validator trust configurations;

• Market-Based SSP Selection

  Aggregated demand across SSNs pressures SSPs to compete on validator quality, uptime, slashing guarantees, and reward rates—aligning infrastructure incentives with AVS security needs;

• Developer Flexibility

  All security primitives are programmable via Catalysis, allowing developers to iterate on incentive structures and core business logic, automate strategy rebalancing, and integrate without bespoke infrastructure overhead.

Reframing the SSN Security Stack

As SSNs evaluate integration with Catalysis, three critical questions emerge—each of which the system explicitly addresses:

1. How much economic security is required?

   SSNs must consider potential corruption profit based on their set-up and how much cost (economic security) would be sufficient to deter an attack. Read more on the topic on our newly-released piece on Target Stake with Symbiotic.

   Catalysis reframes this question further with a deeper second-order one:

   Which sources of cryptoeconomic security (ETH from EigenLayer and Symbiotic, BTC from Babylon and SatLayer, BNB from Kernel, etc.) does an SSN need and wants align itself with?

2. What is the cost of acquiring and maintaining that security?

   Catalysis exposes a unified fee and reward benchmarking layer across SSPs, enabling SSNs to optimize for the lowest-cost, highest-resilience combinations. SSNs can minimize validator acquisition costs, streamline restaker onboarding, and amortize security costs across multiple use cases.

3. What fault conditions govern validator behavior?

   SSNs must specify what constitutes slashing-worthy behavior and how faults are processed. Catalysis makes this logic programmable—enabling fault adjudication and penalty enforcement across SSPs through one cohesive slashing engine. This ensures validator accountability is not lost in cross-platform complexity.

Economic and Game-Theoretic Flows

In essence, Catalysis creates a two-sided restaking marketplace: SSNs compete for reliable security, while SSPs and Operators compete for SSN onboarding.

Assuming the structural advantages introduced by Catalysis play out as expected, a broader set of SSNs would likely enter the system—driving up aggregate demand for restaked capital. This flywheel creates upward pressure on rewards for delegators (via LRTs or direct restakers), incentivizing greater participation and TVL growth. At the same time, increased SSN competition drives demand for high-performing validators, prompting operators to compete on uptime, reliability, and responsiveness.

From a cost-efficiency standpoint, Catalysis introduces a competitive restaking marketplace. SSNs can compare pricing across SSPs and allocate stake where security is cheapest and most stable. This drives downward pressure on security costs as SSPs compete for SSN onboarding and encourages them to improve internal economics and UX.

SSNs also gain more malleability to consider SSPs’ TVL stickiness—how durable and reactive each SSP’s capital base is under slashing, volatility, or adverse events. Those with more consistent capital retention will be perceived as more reliable security sources.

By concentrating demand and standardizing the security procurement process, Catalysis enhances the buying power of SSNs. SSPs are incentivized to compete not just on integration availability, but on economic efficiency, validator quality, and fault tolerance. In this way, Catalysis transforms restaking from a fragmented infrastructure layer into a coordinated, efficient security marketplace.

SSN Cryptoeconomic Security

The Four Types of Security Costs

SSNs incur four core categories of security-related expenses. Catalysis mitigates cost pressure across each through abstraction, routing optimization, and shared infrastructure:

1. Delegator Rewards: Continuous payouts to restakers and LRT holders who supply economic security.
   → Higher security demand requires elevated yields to attract stake, particularly in competitive environments where AVSs must signal safety.

2. Security Rental from SSPs: Although not fully standardized today, future SSPs may charge usage fees (e.g., Symbiotic 3%, EigenLayer 4.5%).
   → Catalysis enables price discovery and blended sourcing across protocols, minimizing net cost per unit of security.

3. Task Execution Fees: Validators are compensated for protocol-specific services.
   → Competitive validator markets lower long-run execution pricing, compressing recurring operating costs.

4. Protocol Development & Security Overhead: Tooling, audits, and DevOps are required to onboard and secure SSNs.
   → Catalysis reduces this burden via a unified SDK and standardized validator and slashing logic across SSPs.

Reducing the Cost of Security Acquisition

Catalysis reduces security acquisition costs by abstracting validator infrastructure, eliminating duplicative onboarding, and enabling price discovery and dynamic stake routing across SSPs.

• Unified Security Infrastructure: Validators are aggregated across SSPs, letting SSNs onboard once to access pooled security.
  → Reduces onboarding friction and improves validator reward saturation by consolidating demand.

• Dynamically-Optimized Stake Allocation: Stake flows to SSPs offering optimal tradeoffs between risk, yield, and validator quality.
  → Avoids degraded providers, lowers capital inefficiency, and better aligns with each SSN’s Target Stake.

• Reward Efficiency and Routing: Rewards are natively routed across SSPs without wrappers or bridges.
  → Cuts gas costs and slippage, simplifying integration logic.

• System-Level Cost Compression: Aggregated SSN demand creates buy-side bargaining power.
  → Improves validator pricing and amortizes fixed infra costs across a broader base.

• Feedback-Driven Delegation Logic: Stake rebalances dynamically in response to performance, slashing, or curator signals.
  → Stake reallocates in real-time, optimizing for current risk-reward landscapes.

• Validator Reuse Across SSNs: Validators serving multiple SSNs operate under shared infrastructure.
  → Avoids re-registration and stake fragmentation, unlocking capital efficiency and reducing idle capacity.

Raising the Cost of Corruption

Catalysis materially increases the Cost of Corruption (CoC) by aggregating security and aligning incentives across SSNs. Whereas traditional architectures enable isolated validator compromise, Catalysis enforces interdependency and accountability at scale.

• Aggregated Security Layer: Restaked capital from multiple SSPs is unified under a single slashing abstraction.
  → Tens of billions in economic security are pooled, making coordinated exploits prohibitively expensive.

• Differentiated Validator Sets Per SSP: Validators are coordinated via Catalysis but form distinct sets per SSP.
  → Attacks must breach multiple operator sets simultaneously, raising both complexity and cost of coordinated corruption.

• Higher Stake at Risk per Attack: Corruption attempts now expose more total stake per validator action.
  → Amplifies slashing losses, increasing the minimum profitable attack threshold.

• Reputational and Long-Term Opportunities: Well-behaved validators gain stronger reputation and opportunities across all integrated and upcoming SSNs.
  → Creates a more feedback-driven, transparent flywheel for operator selection.

• Cross-SSN Risk Propagation Awareness: Catalysis exposes correlation risks across SSNs via shared validator metadata.
  → Enables proactive delegation modeling, deterring systemic exploits by surfacing propagation vectors.

Finding Equilibrium in SSP Allocations

Restaking introduces uncertainty, partial observability, and multidimensional risk tradeoffs that invalidate key assumptions of standard game-theoretic models. In particular, traditional Nash Equilibrium assumes fully rational agents with complete information, selecting strategies that maximize utility deterministically. In restaking environments this model breaks down as participants operate under noisy incentive signals, hidden risks, incomplete slashing semantics, and evolving market conditions. Nash equilibrium also fails to account for coordination frictions, feedback loops, and multi-reward routing that shape actual SSN behavior.

By contrast, Quantal Response Equilibrium (QRE) models decision-making under bounded rationality. Agents do not always select the utility-maximizing action; instead, they assign probabilities to each action via a softmax function over perceived utility. This methodology captures realistic agent behavior: higher-utility SSPs are more likely to attract stake, but suboptimal ones may still receive allocations due to noise, misperception, or hedging. QRE accommodates stochastic dynamics, informational asymmetries, and incentive gradients—core features of restaking ecosystems.

In Catalysis, QRE offers a more robust equilibrium model. Stake does not flow deterministically to the highest-yield SSP. Instead, allocations diffuse across SSPs proportional to their slashing-adjusted utility. At equilibrium, each SSP attracts stake such that no SSN—given its subjective utility estimates and rationality bounds—has incentive to reallocate. The framework enables smoother rebalancing, reduces concentration risk, and aligns with real-world delegation behavior shaped by asymmetric risk-reward signals.

Modelling SSN-to-SSP Allocations Based on Perceived Utility, via QRE

This section models how SSNs allocate stake across SSPs using the QRE framework. It highlights how allocations evolve from noisy, misaligned states toward probabilistic equilibrium as SSNs refine their utility assessments.

At the core is the utility function:

$$\text{Utility}_{SSP_j}^{SSN_i} = \mathbb{E}[\text{Return}_{SSP_j}] - \mathbb{E}[\text{Cost}_{SSP_j}] - \mathbb{E}[\text{Risk}_{SSP_j}]$$

where:

• $$\text{Utility}_{SSP_j}^{SSN_i}$$: Net expected value perceived by an SSN when allocating stake to a given SSP, accounting for the tradeoff between returns, costs, and risks under constrained rationality;

  • $$\mathbb{E}[\text{Return}_{SSP_j}]$$ encompasses not only direct rewards and incentives that the $$SSN_i$$ earns from $$SSP_j$$, but also indirect or strategic benefits such as tailored modularity and collateral options, alignment with the SSN's trust assumptions (e.g., Ethereum or Bitcoin), reputational/brand trust, and long-term coherence with the SSN’s mission or ethos;

  • $$\mathbb{E}[\text{Cost}_{SSP_j}]$$ captures operational and opportunity costs of sourcing security from $$SSP_j$$, including incentives;

  • $$\mathbb{E}[\text{Risk}_{SSP_j}]$$ represent direct and correlated slashing exposures based on SSP risk profile, validator and LRT portfolios overlap, collateral quality, and historical behavior. More on SSP risk evaluation at Restaking Protocols Infra Risk Framework V2.

QRE Interpretation: Perceived Utility

Since SSNs operate under incomplete information and rationality, they don’t source capital deterministically. Instead, they convert raw utility into probabilistic preferences via the softmax formulation:

$$U'_{SSP_j} = \frac{e^{\lambda \cdot \text{Utility}_{SSP_j}}}{\sum_k e^{\lambda \cdot \text{Utility}_{SSP_k}}}$$

• Rationality (λ) scales how strongly agents react to utility differences when allocating probabilistically across options:

  • Low λ → Bounded Rationality / High Noise: SSNs behave erratically, weakly preferring high-utility SSPs; randomness dominates;

  • High λ → Deterministic Behavior: SSNs sharply favor SSPs with higher perceived utility; probabilistic error shrinks;

• Perceived Utility ($$U’_{SSP_j}$$) reflects this interplay—blending observed utility and the SSN’s current rationality level.

At time $$t₁$$ (non-equilibrium), SSNs' allocations are uncoordinated and near-random. SSNs disproportionately allocate to SSPs with higher apparent rewards, stronger brand recognition, or inertia, regardless of underlying risk exposure.

At time $$t₂$$ (near-equilibrium), Catalysis introduces risk and incentive feedback, nudging the system toward equilibrium. SSNs rebalance based on perceived utility gradients that incorporate slashing likelihood, validator-set quality, historical uptime, reward rates, and other metrics. Stake begins to redistribute probabilistically toward more defensible SSPs, even if they weren't initially preferred.

This is visualized in the utility response curves:

• SSP1’s curve rises steeply as SSNs recognize its superior risk-adjusted return profile;

• SSP2’s curve declines, reflecting reassessed risk due to previously hidden risk or reward downsides;

• SSP3, initially undervalued, gains traction under higher $$\lambda$$, as latent utility is revealed through rational inference.

A key inflection occurs around $$\lambda$$ = 4: SSNs transition from misinformed and erratic behavior to grounded preference formation. Rationality begins to meaningfully differentiate between SSPs. Catalysis and risk advisors' feedback and insights play a pivotal role in this shift.

By $$\lambda$$ = 9, SSNs express nearly full discernment, allocating in line with refined perceptions of utility. Stake flows align tightly with risk-adjusted rewards and utility.

Ultimately, Catalysis does not enforce uniform distribution. It offers transparency and steers the system toward a stable probabilistic equilibrium, where stake is allocated in line with relative perceived utility—and no SSN finds further reallocation rational, given available information and risk.

Calculating SSN-to-SSP Allocations Based Required Target Stake

Unlike standard minimax approaches that solely consider worst-case slashing risk and overlook key tradeoffs, our model instead uses perceived utility as a composite function of multiple factors: reward competitiveness, cost efficiency, validator quality, slashing likelihood, and operational reliability.

The stake sourced by $$SSNᵢ$$ from $$SSPⱼ$$ is determined proportionally as:

$$S_i = \left( \frac{U'_{SSP_j}}{\sum_{k=1}^{n} U'_{SSP_k}} \right) \times T$$

where:

• $$S_i$$ is the stake sourced by $$SSNi$$ from $$SSPj$$;

• $$U’_{SSP_j}$$ denotes the perceived utility of $$SSP_j$$ as assessed by $$SSNi$$;

• $$\sum_{k=1}^{n} U'_{SSP_k}$$ aggregates the perceived utility across candidate SSPs;

• $$T$$ defines the SSN's Target Stake across all SSPs for cryptoeconomic security purposes.

  

  Target Stake is the minimum level of staked collateral an SSN must secure such that the Cost of Corruption (CoC) outweighs the Profit from Corruption (PfC). It represents the cryptoeconomic threshold where attacks become irrational under adversarial constraints. The higher the PfC, the more Target Stake is required to render corruption economically infeasible. Check the below section for more detail.

This formulation achieves three objectives:

• Relative Utility Normalization: Stake is assigned based on comparative rather than absolute utility, ensuring efficient delegation even under incomplete information;

• Budget-Constrained Safety: Allocations are anchored to the Target Stake $$T$$, bounding systemic exposure and ensuring cost-aware deployment—avoiding overspend while preserving capital efficiency;

• Framework Extensibility: The logic is extensible beyond SSN-to-SSP flows. It applies equally to LRT-to-SSN or Operator-to-SSN delegation, if utility and target stake parameters are independently defined.

Additional Target Stake Considerations

SSNs with elevated Profit-from-Corruption (PfC) potential must provision proportionally higher Target Stake $$T$$ to offset attack incentives. When adversarial returns exceed slashing penalties, the system becomes economically vulnerable. Raising $$T$$ increases the Cost of Corruption (CoC) and restores economic deterrence.

Catalysis amplifies capital efficiency for high-$$T$$ SSNs by aggregating restaked security across SSPs and enabling dynamic reallocation toward configurations with optimal cost-risk profiles.

A key parameter often overlooked to consider when benchmarking Target Stake is collateral quality. Volatile or illiquid collateral degrade the effective security budget, requiring higher nominal $$T$$ to preserve equivalent resistance to corruption.

For a deep dive check our work with Symbiotic on Target Stake assessments:

Modeling Target Stake Requirements

This research in collaboration with Symbiotic explores how networks can estimate the amount of stake (or collateral) required to operate securely under PoS or restaking-based models.

https://paragraph.com

Localized vs. Correlated SSN Slashing Modes

Catalysis is structurally resistant to classical Byzantine Fault Tolerance (BFT) corruption attacks. Two core design elements raise the cost and coordination complexity of system-wide exploits:

1. Differentiated Validator Sets Across SSPs: While Catalysis presents a unified operator interface to SSNs, each underlying SSP can have its own distinct set of validators. For instance, some operators may be active only within specific SSPs. When an SSN leverages Catalysis, it interacts with a unified coordination layer, even though, under the hood, operator sets can vary across SSPs. This means that any successful corruption attempt will potentially have to compromise multiple, distinct validator sets simultaneously, significantly raising the cost and coordination complexity of an attack and making large-scale exploits logistically implausible;

2. Capital Scale: Catalysis aggregates restaked collateral potentially exceeding $20 billion across multiple ecosystems. An attacker aiming at cross-SSP compromise would require an economically irrational commitment of capital under realistic adversarial models, making large-scale coordinated attacks financially infeasible.

BFT attacks targeting dissimilar SSNs—those with independent validator sets, slashing logic, or infrastructure—form submodular attack surfaces, where each additional SSN increases attacker cost faster than it increases reward. Under Catalysis, this type of exploit is not just disincentivized—it is structurally infeasible. The heterogeneity across SSNs breaks exploit scalability and collapses return-on-attack curves.

Supermodular attacks, by contrast, exploit convergence: shared validators, identical slashing semantics, or common execution infrastructure across SSNs. These reduce marginal cost and amplify adversarial payoff. While theoretically more viable, Catalysis significantly blunts these vectors by enforcing unified (yet partially differentiated set per SSP) validator sets, incentivizing risk diversification, and amplifying system-wide cryptoeconomic security across all served SSNs—raising both detection likelihood and slashing exposure.

As a result, this section does not model catastrophic BFT-style exploits. Instead, it focuses on minor but still slashable faults—e.g., equivocation, liveness failures, or double-signing—and how their impact scope depends on the SSP's underlying slashing mode: whether faults are isolated (localized) or propagate across domains (correlated).

Localized Slashing

EigenLayer exemplifies localized slashing through its Unique Stake and Operator Sets architecture, introduced in ELIP-002:

Unique Stake guarantees that an Operator’s specific slashable stake can be allocated only to one AVS at a particular time. This single pairing strengthens the AVS's security without creating exogenous risk to other AVSs or the protocol at large. Operator Sets provide an in-protocol structure that enshrines the segmentation of Operators into local groups for the accounting, allocation, and slashing of staked security.

Each Operator Set registered under an SSN must deposit dedicated (slashable) stake, isolated from other SSNs—even if the same Operator Set is active elsewhere. This segmentation enforces fault containment:

• Slashable stake: Actively securing a specific SSN; subject to penalties based on that SSN’s slashing logic;

• Non-slashable stake: Idle or delegated elsewhere; remains untouched by unrelated slashing events.

This model defines Localized Slashing: faults are accounted for and penalized within AVS-specific boundaries, preventing risk from propagating across SSNs by default.

However, structural isolation does not eliminate all forms of slashing correlation. Some edge cases can still introduce indirect propagation pathways:

• DeFi Liquidation Contagion: If an LRT backed by a slashed operator is used as collateral in lending markets (e.g., Aave), a sharp NAV decline can trigger liquidations—particularly in high-LTV positions or thin-liquidity pools. Lending protocols that rely on slower or less responsive pricing—often derived from AMMs—may misprice risk during slashing events. In contrast, order book-based markets (e.g, Hyperliquid, dYdX) typically adjust more quickly, potentially containing price dislocations. This mismatch in price realization can accelerate liquidation cascades and lead to TVL erosion across the affected SSPs;

  For further analysis on this topic, refer to: LRT Slashing Risk.

  

  Drawing a parallel scenario to the LST ecosystem: A similar event happened in the 2022 Ankr exploit, where a hacker gained control of a compromised key and used it to mint 6 quadrillion aBNBc tokens—a derivative of Ankr Reward Bearing Staked BNB. Since these tokens were meant to represent a claim on underlying BNB, the exploit effectively created counterfeit BNB at scale. As the hacker offloaded the fake aBNBc, the price of liquid staking tokens like BNBx and stkBNB plummeted. Exploiting the chaos, the attacker used the counterfeit tokens as collateral to borrow stablecoins from Helio, ultimately draining the protocol and leaving it financially crippled. Ankr acknowledged a $5M direct loss.

• Operator-Level Fault Overlap: Even with per-SSN stake isolation, a single operator fault (e.g., downtime, equivocation) can trigger slashes across multiple SSNs they serve. Each AVS enforces its own penalties, but the aggregate result is a multi-AVS capital drawdown;

• Shared Infrastructure Exposure: If multiple Operator Sets rely on common backend components—such as signing keys, RPC endpoints, or oracle/data feeds—a fault in shared infrastructure can cause simultaneous localized slashes, functionally mimicking correlated slashing even under an isolated stake model.

Correlated Slashing

Correlated slashing occurs when a single validator fault propagates beyond its local domain, impacting multiple SSNs through shared dependencies. Unlike localized slashing—where faults are isolated per AVS—correlated slashing reflects a failure of stake isolation, allowing systemic exposure across otherwise independent networks.

Its most critical form emerges from covariance across participants: when SSNs, operators, LRTs, and, under Catalysis, even SSPs, share validator infrastructure, slashing semantics, or capital pools. In this expanded surface area, one slashing event—if left unchecked—can trigger cascading penalties across networks with aligned exposure vectors.

Propagation channels include:

• Shared validator sets securing multiple SSNs;

• Overlapping LRT portfolios of SSNs with collateral tied to affected operators;

• SSPs that service structurally correlated SSNs, amplifying blast radius.

When isolation boundaries blur, a single fault domain can drain capital across multiple SSPs, degrade cross-network trust, and weaken Catalysis’ aggregate security posture.

Mitigation depends on preemptive containment:

• Strict operator segmentation across SSNs to reduce overlap;

• Robust, non-ambiguous slashing definitions to localize penalties;

• Dynamic rebalancing and portfolio caps to avoid systemic overexposure;

• Collateral diversity across LRTs, minimizing reflexive liquidations.

Catalysis enhances risk visibility across these dimensions—but maintaining slashing containment in correlated environments requires intentional design at the SSN, LRT, and SSP levels.

Modelling Localized & Correlated Slashing Modes

This section models how SSNs dynamically rebalance stake allocations across SSPs in response to localized and correlated slashing risks. The Sankey transition from non-equilibrium ($$t1$$) to near-equilibrium ($$t_2$$) captures how Catalysis nudges the system toward context-aware delegation based on perceived utility gradients and risk asymmetries.

Each SSN bar reflects its Target Stake—the minimum capital required for secure operation. SSN2 and SSN5 are flagged as riskier and depicted in yellow.

At $$t₁$$ (non-equilibrium):

• Over 50% of $$SSP2$$’s utilized stake is sourced from high-risk SSNs, creating exposure to correlated slashing events. A fault in either SSN could propagate through $$SSP2$$, impacting unrelated SSNs like $$SSN1$$ and $$SSN3$$. Although unlikely, SSP2 becomes a potential channel for supermodular attack surfaces—where shared infrastructure and protocol and portfolio overlap reduce marginal attack cost and compounds adversarial payoff. If $$SSP2$$ adopts a localized slashing architecture, SSN covariance risk is neutralized, and security posture largely becomes a function of operator quality rather than covariance;

• $$SSP2$$ is the most fragile SSP, likely offering higher yields to compensate for its elevated correlated exposure and attract conservative SSNs willing to absorb higher risk;

• $$SSN4$$ is the least risk-exposed SSN and most isolated from slashing propagation risk, as it does not delegate to $$SSP2$$. It maintains risk neutrality across the stack;

• $$SSN1$$ and $$SSN4$$ display the highest Target Stake requirements, evidenced by taller allocation bars. Both concentrate on $$SSP1$$, suggesting it offers the lowest effective security pricing or strongest validator set incentives;

• $$SSP1$$ and $$SSP3$$ host mostly lower-risk SSNs, but may be under-incentivized. Without sufficient yield, they risk underutilization and capital inefficiency—unless they selectively onboard marginal risk to rebalance.

These dynamics define a non-equilibrium state, where risk is unevenly distributed, yield signals are misaligned, and capital flows inefficiently—revealing the highly misinformed, at times near-irrational allocation decisions that distort utility assessments. Catalysis detects these imbalances and surfaces slashing asymmetries and overexposure zones to prompt reallocation. SSNs can adjust proactively or reactively, absorbing post-event feedback or shifting positions as incentive curves evolve.

At $$t₂$$ (near-equilibrium):

• Aggregate stake across the system increases as more efficient utility routing raises delegation confidence. Catalysis TVL at $$t_2$$ exceeds $$t_1$$, reflected by the thickened bar at the center. More capital is secured, better aligned to perceived utilities and yield-risk profiles;

• $$SSP1$$ and $$SSP3$$ selectively onboard higher-risk SSNs, recalibrating their risk/yield mix to improve stake utilization without breaching acceptable slashing correlation thresholds;

• $$SSN4$$ reallocates significantly to $$SSP2$$, suggesting that its perceived utility for $$SSP2$$ has improved—potentially from post-slashing incentive realignment or updated risk assessments;

• $$SSN1$$ increases allocations to both $$SSP1$$ and $$SSP2$$, indicating balanced exposure and diversified utility sourcing as systemic confidence improves;

• $$SSP2$$ improves its risk-reward profile, either through sharper reward signaling or reduced correlation risk. If previously underused despite high yields, improved clarity in risk scope and validator incentives unlocks latent TVL inflows;

• $$SSP1$$ and $$SSP3$$ achieve higher utilization rates, absorbing previously sidelined capital by optimizing for slashing-aware yield curves;

• $$SSP1$$, in particular, absorbs more stake by accommodating “riskier” stake from $$SSN2$$ and $$SSN5$$, improving yield distribution and validator efficiency without destabilizing its slashing profile.

Catalysis acts not as a passive router but as an active coordination layer—surfacing latent risk, realigning delegation behavior, and driving the system toward a probabilistic equilibrium. Stake no longer flows blindly toward yield. It follows perceived-utility paths, shaped by Catalysis’ intelligence, validator metadata, slashing semantics, and real-time incentive design.

The result: an adaptive, self-correcting delegation topology that preserves capital efficiency while minimizing systemic slashing risk.

Calculating Localized & Correlated Slashing Modes

Quantifying Slashing Propagation Across SSNs

To model how slashing events propagate across SSNs via shared infrastructure, validator overlap, or LRT portfolio covariance, we extend our LRT risk model to compute compounded SSN-level exposure. The framework introduces an amplified temporal risk function that accounts for both baseline slashing risk and the duration-dependent propagation effect:

$$R'_{\text{SSN} \, A} = f_{pw}\left( R_{\text{SSN} \, A} \times e^{\mathcal{S} \cdot \lim\limits_{t \to t+n} \Lambda_{t, A}} \right)$$

where:

• $$R_{\text{SSN}A}$$ is $$\text{SSN}A$$’s baseline risk score profile;

• $$\mathcal{S} \in [0.1, 0.5]$$ is a sensitivity coefficient that scales cascading risk magnitude;
  → Lower values imply localized containment; higher values reflect elevated systemic fragility due to covariance and shared exposure;

• $$\Lambda_{t, A} \in [0.5, 2]$$ is the temporal compounding window, modeling how long the system remains vulnerable to secondary propagation;

• $$f_{pw}$$ is a piecewise function that converts this latent amplification into portfolio-evaluable risk scores;

• $$R'_{\text{SSN} \, A}$$ is the amplified risk score reflecting correlated propagation effects for $$\text{SSN}A$$.

Refer to Restaking Networks Risk Evaluation for a technical deep-dive on SSN risk and to LRT Slashing Risk for more detail on LRT risk and the formula construction.

Conditional Propagation and Correlated Faults

In a correlated, rather than localized, setting, slashing propagation does not terminate at the initial fault domain. If $$\text{SSN} A$$ is slashed and shares dependency vectors with $$\text{SSN} B$$, then $$\text{SSN} B$$ acquires conditional exposure to the upstream slashing event.

This can be modeled using conditional expectation:

$$\mathbb{E}\left[ R'_{\text{SSN} \, B} \mid \mathbb{S}_{\text{SSN} \, A} \right] > \mathbb{E}\left[ \mathbb{S}_{\text{SSN} \, A} \right], \quad \mathbb{S}_{\text{SSN} \, A} \sim R'_{\text{SSN} \, A}$$

where:

• $$\mathbb{E}\left[ R'_{\text{SSN} \, B} \mid \mathbb{S}_{\text{SSN} \, A} \right] > \mathbb{E}\left[ \mathbb{S}_{\text{SSN} \, A} \right]$$ denotes the expected amplified risk score for $$\text{SSN} B$$, given that the covariant $$\text{SSN} A$$ has been slashed. Notably, this condition exceeds the standalone slashing risk observed on $$\text{SSN} A$$ itself;

• $$\mathbb{S}_{\text{SSN} \, A} \sim R'_{\text{SSN} \, A}$$ implies that the slashing event observed on $$\text{SSN} A$$ is statistically consistent with its ex-ante assessed amplified risk.

This formalism captures second-order propagation: slashing on $$\text{SSN} A$$ revises the real-time risk profile of $$\text{SSN} B$$. Such correlations emerge from validator co-dependencies, LRT/SSP portfolio overlap, or entangled slashing semantics.

Amplified events can trigger cascading reallocation, stake withdrawals, and portfolio de-risking behavior. In extreme scenarios, restaking platforms with high TVL—particularly those exposed to frail collateral options—may suffer from systemic trust degradation.

To contain this, protocols must adopt nonlinear risk transmission models and dependency-aware allocation strategies, including:

• Preemptive modeling of second-order propagation;

• Operator-level exposure segmentation;

• Collateral diversification buffers for highly connected SSNs.

Catalysis Rebalancing Feedback Engine

Catalysis serves as an active coordination layer, continuously steering the system toward a stable probabilistic equilibrium. It does not enforce allocation rules. Instead, it surfaces asymmetric risk concentrations, informs incentive design, and enables stake to reorganize dynamically in response to evolving market conditions.

At time $$t_1$$, the system may exhibit unstable configurations—such as excessive correlated exposure to a single SSP (e.g., $$SSP2$$)—which amplify the risk of multi-SSN slashing propagation. Catalysis detects these patterns in real time, quantifies risk gradients, and guides corrective rebalancing through incentive-compatible mechanisms. $$SSP1$$, for example, may be prompted to onboard marginally riskier SSNs to absorb systemic imbalance and reduce covariance across validator clusters.

A core function of the engine is discriminating between localized and correlated slashing vectors. When fault dependencies—such as shared validator sets, infrastructure, or LRT portfolios—are detected across SSNs (e.g., $$SSN1$$, $$SSN3$$, and $$SSN5$$), Catalysis flags these as correlated exposure zones and adjusts delegation incentives to mitigate propagation risk.

The rebalancing logic is modular and extensible, leveraging a suite of programmable primitives:

• Portfolio-Aware Delegation Logic: Incentivizes stake redistribution away from SSNs with excessive validator overlap, reducing conditional exposure and localizing fault domains;

• Validator Caps: Enforces operator concentration thresholds across SSNs to avoid systemic reliance on dominant infrastructure actors;

• Collateral-Type Differentiation: Promotes heterogeneous collateral sourcing to contain DeFi contagion from LRT-backed liquidation cascades;

• Slashing Semantics Harmonization: Standardizes fault definitions across SSPs to ensure symmetry in penalties and reduce exploitability via slashing arbitrage.

Crucially, equilibrium under Quantal Response Equilibrium is not a point solution. It is a distributional outcome wherein each SSN, based on perceived utility, has no incentive to reallocate. Stake flows probabilistically, reflecting the bounded rationality, asymmetric information, and risk signals that define real-world delegation environments.

Catalysis operationalizes this by continuously mapping utility vectors, flagging slashing covariance, and delivering route-aware, risk-adjusted incentives. The system doesn’t just react—it curates. The result is a dynamic, resilient delegation marketplace that organizes around economic stability rather than static configuration.

Conclusion

Catalysis reshapes SSN security economics by embedding awareness of SSP-specific risk, reward, and cost into the core of SSN stake routing. Through unified validator abstraction and programmable delegation logic, it reduces capital inefficiencies, enables market-wide price discovery, and allows SSNs to adapt dynamically in real time.

A stake allocation simulation—modeled through Quantal Response Equilibrium and visualized via a Sankey transition diagram—illustrates the system’s progression from non-equilibrium to near-equilibrium. Stake no longer flows naïvely toward yield-maximizing venues, but reallocates proportionally across SSPs based on risk-adjusted utility curves and Target Stake requirements.

We show that localized slashing isolates faults within the originating SSN, maintaining strict fault containment. Correlated slashing, by contrast, arises from shared validator sets, infrastructure, or portfolio overlap—enabling faults to propagate laterally across SSNs, LRTs, operators, and SSPs. To evaluate this risk, we introduce temporal amplification and conditional propagation formulas that quantify second-order exposure and help guide risk-aware delegation strategies.

Catalysis reframes restaked security as an ongoing coordination game—where utility, risk, and capital efficiency are continuously co-optimized across modular restaking ecosystems.

References

• Catalysis Documentation: https://docs.catalysis.network/

• Economic Security of Multiple Shared Security Protocols, Abhimanyu Nag, Dhruv Bodani, Abhishek Kumar (Catalysis): https://arxiv.org/abs/2505.03843#

• Restaking Protocols Infra Risk Framework V2, Tokensight: https://paragraph.com/@tokensightxyz/restaking-protocols-infra-risk-framework-v2

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

• Modeling Target Stake Requirements in PoS and Restaking-Based Networks, Tokensight & Symbiotic: https://paragraph.com/@tokensightxyz/modeling-target-stake-requirements

• LRT Slashing Risk, Tokensight: https://paragraph.com/@tokensightxyz/lrt-slashing-risk

• EigenDA: AVS Cryptoeconomic Risk Analysis, Tokensight: https://paragraph.com/@tokensightxyz/eigenda-avs-cryptoeconomic-risk-analysis

• Enabling the Builders: How Catalysis Is Unlocking the Next Generation of AVSs, Presto Research: https://www.prestolabs.io/research/enabling-the-builders-how-catalysis-is-unlocking-the-next-generation-of-avss

• Gauging Slashing Risks of Symbiotic Networks, MEV Capital & Node Infra: https://mevcapital.com/gauging-slashing-risks-of-symbiotic-networks/

• Mastering Quantal Response Equilibrium: https://www.numberanalytics.com/blog/quantal-response-equilibrium-game-theory

• Nash Equilibrium: https://www.geeksforgeeks.org/machine-learning/nash-equilibrium/

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

• https://restake.watch/

Learn More on Catalysis

Check Catalysis website and Twitter.

Follow us on X!

Index

1. Abstract

2. Introduction

3. Shared Security Networks and Aggregated Security

4. Operators and Infrastructure Efficiency

5. Shared Security Protocols and the Supply-Demand Equilibria

6. Delegators and Capital Efficiency

7. Potential Risks

8. Strong Cryptoeconomic Security

9. Catalysis: A Unified Security Abstraction Layer

10. Conclusion

Note: The term “Shared Security Networks” will be used herein to represent the networks/services (AVSs, Networks, BSNs, etc.) that leverage restaked collateral to validate their infrastructure needs. And the term “Shared Security Protocols” will be used herein to represent the restaking marketplaces (EigenLayer, Symbiotic, Babylon, SatLayer, etc.) that aggregate this demand and supply security and validation to Shared Security Networks.

Abstract

Catalysis introduces a novel abstraction layer for securing Shared Security Networks (SSNs) across multiple restaking protocols. By decoupling validator coordination, capital delegation, and protocol-specific integrations from individual restaking marketplaces, it transforms fragmented security sourcing into a unified, programmable interface. This design enables SSNs to access diversified cryptoeconomic guarantees without bespoke integrations, while simultaneously allowing operators, delegators, and Shared Security Protocols (SSPs) to participate in a more composable and efficient ecosystem.

The present research piece explores the roles, incentives, and risk surfaces for each participant in the Catalysis architecture. It outlines how the protocol reconfigures participants’ economic incentives, reward flows, and governance coordination across a modular security stack—and what conditions are required for that system to scale resiliently and safely.

Introduction

Catalysis is pioneering the first Security Abstraction Layer that aggregates, unifies, and streamlines cryptoeconomic security across shared security protocols.

By abstracting protocol-specific complexity, Catalysis enables developers and node operators to seamlessly build, scale, and secure decentralized networks like AVSs, BVSs, and DVNs through a single, interoperable coordination layer.

Shared Security Networks and Aggregated Security

SSNs increasingly seek aggregated security by integrating with multiple SSPs. Networks like Omni, Redstone, Ditto Network, and Hyperlane already source restaked capital from a few protocols such as EigenLayer, Symbiotic, and SatLayer—each adding discrete trust domains. This multi-platform approach improves security robustness, but introduces complexity: each SSP comes with its own validator sets, infrastructure specs, slashing semantics, and integration overhead.

Catalysis abstracts these differences away. Through a single programmable interface, SSNs can source diversified restaked security without needing to individually onboard to each SSP. Rather than stitching together security from fragmented ecosystems, Catalysis allows SSNs to operate with a unified validator set, programmable slashing logic, and a standardized delegation pipeline. As a result, when one SSP encounters performance degradation or a slashing event, SSNs are able to retain uptime and security continuity through the multi-SSP model and by reallocating risk exposure on demand.

Key benefits to SSNs:

• Faster deployment with minimal integration overhead, via Catalyst SDK;

• Programmable slashing and reward logic tailored to SSN-specific conditions;

• Modular validator set architecture with optional redundancy and isolation;

• Dynamic security allocation based on real-time risk-yield optimization;

• Reduced exposure to single-SSP failure through multi-platform sourcing;

• Native cross-platform reward distribution without bridges or wrappers;

• Greater pricing power through aggregated demand across SSNs;

• Unified interface for managing validators, stake, and reward flows.

Reframing the SSN Security Model

SSNs evaluating Catalysis—and now SSPs on an opt-in basis—must address three foundational questions:

1. How much economic security is needed?

   SSNs must consider potential corruption profit based on their set-up and how much cost (economic security) would be sufficient to deter an attack. Read more on the topic on our newly-released piece on Target Stake with Symbiotic.

   Catalysis reframes this question further with a deeper second-order one:

   Which sources of cryptoeconomic security (ETH from EigenLayer and Symbiotic, BTC from Babylon and SatLayer, BNB from Kernel, etc.) does an SSN need and wants align itself with?

2. What is the cost of acquiring this security?

   SSNs must consider fees, validator rewards, and protocol-level overhead. Catalysis makes cost benchmarking across SSPs seamless, enabling protocols to optimize for minimum-cost, maximum-resilience setups.

3. What is the slashing and accountability model?

   SSNs must define what validator behavior constitutes a fault and how such faults are adjudicated and penalized. Catalysis makes this logic programmable and enforceable across multiple SSPs through a single interface.

Economic and Game-Theoretic Flows

Assuming the structural advantages introduced by Catalysis play out as expected, a broader set of SSNs would likely enter the system—driving up aggregate demand for restaked capital. This flywheel creates upward pressure on rewards for delegators (via LRTs or direct restakers), incentivizing greater participation and TVL growth. At the same time, increased SSN competition drives demand for high-performing validators, prompting operators to compete on uptime, reliability, and responsiveness.

From a cost-efficiency standpoint, Catalysis introduces a competitive restaking marketplace. SSNs can compare pricing across SSPs and allocate stake where security is cheapest and most stable. This drives downward pressure on security costs as SSPs compete for SSN onboarding and encourages them to improve internal economics and UX.

SSNs also gain more malleability to consider SSPs’ TVL stickiness—how durable and reactive each SSP’s capital base is under slashing, volatility, or adverse events. Those with more consistent capital retention will be perceived as more reliable security sources.

By concentrating demand and standardizing the security procurement process, Catalysis enhances the buying power of SSNs. SSPs are incentivized to compete not just on integration availability, but on economic efficiency, validator quality, and fault tolerance. In this way, Catalysis transforms restaking from a fragmented infrastructure layer into a coordinated, efficient security marketplace.

Operators and Infrastructure Efficiency

Catalysis offers a materially improved operational model for node operators by eliminating the need to maintain separate infrastructure set-ups per SSP. Instead of rebuilding internal tooling and DevOps pipelines for each restaking protocol, operators interact with a unified interface and shared validation logic. While significantly reducing engineering overhead, this makes it feasible to support hundreds of SSNs through a single stack.

This standardization benefits both existing and emerging operators. Experienced teams can expand their SSN coverage without infrastructure fragmentation, while smaller or newer operators—previously priced out by complexity—gain accessible entry points. Catalysis thus lowers barriers to entry while improving decentralization and scalability across the operator landscape.

Key benefits to Operators:

• Unified validation logic for all Operators across SSPs;

• Reduced DevOps expenses and protocol-specific tooling costs;

• Scalable validator workflows with minimal marginal complexity.

Economic and Game-Theoretic Flows

By allowing validators to serve multiple SSNs concurrently across SSPs, Catalysis expands the reward surface available to each operator, proportionally to the number of SSPs. This drives rational incentives for productivity: validators that reliably serve high-stakes SSNs across SSPs accumulate visibility, curator preference, and sustained delegation flows. Operators no longer optimize for individual SSN integrations—they optimize for portfolio-level robustness and economic efficiency across the Catalysis ecosystem.

The expansion of the operator base increases validator supply, introducing downward cost pressure on validation tasks for SSNs. At the same time, increased validator diversity strengthens fault tolerance and mitigates collusion risk—particularly for SSPs that previously relied on a smaller set of infrastructure providers. Delegators and curators benefit as well: a richer operator landscape allows for more granular risk curation, performance-based selection, and differentiated strategy design.

In short, Catalysis transforms validator operations from isolated, protocol-bound deployments into a composable, efficient layer. The outcome is a more decentralized, cost-efficient, and reputationally transparent operator ecosystem, aligned with the needs of SSNs, SSPs, and capital allocators alike.

Shared Security Protocols and the Supply-Demand Equilibria

Catalysis reshapes the dynamics of Shared Security Protocols (SSPs) by abstracting SSNs’ and operators’ integrations, allowing protocols to compete directly on economic and operational effectiveness. Instead of manually onboarding SSNs and managing bespoke deployments, SSPs are accessed through a standardized interface. This lowers coordination costs and allows any SSP to offer its economic security as a composable network.

As Catalysis consolidates SSN demand into a shared routing layer, SSPs supposedly begin to compete not on adoption, but on slashing guarantees, collateral types, governance structure, and responsiveness. The result is a more transparent and performance-aware security marketplace, where SSNs are able to select the best-fit SSPs to their technical requirements, business needs, ethos, and specific alignment metrics.

Key benefits to SSPs:

• Increased protocol utilization through multi-part demand aggregation;

• Frictionless SSN and Operator onboarding across multiple blockchain ecosystems (Ethereum, Solana, Bitcoin, Cosmos, etc.);

• Differentiation via economic efficiency, slashing efficacy, latency, or UX.

Economic and Game-Theoretic Flows

Catalysis creates a positive-sum feedback loop for SSPs: lower onboarding friction leads to the deployment of more SSNs, which increases restaked capital demand, validator participation, and TVL. This generates an economic flywheel, where more SSNs sourcing security through Catalysis results in greater SSP exposure—subsequently attracting more delegators and increasing protocol utility. SSPs offering competitive yield and stronger slashing enforcement will command greater market share, as productivity becomes the primary differentiator.

Additionally, Catalysis eliminates the need for SSPs to independently attract or manage operator and delegator participation. Validator assignment and capital routing are delegated to curator strategies, allowing SSPs to focus on optimizing infrastructure and incentive design. Smaller or emerging SSPs gain credible entry, competing based on merit—fostering ecosystem pluralism.

By reframing restaking as a modular network layer rather than a vertically integrated protocol stack, Catalysis transforms SSPs into cross-chain interoperable security primitives. The result is a more composable and performance-aligned restaking economy, where participation is earned through quality—not gatekeeping.

Delegators and Capital Efficiency

Delegators—whether Liquid Restaking Tokens (LRTs), curators, or direct restakers—are central to restaking economics. Their goal is to maximize risk-adjusted returns while minimizing operational overhead. Catalysis abstracts protocol-specific logic and validator fragmentation, allowing capital to flow across SSNs and SSPs through unified strategies without needing to track slashing rules, unbonding delays, interface inconsistencies, or different requirements such as ToS. This way, yield opportunities are concentrated into a programmable layer, where curator-led strategies turn delegation into a portfolio optimization problem based on validator quality, slashing exposure, and SSN-specific risk.

Key benefits to Delegators:

• Simplified UX with reduced learning-curve fatigue;

• Seamless capital allocation across SSNs and SSPs;

• Reduced re-delegation friction and protocol switching costs;

• Greater diversification through cross-protocols yield exposure.

Economic and Game-Theoretic Flows

Delegators benefit directly from increased security demand from SSNs: competition picks up among SSNs for restaked capital, improving yields for delegators. Simultaneously, as operators compete for delegations, economic and operational performance become the basis for capital inflow—not reputation or incumbency. This dynamic incentivizes validator quality and encourages SSNs to price security accurately via reward terms and slashing conditions.

Potential Risks

Catalysis introduces powerful abstraction and coordination benefits, but these gains come with potential system-level risks that span validator dynamics, correlated slashing and coordination issues, and incentive alignment. At the end, we present some solutions to the key architectural vulnerabilities that must be addressed for Catalysis to scale securely.

Correlated Slashing Risk

Correlated slashing risks intensify under unified abstraction. While the probability of correlated slashing has always existed, the interconnection imposed by a shared security layer significantly amplifies it—enabling single faults to trigger multi-SSP slashing and propagate systemic consequences.

• SSNs: Many high-risk networks and in-portfolio correlated low quality of slashing conditions can trigger or amplify systemic slashing risk;

• Operators: Colluded (or even isolated) operator misbehaviours and shared infrastructure faults can affect multiple SSNs simultaneously, creating widespread fragility;

• SSPs: Slashing would impact all SSPs to different degrees, through loss of stake (cryptoeconomic security), depending on risk profile, origin, correlation, collateral similarity, and DeFi profile of LRTs;

• Delegators: Systemic slashing may trigger rapid liquidations and delegator exits from impacted LRTs and restakers, draining TVL from SSPs and reducing the security buffer for uninvolved SSNs.

Catalysis increases the scope of impact from validator faults. A single operator misbehaviour can trigger multi-SSP slashing, deplete TVL, and propagate losses across SSNs and delegators. Poor portfolio composition and misaligned slashing definitions across SSNs—such as inconsistent fault criteria, penalty severity, or propagation scope— compound the risk. Without strict fault isolation, correlated failures may undermine trust in the abstraction layer.

Balancing Incentives & Rebalancing Risk

There’s a heightened need for precision in incentive calibration and stake management, in the Catalysis platform. In a restaking ecosystem already defined by complexity and overlapping incentive vectors, misalignment at the abstraction layer can produce even greater systemic distortions.

If abstraction logic fails to reflect validator performance accurately, the system risks overcompensating underperformers while penalizing high performers—eroding trust in reward fairness and degrading SSNs’ alignment.

Core risks include:

• Slashing propagation from stake misallocation: without timely—both proactive and reactive—rebalancing, faults in one SSP or SSN can ripple through the system due to poorly distributed validator exposure;

• Distorted incentive signals: inaccurate reward attribution can entrench suboptimal operator behaviour, weakening productivity-based selection;

• Asset-specific tail risk: aggregating stake across SSPs with volatile or homogenous collateral types—such as illiquid LSTs or wrapped assets—increases systemic exposure to liquidity shocks and collateral-specific drawdowns.

Sustaining network health requires tightly aligned incentives, timely rebalancing mechanisms, and asset-aware collateral strategy—otherwise, abstractions that promise efficiency may deliver chaos instead.

Coordination Risks

As the middleware between all the aforementioned participants, the protocol’s ability to enforce governance, route incentives, and execute updates across domains must be resilient by design. Misalignment or failure can kindle cascading execution faults, value misallocation, or systemic deadlocks.

Key coordination risks include:

• Opaque or Centralized Governance: If critical mappings—such as SSN-to-operator assignments, slashing thresholds, or reward flows—are controlled by off-chain committees or multisigs, Catalysis risks becoming a chokepoint. Faulty mappings may trigger misalignment across otherwise healthy systems;

• Multi-Protocol Synchronization Complexity: Catalysis abstracts over heterogeneous chains and restaking protocols. Differences in finality, slashing semantics, validator assumptions, and simple operational standards must be carefully harmonized before deployment;

• Immutability vs Flexibility: Excessive smart-contract immutability can delay unanticipated emergency upgrades during crises; too much flexibility may introduce ambiguity, weakens guarantees, and invite governance capture. Striking the right balance is essential;

• Dispute Resolution and Upgrade Stalling: Without clear escalation paths or upgrade governance, validator slashing disputes or integration bottlenecks may stall coordination under high load or adversarial pressure;

• Interop Layer Fragility: Catalysis depends on reliable cross-chain messaging to propagate validator, slashing, and delegation state. Selecting a brittle or non-performant interoperability solution would create latency, ordering issues, or cross-domain failure propagation.

Coordination failures at the middleware layer don’t just degrade performance, they fracture trust across every interdependent layer. For Catalysis to scale securely, its governance, synchronization logic, and cross-chain interop infrastructure must operate with resilience and flexibility from the outset.

Risk Mitigation Paths

Some ideas worth exploring to address Catalysis’ risk vectors involve a combination of parameter tuning, incentive refinement, and structured onboarding processes. The goal is to prevent feedback loops, reduce correlated exposure, and enforce guardrails without compromising the system’s composability or scalability. For Catalysis to scale securely, it must evolve from being just an abstraction layer to also functioning as a risk alignment engine—ensuring that validator assignments, SSN exposure, and SSP registration follow defensible, systemic safety principles.

• Parameter Calibration: Unbonding periods, opt-in/opt-out mechanics, and stake reallocation frequency must be tightly specified to prevent liquidity fragmentation and systemic feedback loops;

• Slashing Allocation Design: A risk-based slashing scheme—rather than proportional—should be considered to reflect the relative criticality of SSNs, SSP trustworthiness, and operator exposure;

• Access Control and Whitelisting: A principled whitelisting mechanism should govern the onboarding of new SSPs, operators, and SSNs to ensure fault domains remain isolated;

• Governance and Protocol Safeguards: Systemic risk should be bounded via pre-audited slashing parameters, validator caps, and structural risk composition limits embedded at the protocol layer;

• Target Stake Benchmarking: SSNs must be advised on how much cryptoeconomic security is needed to deter attack, based on context-specific PfC modeling and correlation risk;

• Quantitative Risk Modeling: Simulation-based testing, agent-based modeling, and game-theoretic validation should underpin rebalancing logic and curator strategy design.

These mitigation paths do not eliminate systemic risk, but they provide the scaffolding required to contain faults, align incentives, and scale modular security without eroding trust assumptions.

Strong Cryptoeconomic Security

Increased Cost of Corruption

By unifying cryptoeconomic security—validator sets, slashing enforcement, and reward distribution—across multiple SSPs, Catalysis raises the minimum cost of corruption for an SSN. Misbehaviour by an operator results in coordinated slashing across all restaked capital they secure, rather than limited to one protocol. This removes the attack vector inherent in fragmented restaking architectures, where an adversary can exploit the weakest SSP without impacting others. In Catalysis, any fault has system-wide consequences—making selective exploitation economically irrational.

Game-theoretic reasoning reinforces this logic: validators face disincentives to accept bribes or misbehave, as doing so results in forfeiting rewards and activating slashing across multiple domains. Such structure improves bribery resistance and aligns validator incentives with systemic safety. Moreover, the ability to equalize stake across SSPs—without complex reallocation logic—enhances robustness by avoiding capital concentration and single-point dependencies.

Reward Mechanics

Catalysis restructures restaking reward flows by aggregating access to multi-SSN participation through a unified interface. Operators and delegators no longer manage fragmented staking logic across multiple SSPs; instead, they interact with a single abstraction layer that facilitates cross-protocol yield aggregation and dynamic capital routing toward high-performing validators. The architecture increases efficiency across the board—operators can support several SSNs without duplicating infrastructure, while delegators gain broader, composable exposure to diversified restaking markets.

Reward distribution is programmable and performance-based. SSNs define custom incentive curves based on metrics like validator uptime, slashing history, and risk sensitivity. With this structure, stake can be rebalanced toward more reliable validators in real-time, reinforcing meritocratic compensation and improving network alignment.

Additionally, Catalysis enables native reward delivery across multiple SSPs without relying on bridging or cross-chain transfers. SSNs can issue payouts directly to restakers on any platform where they source security. For instance, node operators validating an SSN backed by both EigenLayer and Symbiotic receive discrete payments from each SSP, proportional to their stake and contribution. Such separation preserves protocol-level accountability, simplifies distribution logistics, and enables more transparent and modular reward strategies.

Catalysis: A Unified Security Abstraction Layer

In summary, Catalysis serves as a coordination protocol that abstracts and unifies access to multiple restaking ecosystems. It enables SSNs to source economic security from multiple SSPs through a single programmable interface, while simultaneously allowing operators and delegators to engage with a broader set of SSNs without the need for protocol-specific infrastructure or tooling. The abstraction not only enhances capital efficiency but also introduces a more modular and productivity-sensitive restaking market.

This workflow introduces a powerful flywheel and network effects: as more SSNs integrate, capital flows increase; as capital deepens, SSPs compete more effectively; as operators perform, delegation becomes more strategic and risk-aware.

Each actor in the Catalysis ecosystem benefits from the shift to modular coordination:

• SSNs gain faster onboarding, no SSP lock-in, and access to a broader validator market;

• Operators simplify infrastructure by validating multiple SSNs through one interface and are rewarded based on aggregate effectiveness;

• SSPs attract more SSNs and capital without managing direct integrations, and differentiate through slashing rigor and economic design;

• Delegators achieve higher yield diversity, reduced concentration risk, and easier portfolio curation;

• Catalysis itself becomes the neutral middleware and abstraction layer—positioned to standardize cross-chain and cross-protocol security provisioning and boost emerging applications in restaking and beyond.

Catalysis establishes a shared marketplace where cryptoeconomic security is priced, routed, and allocated dynamically. It enables price discovery between SSNs and SSPs, fosters yield competition among operators, and allows capital to flow efficiently to where it is most productive. This creates a reinforcing loop of liquidity, TVL, validator net productivity, and demand-side pressure that makes security provisioning more cost-efficient and composable.

The central trade-off in Catalysis is between greater efficiency and increased interdependence. Abstracting validator coordination and capital delegation boosts reuse and reduces fragmentation, but also could make the system more sensitive to faults. To scale securely, Catalysis requires rigorous research and configuration into validator matching, and guardrails to contain the spread of slashing events across its shared security domains.

Conclusion

Catalysis represents a structural revolution in restaking—shifting from siloed integrations to a programmable coordination layer that dynamically allocates trust and capital across SSNs, operators, and SSPs. By embedding performance-sensitive incentives, unified slashing logic, and market-driven validator assignment, it makes modular security both scalable and economically efficient. If executed with sound parameterization, transparent governance, and risk-aware delegation strategies, Catalysis has the potential to become the go-to infrastructure solution for launching and securing SSNs across the restaking ecosystem.

References

• Catalysis Documentation: https://docs.catalysis.network/

• Economic Security of Multiple Shared Security Protocols, Abhimanyu Nag, Dhruv Bodani, Abhishek Kumar (Catalysis): https://arxiv.org/abs/2505.03843#

• Restaking Protocols Infra Risk Framework V2, Tokensight: https://paragraph.com/@tokensightxyz/restaking-protocols-infra-risk-framework-v2

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

• Modeling Target Stake Requirements in PoS and Restaking-Based Networks, Tokensight & Symbiotic: https://paragraph.com/@tokensightxyz/modeling-target-stake-requirements

• LRT Slashing Risk, Tokensight: https://paragraph.com/@tokensightxyz/lrt-slashing-risk

• EigenDA: AVS Cryptoeconomic Risk Analysis, Tokensight: https://paragraph.com/@tokensightxyz/eigenda-avs-cryptoeconomic-risk-analysis

• Enabling the Builders: How Catalysis Is Unlocking the Next Generation of AVSs, Presto Research: https://www.prestolabs.io/research/enabling-the-builders-how-catalysis-is-unlocking-the-next-generation-of-avss

• Gauging Slashing Risks of Symbiotic Networks, MEV Capital & Node Infra: https://mevcapital.com/gauging-slashing-risks-of-symbiotic-networks/

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

• https://restake.watch/

Learn More on Catalysis

Check Catalysis website and Twitter.

Follow us on X!

Abstract

This research in collaboration with Symbiotic explores how networks can estimate the amount of stake (or collateral) required to operate securely under Proof-of-Stake or restaking-based models. It introduces a framework for calculating “target stake” based on variables such as total value at risk, attack profitability, validator behavior, and slashing conditions. It also accounts for added complexities introduced by restaking, including collateral reuse and cross-network risk, and proposes how flexible, context-specific security thresholds can be designed for services like data availability, oracles, or zero-knowledge provers.

Modeling Target Stake Requirements in Proof-of-Stake and Restaking-Based Networks

Abstract This research in collaboration with TokenSight explores how networks can estimate the amount of stake (or collateral) required to operate securely under Proof-of-Stake or restaking-based models. It introduces a framework for calculating "target stake" based on variables such as total value at risk, attack profitability, validator behavior, and slashing

https://blog.symbiotic.fi

Target Stake

Before defining the target stake itself, it's important to understand what it's meant to defend against. A protocol needs enough stake bonded to make corruption economically irrational. This baseline level, the minimum stake required to deter an economically motivated attack, is what we refer to as minCoC, or the minimum cost of corruption. The higher the potential reward from corruption, the weaker the network’s slashing conditions, or the greater its infrastructure risk and slashing overlap with other networks, the more stake is needed to secure it.

Measuring PfC

To model the required stake for economic security, it’s essential to understand what an attacker could gain. This is captured by PfC, the potential profit from corruption. For accurate modeling, we distinguish between two categories:

• Endogenous PfC: Profit extracted within the protocol, by manipulating internal mechanics.

  Examples include:

  • Transaction ordering (MEV)

  • Validation logic

  • Proof generation or minting

  • Internal slashing evasion

  This can often be measured quantitatively as average value transacted (AVT) per epoch or window, depending on the network type.

• Exogenous PfC: Profit extracted outside the protocol, using the network as a vector to influence external ecosystems (typically in DeFi).

  Examples include:

  • Arbitrage opportunities

  • Shorting or forced liquidations

  • Bridge exploits and downstream capital drains

  Exogenous PfC is more contextual and harder to measure directly. In practice, we treat it as a scalar multiplier applied to the endogenous baseline, reflecting the network’s exposure to external attack surfaces.

The target stake must be set such that the cost to corrupt (minCoC) exceeds the expected PfC: minCoC > PfC

The type of corruption profit (PfC) a network is exposed to depends on its role in the stack. Some networks (like sequencers and provers) are vulnerable to endogenous attacks, where profits are extracted through internal logic like MEV or forged proofs. Others, like oracles and bridges, are more exposed to exogenous attack surfaces, where the protocol is used to manipulate downstream systems or trigger external value extraction.

Below is a breakdown of different network types, how they map to PfC categories, and historical examples that illustrate the nature of attacks seen (or expected) in each case:

Target Stake Formula

With PfC defined, we can now formalize how to compute the minimum amount of stake required to economically secure a network. The formula below captures the relationship between the profit from corruption, the stake required to corrupt, and a set of modifiers that reflect the quality of slashing conditions, network-specific risks, and correlated validator exposure. The goal is to ensure that the cost to corrupt the system (minCoC) exceeds the potential profit, creating a deterrent that’s enforceable and economically rational.

PfC_endo can be reasonably estimated based on in-protocol activity, but PfCexo is harder to quantify. To account for this, we introduce a scaling term α, which amplifies the total PfC value based on the network’s exposure to exogenous attack surfaces. Together, PfCendo * αPfCexo represents the risk-adjusted corruption profit, capturing both internal and external threat vectors.

The denominator then adjusts this value based on network-specific defensive characteristics, including the percentage of stake required to attack, the strength and uniqueness of slashing conditions, and the network’s overall security posture. This allows us to compute a target stake threshold that dynamically adapts to the economic realities of each network or service.

Example

To illustrate how the formula performs in practice, we applied it to several representative network types — spanning from sequencers and ZK provers to oracles and data availability layers. Each example assumes a base endogenous PfC estimate and applies a network-specific multiplier αPfCexo to account for external risk exposure.

By adjusting these variables across different contexts, we show how seemingly similar services can require vastly different security budgets. For instance, the sequencer and ZK prover examples result in relatively modest target stakes, as their attack surfaces are mostly endogenous and easier to quantify. In contrast, oracles and DA layers, which are tightly coupled to downstream DeFi ecosystems, show significantly higher required stake due to harder-to-measure, externally realized attack profits.

These examples help demonstrate how network-specific risk and validator strategy design directly affect how much stake is truly needed to secure a system. The more exogenous risk a network exposes itself to, the higher the required stake to maintain economic security.

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

TL;DR of V2 Risk Framework

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

10. 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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

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

• 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

• SatLayer: https://docs.satlayer.xyz/, https://x.com/Kairos_Res/status/1912083631394238926

• Kernel: https://kerneldao.gitbook.io/kernel, https://kerneldao.gitbook.io/litepaper, https://blogs.kerneldao.com/

• 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/

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

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!

We are thrilled to announce our research partnership with Catalysis, a protocol introducing a novel security abstraction layer for decentralized networks. The collaboration will focus on the economic and security implications of Catalysis’ pioneering Shared Security Abstraction layer.

What is Catalysis?

Catalysis is building the first Security Abstraction Layer designed to standardize and unify economic security across multiple shared security protocols—including EigenLayer, Symbiotic, and SatLayer.

By abstracting the complexities of integrating with individual restaking ecosystems, Catalysis provides a unified framework for developers and node operators to deploy and manage decentralized systems such as AVSs (Actively Validated Services), BSNs (Bitcoin Secured Networks), or BVSs (Bitcoin Validated Services)—or Shared Security Networks (SSNs) in short.

Utility of Catalysis

Shared security is rapidly transforming decentralized infrastructure, but the operational burden of launching and maintaining SSNs remains significant. Catalysis addresses these challenges through:

• Cross-Ecosystem Security: Seamless integration with restaking protocols across Ethereum, Bitcoin (via Babylon), Solana, and others;

• Accelerated Deployment: Developer-friendly SDKs and streamlined documentation reduce SSN time-to-market by an estimated 80%;

• Aggregated Economic Security: Access to over $20B in restaked collateral across multiple protocols, enhancing security guarantees;

• Programmable Security Rebalancing: Real-time control over the allocation and reallocation of security via a single, unified interface.

• Infrastructure Resilience: Diversified security provisioning across shared security protocols improves fault tolerance and systemic robustness, especially for SSNs.

Motivation for Collaboration

Catalysis introduces a new layer of modularity and flexibility to the shared security stack, but also surfaces complex economic and operational risk vectors. Our research will focus on:

• Operator Exposure: Analyzing how node operators manage risk under multi-AVS commitments;

• Cascading Slashing Risk: Assessing how faults in one protocol may propagate through shared security dependencies;

• Security Layer Composability: Studying how programmable security abstraction interacts with incentive structures to maintain system-wide safety.

Our analysis will draw on game-theoretic models to understand strategic behavior across protocols, SSNs, and operators, structured risk frameworks to identify and classify systemic vulnerabilities and quantitative economic methods to model capital allocation, incentive dynamics and security guarantees under varying network conditions.

Next Steps

We will be publishing a technical article series based on this research, offering a structured view into how programmable security abstraction reshapes shared security coordination, protocol design and risk allocation.

This collaboration aims to support a deeper understanding of Catalysis’ architecture and its broader role in the evolving decentralized security landscape.

Stay tuned for new developments from our partnership with Catalysis!

Follow us on X and subscribe!

Catalysis References:

1. Website: https://catalysis.network

2. Documentation: https://docs.catalysis.network

3. Twitter: https://x.com/0xcatalysis

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 ($$np$$)

  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{np}} = f_{\text{pw}}(R_{\text{np}})$$

  ---

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

  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{wcr},a})$$ equals 10%. N/AVS $$a$$'s risk is defined as $$R_a$$.

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

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

  ---

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

  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{aprir}} = R'_{\text{wcr}} \times R'_{\text{a}}$$

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

  ---

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

  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{sor}} = \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{sor}} = f_{\text{pw}}(R_{\text{sor}})$$
  

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{np},\mathcal{L}} + R'_{\text{wcr},\mathcal{L}} + R'_{\text{aprir},\mathcal{L}} + R'_{\text{sor},\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!

In restaking, N/AVS protocols gain a unique competitive advantage: they inherit validator trust, cryptoeconomic security, protocol-level hooks, SDKs, and pre-integrated infrastructure—bypassing the need to independently bootstrap operators, secure a new network, or issue a fragile native token; this upstream advantage dramatically reduces the cost and complexity at launch. Yet, to succeed, N/AVS still need to establish moats at higher layers of abstraction, as these become increasingly commoditized infrastructure primitives.

As restaking infrastructure and ecosystems mature, the intra-N/AVS competitive landscape is rapidly intensifying, with new entrants filling out existing verticals like DA, Oracles, Sequencers, and AI/ZK Coprocessors. In this environment, early operational leverage is no longer sufficient. To remain sustainable, N/AVS must layer both trad business and restaking-specific moats across the stack. Differentiation now depends on execution at higher-order layers: modularity, ecosystem alignment, extensibility, and defensibility through usage-driven feedback loops.

N/AVS Temporal Moat Framework

While challenging to neatly categorize, this piece introduces a structured and temporal framework for N/AVS moat development, defined across three progressive stages: $$T1$$—first-mover advantage and early PMF; $$T2$$—vertical scaling and niche monopolization; and $$T3$$—horizontal expansion and the pursuit of last-mover advantage. These stages are sequential: they (generally) do not unfold in parallel, nor does $$T2$$ precede $$T1$$ or $$T3$$ substitute $$T2$$.

Motivated by Opacity Network’s momentum and early success, we believe this framework offers meaningful strategic guidance to the industry, is useful across any N/AVS category, and offers a way to evaluate how N/AVS move from mere restaking beneficiaries to defensible, dominant protocols. The article outlines core moat structures tailored to N/AVS, analyzes how Opacity instantiated them to gain early traction and PMF, and reflects on what a N/AVS may need to achieve lasting advantage.

Time $$T1$$: First-Mover Advantage and Product-Market Fit

This phase is defined by technical discovery, execution excellence, early integrations, and narrative fine-tuning. The N/AVS identifies a pain point within a narrow audience, ships a focused solution, and captures the first concrete market signal.

• 10x Product Improvement & Specialization: Tackling a well-defined pain point with a clearly superior (10x) tech product (versus the alternative), combined with a solid execution design and roadmap, confers a first-mover position in that niche market.

• Modularity and SDK Ecosystem: Providing a comprehensive SDK ecosystem and DevRel support simplifies the development process, fostering strong momentum and network effects. Robust modularity and minimal integration friction enhance UX, offering developers accessible, well-documented tools that reduce decision fatigue and encourage adoption.

• Speed of Strategic Integrations: Speed matters because it creates momentum. Strategic and rapid integrations with client applications and protocols in a niche, where no other solution is available to them, assures a significant competitive advantage;

• Narrative Positioning & Timing: Aligning with emerging narratives, such as the growing emphasis on zero-knowledge proving and increasing concerns over data centralization, creates a compelling, culturally resonant positioning for technologies like zkTLS.

Time $$T2$$: Vertical Scaling and Niche Monopolization

This stage reflects increased maturity across product, economic design, and protocol security. The N/AVS deepens its control over its initial domain, achieving a "dynamic monopoly" status.

• Dual Token Quorum Modality: Opting-in to a dual token quorum model, as offered by platforms like EigenLayer, ensures deep ETH-denominated liquidity while stabilizing a novel, potentially volatile native token. Such balance requires careful consideration of the N/AVS's protocol maturity, strategic goals, and risk tolerance, providing a useful solution whilst native-token liquidity is scarce and as the ecosystem and tokenomics evolve.

• Comprehensive Slashing Conditions: Transparent and well-defined slashing conditions protect the protocol against threats and builds trust by demonstrating a thorough understanding of potential attack vectors, credible mechanisms for adjudicating them, and a strong commitment to robust cryptoeconomic security.

• Risk-Reward Balance Optimization: Delivering consistently favorable risk-adjusted returns fosters loyalty and confidence among users and validators. Calibrating reward structures, transparent slashing logic, and awareness of cross-N/AVS dependencies and correlated risks make sustainable incentive design inseparable from protocol security.

• Product/Feature Composability: Represents the ability of the N/AVS’s product/features to integrate seamlessly with other protocols—enabling downstream use, stacking, and reuse across applications and domains, both within and beyond web3. Composability reinforces moats by making the N/AVS more deeply embedded and harder to replace.

• Expansion of Modularity and SDK Ecosystem: Strengthening ecosystem support, advancing SDK development, and reducing integration friction through continuous feedback loops solidify the N/AVS's vertical positioning and usability within a domain.

Time $$T3$$: Horizontal Expansion and Last-Mover Advantage

With a monopoly established in the original niche, the N/AVS can explore broader opportunities.

• Expansion of Product/Feature Composability: Achieving greater portability and reusability across diverse protocols and industries, facilitated by iterative feedback loops, broadens the N/AVS's applicability.

• Horizontal Expansion: Concentrically diversifying into adjacent zero-knowledge categories, such as zkML (AI verification and inference) or the-currently-disenchanted zkVoting (verifiable, private ballots), leverages existing strengths to capture new markets.

• Branding: A strong brand becomes the default choice in new categories, even before technical superiority is proven. Branding is a last-mover moat as it unlocks mindshare, trust, and recruitment in horizontal markets where users face overwhelming option sets.

Opacity Network as a $$T1$$ Case Study

Opacity Network is a zkTLS AVS on EigenLayer that enables private, verifiable retrieval of HTTPS data using a combination of TLS (Transport Layer Security) interception and ZK proofs. Simply explained, it allows users to prove claims about remote web data—without revealing the underlying request or contents—bridging web2 trust gaps for web3 applications.

Opacity has successfully reached time $$T1$$, securing first-mover advantage and achieving real-world product-market fit in the zkTLS space:

• 10x Product Improvement & Specialization: Developed the first-of-its-kind zkTLS + MPC (Multi-Party Computation) infrastructure to enable private, verifiable retrieval of Web2 data—where MPC ensures sensitive session data remains hidden even during collaborative proof generation. Purpose-built for secure Web2-to-Web3 data bridging;

• Modularity & SDK Ecosystem: Already offers multi-platform developer tools—inclusing iOS, Android, React Native, and Flutter SDKs—that facilitate and accelerate adoption and ease of integration, enabling developers to seamlessly incorporate Opacity's product/features into their applications;

• Speed of Strategic Integrations: Demonstrated strong interest by securing adoption and integrations with applications like Earnifi, Digg, and ElizaOS, which now rely on Opacity’s proofs for data authentication and verification across various financial and agentic use cases;

• Narrative Positioning & Timing: Positions itself as infrastructure for verifiable, privacy-preserving user data, aligning with current industry trends and concerns.

The posts below offer a more insight and deep-dives into Opacity’s zkTLS architecture and real-world traction:

nader dabit

@dabit3

zkTLS is the first crypto-native technology that's actually onboarding the masses, and I think it's still wildly underrated.

zkTLS is already being used by top apps in the App Store as well as by some of the most successful web2 founders (and the number is growing rapidly).

644

6:02 PM • Apr 4, 2025

Pavel Paramonov

@paramonoww

How can we make the use of web2 data in web3 actually private and verifiable?

Many people who claim that web3 is the new internet define it with the phrase "read, write, own." The "read" and "write" parts are clear, but when it comes to "own" in terms of data, we hardly own

244

2:17 PM • Feb 11, 2025

As Opacity transitions into $$T2$$, the focus shifts to vertical scaling and consolidating dominance within the zkTLS category: the platform's current positioning as infrastructure for verifiable, privacy-preserving user data indicates a strategic alignment with broader industry trends, suggesting readiness for deeper (vertical) integration and expansion within its niche. Durable horizontal expansion and branding image at $$T3$$—perhaps into adjacent ZK-native domains such as zkML or zkID (verifiable identity)—must be staged carefully. Advancing too early risks diluting focus and forfeiting the entrenchment, feedback loops, and ecosystem lock-in required to secure true last-mover advantage.

Conclusion

As restaking unifies the economic security layer across N/AVS, the locus of competition shifts upward — toward protocol specialization, aligned incentive structures, and seamless integration into application workflows. Security is no longer a differentiator; execution is.

Opacity has exemplified this transition at $$T1$$: achieving product-market fit not through novelty alone, but through tightly-scoped functionality, developer-first tooling, and a well-timed narrative around private data verifiability.

Looking forward, the N/AVS that endure will evolve into trust-layer platforms—not just offering cryptographic guarantees, but defining composable primitives that interlock with broader systems. The strategic progression outlined here—from niche precision to vertical consolidation to durable expansion—applies across the whole N/AVS landscape, whether in zkTLS, sequencing, or interoperability. The path to lasting dominance begins with depth, not breadth.

Subscribe and follow us on X!

In this article, we introduced a protocol risk evaluation approach designed for restaking portfolio management on any restaking platform. This methodology isn’t limited to restaking — any staking protocol can be assessed in the same way. Unlike most existing approaches, we focus on fundamental analysis of a protocol's slashing risk. To illustrate this, we evaluate six networks and explore how this framework can be applied to portfolio construction from a restaker's perspective.

Worth noting that we’ve stuck to Symbiotic's “network”, for notation of protocols using stake for cryptoeconomic security, despite various platforms using different acronyms to describe the same kind of concept. For example, EigenLayer uses Actively Validated Services (AVS), Babylon uses Bitcoin Validated Services (BCN), Jito uses Node Consensus Networks (NCN), etc. We think "network" is the best fit, since the framework we’ve built can be applied beyond the restaking ecosystem.

Check the full article on HackMD and our Twitter thread for a succinct overview:

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

tokensight

@tokensightxyz

Restaking Network Risk Evaluation
Developing a Fundamental Approach

We have launched, with @P2Pvalidator, an in-depth research piece on restaking networks/services slashing risk evaluation, at a fundamental protocol level!

Full study → hackmd.io/@lCkxYGq-RPqCf…

P2P.org

@P2Pvalidator

.@P2Pvalidator and @tokensightxyz have launched a new study on Ethereum Restaking risks.
The study examines how the same collateral used across multiple protocols creates unique security challenges.

You can follow the structured study, Staking Network Risk Evaluation:

13

11:12 AM • Apr 3, 2025

A short summary with the top 5 insights:

1. There Is No Industry Standard for Evaluating Network Risk

Despite the growing financial and technical complexity of restaking, the industry lacks a unified methodology for assessing slashing risk at the protocol level. Existing approaches largely focus on validator behavior, ignoring the nuanced and sometimes systemic risks embedded in networks’ designs. This paper proposes a structured, first-principles framework that fills this gap by evaluating risks rooted in the architecture, consensus design, and operational characteristics of networks themselves—providing a basis for protocol-level risk assessment.

2. Statistical/Stochastic Models Alone Are Insufficient for Slashing Risk Estimation

Slashing events are rare, inconsistent, and partially influenced by idiosyncratic protocol design flaws, making purely empirical, data-driven, assumption-based approaches unreliable. Historical data is either too sparse or not transferable across network architectures. The paper advocates for fundamental infrastructure assessment as essential not only in the absence of data, but also as a long-term anchor for modeling stochastic risk estimations.

3. A Structured, Weighted Scoring Framework Makes Risk More Quantifiable

To enable meaningful evaluation and comparison, we introduce a scoring system built around seven weighted metrics: Execution Architecture, Consensus Design, Slashing Conditions, Security Audits, Code Complexity, Maturity, and Reputation. Each network is assigned a score across these dimensions, calibrated by weighting and confidence levels that reflect the importance and availability of information. The resulting composite score (R) captures both the expected risk of slashing and the uncertainty of the evaluation itself, allowing restakers and researchers to rank networks based on risk exposure and make more informed, portfolio-aware decisions.

4. Unified Metrics Enable Comparability Across Diverse Network Categories

The framework’s power lies in its ability to normalize risk evaluation across distinct network categories—DA, Oracles, ZK, DePIN, AI, and Interop. By abstracting protocol-specific features into universal metrics and scoring them within a consistent structure, the framework enables side-by-side comparison of otherwise incomparable protocols, making it an effective tool for restakers managing diversified exposure across different networks.

5. The Composite Risk Score Serves as a Proxy for Expected Stake Loss

The final output of the framework—the network risk score $$(R)$$—functions as a proxy for expected slashing loss and is designed to be actionable: can be plugged into yield/risk optimization models, used within a broader portfolio-based decision model, or on further research into network covariance and cascading risks. As richer restaking-related data becomes available, this framework will support dynamic recalibration while remaining grounded in first-principles logic.

Follow us on X and subscribe!

We are thrilled to announce our partnership with P2P on researching N/AVS risk fundamentals across restaking protocols!

P2P: Leading Staking Infrastructure Provider & Operator

P2P.org is a non-custodial staking infrastructure and technology provider, delivering institutional-grade solutions such as Staking-As-A-Business (ETH and BTC), EigenLayer/Symbiotic Restaking, DVT Staking, Data Services, and robust API Integrations, across over 35 PoS blockchains.

In the restaking domain, P2P is integrated with EigenLayer (largest Operator by TVL) to boost security and economic opportunities for (re)stakers, facilitated by their dedicated Staking API. P2P is also collaborating with Symbiotic to improve flexible restaking solutions within the protocol and with Babylon to support non-custodial BTC staking. Additionally, P2P has collaborated with SSV.network to incorporate Distributed Validator Technology (DVT) into its staking services, for added security.

Strategic Partnership Motivation

N/AVS are protocols with deployed infrastructure on restaking protocols, like EigenLayer and Symbiotic, seeking shared security provided by a network of slashable Operators that validate tasks. Particularly with the introduction of Slashing, it becomes imperative for Operators like P2P to develop deep protocol-level understanding of these services, mainly around execution and consensus profiles, and overall security requirements.

In collaboration, Tokensight and P2P have developed foundational and technical materials on N/AVS risk fundamentals to the wider restaking audience and are excited to release them soon! We envision exploring additional vectors of research and development across the space.

Learn More

Learn more about P2P on their Website, Product Solutions, and Twitter.

For additional resources, check the below article by P2P and Tokensight's Paragraph account.

Introduction to Restaking Risk Framework

Restaking in presents unique opportunities and challenges. This article explores the risks involved in restaking, such as smart contract vulnerabilities, operator issues, and protocol flaws, and offers practical strategies to mitigate these risks. Whether you're an experienced investor or a newcomer, this guide provides essential insights for secure and profitable

https://p2p.org

Stay tuned for new developments from our partnership with P2P!

Follow us on X and subscribe!

Contents

1. Abstract

2. Breakdown

   2.1 Data Workflow

   2.2 Consensus Architecture

3. EIGEN Fault Types for eOracle

   3.1 Objectively Attributable Faults

   3.2 Intersubjectively Attributable Faults

   3.3 Non-Attributable Faults

4. Corruption Scenarios for eOracle

   4.1 Corruption Analysis with Pooled Security

   4.1.1 Liveness Tolerance Violation (>1/3 Stake Attack)

   4.1.2 Safety Tolerance Violation (>2/3 Stake Attack)

   4.1.3 Factors to Consider When Estimating Cost of Corruption & Profit from Corruption

   4.2 Corruption Analysis in an Intersubjective Staking World with Attributable Security

   4.2.1 Cryptoeconomic Security

   4.2.2 Strong Cryptoeconomic Security

5. eOracle: CoC vs. PfC Scenarios Under Different Slashing Types

6. Conclusion

1. Abstract

The present article by Tokensight has been written to provide a technical overview of eOracle, as an oracle AVS on EigenLayer. In this piece, we’ll explore its data workflow and consensus architectures, types of objective and intersubjective faults, and potential corruption scenarios that may occur along those faults.

2. eOracle Breakdown

eOracle is a decentralized oracle solution that securely delivers external data to blockchain networks. It sets a new security standard for oracle technology by leveraging a dual staking system: restaked ETH via EigenLayer for objective-fault security, and eOracle's native token staking for intersubjective-fault security (TBD, yet to be launched). This dual quorum model ensures robust cryptoeconomic security, with protection anchored in both restaked ETH and eOracle’s native token. It is an outstanding question whether EIGEN will also be used for intersubjective slashing within eOracle's system and its specific utility function if so.

The protocol's business model focuses on two main user segments: Data Users (DApps, chains, or entities requiring on-chain external data) and Custom Oracle Builders (developers or companies creating unique oracles on eOracle's infrastructure).

By building on EigenLayer, eOracle benefits from:

• Bootstrapping: eOracle leverages EigenLayer to instantly access a large independent pool of Ethereum node operators, solving the critical challenge of bootstrapping a trustless system, offering customers a robust, decentralized oracle service from day one.

• Unparalleled Security: The protocol benefits from the security of restaked ETH, providing robust cryptoeconomic guarantees comparable to other top networks, which minimizes the risk of oracle failure.

• Capital Efficiency: EigenLayer’s shared security model significantly lowers operational costs, allowing eOracle to offer high-quality, secure oracle services at a much lower cost to both data users and oracle builders.

2.1 eOracle Data Workflow

Overviewing eOracle’s data processing workflow:

• Data Sourcing: eOracle operators connect to APIs or WebSockets, fetching real-time data from publicly accessible sources. The data type and frequency of reporting are defined programmatically by the user or application.

• Data Signing: Operators cryptographically sign the fetched data with their private key to ensure its integrity and authenticity.

• Transaction Submission: The signed data is submitted as a transaction to the EO-chain, with gas fees paid in native tokens or ETH. The transaction includes data, signature, and operator identity.

• Identity Verification: Upon receiving the transaction, an eOracle node verifies the operator’s signature using public key cryptography to authenticate the report.

• Data Aggregation: Verified data is aggregated on the EO-chain using various schemes, ranging from statistical averages to more sophisticated methods such as Byzantine fault-tolerant aggregation to filter out malicious reports.

• Data Publication on Target Blockchains: Aggregated data, once validated, is published on target blockchains with a Merkle tree structure, allowing users to verify data using a Merkle proof.

2.2 eOracle Consensus Architecture

eOracle operates an independent PoS blockchain called the EO-chain, powered by EigenLayer operators and using the eBFT consensus mechanism, which ensures transparent, immutable data settlement and aggregation through on-chain verification, while offloading computation from target chains.

Now diving in in detail:

• Operator Stake Validation: Follows a stake-weighted approach: the influence of an operator is proportional to their staked value, ensuring that those with larger stakes have a stronger say in the final outcome.

• Permissionless Validation: Any node can validate data reports, aiming therefore for decentralization and censorship resistance by preventing a single authority from blocking or altering data.

• Consensus Formation via eBFT: The eBFT mechanism ensures that more than two-thirds of validators must agree on the final aggregated data before it’s confirmed for accuracy and network liveness.

• Immediate Block Finality: Operators propose blocks with immediate finality, avoiding forks and reorgs, which enhances efficiency and fault tolerance, making data confirmation quick and reliable.

• Cryptographic BLS Signatures: The aggregated result is cryptographically secured by BLS threshold signatures, allowing multiple validator signatures to be combined into one, ensuring data integrity while optimizing network performance.

• Slashing and Reward Mechanism: Honest validators are rewarded, while those submitting malicious or inaccurate data face slashing penalties on their restaked ETH or native tokens, encouraging consistent integrity in the network.

3. EIGEN Fault Types for eOracle

On the EIGEN: The Universal Intersubjective Work Token whitepaper, EigenLayer introduced three distinct ways how faults can be attributed to a malicious party:

3.1 Objectively Attributable Faults

Objectively-Attributable Faults faults that can be proven both mathematically and cryptographically, independent of subjective opinions. Examples include deterministic faults like execution validity, where anyone can verify if a node runs a piece of code on a distributed VM and checks if the output is correct based on predefined rules.

• Fault examples for Oracles:

Data Corruption & Signing Issues (Double-Signing & Wrongful Block Signing): Data could be manipulated via the Data Validators' reporting, potentially profiting from subsequent user malfunctions; also if nodes sign two conflicting signatures—either maliciously or non-maliciously—, then it can be proven on-chain that the nodes have committed an on-chain attributable fault.

3.2 Intersubjectively Attributable Faults (TBD)

Intersubjectively-Attributable Faults require a broad-based consensus agreement among active observers of the system. For example, verifying the accuracy of a price reported by an oracle depends on collective agreement, as it may not be immediately verifiable. Intersubjective staking involves achieving consensus among honest participants to confirm events that are not easily observable or occur off-chain.

• Fault examples for Oracles:

Sybil & Data Stalling: Fake identities can be spun up by adversaries which may not be clearly/immediately verifiable onchain, creating a need for consensus from onlookers. Data could be halted on the oracle's reporting stage, which may lead to disagreements on whether an attack occurred. To mitigate data-withholding issues, contracts can specify a maximum allowable period for withholding data, such as up to 1 day, to clearly define what constitutes an attack.

Favourable and concrete incentives and infrastructure that facilitate light nodes to join and monitor the network these kinds of intersubjective faults would also be strongly advised. Light nodes will play a important role in observing, inputting, and assisting on consensus-reaching toward these intersubjective matters, and therefore, ultimately, be useful in fostering intersubjective cohesion and mitigating intersubjective fracture.

As per EigenLayer's whitepaper:

"To make the faults intersubjectively attributable, the AVS may need to focus on developing robust monitoring infrastructure including light clients. This can lower the cost-of-monitoring, ensuring that there will be a wide net of community members from EIGEN’s social consensus who will be operating the AVS’s light node software for monitoring the EigenLayer operators that have opted into the AVS."

"Intersubjective cohesion. An important requirement for social consensus to be able to resolve intersubjective faults for potentially verifiable digital tasks is that all honest members of social consensus should be in cohesion about what the correct fork of bEIGEN after an intersubjective challenge is triggered."

"Intersubjective fracture. If an AVS doesn’t carefully design its light node architecture for users to utilize when resolving intersubjective faults, it presents the risk of a fracture in the social consensus."

Learn more on Tokensight’s deep-dive post dedicated to Intersubjective Fracture and Cohesion within the EIGEN token.

3.3 Non-Attributable Faults

Non-Attributable Faults occur when only the victim is aware of the fault, preventing third parties from conclusively determining whether a fault has occurred or if there is malicious intent within the system or by an individual. For example, in a secret-sharing system where the secret is revealed only after a predetermined period, collusion among nodes may lead to premature disclosure of the secret, which could be undetectable without external knowledge.

• Fault examples for Oracles:

Validator & Third-Party Providers Collusion: When a group of validators colludes to discreetly approve incorrect data validations, the fault becomes non-attributable, as it is challenging for external observers to identify the responsible validators. This kind of collusion obscures fault origins, requiring sophisticated collusion-resistant solutions and enhanced decentralization.

4. Corruption Scenarios for eOracle

Cost of Corruption is defined as the cost enforced by the system on an attacker or group of colluding attackers to successfully carry out and compromise eOracle's security. Profit from Corruption comprises the net value the same attacker or group of attackers is able to extract after performing the attack.

In a standard pooled security context for a single AVS the below holds true:

4.1 Corruption Analysis with Pooled Security

In the context of intersubjective faults, assessing the profit from corrupting an Oracle service like eOracle involves complex social dynamics. Instead of straightforward slashing, malicious operators will see their stake forked, a process governed by the social consensus within the EIGEN ecosystem. This highlights the critical role of consensus-based approaches in managing and resolving disputes over intersubjective faults.

Social consensus mechanisms and forking conditions must consider both Liveness and Safety when developing risk mitigation strategies and modeling potential attack vectors for this type of AVS, in preparation for EigenLayer’s Slashing release.

4.1.1 Liveness Tolerance Violation (>1/3 Stake Attack)

This scenario occurs when validators holding more than one-third of the network's stake interfere with the smooth operation of the system. Such interference can result in delayed or non-production of data availability attestations, impacting the network's ability to operate efficiently. This type of manipulation is classified as an Intersubjectively Attributable Fault—due to its off-chain and concurrently observable impact—where the malicious activity can include:

• Data Censorship: Deliberately blocking or ignoring certain transactions, thus manipulating the visibility and processing of data. This selective interference can distort the network's perception of data availability.

• Data Stalling: Intentionally slowing down the data verification and attestation processes. This action can increase latency, affecting the timeliness and reliability of data availability, and may lead users to question the system’s effectiveness.

Cost of Acquiring ≥1/3 Stake

Dual Staking Scenario (Restaked ETH and Native Token Staking): With $1.5B of restaked Ether in the eOracle AVS contract on EigenLayer and an additional $1.5B of native token staked, an attacker or group of attackers would need to acquire, at least, $500M worth of restaked ETH and $500M of staked native token, totalling $1B in required capital to corrupt the network. The dual staking mechanism effectively doubles the cost of corruption compared to the solo restaked ETH or solo native token staking scenarios.

4.1.2 Safety Tolerance Violation (>2/3 Stake Attack)

This condition arises when validators control more than two-thirds of the network's stake, enabling them to manipulate the data validation process. Such a level of control can lead to the certification of false data as correct, which is a direct threat to the integrity of the network. This type of manipulation is classified as an Objectively Attributable Fault—due to its deterministic validity and on-chain observable impact—where the malicious activity can include:

• Data Corruption: The process of certifying incorrect or compromised data as valid and available, which can deceive the network and its users into relying on false information.

• Double-Signing: Engaging in the signing of conflicting data attestations, thereby creating ambiguity and mistrust regarding the true availability and integrity of data.

Cost of Acquiring ≥2/3 Stake

Dual Staking Scenario (Restaked ETH and Native Token Staking): With $1.5B of restaked ETH in the eOracle AVS contract on EigenLayer and an additional $1.5B of native token staked, an attacker or group of attackers would need to acquire, at least, $1B worth of restaked ETH and $1B of staked native token, totaling $2B in required capital to corrupt the network. Effectively doubling the cost of corruption compared to the solo restaked ETH or solo native token staking scenarios.

Profit from Corrupting Stake

The potential Profit from an attack can be calculated as:

Profit = Value of Data — Cost of Acquiring the Necessary Stake — Cost of Executing the Attack*

• although being somewhat of a subjective variable, the manipulation of financial outcomes, based on corrupted data, could potentially be exploited for financial leverage, in an indirectly monetary or even non-monetary way.

For example, if an attacker incurs a $2B cost to garner $500 million worth of data, the direct financial outcome appears unprofitable. However, considering the indirect benefits like strategic dominance or long-term market manipulation may provide a broader context to justify such expenses, in an oracle scenario.

4.1.3 Factors to Consider When Estimating Cost of Corruption & Profit from Corruption

Factors to Consider To Increase Cost of Corruption

• Transport Layer Security (TLS/zkTLS): TLS secures data exchanges between validators by encrypting communications and authenticating participants, therefore raising the difficulty and cost for attackers seeking to corrupt the network.

• Zero-Knowledge Proofs: A few types of zk proofs could be implemented for eOracle’s benefit in the fields of data privacy, particularly, increasing its security profile further when faced with an attack.

• Trusted Execution Environments (TEE): Secure portions of hardware that generate and securely store validator keys and databases of previously signed data. By design, they enhance security without compromising scalability.

• Distributed Validator Technology (DVT): Incentivizes client diversity through the distribution of the validation process across multiple operators, reducing the risk of a single chokepoint in case of failure/corruption. Constitutes a deterrent for a malicious attacker to proceed or makes it significantly more resource-intensive to forge.

• Legal Consequences: Public entity validators not only incur considerable financial costs but also jeopardize their social standing and may encounter legal repercussions if they partake in malicious actions.

Some of the above, are being actively researched by the eOracle team.

Factors to Consider When Estimating and Reducing Profit from Corruption

• Integration of Oracle/Bridge Solution: To restrict the potential PfC extracted from eOracle, an oracle or bridge solution can be set-up to restrict the value flow within the period of slashing, or an oracle can have bounds on the total value transacted within a given period.

• Withdrawal Lock-Up Period: Lock-up period applied to validators for security against corruption attacks.

• Associated Costs: This includes both the acquisition cost of the necessary stake and operational expenses related to the attack.

• Legal and Reputational Risks: Potential legal consequences and reputational damages can significantly deter these attacks.

By considering both intersubjectively and objectively attributable faults, stakeholders can better understand the varied nature of potential attacks toward eOracle and develop more effective defense mechanisms.

4.2 Corruption Analysis in an Intersubjective Staking World with Attributable Security

4.2.1 Cryptoeconomic Security

Cryptoeconomic Security: "For any attacker, the maximal profit extractable from attacking the safety (profit-from-corruption) is smaller than the minimum cost enforced by the system on the attacker (cost-of-corruption).", as per the EigenLayer whitepaper.

However, there's a fundamental problem: the profit-from-corruption is non-measurable (or almost impossible to measure). The adversary may have perverse incentives outside the system’s scope of measurement. Moreover, this notion does not guarantee that the user actually gets compensated for the value that they lost in the case the attack happened in fact. We must therefore define a more robust notion of cryptoeconomic safety.

4.2.2 Strong Cryptoeconomic Security

Strong Cryptoeconomic Security: "Any user should be compensated a pre-specified amount in the event that the safety guarantee to the user is violated.", as per EigenLayer whitepaper.

This security threshold is accomplished if the Redistributable Stake obtained by the AVS is greater than the Harm from Corruption. The equation is fully measurable onchain:

• Redistributable Stake is the amount of stake that is uniquely attributable to the affected AVS for the fault, it allows to self-specify how much security they want;

• Harm from Corruption can be estimated by attempting to simulate scenarios where funds can be extracted, like censorship within the proof period for Brevis, with confidence intervals, time-series scenario analysis, and Value-at-Risk concepts in mind, once AVS payments and attributable security are fully functional (very much central to Tokensight's ethos).

If an objectively-verifiable misbehavior is detected, the operator’s bEIGEN stake will be slashed. In cases of agreement-based intersubjective misbehavior, an operator’s bEIGEN1 token will be be burned and the compliant and remaining bEIGEN1 tokens forked into bEIGEN2, resulting in the loss of access to the former and the inability to redeem the latter.

5. eOracle: CoC vs. PfC Scenarios Under Different Slashing Types

The chart illustrates the balance between the Cost of Corruption (CoC) and the Profit from Corruption (PfC), based on the Cryptoeconomic Security section of eOracle’s documentation, emphasizing the AVS’s cryptoeconomic security across three scenarios.

• The dark blue bars represent CoC: Restaked ETH Slashing, showing the penalties for misbehavior through ETH stake slashing.

• The light blue bars represent Native Token Stake Slashing, which adds additional slashing penalties for malicious actors, at the AVS level.

CoC remains constant across all scenarios illustrated, representing the economic deterrent to corrupt the oracle system and profiting from it.

The PfC variables show the potential profit attackers can gain:

• The dark green bars represent Profit from Manipulation (PfM), where internal profit is gained from corrupting data (e.g., price updates).

• The light green bars show Profit from Depreciation (PfD), or external profit from short selling the protocol’s token post-attack.

The scenarios illustrate varying short-selling interest levels, with the high PfM & high shorting scenario exceeding the CoC, indicating greater profit potential for attackers.

The CES (Cryptoeconomic Security) margin, the difference between CoC and PfC, determines whether the protocol is secure or vulnerable. In the low and medium scenarios, CoC outweighs PfC, keeping the system secure. However, in the high PfM & high shorting scenario, the attacker’s potential profit surpasses the CoC, making the system vulnerable. This highlights the need for strong CoC and appropriate slashing mechanisms, especially when the market is prone to short selling pressures due to periods of high interest, ensuring eOracle remains secure and resilient against external and internal threats.

A more refined definition for CES focuses on attack deterrence and effort to execute an attack by a) making it operationally difficult and risky through slashing penalties so it’s not attempted, and b) requiring high coordination and budgeting efforts to carry it out successfully.

Visit eOracle’s detailed and comprehensive section on CES at:

Cryptoeconomic Security | eOracle

While traditional oracles rely on their proprietary tokens to maintain ecosystem health and secure operations, eOracle introduces a novel security approach with its dual-token design. The model synergizes the specific advantages of a protocol-dedicated token with the enhanced security and economic stability provided by a well-established token like ETH, used for staking purposes.

https://docs.eoracle.io

A swath of multi-agent simulations based on actual data and more precise risk parameters will be central to understand the risks computed through various stress scenario analysis for Oracles. Tokensight plans to do much more in this topic going forward.

6. Conclusion

As covered in the Breakdown section, with this AVS on EigenLayer, developers can now leverage a decentralized and secure Oracle framework, tap into restaked ETH for enhanced cryptoeconomic security, and build custom oracle solutions with reduced operational costs, all while benefiting from EigenLayer’s shared security model and the high scalability of eOracle.

To wrap up this in-depth piece of eOracle, some important considerations remain about its long-term viability and operational efficiency:

1. Technological & Competitive Edge: Will eOracle explore and securely implement TEEs, TLS, light node infrastructure or other valuable solutions to improve its product and front-run alternative solutions that will be built as AVSs?

2. Faults' Natures: How effectively will intersubjectively-attributable and non-attributable faults, especially in high-stakes scenarios involving high traffic, be managed? What kinds of scenarios should we monitor that may trigger these novel kinds of faults?

3. Operator Dynamics: What will be the criteria for selecting operators for eOracle? Is there a centralization risk, and how diverse or entrenched will the operator set be?

4. Attack Vectors: Are there more effective or damaging strategies for attacks, even against such a robust zero-knowledge architecture? What other vulnerabilities could potentially be exploited?

5. Code Complexity: As an AVS, how complex will eOracle underlying code be, and what might this complexity mean for system robustness and bug susceptibility? How well defined will the parameters of slashing intersubjective be (helpful in mitigating code complexity through excessive slashing rules for objective faults)?

These inquiries are central for the community to consider as eOracle becomes fully operational in the coming months. Tokensight will continue to monitor eOracle's development and provide updates through further technical research.

Follow us on X at @tokensightxyz!

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!

Ebisu <> Tokensight Partnership Motivation

A few weeks ago, Ebisu Finance and Tokensight announced their strategic partnership to strengthen the risk understanding and underwriting of liquid restaking tokens (LRTs) as collateral assets in Ebisu’ DeFi marketplace. The collaboration focused on developing a comprehensive framework to conduct infrastructure risk assessments on LRTs based on their portfolio-selected Actively Validated Services (AVS) on EigenLayer.

Ebisu Finance triggers the potential of LRTfi through two main products:

• Ebisu Money: A collateralized debt position (CDP) protocol that lets users borrow US dollar or ETH denominated stablecoins against liquid restaking tokens (LRTs).

• Ebisu Earn: A suite of restaking yield vaults that automate real yield generation across a basket of LRT DeFi strategies providing diverse exposure to various LRTs and restaking protocols.

As liquid restaking protocols begin composing their AVS portfolio strategies, LRTfi protocols like Ebisu must look beyond traditional DeFi metrics and consider the infrastructure risk introduced by EigenLayer services. Using our mathematical, research-driven frameworks, we have guided Ebisu in evaluating LRT collateral health by focusing on these infrastructure risks. We've recommended on protocol parameters benchmarks, such as deposit caps and minimum collateralization ratios, to prevent liquidations, mitigate risky lending practices, and ensure the secure scaling of its DeFi marketplace.

Assessing the soundness and solvency of these new assets from first principles is essential. Let’s dive in!

AVSs and LRTs are core to the EigenLayer ecosystem. AVSs are services built on EigenLayer that benefit from pooled security, costs reduction, and a simplified initial bootstrapping process. They share a common security base with other AVSs, much like how dApps on Ethereum leverage the main L1's security.

LRTs are similar to liquid staking tokens, allowing users to maintain liquidity while restaking formerly illiquid assets. They enable restaking across multiple protocols at once, creating both new opportunities and new risks. Unlike traditional staking tokens, LRTs factor in infrastructure risk as well, as their yield and security depend on the health and performance of the AVSs on EigenLayer.

Tokensight’s framework for underwriting infrastructure risk for AVSs evaluates each service's risk profile based on various components in their architecture. As detailed below, the framework starts by identifying the vulnerabilities and strengths of each AVS within their particular category, which influences the overall risk profile of the LRTs that support it.

Key Parameters in AVS Risk Calculation:

1. AVS Business Model: Considers the AVS's business model, such as Pure Wallet, Tokenize the Fee, Dual Staking Utility, or Native AVS Token Payment, and evaluates the balance of the token composition. At this early stage of development, all AVSs are assumed to use a Dual Staking model with a 50/50 ETH to native AVS token balance;

2. AVS Protocol Security: Evaluates the protocol's security by considering the number of code audits performed, GitHub code coverage percentage, and overall code complexity, which may affect vulnerability to bugs;

3. AVS Operator Profile: Evaluates the reputation, geographical distribution, and level of entrenchment of EigenLayer operators validating the AVS;

4. Protocol Execution Mechanics: Examines the reliability and security of the various dependencies, smart contract executions, and cryptographic algorithms used by the AVS at an execution level;

5. Protocol Consensus Design: Evaluates the type and security of the protocol’s consensus mechanism and node network (if separate from EigenLayer’s), focusing on its ability to maintain network integrity and liveness;

6. Protocol Risk Mitigation Solutions: Evaluates the protocol's architectural vulnerabilities and the effectiveness of its risk mitigation mechanisms.

Each parameter is assigned a quantitative value within a specific range, and the product of its likelihood and impact scores is also factored into the calculation. Additionally, two overarching AVS parameters—regulatory risk and maturity level—are also considered. An Individual AVS Risk Score (IR) is then calculated, reflecting the risk of the AVS experiencing a fault (malicious or non-malicious) and being slashed.

The reader can view a qualitative and simplified version of this framework in the AVS risk matrices on the AVS page of u--1:’s website. Public-facing risk assessments have been integrated, through our partnership with u--1: for EigenDA, Omni, Lagrange State Committees and ZK Coprocessor, and Brevis, with more to be added in the future.

https://u--1.com

AVSs | u--1

Live data for AVSs including TVLs and largest operators

The following analysis is based on u--1:’s real-time AVS registrations for Ether.fi, Renzo, Puffer, and Kelp LRTs:

The LIR score reflects the overall risk of each LRT, based on the combined individual risk scores of its registered AVSs, in isolation. This calculation helps determine each AVS's contribution to the LRT portfolio's total risk.

Where:

• IR is the Individual Risk score for each registered AVS;

• w represents the proportion of the total amount an LRT's operators have delegated to each AVS, divided by the total amount delegated to all AVSs in its portfolio. For instance, if an LRT has delegated $1B in total to AVSs, with $100M allocated to EigenDA, the weighting (w) for EigenDA would be 10%;

• a represents the sequential number of AVSs (n) in a given LRT portfolio, starting with 1;

• LIR represents the aggregate risk score for the LRT portfolio (t), factoring in the individual, isolated risks of each AVS in its portfolio, weighted by the LRT's relative delegation to each AVS.

While the LIR score assesses risks based on individual AVSs in isolation, LPR provides a broader perspective by considering the collective risks of the AVSs within a pooled security ecosystem. It captures the aggregate risk of the ecosystem-aware AVS portfolio, accounting for its interdependencies and cumulative risk exposures.

Where:

• N quantifies the added risk based on the number of AVS registration an LRT has;

• C quantifies the added risk based on the concentration of AVSs in the same category;

• A quantifies the added risk based on the aggregate risk score of the AVS portfolio, considering the grouped risk of individual AVSs;

• LIR is directly dependent on and proportional to the sum of the independent variables N, C, and A. By summing these variables and multiplying by LIR, we capture their combined impact and how they amplify the original LIR value.

• LPR therefore offers a comprehensive view of the interdependent risk exposure within the pooled ecosystem of AVSs selected by the LRT.

At this early stage and when slashing is firstly introduced, LRTs face significant risk exposure if they delegate to an excessive number of AVSs (N), particularly if these AVSs are in the same service category (C) due to increased dependency in case of an exploit, and if the majority of their AVSs have high individual infrastructure risks (A), as computed by IR above.

The calculated LIR and LPR scores reveal varying risk levels across the different LRTs. This stratified approach helps maintain the overall health and stability of the ecosystem by tailoring risk management measures to each LRT's specific profile.

As our research and understanding progress, additional insightful metrics, such as operators' risk profiles based on delegated AVSs, level of operators' entrenchment onto a set of AVSs, and the degree of the probable cascading effects pursuant to infrastructure vulnerabilities and AVS slashing conditions, will be integrated into our calculations to more accurately measure the complex nature of these products, within EigenLayer and other restaking protocols.

Ultimately, it's crucial for Ebisu and LRTfi protocols to set appropriate Deposit Caps (DC) and Minimum Collateralization Ratios (CR) for each LRT, as a collateral asset on their marketplace, based on their underlying, specific risks. These metrics help the protocol mitigate potential liquidations and maintain solvency, especially in adverse conditions or black-swan events:

• DC is calculated by adjusting the total allowable amount for LRT deposits (as set by Ebisu) according to each LRT’s Pooled Risk score (LPR), which ensures that each deposit cap aligns with the risk profile of its LRT; preventing undue exposure to high-risk collateral.

• CR is determined by relativizing the pooled risk of an individual LRT (LPR) against the aggregate pooled risk of all LRTs. The CR value is set to maintain adequate overcollateralization (with a baseline of 100%), ensuring sufficient collateral is available to cover potential losses and protect the protocol from cascading liquidations and market volatility.

By setting DeFi protocol parameters like deposit caps and collateralization ratios according to the framework above, Ebisu Finance can effectively manage risk and maintain solvency and consumer trust in its DeFi marketplace.

The Ebisu team is also advised to enhance these assessments with additional DeFi metrics for LRTs, such as liquidity, volatility, and supply, to gain a comprehensive view of the health and stability of restaked assets. Upcoming research on slashing conditions and their impacts will also be a key focus.

As liquid restaking on EigenLayer evolves, robust risk assessment frameworks are becoming increasingly vital. The partnership with Ebisu Finance provides a structured approach to managing these new risks, ensuring LRTs are evaluated based on their infrastructure security, aligning with Ebisu’s commitment to building a fully decentralized, censorship-resistant protocol.

Visit the official Ebisu Finance website to dive deeper and stay updated on their latest developments! Also learn more on EigenLayer by checking their website.

Learn more on their ethos and the LRTfi space on the insightful blog posts: Introducing Ebisu & ebUSD and Underwriting LRTs: Balancing High Yields with Security.

Follow us on X!

Our collaboration aims to enhance community understanding of the risks within the restaking ecosystem through rigorous research and analytics.

Assessing and understanding this complex and novel set of risks from first principles is essential. This partnership provides a deeper dive into the risks, ensuring that the restaking and crypto community are well-informed and equipped to navigate the space well.

We have pursued a simplified approach based on the qualitative assignments on the degree of risk (low to high <-> 1 to 3) per AVS component on the AVS matrices integrated on u--1. The aggregate risk score per AVS is the result of the sum of the quantitative values of their components.

AVS component A => low risk => 1
AVS component B => medium risk => 2
AVS component C => high risk => 3

Example for EigenDA:

• Matrix: https://u--1.com/avs/0x870679e138bcdf293b7ff14dd44b70fc97e12fc0

• API: https://api.u--1.com/v1/avs-risks-summary

Summing each quantitative score per component, we arrive at a final aggregate value of 11, representing EigenDA's risk score. The risk scores in the API can be queried for all integrated AVSs: EigenDA, Omni, Lagrange ZK Coprocessor and State Committees, and Brevis.

This approach provides users with a consumer-friendly, initial quantitative assessment for AVS risks. We plan to work further with u--1: to offer greater granularity on risks for AVSs, LRTs and Operators, as our API-appropriate quantitative modelling evolves.

Visit u--1 website to learn more, and their API page at https://u--1.com/api.

Follow us on X!

Through this collaboration, we will assist Ion in underwriting LRT risk by conducting infrastructure risk assessments on portfolio-selected Actively Validated Services (AVS) on EigenLayer, to ultimately inform on various parameters within their protocol, such as LTV ratios, interest rate parameters, supply caps, and more.

Ion Protocol unleashes EigenFi by enabling restakers to collateralize LRTs and increase their exposure to restaking positions with low-risk, non-custodial reward accrual optimization. In addition, lenders can gain isolated exposure to LRT yield by lending to a specific LRT market or they can gain pooled exposure by depositing in the Ion Vault. 

As liquid restaking protocols begin composing their AVS portfolio strategies, EigenFi protocols like Ion must look beyond traditional DeFi metrics and account for the infrastructure risk from EigenLayer services, which is crucial for LRT yield generation and security.

Using our mathematical, research-driven frameworks, we will assist Ion in evaluating LRT collateral health by focusing on infrastructure risks within their particular AVS portfolios. Based on those results, we will recommend protocol parameters, such as LTV ratios, interest rates, and supply caps, to prevent unforeseen liquidations, mitigate risky lending practices, and ensure secure scaling of its DeFi marketplace.

Tokensight's basic three step process is:

1. Underwriting AVS risk individually and in isolation (sample, illustrative dashboard: https://eigenavsrisk.streamlit.app/);

2. Underwriting AVS risk as a pooled service in the context of an AVS ecosystem on EigenLayer, taking in consideration thoughtful parameters that might mitigate/exacerbate its risk within that context;

3. Composing the aggregate, pooled risk of a given AVS selected-portfolio by an LRP and derive its health as a collateral asset in the context of Ion requirements.

We are committed to work closely with the Ion team and provide ongoing risk underwriting intelligence for Ion Protocol, including future quantitative modeling and cryptoeconomic security simulations.

In the coming weeks, we will share some findings from our research and joint collaboration. Stay tuned for more updates!

Visit the official Ion's website to dive deeper and stay tune for latest updates!

Learn more on their ethos and the EigenFi space on the blog post: Underwriting LRTs: Balancing High Yields with Security.

Thank you. Follow us on X!