Introduction to AVS

At the heart of any blockchain's security is a concept known as staking—validators lock up their assets to earn the right to secure the network. This has been incredibly effective for chains like Ethereum, but it has also created silos of security. 

Each blockchain and protocol is forced to build its own isolated set of validators, which not only fragments security but also introduces inefficiencies. The idea behind EigenLayer’s AVS is simple but powerful:

“Why not allow Ethereum’s validators to do more with their staked ETH?”

Instead of each protocol creating separate sets of validators, why not leverage Ethereum’s robust validator set to secure multiple decentralized networks simultaneously? This creates a security sharing model—validators can now re-stake their assets across various protocols, leading to stronger, more unified protection across the decentralized world. 

As a mental model, you may think of this as “Validator as a Service”. An Actively Validated Services (AVS) is any system that requires its own distributed set of validator nodes for verifying some form of data(transactional or otherwise). 

This can range from Layer 2 to Data Availability Layers to Oracle Networks. AVSs leverage restaked ETH via EigenLayer smart contracts to use the programmable trust from the Ethereum network

How does it work?

(I) Restaking

  • Stakers can allocate their native ETH or Liquid Staking Tokens (LSTs) to secure services within the EigenLayer ecosystem, a process known as restaking.
  • Through restaking, the security guaranteed by staked tokens is extended to encompass additional services beyond Ethereum, specifically Actively Validated Services (AVSs).

(II) Operators

  • Operators essentially serve as the gatekeepers of security for the new networks that leverage EigenLayer’s AVS.
  • Operators take on the responsibility of performing the actual validation work, which includes maintaining uptime, ensuring the nodes are running correctly, and adhering to the protocols they are validating. 
  • In return, they receive rewards, just like Ethereum validators do for securing the Ethereum network.

(III) Delegation

  • Stakers may either entrust their staked ETH to operators or take on the role of operators by running their own validation services. 
  • This arrangement follows a dual opt-in process, guaranteeing that both stakers and operators mutually agree to the conditions.
  • Restakers have the discretion to choose the specific AVSs (Actively Validation Services) they wish to validate.
Working of AVS

AVS Categories

There are 17 Active AVSs deployed on Eigen Layer as of writing this blog. Here’s a breakdown of the different categories, addressing different sectors of the industry:

  • Blockchain Rollups: This can comprise of ZK or Optimistic Rollups. They are responsible for executing transactions off-chain for better scalability. Examples: AltLayer.
  • Coprocessors: These are specialized infrastructures responsible for handling heavy computation off-chain, thus reducing the load on the network itself. This can include ZK and database coprocessors, FHE or MPC. Example: Brevis
  • Data Availability: DA Layers ensures that all necessary data for transaction validation and execution is readily accessible and stored in a manner that can be reliably retrieved. Example: Eigen DA
  • Interoperability Layers: These networks allow communication and data transfer between different Blockchain networks. Example: Hyperlane.
  • Oracle: Oracle networks provide secure and reliable real-world data to Blockchain networks. Example: Eoracle
  • DePin: DePin infrastructure allows tokenization of real-world services. Example: Witness Chain.

AVS Risks

Generalized AVS Risks

Engagement with an Actively Validated Services (AVS) encompasses a variety of inherent risks that necessitate thorough comprehension prior to assessing the specific attributes of any particular AVS. The primary external risks can be categorized as follows:

Asset Staking Risks(Native ETH/ LSTs)

In the case of LST restaking, funds are directly stored within EigenLayer contracts, whereas native ETH restaking involves funds that remain on the Ethereum Beacon chain. Consequently, participants in LST restaking may incur financial losses attributable to risks associated with EigenLayer contracts. 

The inherent volatility of Ethereum (ETH) and the potential for slashing penalties can significantly affect the returns for stakers. Additionally, LST tokens may experience a loss of peg or undergo price fluctuations and devaluation due to contract upgrades or security breaches.

Unintended Slashing Risks 

Unintended slashing represents a significant risk within the EigenLayer framework, particularly in the context of Actively Validated Services (AVS). One such risk related to unintentional slashing is that an AVS could be susceptible to a programming bug that developers don’t know exists that results in the loss of funds for honest users. 

Moreover, misconfigurations or bugs in operator software can also lead to unintended slashing incidents. These technical issues may inadvertently trigger slashing conditions, penalizing node operators (NOs) who have acted in good faith.

EigenLayer Smart Contract Risks

The intricate nature and potential vulnerabilities embedded within EigenLayer's smart contracts may expose users and AVS to substantial financial losses. Engaging in restaking and constructing AVS atop EigenLayer necessitates interaction with the project's contracts, thereby increasing susceptibility to contract-related attacks.

Regulatory Risk 

The regulatory landscape for cryptocurrencies and staking activities is constantly evolving. Changes in regulations could impact the feasibility of restaking. EigenLayer itself might face regulatory challenges, potentially being classified as an illegal financial activity in some regions. 

This regulatory uncertainty poses a significant risk for AVS until clear guidelines are established.

Centralization Risks within EigenLayer

A scenario wherein a considerable amount of ether is locked within EigenLayer poses a risk; should a major operator experience a significant slashing event, it could trigger a cascading effect of slashing damages. In extreme cases, this could jeopardize the overall security of the Ethereum network.

Potential Collusion Among Node Operators

The EigenLayer white paper raises concerns regarding the possibility of collusion among operators. Ideally, operators would distribute their restaked ETH across multiple AVSs to mitigate the risk of any single AVS being compromised. 

However, in practice, operators may conspire to concentrate their stakes, thereby exploiting specific AVSs for substantial financial gain at the expense of security.

Interconnected Risks and Systemic Vulnerabilities

There exist potential correlations among the operations of different Actively Validated Services (AVSs), the geographical distribution of node operators, and the software utilized across these systems. 

These interrelated factors can contribute to systemic risks that may propagate throughout the network. Specifically, if multiple slashing events transpire simultaneously or in close temporal proximity, the resulting impact could be magnified, leading to widespread disruptions and destabilization within the AVS ecosystem.

Unique Risks Associated with Each AVS

Each AVS may present unique risks that stem from its specific operational parameters and technological implementations. These include:

Subjective Conditions for Slashing

Slashing serves as a critical mechanism within staking protocols to ensure that node operators (NOs) act in the best interests of the network. The design space for slashing is already extensive, and each AVS has the capability to impose its own slashing conditions to deter malicious behavior by operators. 

This complexity is further compounded by pooled security, which introduces additional uncertainties. Ambiguities in slashing conditions can lead to inconsistent penalties, resulting in potential financial losses for honest Operators.

Inherent Vulnerabilities in AVS Smart Contracts

Each AVS typically deploys smart contracts, which may contain undiscovered vulnerabilities. Conducting thorough audits by reputable cybersecurity firms is essential to identify and mitigate these weaknesses, as unaddressed flaws can lead to significant financial losses and operational disruptions.

Suboptimal Network Requirements

Certain AVSs may impose network specifications that are not optimal for all operators or may require computational resources that are excessively demanding. This can lead to inefficiencies in the operation of the AVS.

Software Reliability Concerns Among Node Operators

The software utilized by node operators is susceptible to bugs and errors, which can significantly undermine service reliability for the AVS.

Factors for AVS Risk Evaluation

Factors that can be helpful in the the Risk Evaluations of AVS:

I. Performance and Operational Metrics

(i) Performance Metrics
  • Business Model & Revenue Generation: A comprehensive understanding of the underlying business model is essential for evaluating the long-term sustainability of an AVS. Revenue streams may comprise transaction fees, staking rewards, and premium services, all of which contribute to the financial health of the service.
  • Profitability: The profitability of an AVS is a critical determinant in assessing the sustainability of rewards for restakers. Should the AVS fail to achieve profitability, it could lead to diminished rewards for restakers or even prompt the cessation of operations altogether.
  • Total Restaked Value: This metric serves as an objective indicator of the crypto-economic security inherent in an AVS. An increase in total restaked value correlates with a heightened Cost-of-Corruption, thereby influencing risk evaluations.
  • Total Operators: The number of operators engaged with the AVS can provide insights into its level of decentralization and potential risks. A greater number of operators may enhance security and resilience against systemic failures.
  • Total Stakers: Evaluating the total number of stakers offers valuable insights into community engagement and trust in the AVS. A robust staking community often signifies confidence in the service's reliability and operational integrity.
(ii) Historical Incidents
  • Analysis of previous failures or breaches in the AVS can serve as important metrics in terms of risk of AVS. Historical incidents provide invaluable insights into vulnerabilities, operational deficiencies, and the efficacy of response strategies, thereby significantly influencing the overall risk assessment framework for AVS.
(iii) Smart Contract Maturity
  • The maturity of a smart contract is directly correlated with the robustness and reliability of its underlying code, as more mature contracts are typically subjected to extensive testing and real-world application. This rigorous testing process significantly reduces the likelihood of vulnerabilities, thereby enhancing the overall integrity of the contract.
(iv) Code Complexity
  • Complex codebases often lead to a higher incidence of bugs due to several factors, including intricate logic paths, interdependencies among modules, and the challenges associated with maintaining state consistency across various components. Consequently, the implementation of clear and straightforward coding practices is essential for mitigating the risk of bugs and vulnerabilities. Simplified code structures not only enhance the ease of auditing but also significantly reduce the likelihood of errors.
(v) Immutability and Upgrade History
  • Smart contracts are fundamentally characterized by their immutability; however, the implementation of the proxy pattern provides developers with a mechanism to rectify vulnerabilities or incorporate new functionalities without necessitating the deployment of entirely new contracts. This inherent immutability presents significant risks, particularly in instances where bugs are identified after deployment. Maintaining a transparent and well-documented upgrade history becomes imperative for ensuring accountability. Moreover, a thorough upgrade history is vital for conducting comprehensive risk assessment of an AVS.

II. Security and Risk Management

(i) Audits
  • Regular audits conducted by reputable firms are crucial for assessing an organization’s security posture and compliance with regulations. Engaging two to three well-regarded auditing firms typically indicates a low risk profile, as these audits identify vulnerabilities and provide actionable insights. Conversely, infrequent or poorly executed audits can lead to undetected security gaps, increasing the risk of data breaches, financial losses, and reputational damage.
(ii) Bug Bounty Programs
  • Bug bounty programs incentivize external developers and ethical hackers to identify and report vulnerabilities within an organization’s systems in exchange for monetary rewards. The presence of such a program reflects a proactive approach to cybersecurity, significantly lowering risk levels by facilitating continuous testing and vulnerability identification. In contrast, the absence of a bug bounty program may leave critical vulnerabilities unaddressed, exposing the organization to increased risks of cyberattacks and potential data breaches.
(iii) Cybersecurity Event Response Plan
  • A well-defined cybersecurity event response plan outlines procedures for effectively managing security incidents, including preparation, identification, containment, eradication, recovery, and post-incident review. Protocols with robust response plans can quickly mobilize resources during incidents, minimizing damage and recovery time, thereby maintaining a low risk profile.

III. Dependencies and Structural Risks

(i) Centralized Components
  • Centralized elements can create single points of failure, making the system vulnerable to outages, attacks, or failures. If these components are compromised, they can jeopardize the integrity and availability of the entire system, leading to significant operational disruptions and potential data loss.
(ii) Counterparty Risk and External Dependencies
  • Reliance on external systems and services introduces counterparty risk, which is the probability that one party in a transaction will default on its obligations. This dependence can lead to vulnerabilities related to the performance, security, and reliability of those external entities. If a key participant in the ecosystem experiences a failure or breach, it may trigger cascading effects across interconnected systems, potentially resulting in significant operational disruptions and financial losses for all parties involved.

IV. Behavioral and Economic Factors

(i) Operator Dynamics
  • Operator dynamics, including the operator profile and stake distribution among operators, significantly influence the stability and risk profile of the AVS ecosystem. A diverse stake distribution can mitigate risks associated with centralized control, while a concentrated operator profile may lead to vulnerabilities if key operators face challenges. Operator dynamics is essential for assessing the overall risk of the system.
(ii) Restaked Asset Type
  • Different types of restaked assets carry unique risk profiles that require individual assessment to understand their specific vulnerabilities. Evaluating these assets helps identify potential risks associated with market fluctuations, operational failures, or regulatory changes.
(iii) Cost-of-Corruption (CoC) and Profit-from-Corruption (PfC) Analysis

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

And, The Profit from an attack can be calculated as:

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

  • For an AVS to maintain a state of crypto-economic security, it is imperative that the Cost of Corruption remains less than the Profit from Corruption. This relationship serves as a critical metric in evaluating the risk associated with corruption within AVS risk frameworks.
  • To assess factors influencing corruption risks, one must consider that a higher Cost of Corruption coupled with a lower Profit from Corruption indicates a reduced risk profile for the AVS. Consequently, strategies aimed at increasing the Cost of Corruption should be developed and implemented.

V. Regulatory and Compliance Factors

(i) Regulatory Complexity
  • A thorough understanding of the legal framework is essential for effectively navigating compliance risks and ensuring operational legitimacy within the ecosystem. If the AVS is compliant with all relevant legal regulations, it signifies a strong commitment to governance and risk management, thereby reducing overall risk exposure.

EigenLayer's New Security Model for AVSs

The new security model of EigenLayer introduces a transformative approach to the management of AVSs, emphasizing enhanced control, localized governance, and economic efficiency. This model allows operators to selectively allocate a fraction of their stake to multiple AVSs, with the total allocation not exceeding one. Learn more here.

(I) Enhanced Control Over Slashing Risk

The introduction of Unique Stake enables operators to isolate slashing risks to individual AVSs. This feature allows operators to determine the specific amount of their stake that can be slashed by each AVS, thereby providing a tailored risk management strategy that was previously unavailable.

(II) Guaranteed Slashable Stake

Each AVS possesses a clear understanding of its available slashable stake, which is calculated by aggregating the Unique Stake allocated by all participating operators. This transparency ensures that AVSs can confidently rely on the economic backing they have secured.

(III) Elimination of a Common Veto Committee

The new model negates the need for a centralized veto committee, as slashing is confined to individual AVSs. This decentralization allows each AVS to establish its own governance and slashing mechanisms, promoting autonomy and reducing systemic risk across the network.

(IV) Permissionless Onboarding of AVSs

The onboarding process for new AVSs is designed to be permissionless, requiring only operator consent for participation. This open framework encourages innovation and expansion within the ecosystem by allowing diverse services to emerge without bureaucratic constraints.

(V) Pooled Security Mechanism

EigenLayer employs a pooled security approach where the economic security is shared across multiple AVSs. For instance, if there are 100 AVSs each backed by $1 billion in security, the cost to compromise any single AVS increases significantly due to the collective economic strength. This mechanism not only enhances security but also makes launching new protocols more economically feasible.

(VI) Incentivized Payments for Slashable Stakes

With each AVS having uniquely slashable stakes, there is an inherent incentive structure that mitigates the tragedy of the common scenario. AVSs are required to compensate for their allocated portion of stake, ensuring that all participants have a vested interest in maintaining network integrity.

(VII) Future Redistribution Capabilities

The design anticipates future enhancements, including mechanisms for redistributing slashed stakes back to AVSs, although this feature will not be part of the initial version rollout. This forward compatibility suggests a commitment to ongoing improvement and adaptability within the EigenLayer ecosystem.

Collaboration with Byzantine

This blog represents a collaborative effort with Byzantine Protocol aimed at enhancing risk management for Actively Validated Services (AVSs). At RiskLayer, our principal goal is to deliver comprehensive AVS risk scoring, thereby enabling the Byzantine team to effectively identify, manage, and mitigate risks associated with these AVSs. Read more about Byzantine & RiskLayer Partnership here.

Disclaimer

As the development of Actively Validated Services (AVSs) is ongoing and the slashing rules and fee generation mechanisms are still in a transitional phase, our objective is to establish a risk framework for AVSs. The AVS and restaking industry remains in its early stages of evolution, with many aspects still under development. We will update this documentation accordingly to reflect any changes.