Useful Links

• Website: https://app.eigenlayer.xyz/

• Documentation: https://docs.eigenlayer.xyz/eigenda/overview/

• Social: Twitter | Discord

• Contracts: https://github.com/Layr-Labs/eigenda

Introduction

This report is conducted by the YieldNest independent risk and research team operated by Llama Risk as part of a series on AVS risk assessments. In this report, we examine EigenLabs's EigenDA.

This report will comprehensively cover all relevant risk factors of EigenLabs's EigenDA for AVS onboarding to YieldNest. Our approach involves both quantitative and qualitative analysis to help determine whether the AVS can be safely onboarded to YieldNest and to what extent there should be restrictions on the protocol's exposure to that AVS.

As YieldNest will be onboarding a variety of AVSs, our review involves comparative analysis to determine suitability of the AVS. Risks are categorized into:

• Technology Risk - risks related to smart contracts and dependencies

• Counterparty Risk - risks related to governance, centralization vectors, and legal and regulatory considerations

These risk categories will be summarized in the final section of this report and are meant to assist tokenholders in their determination around onboarding EigenDA and setting suitable parameters.

Section 1: Fundamentals

This section addresses the fundamentals of the AVS. It's essential to convey (1) the value proposition of the AVS, and (2) the sustainability of its service offering. This section contains descriptive elements that provide an introduction to the AVS along with relevant adoption metrics.

This section is divided into three sub-sections:

• 1.1: Description of the AVS

• 1.2: AVS Tokenomics and Economic Subsidies

• 1.3: Usage Metrics

1.1 AVS Business Fundamentals

1.1.1 AVS Category

EigenDA is a Data Availability (DA) service, implemented as an Actively Validated Service (AVS) on EigenLayer, that aims to provide a secure and scalable DA for L2 Rollups on Ethereum. It aims to alleviate a bottleneck in L2 scalability by increasing throughput and reducing transaction costs when submitting batches to Ethereum. EigenDA is made by EigenLabs and built on top of EigenLayer, currently on mainnet since Q2 2024. It is also available on Holesky testnet for testing and development purposes.

Understanding Data Availability (DA)

When Rollups submit a batch of data to Ethereum, it is compressed into a summary that can be challenged over a predefined time window. In this context, data availability refers to the complete transaction data which must be accessible over the challenge window (e.g. 7 days). In case any error is detected, it should be possible for anyone to submit a fraud proof, thus balancing scalability with security.

It is important to note that data availability focuses solely on the publication and temporary storage of data, and does not address the long-term retention of transaction data.

Source: celestia.org

Key Aspects of a DA System:

• Security: In a DA system, security encompasses the necessary conditions to guarantee that all data blobs, once certified as available by the system, are indeed accessible for download by honest parties.

• Throughput: Throughput refers to the capacity of the DA system to process data blobs, usually quantified as the volume of data it can handle per second (bytes/second).

1.1.2 Business Model

EigenDA operates as an AVS on EigenLayer, leveraging the security benefits of Ethereum to offer a data availability service for L2 rollups. This architectural choice simplifies the implementation of EigenDA, as it does not require a proprietary chain or consensus protocol but instead utilizes the existing infrastructure of Ethereum.

EigenDA intends to advance the Ethereum scaling endgame, which aims to deconstruct Ethereum's monolithic structure into distinct layers. This includes a bifurcation into a consensus and DA layer (L1) and an execution layer (L2). EigenDA proposes an even further segmentation to enhance scalability for blockchain users.

A core advantage of DA systems is throughput. EigenDA is engineered for horizontal scaling, which enhances network throughput as the number of operators increases. In private tests involving 100 nodes with standard specifications, EigenDA has demonstrated a throughput capability of up to 10 MBps, with plans to expand up to 1 GBps. This scalability makes it feasible to support bandwidth-intensive applications.

The primary customers for a DA layer are L2 infrastructure providers. The economics of L2 rollups are distinct from those of L1s - DA costs are not only higher and unpredictable but are also incurred in a non-native token. This variability introduces exchange rate risks for rollups, complicating their ability to set stable prices or subsidize initial adoption. EigenDA is exploring solutions that allow rollups to compensate stakers in native rollup tokens at predictable rates, thereby combining the scale benefits of a shared security model with stable, native token transactions.

1.1.3 Organizational Structure

EigenLabs is structured as a research and engineering organization with a prime focus on advancing open innovation on the Ethereum blockchain. The company was founded by Sreeram Kannan, a former professor at the University of Washington and Head of the UW Blockchain Lab. The latter institution emerged as the incubator from where initial contributors were recruited.

Along with Sreeram Kannan (LinkedIn) who acts as EigenLabs CEO, other noteworthy team members are:

• Chris Dury (Chief Operating Officer) - LinkedIn;

• Calvin Liu (Chief Strategy Officer) - LinkedIn;

• Sid Sanyal (VP of Engineering) - LinkedIn;

• Jeffrey Commons, Gautham Anant and Daniel Mancia - some of the leading engineers;

• Scott Conner (Dir. of Protocol Development) - LinkedIn;

LinkedIn profiles of leading personnel are linked to show credibility of their professional track record.

1.1.4 Third-Party Relations

EigenDA has announced upcoming collaborations with notable entities in its recent article, including Celo in its transition from L1 to Ethereum L2, Mantle and its range of products within the BitDAO ecosystem, Fluent with a zkWASM execution layer, and Layer N which offers zk-OP hybrid rollups for financial applications.

In March 2023, EigenLayer successfully closed a Series A funding round, securing $50M on top of $14.5M collected in Seed round. Following the deployment on a testnet, the project further raised $100M in a Series B round in February 2024. The long list of investors in Eigen Labs is headed by a16z Crypto & Blockchain Capital. Polychain Capital and Ethereal Ventures are also positioned as lead investors.

Source: Rootdata

Eigen Labs has been actively forming partnerships with other protocols to enhance EigenDA adoption, listed below.

• AltLayer and Offchain Labs: provide EigenDA support for Arbitrum Orbit chains. Developers are offered lower transaction fees and higher transaction volumes by building EigenDA-based Orbit rollups that bridge from Arbitrum One, Arbitrum Nova, and Ethereum.

• Pontem: integrate Lumio with EigenDA by supporting Lumio's transaction data in a cost-effective manner to further reduce rollup costs. Applications originally developed for other chains (Aptos or Solana) would gain the ability to expand to Lumio (which supports any blockchain VM).

• Swell: strategic alliance with AltLayer and EigenDA to introduce its proprietary Layer 2 rollup, tailored specifically for restaking applications. Their platform will employ a zkEVM framework, based on the Polygon CDK, with EigenDA serving as data availability layer. Swell L2 is designed as a "restaked rollup" having not only enhanced security but also elevated decentralization credentials through multiple AVS integrations.

1.1.5 Competition

The Data Availability (DA) market currently includes Ethereum DA, Celestia, EigenDA, and other emerging technologies such as Near DA and Polygon Avail. We will primarily focus on EigenDA and Celestia, which are becoming the predominant contenders in the DA landscape, while also referencing the advancements in Ethereum DA, particularly post EIP-4844 (also known as Proto-Danksharding).

EigenDA Compared to Ethereum DA

• By leveraging EigenLayer, EigenDA separates data availability from consensus processes. This allows nodes to process proofs of data availability in parallel rather than waiting for a sequential order.

• EigenDA nodes are not required to download and store entire datasets. Using a method of data protection, in which data is broken into fragments and stored across a set of different nodes, known as erasure coding and a form of zero-knowledge proofs, called KZG commitments, that enables nodes to prove they hold a specific set of data - nodes efficiently verify data by downloading minimal data chunks. Managing small portions of data shards considerably lowers operational and maintenance costs, and increases network throughput.

• While EigenDA leverages part of the mainnet’s security, it inherently possesses a lower security profile compared to Ethereum DA, which could be a trade-off for its increased efficiency and lower costs.

According to EigenDA, it can process data up to 200x that of mainnet, with increased throughput as more node operators opt into the network.

Source: AVS Token Design Considerations: EigenDA compared to Celestia

EigenDA Compared to Celestia

Celestia is the first modular Data Availability (DA) network that operates on a modular Proof of Stake (PoS) blockchain, built on Cosmos SDK. It facilitates the independent launch of blockchains by simplifying the technology and infrastructure required. The security of Celestia is thus dependent on the integrity of its PoS chain and the value of its TIA token.

Although Celestia and EigenDA currently employ distinct approaches to data availability sampling (DAS) and encoding proofs, the maturation of DAS and KZG technologies may lead to a convergence in their methodologies. Notably, @sreeramkannan has suggested that EigenDA could potentially incorporate DAS to support more light nodes in the future. Similarly, @likebeckett has indicated that Celestia might adopt validity proofs based on KZG commitments if they prove more advantageous than fraud proofs. As such, the current differences in DA technical architecture might not remain as core differentiators moving forward. It appears more likely that the significant distinctions will involve aspects such as network security, usage costs, and throughput capabilities.

See a summary of the comparative study between EigenDA and Celestia conducted by Momentum Capital on February 1, 2024:

Source: MT Capital

• Celestia’s security relies on its Proof of Stake (PoS) network, requiring nodes to stake TIA tokens, thus incurring setup costs. EigenDA, leveraging Ethereum’s security, allows nodes to register as re-stakers, thereby avoiding setup costs. Note that EigenDA's setup cost could change with the introduction of EIGEN token and its staking mechanism.

• Celestia leverages the Tendermint consensus mechanism, which depends on peer-to-peer (P2P) network propagation. EigenDA separates data availability from consensus, utilizing direct unicast for more rapid network communication and confirmation, free from the constraints of traditional consensus protocols and P2P network throughput. However, for final block confirmation, EigenDA relies on an EigenDA contract on the Ethereum mainnet, which takes approximately 12 minutes — significantly longer than Celestia’s 15-second confirmation time.

• The security of Celestia is bolstered by its network value; the higher the value, the more costly and unlikely an attack becomes. With approximately $1.2 billion staked, an attack on Celestia would cost over $0.8 billion. EigenDA, however, benefits from a subset of Ethereum’s security based on the value of restaked assets, estimated at $10 billion (as detailed in section 3.2.6 Cost-of-Corruption (CoC)). Both solutions also incorporate a fallback security mechanism through social consensus (as detailed in section 3.2.7 Slashing Conditions Intersubjectivity).

• Celestia’s full nodes are tasked with broadcasting, consensus, and validation, necessitating a bandwidth of 128MB/s for downloads and 12.5MB/s for uploads. Conversely, EigenDA nodes, which are not responsible for broadcasting and consensus, require only 0.3MB/s of bandwidth. This significantly reduces the operational load on EigenDA nodes compared to Celestia.

1.1.6 Restaked Asset Selection

Currently, EigenDA lacks a publicly disclosed methodology for selecting acceptable restaked assets. As it stands, EigenDA supports all assets that are available for restaking through EigenLayer, as demonstrated in the accompanying illustration. This approach allows for a wide range of assets to be utilized within the network, aligning with the offerings of EigenLayer. However, it also introduces dependencies risks, which we will address more thoroughly later in this report.

Source: app.eigenlayer.xyz

Collateral structure of the AVS is important because:

1. Native Restaked ETH has a different risk profile than ETH LSTs.

2. Volatility of the AVS economic security TVL (dollar denomination). i.e. an AVS "economic security network" with a larger share of ETH LSTs will probably have higher volatility than one backed by Native Restaked ETH

The EigenDA "security/operator network" collateral structure is currently consisting of mostly native restaked ETH:

Source: Staking Rewards | Date: 5/22/2024

1.2 AVS Tokenomics and Economic Subsidies

Many AVSs may introduce native tokens to incentivize restakers, operators, and potentially capture additional value from their services. Understanding the tokenomics and incentive structures is crucial for assessing the long-term sustainability and potential returns of an AVS. AVSs may use native token incentives to boost yield or build some sort of long-term “loyalty program” (e.g. points distribution).

• Case 1: Native Token Incentives: AVSs may launch native tokens to incentivize restakers and operators by offering competitive yields or rewards. Key considerations include token allocation, distribution schedules, token utilities, and tokenomic mechanisms (e.g., sinks, velocity controls, inflation).

• Case 2: Points Incentive Programs: Instead of native tokens, some AVSs may opt for non-transferable points or reward systems to incentivize participation and loyalty.

1.2.1 Existence of an Incentive Program

Native Token Incentives

As of May 9th, 2024, EigenDA has not issued a token nor disclosed any intentions to do so publicly. This may become relevant to the EigenDA incentives strategy, should they release a token in the future.

The method by which EigenDA intends to compensate restakers remains unspecified. Should the platform decide against introducing a token, it will need to rely on either protocol-generated profits or external funding to facilitate these payments.

Points Program Incentives

As of May 9th, 2024, EigenDA neither operates an ongoing incentive program nor has it implemented one in the past. There are also no publicly announced plans to initiate such a program in the near future.

However, EigenDA benefits indirectly from the incentive program of EigenLayer. This program rewards restakers with "points" that are recorded off-chain and can be redeemed for EIGEN tokens during scheduled airdrops.

EigenLayer Points are a measure of staking participation equal to the time-integrated amount staked in units of ETH * hours. For instance, a user who stakes 1 stETH for 10 days should accrue 240 restaking points over this time period - 1 ETH * 10 days * 24 hours/day = 240. More information about EigenLayer's Points program can be obtained from their public documentation.

EigenLayer has introduced the first phase of its "stakedrop" - an airdrop that must be staked and cannot be sold - at Apr 29, 2024, with a blog post in the EigenFoundation website. The rollout process of EigenLayer's incentive program is too complex to cover in this report, and together with the EIGEN token, a separate blog post will be conducted by the YieldNest Risk Team to cover those.

Additionally, various Liquid Restaking Token (LRT) protocols that interact with EigenDA also offer or have offered similar incentive schemes, further impacting EigenLayer's ecosystem.

1.2.2 Implications of the Incentive Program

The incentive programs run by EigenLayer and various LRT protocols are designed to attract capital through restaked assets. These assets are channeled towards EigenLayer and the respective LRT protocols, ultimately supporting EigenDA, among other AVSs, with the anticipation of future yields and partnerships. It is worth highlighting that the aforementioned incentive programs do not benefit EigenDA or any other AVS directly, as private restakers may choose to not secure any AVS with their restaked assets. It may make more sense for LRT protocols to use their assets to opt into AVSs, as mentioned previously, to start forming partnerships and position themselves to be the first beneficiaries of AVS rewards, when those starts to flow in.

However, it is important to consider the potential long-term effects of these programs. Should these incentive schemes be discontinued, it is reasonable to expect some capital to migrate towards alternative investment opportunities. This shift could result in a sudden decrease in both the cryptoeconomic security of EigenDA and the overall participation of users, including restakers and node operators.

This Dune Dashboard shows withdrawal requests from EigenLayer. The EIGEN distribution announcement took place on April 29, 2024 with a snapshot taken on March 15, 2024. We can see that there were modest withdrawal requests immediately following the announcement. A large 450k ETH uptick on May 8th has been associated with Puffer Finance migrating operations with the intention to natively restake the capital, as mentioned here.

Source: Dune

However, in the time since the EIGEN airdrop announcement, the overall EigenLayer TVL has remained static, indicating that users may be anticipating future rewards for continued interaction with the protocol, and perhaps a cooling in speculative activity.

1.3 Usage Metrics

1.3.1 Total Restaked Value

The Total Restaked Value is an objective metric indicating the level of crypto-economic security an AVS possesses. As the total restaked value increases, the Cost-of-Corruption increases.

Below, we provide two charts showing EigenDA's total restaked assets in ETH and USD:

A table showing the growth in percentages is provided below:

1.3.2 Active Clients

The number of Active Clients can help assess the AVS's product-market fit (PMF) and the resiliency of its revenue sources. This metric may also provide insights into the sustainability of the AVS's rewards.

https://www.eigenda.xyz/ features a comprehensive list of ecosystem participants, among which RaaS and Rollupstacks are notably building on the EigenDA infrastructure. As of the date of writing, it has been observed that while none of these projects have reached full operational status on EigenDA, the majority are currently integrated within the testnet environment.

MantleDA can be the frontrunner in the transition process towards full deployment. According to Mantle docs, there is a planned migration of their data availability component to EigenDA, contingent upon the readiness of EigenDA's standardized solution for the mainnet launch.

1.3.3 Client Activity

Client Activity can offer additional insights into the sustainability of the AVS's revenue sources and restakers' rewards by examining the level of activity among the AVS's clients.

Currently, EigenDA has yet to onboard active clients. Therefore, to address target market dynamics we show below the activity of the rollups, which represent the core demographic that EigenDA aims to engage.

Source: L2Beat

1.3.4 Restaking Yield

The Restaking Yield is an objective metric that indicates the return on investment for restakers who opt into the AVS.

AVSs on EigenLayer has yet to start paying rewards to restakers, hence, restaking yield that comes from EigenDA is non-existent at the moment. In a recent podcast, the founder of EigenLabs, Sreeram Kannan, mentioned that AVS rewards will come before slashing - this sub-section will need to be revisited once that happens.

As per a Twitter post on May 3, EigenDA will not take a fee in its initial bootstrapping phase. It has not indicated it will deploy its own token, but this continues to be an unknown factor. Restakers may consider these unknowns when making their personal assessment of potential future EigenDA restaking yields.

1.3.5 Profitability

The Profitability of the AVS can help assess the sustainability of the restakers' rewards. If the AVS is not profitable, restakers may anticipate a decrease in rewards or even the termination of the AVS's operations altogether.

As mentioned above, EigenDA appears not to be taking a fee for services during the initial bootstrapping phase. The length of this phase is unknown and likely determined by the level of initial onboarding interest from rollup and RaaS partners. At this time, EigenDA does not generate any revenue.

AVSs inevitably incur operational expenses in their ordinary course of business. These expenditures should be taken into account for the profitability analysis, though detailed reports on EigenDA operational expenses, including on-chain traces thereof, remain unverifiable at present.

1.3.6 Target Market Size

This section aims to identify the category of the AVS, such as "Data Availability", in relation to the total addressable market, like the total revenue of DA networks. The goal is to understand the size of the market sector and dominance of the AVS.

Total Unique Blobs represent the distinct data entries processed by Ethereum's native data availability (DA) solution daily. This metric provides insights into the diversity and volume of unique data transactions occurring on the network. Similarly, Total Blob Sizes per Day (GB) measure the cumulative size of all data blobs processed by Ethereum's native DA solution, expressed in gigabytes, highlighting the volume of data being handled daily. By analyzing these metrics, we aim to illustrate the target market for EigenDA, as most rollups currently rely on Ethereum's native DA. EigenDA can potentially capture this market by offering a more efficient, scalable, and cost-effective solution for data availability.

Source: Blobscan

Source: Blobscan

After blob transactions went live in March 2024, several L2s adopted them. The graphs below illustrate a substantial cost differential between publishing transaction batches to L1 and submitting blobs to L1.

Source: Niftytable Dune Dashboard

The market for blob transactions is still undergoing adjustments to the fluctuating demands of L2s. Blob pricing, consequently, remains sensitive to variations in network congestion and heightened demand for blob space. Given the increasing adoption of blobs by L2s to enhance their scalability, network congestion is anticipated to reoccur.

Source: Coin Metrics

If positioned effectively to capitalize on the market opportunities, EigenDA stands to gain substantial exposure to a rapidly expanding sector. The indicative fees, outlined below, showcase potential revenue streams.

Source: Coin Metrics

Section 2: Technology Risks

This section addresses the persistence of the AVS properties from a technological perspective. It aims to convey (1) a general understanding of the system architecture, (2) where technological risk arises that can change the fundamental properties of the AVS (e.g., unresolved audit issues), and (3) any dependency requirements that may present potential issues (i.e., composability risk).

This section is divided into three sub-sections:

• 2.1: System Architecture

• 2.2: Smart Contract Risk

• 2.3: Product and Layer Composability

2.1 System Architecture

2.1.1 Overview and Context

EigenDA's architecture involves three components:

• Operators

• The Disperser

• Retrievers

Operators

EigenDA operators are:

"third-parties running the EigenDA node software, registered in EigenLayer with stake delegated to them. EigenDA operators are responsible for storing data blobs associated with valid storage requests. Valid storage requests are requests where fees are paid and the provided blob chunk verifies against the provided KZG commitment and proof. In the case of a successful verification the operator stores the blob and signs a message with the KZG commitment and the chunk index they hold, and sends it back to the disperser. EigenDA operators are collectively trusted, as they are, ideally, a distributed and non-related set of nodes, with financial value at stake – when writing a blob to EigenDA, clients must choose the exact threshold of stake with which they would like their blob to be stored."

Disperser

The EigenDA disperser is:

"an untrusted service, hosted by EigenLabs which is responsible for interfacing between EigenDA clients, operators, and contracts. EigenDA clients make dispersal requests to the disperser, which encodes the blob, calculates the encoded blob's KZG commitment, and generates a KZG proof for each chunk. Then the disperser sends chunks, KZG commitment, and KZG proofs to operators, who return signatures. The disperser then aggregates these signatures and uploads them to Ethereum in the form of calldata to the EigenDA contract. This step is a necessary precondition for slashing operators for misbehavior."

Retrievers

The EigenDA retriever is:

"a service that queries EigenDA operators for blob chunks, verifies that blob chunks are accurate, and reconstructs the original blob for the end user (sidechains or rollups using EigenDA for data availability). EigenDA hosts a retriever service, but users may also host their own retriever as a sidecar to their sequencer, or optimistically verify EigenDA's retriever service."

2.1.2 Architecture Diagram

The diagram below shows the basic flow of data through EigenDA:

Source: intro-to-eigenda-hyperscale-data-availability-for-rollups

In their blog post, EigenDA does a good job of summarizing the sequence of events:

1. The rollup Sequencer creates a block with transactions, and sends a request to disperse the data blob.

2. The Disperser is responsible for erasure encoding data blobs into chunks, generating a KZG commitment and KZG multi-reveal proofs, and sending the commitment, chunks, and proofs, to the operator nodes of the EigenDA network.

3. Rollups are able to run their own retriever, or use a retriever service that a third party (for example, EigenLabs) operates for convenience and amortization of signature verification costs. It is possible for a rollup to use a retriever service optimistically, such that in the case the service is non-responsive or censoring, the rollup can use its own retriever as a backstop, thus getting amortization benefits in the optimistic mode without sacrificing censorship resistance.

4. The EigenDA nodes verify the chunks they receive against the KZG commitment using the multireveal proofs, persist the data, then generate and return a signature back to the Disperser for aggregation.

It is worth reiterating that the disperser is currently a centralized component, hosted by EigenLabs. The EigenLabs team did mention that there are plans to make this component decentralized, in the future. However, no public roadmap to do so is available.

2.1.3 Node Operator Eligibility

There is currently an "Operator Set Cap" that limits the number of active node operators on EigenDA. This value is currently set to 200 and has been selected to increase performance and reduce costs to submit attestations to Ethereum L1.

Prospective EigenDA operators must first register as an EigenLayer operator and meet certain stake requirements, as described in EigenDA documentation. These requirements are evaluated on a per-quorum basis, relative to the weighting for each quorum:

• Minimum stake floor - Each operator must have at least 32 ETH to join the ETH quorum, or 1 EIGEN to join the EIGEN quorum.

• Congested operator set stake floor - When the global operator cap (200) is reached, the joining operator must have more than 1.1X the quorum weight of the current lowest-weighted operator in order to replace that operator.

An off-chain Churn Approver is employed to churn active node operators due to on-chain computation restrictions. It supplies a signature to approve prospective node operators that meet eligibility requirements and removes the lowest-stake operator. The Approver operates in conjunction with a smart contract, making the following checks which can be modified by governance:

• The new operator needs at least 1.1x the ejected operator’s stake.

• The ejected operator must constitute less than 10.01% of the total stake.

2.1.4 Node Operator Responsibility

Upon joining EigenDA, operators are required to fulfill certain responsibilities mandated by the protocol. These include maintaining a high standard of honesty, availability, and performance in delivering the EigenDA node service. The network holds operators accountable for these duties, and penalties may be imposed for non-compliance.

The node operator software, along with the associated responsibilities and requirements, is comprehensively documented by EigenDA in their public documentation. This section aims to summarize those explanations and present them in a clearer, more accessible format:

Responsibilities

An operator’s primary obligations revolve around data management and verification, which can be categorized into three core responsibilities, as communicated in the protocol docs:

1. Blobs Verification and Storage: Operators must verify, store, and attest to the accuracy and integrity of data blobs assigned to them. The assignment is determined by a dispersal request that specifies the quorum. If the operator's quorum is responsible for a blob, and if the operator is responsible for at least one blob in a batch, they must manage the entire batch. The management includes receiving, validating, and storing all relevant data.

2. Blobs Attestation: Once an operator verifies a batch and its blobs, they are required to sign the batch. The signature shall serve as a confirmation of the validation and storage processes, and it also indicates the operator's continued commitment to providing access to the stored data in the future.

3. Serving the Blobs: After the storage phase, operators are obliged to serve the blobs upon request. Importantly, the storage and retrieval functions are interlinked; the latter assumes that data has been stored as per protocol specifications.

Operator Lifecycle

Operators have distinct responsibilities that are dictated by their commitments to specific quorums, i.e independent groups for attestation. The duties of each operator are quantified based on every quorum they belong to. Their responsibilities are segmented into various stages of the operator’s lifecycle within the quorum, starting from their opt-in until the end of their commitment period and beyond.

The following is the lifecycle of an active operator, with responsibilities at different stages from when the operator opted-in the quorum to opt-out and beyond:

Source: docs.eigenlayer.xyz

Note that even after the operator opts out (B), they are fully responsible for dispersal/storing/retrieval for some time, specified as the BLOCK_STALE_MEASURE (150 blocks in the image above). The operator continues being responsible to store and serve existing data for a length given as C+STORE_DURATION_MEASURE (150 blocks + 2 weeks in the image above). After this period, the operator is completely offboarded.

The operator can re-opt in the quorum at any point from B to D, which will reinitiate the lifecycle.

2.1.5 Node Operator Software Requirements

EigenDA specifies node operator system requirements in detail in the protocol docs. A summary of requirements is given below.

EigenDA calls the total amount of stake an operator has across all quorums as their 'Total Quorum Stake' (TQS). This determines the NO's Node Class and how much throughput (number of data blobs) they are required to store.

Source: docs.eigenlayer.xyz

Likewise, the Required Storage scales with the NO's TQS:

Source: docs.eigenlayer.xyz

Since system requirements scale dynamically in accordance with the amount of stake delegated to the operator, node operators may, from time to time, need to upgrade their system setups in order to continue meeting their responsibilities. Guidance for performing such upgrades is covered in EigenDA's public documentation under the System Upgrades section.

Currently, the EigenDA protocol requires DA nodes to publish their IP address to the Ethereum L1 so providers and consumers of data can reach the node at this address. Consequently, node operators must be able to meet certain IP address stability and reachability requirements, as summarized in the table below:

Source: docs.eigenlayer.xyz

2.1.6 Slashing and Ejection Conditions

SLA and Node Operator Ejection

Operators that opt into EigenDA are required to adequately perform data availability services and may face forced ejection in case of poor performance. Operators must carry out both attestation and serving (retrieval) functions. The assessment of their performance in these areas is conducted using the service level indicators (SLI) specified below, evaluated over a rolling 24-hour interval:

Source: docs.eigenlayer.xyz

The service level agreement (SLA) sets the thresholds for performance based on the operator's share of quorum stake. When an operator possesses a greater share of the quorum stake, there are more stringent requirements on their performance. Since the impact of an operator's failure to perform its responsibilities scales with the amount of stake delegated to the operator, operators holding a larger percentage of delegated stake are held to higher standards of availability.

Source: docs.eigenlayer.xyz

Operators may have delegated stake in multiple quorums, in which case they are beholden to the SLA of their relative share of stake quorum in each of their respective quorums (e.g. 1% share in quroum 1 == 90% daily SLA required, 7% share in quorum 2 == 95% daily SLA required).

The ejection terms, as stated in the protocol docs, state:

"Operators can be subject to forced ejection from the protocol if they fail to meet their Rolling Daily SLA. This action can occur with or without prior notice and may follow initial soft enforcement steps, including the disclosure of the operator's SLI and overall ranking. Ejection is performed on a per quorum basis. An operator holding a 10% stake in 'quorum 0' who does not attest to blobs for 45 minutes may face immediate ejection from that quorum, particularly if their performance compromises the network's liveness. In addition to removal from quorums, following ejection operators will be unable to join any quorum for a cooldown period of 7 days."

The ejection process is designed for automated execution, aligning strictly with predefined ejection terms. Both the performance measurements and the ejection procedure are transparent and objectively verifiable. Anyone with access to Ethereum data can verify these processes provided they adhere or not to the specified SLA conditions.

The service that is responsible for ejecting node operators is an off-chain service, named EjectionManager and is written in Go. Source code is available here. This service interacts with EigenDA's BLSApkRegistry contract, which allows the EigenDA's RegistryCoordinator to register or deregister node operators. The RegistryCoordinator contract has a permissionless function, called updateOperators, that allows anyone to update the StakeRegistry's view of one or more operators' stakes. If any operator is found to be below the minimum stake for the quorum, they are automatically deregistered. Stakes are queried from the Eigenlayer core DelegationManager contract, and are not dependent on user input.

Slashing Conditions

It should be noted that, as of May 9th, 2024, the implementation of slashing mechanisms is not yet active on either EigenLayer or EigenDA. The following description of slashing conditions refers to a design plan for a future upgrade.

A primary mode of operator failure in EigenDA involves nodes certifying data items without properly storing them for the mandated duration. To address this issue, EigenDA employs a mechanism known as Proof of Custody, initially proposed by Justin Drake and Dankrad Feist from the Ethereum Foundation. This system requires each node operator to periodically compute and commit to a value derived from a function that can only be calculated by possessing all allocated blob chunks over a specific storage period. Failing to compute this function while attesting to the blobs can result in the slashing of the restaked assets of the node or its delegates.

An additional slashing risk arises if EigenDA nodes deliver an incorrect signature to the Disperser. It is important to highlight that the Disperser operates by default as a centralized component operated by EigenLabs; therefore, control over this component enables the Disperser to deem a node operator's submission faulty, potentially leading to slashing. EigenDA also introduces an intersubjective slashing condition, which is elaborated upon in a later section.

2.2 Smart Contract Risk

2.2.1 Protocol Audits

EigenDA's contracts received a total of 1 audit:

• Dedaub (2024-2-5): The audit covered both EigenLabs's eigenlayer-middleware repository, which is to be used by in a large variety of settings, by different AVSs (including EigenDA). The EigenDA repository was also included in the audit scope. The audit concluded with 4 protocol level considerations (none were attributed to EigenDA's contracts), 0 critical or high sevirity issues, 1 medium severity issue (attributed to EigenDA's contracts), 2 low severity issues (none were attributed to EigenDA's contracts), 1 centralization issue (attributed to EigenDA's contracts), and 13 informational issues (3 attributed to EigenDA's contracts). EigenDA's medium severity issue was resolved.

The audit fully covered EigenDA's smart contracts, as shown below:

2.2.2 Concerning Audit Signs

The audit seems to have been extensive and not many issues were found for EigenDA's contracts. However, the audit highlighted EigenDA as a completely centralized system at this point, pointing out that a single permissioned account can confirm batches. We will describe centralization vectors throughout the report, which creates a trust obligation.

A major caveat, mentioned in the audit, is that the smart contract code constitutes a small part of the overall implementation. There are about 400 lines (excluding interfaces) of smart contract code and many thousands of lines of Go (i.e., offchain code). Most of the obligations of correctness are assigned to off-chain code. Even checks defined inside smart contracts (such as the function verifyBlob in EigenDARollupUtils) are intended fully to be applied offchain (the function is not called by any other smart contract code) and sanity-check inputs against other inputs, not against onchain state.

Generally, the line between onchain and offchain validation in EigenDA is hard to discern and it seems possible that it may shift in the future (e.g., with more decentralization).

2.2.3 Bug Bounty

Currently, EigenDA does not offer a bug bounty program.

However, it is important to note that EigenLayer, the underlying platform for EigenDA, operates a generous and comprehensive bug bounty program. Despite this, it is critical to understand that no assets specific to EigenDA are included within the scope of EigenLayer's bug bounty coverage.

2.2.4 Immutability and Upgrade History

EigenDA's smart contracts possess pausability and upgradeability features, managed by the EigenLayer's Operations Multisig, which is controlled by a 3/6 quorum. Upgradeability is facilitated through the Transparent Upgradeable Proxy pattern.

A list of deployed contracts is accessible here: Deployed Contracts.

It may be worth reiterating that EigenDA's system is, as of today, completely reliant on centralized entities. As such, immutable smart contracts will not provide any value at this point, and may actually prove to be less resilient, since users are already assuming that the controlling team is honest.

Historical Contracts Upgrades

Using upgradehub we can see the history of upgrades to a proxy smart contract.

EigenDA's mainnet onchain contracts can be viewed at their github. We will go over each proxy contract and check whether any upgrades were made, and if so, try to identify interesting changes:

Source: RegistryCoordinator | StakeRegistry | IndexRegistry | BLSApkRegistry | EigenDAServiceManager

*Contract was upgraded once, without modifying any logic, but adding documentation and changing several constant variables, which act as system parameters, specifically:

• BLOCK_STALE_MEASURE, which is about the maximum amount of blocks in the past that the service will consider stake amounts to still be 'valid'. Was increased from 150 to 300.

• quorumAdversaryThresholdPercentages, which is the quorum adversary threshold percentages, stored as an ordered bytes array. Was increased from hex"21" to hex"2121".

• quorumConfirmationThresholdPercentages, which is the quorum confirmation threshold percentages, stored as an ordered bytes array. Was increased from hex"37" to hex"3737".

2.2.5 Developer Activity

The code for EigenDA's onchain and offchain systems is open-sourced on GitHub. The repository has a total of 34 contributors, and is being updated daily.

Source: GitHub

The public repository also contains tests for onchain and offchain code, as well as CI-CD pipelines for automated integration and deployment tasks. The development team is making use of Pull Requests to review any submitted code before it is merged into the main branch. Additionally, the team works with versioned releases to ensure an organized publishing process. The repository has been starred more than 130 times, and forked more than 170 times.

The above, in addition to a well-documented repository, is indicative of mature development practices.

2.2.6 SC Maturity

EigenDA's smart contracts on the Ethereum mainnet have been active for less than two months. Prior to this, the platform underwent extensive testing on the Holesky and Goerli testnets for over three months. Despite the relatively short period since its launch and the fact that not all features have been activated yet, the EigenDA team has showcased their impressive technical prowess and adherence to rigorous development standards throughout the rollout process.

The development lifecycle has been transparent since November 13, 2023, including comprehensive records of bug fixes, feature updates, and testing protocols.

The successful completion of security audits and the implementation of good practices suggest that the EigenDA team is capable and has taken all appropriate measures to ensure a robust system under the given circumstances.

2.2.7 Previous Incidents

As of the current date, there have been no incidents publicly reported that involve EigenDA's smart contracts or its offchain systems.

2.2.8 Cybersecurity Event Response Plan (CERP)

Cybersecurity incident response plan (as per the accepted ISO standards) has not been found. Despite inquiries into the procedures and documentation EigenLabs has established for managing severe security incidents, our findings were limited to generic recommendations outlined in the EigenLayer Operator Guidelines.

The suggested mitigation measures for a container compromise entail isolating the affected containers, conducting a thorough analysis of the incident, and subsequently restoring services. We have to recognize that these are merely recommendations to operators and do not constitute a formal, organization-wide response strategy. There is an absence of verifiable documentation demonstrating the adoption of these security practices by EigenDA.

2.3 Product and Layer Composability

2.3.1 Centralized Components

Disperser

The disperser plays a critical role in the EigenDA system. Its proper operation is essential not only to prevent undue slashing of restakers but also to ensure that users can access valid data. Malfunctioning or malicious behavior of the disperser could result in users receiving inaccurate data, and potentially lead to restakers being unjustly slashed. Currently, the disperser is operated solely by the EigenLabs team, centralizing this crucial component and necessitating a degree of trust in their management. While there is an intention to decentralize the disperser, no public roadmap for this transition has been disclosed as of yet.

Retrievers

Retrievers are vital for delivering data to users. Users have the option to operate their own retriever or to optimistically use the one hosted by EigenLabs. Although this setup allows some degree of autonomy, the centralization of the EigenLabs-hosted retriever poses a less critical but still relevant risk. It is advisable for users not to place full trust in the centralized retriever and to either manage their own or verify the data received thoroughly. Faulty or malicious data from the centralized retriever could compromise the functionality of their systems. Unlike the disperser, the retriever’s malfunction or malice can not directly jeopardize the stakes of restakers.

Proxy Contracts

EigenDA uses proxy contracts, which can be upgraded by the EigenDA team to implement any new logic or modify system parameters.

2.3.2 Dependencies

EigenLayer Integration

EigenDA distinguishes itself as an AVS through integration with EigenLayer. This platform extends Ethereum's decentralized security infrastructure to additional applications such as Data Availability (DA) layers, oracle networks, and sidechains, offering validators enhanced yield in exchange for assuming greater responsibilities and risks. The collaboration between EigenDA and EigenLayer's contracts enables this restaking functionality.

However, two primary risks are associated with EigenLayer:

1. the potential for crypto-economic security breaches if the cost of corruption is lower than the profit from corruption and

2. the possibility of wrongful slashing due to inaccurately defined slashing conditions or unexpected behavior of node operators.

EigenLayer addresses these concerns by developing automated monitoring systems and establishing a security council to oversee slashing decisions.

EigenDA has another security risk, as a DA system, in the form of nodes colluding to withhold data. This security risk cannot be observed onchain (and as such, is defined as an intersubjective fault), and so cannot be resolved by restaking alone. To address that, EigenDA plans to use EigenLayer's EIGEN token. It is also important to acknowledge that EigenLayer, while foundational to the functionality of EigenDA, remains a centralized system with a smart contract that could be unilaterally upgraded by its managing team.

Restaked Assets

EigenDA currently supports all restaked assets available through EigenLayer. This integration, however, introduces certain risks to EigenDA's cryptoeconomic security. For instance, any significant drop in the price of these assets - potentially triggered by a depegging event due to a bug in a Liquid Staking Derivative (LSD) smart contract - could swiftly and adversely impact the dollar value of the restaked assets. Such a scenario would subsequently decrease EigenDA's cryptoeconomic security.

Moreover, the control over some of these restaked assets remains centralized. Therefore, even in the absence of a contract bug, actions by a malicious administrative team could negatively affect the value of these assets, further jeopardizing the system's security.

2.3.3 Opt Out Process

The opt-out process for EigenDA, may be more prolonged than restakers might initially anticipate. This process requires a minimum duration of two weeks and may extend further depending on the duration for which node operators have been engaged with the AVS, among other factors. Additionally, the process mandates several specific actions on the part of node operators. This 2-week duration was set based on how long the blobs are promised to be available on EigenDA. EigenDA generally needs operators to keep serving data even after they stop receiving new blobs.

In general, an AVS should set the opt out period to be longer than the length of a node's obligations (assuming they take on no further new work). This aspect of the AVS is particularly critical to evaluate if the expected rewards are not projected to be sustainable, or if restakers only intend to participate in the AVS for a brief period. A cumbersome or lengthy opt-out process could significantly hinder restakers’ ability to disengage from the AVS on short notice.

2.3.4 Node Operator Software Maturity

Assessing the maturity of the node operator software for EigenDA qualitatively is challenging at this stage. The software has not undergone formal audits, and an in-depth code review falls outside the scope of this report. Quantitative evaluation is similarly difficult since slashing mechanisms are not yet activated, and there is no publicly available data concerning software bugs.

Despite these limitations, the apparent expertise of the development team and their adherence to publicly visible best practices - such as the publication of tests for the node operator software - suggest that they are progressing in the right direction. These practices indicate a commitment to quality and security that bodes well for the future maturity of the software.

Section 3: Counterparty Risks

This section addresses the persistence of the AVS's properties from an ownership and control perspective. The reader should get a clear idea of (1) who can legitimately set the properties of the AVS (e.g. intersubjective slashing), (2) node operator security assurances, and (3) the rights and obligations imposed on the operations of the AVS.

This section is divided into three subsections:

• 3.1: Governance

• 3.2: Node Operator Security Assurances

• 3.3: Legal

3.1 Governance

3.1.1 Governance Scope

As of the current phase, EigenDA operates without a Decentralized Autonomous Organization (DAO), with governance centralized within the EigenLabs team. There are no public plans to transition towards DAO governance.

3.1.2 Access Control

The control mechanisms of EigenDA's smart contracts pivot around the various EigenLayer-controlled multisig wallets. EigenDA's proxy contracts are owned by the EigenLayer Operations 3/6 Multisig.

All associated addresses are EOAs and their identities are not publicly disclosed. The current signers are:

• 0xa2425B00F9A9457AEdd51d4C36d9917eA1Aa7a02

• 0xb7Ae34BB33da55f12797e793E01e63a17B11d108

• 0x27ff193A6A1574A611E21c39FDA636fA1d61ba30

• 0x422e2F724faFE75F3635458aD7D3Ac803DCD7ff1

• 0xeD7Ef087d1C01ecCA9a9688a44aaeDDEf4ea560E

• 0xe7fFd467F7526abf9c8796EDeE0AD30110419127

The 3/6 signature requirement to upgrade contracts introduces a relatively lenient security posture. This threshold introduces potential risks concerning the persistency of the onchain contracts. Moreover, the lack of a timelock mechanism compounds these risks, permitting the enactment of changes with immediate effect, bypassing the opportunity for community scrutiny or preventive review.

This structure, while facilitating agility in decision-making, potentially compromises the protocol's resilience against unauthorized or hasty modifications. Enhancing the governance framework with more stringent control mechanisms, such as on-chain voting or the incorporation of a timelock to allow for discontent participants to exit, could significantly reinforce the protocol's governance structure and stakeholder confidence.

An additional privileged role in EigenDA's contracts, specifically in the EigenDAServiceManager contract, is the isBatchConfirmer, which can call the confirmBatch function, which is used for (1) submitting data availability certificates, (2) check that the aggregate signature is valid, and (3) check whether quorum has been achieved or not. Correctness of the confirmBatch function is vital to the EigenDA system, for all participants. However, for restakers and node operators, the implications of a malicious execution of this function, or more specifically, the off-chain computation that precedes the execution of the function, could mean slashing of their restaked assets, as the node operator's input could be deemed invalid.

Several addresses can be whitelisted under the isBatchConfirmer storage variable. The current addresses are provided below:

• 0x8ED83c6Bb12E441Ca2C3a544F525d4a3Fb6484D8 (EOA)

• 0x5A49Bf6c5690E22dFff3eB37F7dd18254eC361ED (EOA)

• 0x454Ef2f69f91527856E06659f92a66f464C1ca4e (EOA)

3.1.3 Distribution of Governance

As of now, EigenDA has not introduced a governance token, and details regarding the future distribution process remain undisclosed. Further information is expected to be provided as developments occur.

3.1.4 Proposals Frequency

Currently, EigenDA lacks a formal mechanism for community proposals or voting due to the absence of governance tokens. Despite this, community members can still engage and interact with the EigenLayer and EigenDA teams. Discussions and feedback can be conducted on their Discord server, providing a platform for community interaction and input on matters related to the protocol.

3.1.5 Participation

Given the absence of a formal public decision-making process within EigenDA, accurately measuring participation is inherently subjective. Therefore, an analysis of participation levels is not included in this report, as it may not provide objectively useful insights.

3.1.6 Slashing Veto Committee

Slashing is not live on EigenLayer, nor on EigenDA, as of May 9th 2024, hence the Slashing Veto Commitee is not live as well, at this point.

It is reasonable to assume that once slashing conditions go live on EigenLayer and EigenDA, the slashing veto committee will be live as well, and EigenDA will be included in it, since it's EigenLayer's first and largest AVS.

3.2.7 Slashing Conditions Intersubjectivity

The newly launched EIGEN token (whitepaper) outlines a cryptoeconomic security mechanism it claims will address "Intersubjective faults". This may become relevant to EigenDA, as the AVS allows EIGEN token staking. Intersubjective slashing is a form of economic voting that may allow stakeholders to penalize malicious actors.

Intersubjective conditions refer to a fault that cannot be objectively observed onchain, and requires offchain observers to decide whether a fault was made by node operators or not. EigenDA has such an attack vector, which is manifested by a collusion of node operators to withhold data. This attack vector is only observable from outside of the Ethereum chain as entities requesting the underlying data will not have access to it. Therefore, this data withholding attack falls under the scope of an intersubjective fault.

Similar to how blockchain forks result in two tokens that may compete for value, the goal of the EIGEN token is to allow social consensus amid faults in AVS-related computations, by enabling a fork of the EIGEN token on the application layer. It is designed such that it does not overload Ethereum's social consensus. It is worth noting that the economic security affordable by EIGEN's intersubjective staking tops out at the staked EIGEN market cap.

In the case of nodes colluding to withhold data (requiring the EIGEN token's social consensus as a security mechanism), EigenDA may need to focus on developing a robust monitoring infrastructure. This may include light clients to lower the cost-of-monitoring, to enable efficient recognition of the collusion, and trigger EIGEN's enabled social consensus.

As of 29 May 2024, there are almost 50M EIGEN tokens staked for EigenDA. Since EIGEN token is not transferable at the moment, a fair market value cannot be determined. Once EIGEN becomes transferable and its value increases, the incentive for social consensus to kick in and enforce intersubjective faults will be higher, and vice versa.

The economic incentive for EIGEN stakers to raise the challenge for the fraudulent computation is such that they will receive a portion of the burned tokens of the malicious node. A concrete example, in the case of EigenDA, could be that one of the nodes is withholding or censoring data, in such case, all other EigenDA nodes, that were required to stake EIGEN tokens, will have an incentive to raise a challenge saying that the malicious node is withholding or censoring data. Once the challenge is raised, all other nodes (that have staked EIGEN tokens) will need to decide whether or not the malicious node is in fact malicious. Assuming the network reaches the correct conclusion, nodes that failed to fork their EIGEN tokens will be slashed, and nodes that did fork their tokens will be rewarded, with a portion of the slashed EIGEN tokens.

A further explanation of the mechanics of the EIGEN token and its enabled social consensus is out of the scope of this report, and will be conducted on a separate blog post.

3.2 Node Operator Security Assurances

This information can be valuable when evaluating the decentralization, resilience, and long-term sustainability of an AVS, which are crucial factors in the AVS selection process. The list of EigenDA node operators can be found on the EigenLayer UI.

3.2.1 Node Operator Set

As of May 9th, 2024, EigenDA boasts a diverse network of 175 operators running its software. This operator set includes both large-scale professional node operators and smaller entities, ensuring a broad spectrum of participation and expertise. Prominent operators include P2P.org, Luganodes, Galaxy, and Figment, as well as smaller operators like dogswithnodes, Milady Operator, and Node Guardians.

The selection process for EigenDA node operators is designed to be permissionless, allowing anyone to participate provided they can meet the specific requirements set by EigenLayer and EigenDA. These criteria are outlined in greater detail in the node operator architecture sections (2.3.3-5). This open approach facilitates a diverse and robust network of operators by ensuring that all potential participants have the opportunity to contribute, as long as they adhere to the established standards.

3.2.2 Node Operator Collateralization

As of today, there is no requirement for EigenDA's nodes to hold any form of collateral. And there are no public plans to change that.

The newly launched EIGEN token may be staked and delegated to an EigenDA operator. The announcement also highlights that EigenDA is currently the only AVS that uses an EIGEN quorum. To join the quorum each operator must have at least 1 EIGEN. At the date of writing, EigenDA sits on over 30M in staked EIGEN.

Source: https://app.eigenlayer.xyz/avs

3.2.3 Restakers per Operator

Number of Restakers

A high number of restakers, coupled with the stake per restaker, can provide valuable insight into the resiliency of the AVS's crypto-economic security. If the number of restakers is low or the concentration of stake is high, the AVS's crypto-economic security becomes reliant on fewer entities. These entities could potentially opt out of the AVS, resulting in a significant decrease in the AVS's Cost-of-Corruption.

Source: StakingRewards

• Growth in last 24h - 2.61%

• Growth in last 7 days - 96.84%

• Growth in last 30 days - 139.82%

Number of Node Operators

The same principle from the previous subsection applies here: as the number of node operators increases, the likelihood of node operator collusion decreases, thereby enhancing the resiliency of the AVS. This particularly improves the decentralization security of the AVS, though it has a lesser impact on its crypto-economic security.

Source: Staking Rewards

• Growth in last 24h - 3.30%

• Growth in last 7 days - 52.85%

• Growth in last 30 days - 66.37%

Restakers per Operator

Restakers per Operator is a valuable indicator to assess the level of centralization or decentralization within an AVS.

• A higher value of restakers per operator may indicate a more concentrated delegation of restaked ETH among a smaller number of operators, potentially leading to centralization risks.

• Conversely, a lower value of restakers per operator suggests a more evenly distributed delegation of restaked ETH across multiple operators, which is generally desirable for decentralization.

• By analyzing this indicator, it's possible to identify AVSs where the restaked ETH is heavily concentrated among a few operators, which could make the network more susceptible to collusion, censorship, or other malicious behaviors.

Source: Staking Rewards

3.2.4 Delegated ETH Distribution

The purpose of this metric is to show the distribution of ETH delegated to node operators by restaking protocol and/or whale addresses. Understanding the concentration of delegated restaked assets helps assess the AVS's dependency on a small number of whale addresses or specific restaking protocols.

As can be seen in the provided screenshot below, out of the ~$14.04B restaked in EigenDA, P2P.org controls ~$1.4B - roughly 10% of the total restaked value - followed by almost 250 other node operators with significantly less controlled value.

Source: StakingRewards

This indicates an outsized influence by P2P.org and reliance by the AVS in it to ensure integrity of its data availability service. If P2P.org turns malicious, EigenDA's security could be impacted, but probably not compromised, as the restaked assets seems to be reasonably well distributed across other node operators.

3.2.5 Operator Churn Rate

The Operator Churn Rate indicator can track the rate at which new operators join or existing operators leave the AVS over time.

Restakers Churn Rate is an indicator used in combination with "Operator Churn Rate" that can provide insights about market supply side (from AVS perspective). At the moment we can refer on the LRT protocols as "restakers".

The operator churn rate here is fetched from EigenDA's AVSDirectory contract, using OperatorAVSRegistrationStatusUpdated events. The churn calculation is churn_rate = deregistrations / (registrations + deregistrations). In April, there were 532 node operator registrations and 32 deregistrations for a churn rate of roughly 5.5%. In May there were 359 registrations and 33 deregistrations for a churn rate of roughly 8.5%. Mainnet churn data is available only for those two months.

3.2.6 Economic Security per Node Operator/Restaker

Per Node Operator

Economic Security per Operator represents the average economic security (i.e., the dollar value of restaked ETH) per operator in an AVS.

This indicator can serve as a proxy for the level of decentralization and distribution of economic security among the operators. A highly skewed distribution, with a few operators controlling a disproportionately large share of economic security may raise concerns about centralization risks.

Source: Staking Rewards

Per Restaker

Economic Security per Restaker represents the average economic security (i.e., the dollar value of restaked ETH) per restaker in an AVS.

This indicator can:

• provide insights into the level of commitment and trust that restakers have in the AVS. A higher economic security per restaker may indicate stronger confidence and willingness to stake larger amounts of ETH in the AVS.

• help identify AVSs with a more concentrated or distributed base of restakers, which can have implications for the stability and resilience of the restaked ETH pool.

Source: Staking Rewards

3.2.7 Cost-of-Corruption (CoC)

In their whitepaper, EigenLayer describes cryptoeconomic security as the quantification of the cost that an adversary must bear in order to cause a protocol to lose a desired security property. This is referred to as the Cost-of-Corruption (CoC). When CoC is much greater than any potential Profit-from-Corruption (PfC), we say that the system has robust cryptoeconomic security. Cryptoeconomic security stands in contrast with systems that provide majority-trust security guarantees which only hold under the assumption that at least a threshold percentage of operators are altruistic and will act honestly. A core idea of EigenLayer is to provision cryptoeconomic security through various slashing mechanisms which levy a high cost of corruption.

A key function of the EigenLayer smart contracts is to hold the withdrawal credentials of Ethereum Proof-of-Stake (PoS) stakers. If a staker who is restaked on EigenLayer is proven to have behaved adversarially while participating in an AVS, then that staker’s ETH will be subject to slashing and are frozen, that is, prevented from further participation on any AVS on EigenLayer. Since the withdrawal address of the staker is set to the EigenLayer contracts, when the staker withdraws their ETH from participation in Ethereum consensus through EigenLayer, the withdrawn ETH will be slashed according to the onchain slashing contract of the AVS.

Given a set of colluding validators that we henceforth term the attacker, we assume that the attacker has the ability to corrupt the majority of the validators. Therefore, the attacker possesses the power to manipulate the consensus process, potentially leading to double-spending, censoring transactions, or altering the integrity of the blockchain's state.

To assess whether attacking is beneficial, the attacker must take into account two elements: the Cost of Corruption and the Profit from Corruption (PfC).

CoC encompasses the total resources the attacker must invest to successfully manipulate the protocol, i.e., slashing of their stake, technical resources required for the attack and other associated expenses. Since we focus on assessing the efficacy of stake slashing as a deterrent, and its influence on the Cryptoeconomic security (CES), we assume that the CoC primarily involves the loss of the attacker's staked assets, while other costs will be disregarded.

PfC signifies the potential gains the attacker would achieve post-successful manipulation. An analysis requires a more subtle approach toward PfC, and thus we divide PfC into two sources as follows:

• Profit from Manipulation (PfM), is the internal profit the attacker can gain by manipulating the protocol. For instance, for EigenDA, it is the profit that could be extracted by a malicious data blob update. The PfM is upper-bounded by the protocol's Total Value Secured (TVS).

• Profit from Depreciation (PfD) addresses the external profit the attacker can gain from betting on price volatility or depreciation through, e.g., derivative markets or short selling.

Notice that PfC = PfM + PfD. A rational attacker will only attack if CoC < PfC.

A further explanation of CoC is out of the scope of this report, and will be done in a later blog post by the YieldNest Risk Team.

As noted in section 1.3.2 (Active Clients), as of the date of writing, none of EigenDA's potential clients have reached full operational status. This means that faults on EigenDA's DA will not affect any of its clients, at this point, and so there is no PfC.

3.3 Legal

3.3.1 Legal Structure

The company name Layr Labs appears on the EigenLayer GitHub repository. This is a corporation established in Delaware, USA with a principal place of business in Washington, as shown by the Notice of Exempt Offering of Securities filed with the SEC in 2023.

Layr Labs Inc. is now defunct according to the OpenCorporate query below. The entity is reported voluntarily dissolved as per public data retrieved from the Washington Secretary of State - Corporations Division.

Source: Opencorporates

The primary business entity remains Eigen Labs, Inc., a Stock Corporation, located in Redmond, Washington. Officially filed on April 15, 2024, this corporation is recognized under the document number 6188353. Governed by the California Secretary of State, the corporation maintains an active filing status.

Source: Bizprofile

3.3.2 Legal Arrangements

To secure EigenDA, Operators opt into a smart contract that dictates the compensation they will earn for securing the network along with the punitive measures for non-compliance, commonly referred to as "slashing" penalties. This arrangement is conducted in alignment with the Protocol Service Level Agreement (SLA) that Operators are expected to fulfill. Their obligations are detailed in the documentation that points to an automated regime of enforcing rights - e.g. "Operators can be subject to forced ejection from the protocol if they fail to meet their Rolling Daily SLA".

Our review indicates a notable absence of formalized agreements among the Operators and EigenDA. This omission is particularly disadvantageous in the realm of dispute resolution, where reliance solely on autonomous blockchain mechanisms may not always be adequate.

In the realm of customer relations, access to http://www.eigenlayer.xyz/, the front-end interface and any other service provided by EigenLabs, is governed by their Terms of Service. These terms contain the key notions of EigenLayer Protocol ("a set of decentralized open-sourced smart contracts that allow for the restaking of digital assets") and EigenDA Protocol ("smart contracts that provide a data availability service built on top of Ethereum").

Importantly, the Terms of Service clarify that both the EigenLayer and EigenDA protocols do not constitute a part of the services directly offered by EigenLabs. The use of these protocols is solely at the discretion and risk of the user. Additionally, any third-party technologies that must be used to interact with these protocols, such as wallets, are also not considered part of EigenLabs' services. Users are explicitly advised that the use of such technologies is at their own risk.

This delineation is a standardized approach to define the scope of services clearly and to construct the framework for limiting EigenLabs' liability. The services are expressly provided on an "AS IS" and "AS AVAILABLE" basis. EigenLabs categorically disclaims all warranties and conditions, whether express, implied, or statutory. The company maintains that it shall not be liable for any damages of any kind arising from the use of its services. Consequently, EigenLabs cannot be held liable for any damages resulting from the use of the EigenLayer and EigenDA protocols, as these are considered outside the defined scope of services.

3.3.3 Regulatory Risk

Eigen Labs does not indicate possession of particular permits or licenses. The business model (blockchain-based data availability services) does not suggest authorization under a specific framework, which is de facto non-existent in the US. At the moment, the United States has no federal regulatory framework for digital assets. Cryptocurrencies are on the radar of both federal and state governments. Most of the focus has been at the administrative and agency level, including the Securities and Exchange Commission (SEC), the Commodity Futures Trading Commission (CFTC), the Federal Trade Commission (FTC) and the Department of the Treasury and the Financial Crimes Enforcement Network (FinCEN).

The Biden Administration has issued an Executive Order focusing on mitigating risks associated with the proliferation of digital assets and blockchain technology. This directive prioritizes six areas:

• consumer and investor protection

• financial stability

• combating illicit finance

• reinforcing U.S. leadership in the global financial system and enhancing economic competitiveness

• promoting financial inclusion

• encouraging responsible innovation.

In this fragmented regulatory landscape, the product of Eigen Labs can be seen as either put outside of the scope of examination of the competent agencies or entirely exempt from regulation on the basis of regulatory-agnostic development of blockchain infrastructure.

We should not ignore the fact that regulations could quickly change in ways that impact endeavors connected to re-staking or yield-bearing activities. In this regard, EigenDA itself also bears regulatory uncertainties, such as even being deemed an unauthorized financial operation in some countries.

Section 4: Risk Management

This section will summarize the findings of the report by highlighting the most significant risk factors in each of the risk categories: Technology Risk, and Counterparty Risk.

• 4.1: Technology Risk

• 4.2: Counterparty Risk

• 4.3: Risk Rating

4.1 Technology Risk

4.1.1 Smart Contract

The review of audits and development activities indicates that the EigenDA team is highly competent and is taking the necessary steps toward developing a robust AVS. However, to enhance trust and security for potential participants, implementing additional safeguards could be beneficial. Specifically, the introduction of a bug bounty program would incentivize the discovery and resolution of vulnerabilities, and the establishment of timelocks for contract upgrades would provide further assurance by allowing time for community review and reaction before changes take effect.

4.1.2 Dependencies

The collaboration between EigenLabs's EigenDA and EigenLayer introduces multiple potential risks, including crypto-economic vulnerabilities, the possibility of inaccurately defined or improperly executed slashing conditions, and centralization concerns. Despite these risks, the integration is designed to offer increased validator yields and enhanced crypto-economic security.

Given EigenDA’s status as an AVS on EigenLayer, there are inherent limitations in the ability of the EigenDA team to mitigate these risk vectors directly. Nonetheless, adopting a more selective approach in the choice of restaked assets could reduce exposure to these dependencies. For instance, restricting restaked assets to native ETH could potentially lower the overall system risk by simplifying the asset profile and reducing the impact of external economic fluctuations.

4.1.3 Slashing Conditions

Slashing represents an inherent risk for restakers using EigenLayer. Assuming that the chosen node operators perform their duties honestly, the principal risk arises from unjust slashing due to bugs or malicious activities from other system components, notably the disperser. To counter potential unjust slashing, EigenLayer has instituted the Slashing Veto Committee. It is anticipated that EigenDA will be incorporated into this committee once operational.

Additionally, EigenDA is susceptible to the risk of node collusion, which cannot be objectively verified onchain. Mitigation strategies involve the future utilization of EigenLayer's EIGEN token and its associated mechanics ("Intersubjective Slashing"). The risk to restakers from this type of fault, assuming their node operators are honest and EIGEN’s social consensus mechanism functions as intended, would necessitate specific actions if such a fault ever occurs.

4.1.4 Opt Out Process

The process of opting out from EigenDA requires a minimum of two weeks and can potentially extend much longer. More specifically, the opt-out process is determined by the responsibilities of the node operator to continue serving data through a reasonable challenge window (satisfying the requirements of L2 rollups). This process emphasizes the importance of committing to EigenDA with a long-term perspective in mind. Engaging with the platform should be considered carefully, recognizing that disengagement might not be immediate or straightforward.

4.2 Counterparty Risk

4.2.1 Centralization

As of the current date, EigenDA operates as a completely centralized system. This centralization stems not only from its upgradeable smart contracts, which can be modified by a centralized group of entities, but also due to its process for aggregating node operator signatures. This aggregation is handled by the centralized disperser. Consequently, choosing to participate in EigenDA requires placing complete trust in the EigenDA and EigenLayer teams, collectively known as EigenLabs.

4.2.2 Legal

EigenDA developments are in the hands of Eigen Labs, Inc., a company headquartered in the United States. The location of the company inevitably subjects it and its activities to the scrutiny of various competent authorities. The regulatory environment for digital assets in the US is currently unpredictable due to the absence of a definitive legal framework governing such assets. Although Eigen Labs is presently operating in a manner that does not explicitly contravene existing laws and regulations, this status could swiftly change.

In operational terms, the relationships between EigenDA and its operators are governed by a standardized, automatically enforceable SLA. While this setup capitalizes on the inherent scalability and transparency of the blockchain technology, it could potentially restrict dispute resolution processes. In the absence of a robust on-chain mechanism for handling disputes, parties may find themselves limited in their ability to resolve conflicts.

4.3 Risk Rating

Based on the risks identified for each category, the following chart summarizes a risk rating for EigenDA as an AVS. The rating for each category is ranked from excellent, good, ok, and poor.

• We rank EigenDA good in smart contracts, this rating reflects a successful audit of its core system and adherence to excellent code lifecycle and development practices. However, the absence of a bug bounty program and the fact that the contracts have undergone only one public audit necessitate a downgrade from excellent to good.

• We rank EigenDA ok in dependencies, due to the centralization issues associated with some of its supported restaked assets.

• We rank EigenDA good in Slashing Conditions, the presence of an intersubjective slashing fault prevents an excellent rating, despite the advantages of its lightweight node operator software and likely inclusion in EigenLayer's slashing veto committee.

• We rank EigenDA ok in Opt Out Process, the opt-out process can be lengthy and comprises of several steps, which could incur slashing penalties if done incorrectly, reflecting significant potential inconvenience for restakers wishing to disengage.

• We rank EigenDA poor in decentralization, due to the complete centralization of its system and the lack of a clear plan towards decentralization.

• We rank EigenDA ok in legal, due to the clarity of the legal structure and the transparent arrangements with counterparts.