Memorandum on YieldNest Initial AVS & Operators Selection

Memorandum on YieldNest Initial AVS & Operators Selection

Memorandum on YieldNest Initial AVS & Operators Selection

Curve

Curve

Jul 1, 2024

Introduction

This document will present an initial AVS screening and node operator methodology we use to inform our advisory to YieldNest in the temporary absence of slashing conditions. This will serve as the basis for the strategy decisions YieldNest may employ in this early stage which give credence to its initial operator and AVS selections. We supply the community with concise overviews of AVSs currently live on EigenLayer which may be referred to for an initial review of YieldNest's AVS exposure. We also point out professional node operators being considered for onboarding and the due diligence process in selecting operator exposures.

We plan to subsequently perform a comprehensive risk assessment of the most promising AVSs so that, when slashing conditions are introduced, YieldNest is prepared to adjust its AVS selection such that it optimizes its risk exposure. See our EigenDA AVS Risk Assessment for reference to the depth and breadth of our upcoming AVS risk analyses.

See here a list of YieldNest Risk AVS briefs. These are offered as an initial vetting of available AVSs, and are included in YieldNest's initial AVS exposure strategy:

See here a list of YieldNest Risk Node Operator assessments. These operators are intended to make up the initial whitelabel operator partners and are expected to grow over time:

  • Validation Cloud (Report coming soon)

  • P2P (report coming soon)

Section 1: AVS Selection

1.1 Expedited AVS Selection

The first section of this memorandum is intended to provide advisory on expedited AVS selection. The AVS ecosystem on EigenLayer currently includes more than ten active projects, each requiring high levels of shared security. Many more are in testnet phase with limited functionality and sometimes immature product offering.

Rewards Distribution

A significant challenge within this landscape is the lack of transparency concerning the economics of reward distribution. This ambiguity persists across both developmental projects and those operational on mainnet, primarily because reward mechanisms on EigenLayer have not yet been activated. Restakers are anticipated to receive a variety of tokens as compensation for providing security; however, these expected returns are currently confined to the future potential value derived from token airdrops. This delay in reward activation temporarily eliminates the need for a resource-intensive reward management process, presenting a unique, albeit temporary, advantage.

Slashing Conditions

One of the primary benefits of the current phase in EigenLayer's development is the absence of active slashing. This no-slashing period provides a significant opportunity for restakers to engage with multiple AVSs without incurring opportunity costs, maintaining a favorable risk-reward balance. Restakers gain exposure to potential yields from AVS-originated rewards, which are anticipated to be activated before slashing mechanisms according to recent updates from the EigenLayer team.

Initial AVS Screening Strategy

Considering the current environment, it is advisable for YieldNest to capitalize on this opportunity by adopting a more liberal approach to AVS onboarding. This strategy is viable only within the no-slashing phase, allowing YieldNest to maximize exposure to a variety of active AVSs with minimal risk. However, it is critical to implement certain risk mitigation tactics to safeguard against future changes in the operational landscape of AVS.

A thorough, retroactive review should be conducted in alignment with the methodologies described later in this memorandum. This review will identify any contradictions or concerning risk factors within the selected AVSs. Should the slashing mechanism be activated, it is imperative that each AVS undergoes a comprehensive risk assessment to determine its suitability relative to YieldNest’s risk preferences and strategic objectives.

1.2 AVS Screening Methodology

This part of the memorandum outlines a proposed methodology for a quick preliminary assessment of AVSs on EigenLayer. In the rapidly evolving ecosystem of EigenLayer, numerous services are launched with varying levels of readiness for market deployment. It is crucial to identify those services that merely ride the wave of EigenLayer's growing popularity, possibly without sufficient readiness to reliably serve customers and partners. We aim to refine the process of identifying the most promising AVSs by considering multiple indicators of project diligence.

Prevalence of Centralization Vectors

Upon an in-depth review of EigenDA—the inaugural AVS deployed on EigenLayer—we have identified a prevalent risk of centralization in newly introduced projects. Primarily driven by the necessity to secure funding, correct coding errors, and enhance smart contracts or address security concerns, the control of these projects often remains with a select few. Notably, EigenDA, a leading example among EigenLayer AVSs, exhibits similar traits. Despite the recent introduction of the native EIGEN token, EigenLayer itself has not progressed significantly towards decentralization—a goal stated on their development roadmap.

EigenLayer's team wields significant influence over protocol development trajectory, shouldering the critical responsibilities of designing and implementing core features and upgrades. Compounding this risk is the reality that, despite EigenLayer's promotion of an open marketplace for AVSs, the initial selection and support processes are not entirely permissionless. Instead, they are curated to a certain extent by the EigenLayer team, introducing an element of centralized oversight. Moreover, we must remain cognizant of the inherent risk that larger operators, leveraging economies of scale, could potentially dominate the market, leading to an undesirable centralization of validation power.

The centralization concerns discussed above raise pertinent questions about the level of trust users place in the EigenLayer team. Currently, the community appears to trust their decisions on the protocol design and operational implementations. This situation typifies early-stage AVS businesses where centralization is unavoidable; however, the character and reputation of the individuals holding power, along with the trust placed in them by investors, are critical.

Absence of Slashing

The strategy for selecting AVSs on EigenLayer can afford to be moderately relaxed due to the absence of slashing mechanisms. EigenLayer's mainnet launch announcement has shed light on the forthcoming activation of the penalizing mechanism. Although the slashing has not yet been fully activated, it is scheduled to be implemented later this year once the EigenLayer marketplace stabilizes and further security measures are in place.

Without the threat of financial penalties for misconduct, operators and restakers are not currently held financially accountable for any infractions. This presents YieldNest with the unique opportunity to integrate various services without the risk of slashing repercussions. However, this advantage is temporary as the activation of slashing on EigenLayer is anticipated in the future and should logically follow the provision of rewards to operators. This situation necessitates that our proposed method for shortlisting AVSs is adaptable and subject to review once slashing becomes operational.

Initial AVS Screening Process

The screening process for AVSs should incorporate rigorous open-source data validation across several critical categories. We employ this methodology in the AVS briefs linked at the top of this document. Relevant checklist items are described below:

  • Unique Selling Proposition: What specific challenges within the target blockchain sector does AVS aim to resolve? What unique solutions and functionalities does AVS employ?

  • Economic Model: What crypto-economic mechanisms does the AVS implement to sustain its ecosystem and incentivize participation? How does AVS intend to pay for rented security?

  • Points Program: Does AVS currently operate any points or rewards programs to enhance engagement and users/partners loyalty?

  • Builders: Who comprises the project team? What are their backgrounds and reputations?

  • Backers: Who are the investors and announced partners of the project, if any?

  • Centralization: Which elements of the system are centralized, and who controls them?

  • Security: Has the project undergone a comprehensive security audit? Is there an ongoing active bug bounty program?

  • Maturity: How long has the project been operational? When was the codebase deployed, and how frequently are updates committed?

  • Opt-Out: Under what conditions node operators are allowed to exit from AVS validation?

  • Regulatory Complexity: Differentiate between the requirements (legal structure, licenses, compliance, etc.) imposed over infrastructure AVSs and these engaging with novel business models or financial-related activities

This checklist is tailored specifically for the expedited AVS selection process and serves as an initial screening tool. The evaluation criteria included in this checklist do not delve into the depth and complexity characteristic of a comprehensive risk assessment. The screening process is streamlined to provide preliminary insights, which are less detailed than those derived from full-scale evaluations.

The effectiveness of the screening relies heavily on the availability and reliability of public data. Items on the checklist are checked against publicly accessible information, which may not provide a complete picture of the AVS’s risk profile.
The use of this checklist is not intended, nor should it be used, as a substitute for the full-scale risk reports produced by the YieldNest Risk Team.

1.3 AVS Categories

To help inform YieldNest on the eventual curation of AVS exposures within a suitable basket, we present an initial approach to AVS categorization, whereby YieldNest may strive to diversify its exposure to frontrunners in each category. Categorization is also generally useful for conceptualizing the landscape of emerging services.

1. Rollup Services

Within the EigenLayer ecosystem, each sub-category under Rollup Services represents a specialized function or set of functions that can be offered by a specific AVS. These protocols leverage the cryptoeconomic security provided by restaked ETH.
The modular nature of these services enables the development of highly customizable and scalable blockchain applications.

  • Data Availability: this service ensures that all necessary data for transaction validation and execution is readily accessible and stored in a manner that can be reliably retrieved.

  • Sequencing: this service organizes and orders transactions into blocks, providing a reliable sequence for transaction processing and validation. It ensures that transactions are processed in the correct order, which is crucial for maintaining the integrity of the blockchain.

  • Verification: this service involves the process of confirming the accuracy and validity of transactions and blocks. Verification ensures that all transactions are legitimate and comply with the network's rules and protocols

  • Finality and State Proofs: finality provides mechanisms to ensure that once a transaction is confirmed, it cannot be reversed or altered. Finality guarantees that transactions are permanent and immutable after a certain point. State proofs are cryptographic proofs that validate the state of the blockchain at a specific point in time, ensuring the integrity and finality of the blockchain state. These proofs allow participants to verify the correctness of the blockchain state without needing to trust a central authority.

  • Rollup-as-a-Service (RaaS): this service offers a turnkey solution for deploying and managing rollup instances. RaaS provides scalability and efficiency for blockchain applications, allowing developers to implement rollups without the need for extensive infrastructure management

2. Coprocessors

Coprocessors are specialized modules designed to offload and handle specific computational tasks, often enhancing the performance and efficiency of blockchain networks. They typically involve advanced cryptographic operations and are focused on improving privacy, security, and computational efficiency. Sub-categories of coprocessors include off-chain, parallel, multi-party, and other tech related to computation. Use cases may include general computation, AI, database operations, and EVM computations.

Coprocessors can be categorized based on their security design or by their intended use case:

  • ZK coprocessors: specialized modules designed to enhance the scalability and efficiency of blockchain networks by leveraging zero-knowledge proofs.

  • Database coprocessors: specialized hardware or software modules designed to accelerate database operations by offloading specific tasks from the main CPU to improve performance and efficiency.

  • Trusted execution environments (TEE): secure enclaves are isolated environments where data can be encrypted, but computations can still be performed on them. The key idea is to isolate the data and computation so even privileged system processes can't access it.

  • Secure multi-party computation (MPC): a cryptographic protocol that distributes a computation across multiple parties where no individual party can see the other parties’ data.

  • Fully Homomorphic Encryption (FHE): permits computations on encrypted data without ever decrypting it, making it stable even with highly intensive computation.

3. Interoperability

Interoperability services enable communication and data transfer between different blockchain networks. These protocols ensure that various blockchain ecosystems can interact, share resources, and operate together, improving the overall utility and flexibility of decentralized applications.

Blockchain interoperability may be specific to value transfers or may be generalized to interoperability of any arbitrary data:

  • Cross-Chain token bridges: bridge networks that allow the secure transfer of tokens between networks.

  • Cross-Chain messaging protocol: Generalize bridge networks that allow the secure transfer of arbitrary data between networks, for example to make smart contract calls and facilitate data exchange.

4. Web3 Infrastructure

This category covers all types of networks that outsource cryptoeconomic security (trust) from Ethereum in the form of restaked ETH. These networks leverage the security and trust of the Ethereum ecosystem by utilizing restaked ETH to secure their operations, ensuring robustness and decentralization.

Decentralized networks may encompass the consensus layer, blockchain service provider, and application layer:

  • Secured networks: decentralized networks that operate as secure Layer 1, Layer 2, or sidechain solutions but outsource security (trust) from Ethereum (restaked ETH). All networks that require distributed validator mechanisms. This includes secured Layer 2s like Cyber, Xterio, and DODOchain "MACH"

  • Oracles: decentralized networks that provide reliable and tamper-proof external data to smart contracts, bridging information between blockchain and real-world. This includes eOracle and OpenLayer.

  • DePIN: decentralized networks that coordinate and manage real-world endeavors via on-chain token incentives. Possible use cases include car-sharing, peer-to-peer solar power trading, and 5G or WiFi connectivity.

5. AVS Tooling

This category may include any AVS designed to support other AVSs.

  • Inter-AVS services: any service wherein an AVS provides services to other AVSs, including tools and services designed to facilitate interaction and collaboration between different AVSs.

  • Developer Services: tools and frameworks that assist developers in building, testing, and deploying AVSs, providing resources such as SDKs, APIs, and documentation.

  • Management and Monitoring Services: services for managing payments to restakers and operators, helping operators with node management, and monitoring.

  • Security Services: systems delivering essential security functionalities to decentralized protocols, instrumental in thwarting potential exploits and safeguarding staked assets, often combining off-chain monitoring and on-chain responses.

Section 2: Node Operator Selection

2.1 Operator Selection

YieldNest's approach to delegating restaked assets to node operators should be strategically designed to optimize network efficiency and security while ensuring and potentially maximizing reward distribution. Although the current absence of active slashing mitigates certain risks for restakers, the selection of operators remains crucial due to their pivotal role in the restaking ecosystem.

YieldNest's focus on professional operators is well-founded, as these entities typically possess sophisticated infrastructures capable of scaling operations and maintaining a high uptime assurance. Such service providers have implemented cutting-edge security protocols to safeguard staked assets and maintain the integrity of the (re)staking process. By offering expert management and continuous monitoring of staked assets, these professional operators significantly reduce the risks associated with restaking, such as potential slashing events or downtime penalties.

To this end, we have developed an assessment framework for evaluating restaking service providers based on multiple criteria:

  • Operator Fundamentals: We conduct a thorough examination of the service offering, its operational longevity, and the profile of investors and backers supporting the entity.

  • Business Sustainability: The node operator's business model undergoes scrutiny, including an evaluation of revenue streams and strategic industry partnerships. This information provides valuable insights into the long-term sustainability of the operator's business operations.

  • Regulatory Compliance: We investigate the operator's legal status, paying particular attention to jurisdiction-specific conditions and the resulting obligations to customers. This analysis helps ascertain the likelihood of adverse regulatory environments that could jeopardize the operator's service offerings and clarifies user assurances.

  • Security Protocols: Our assessment encompasses a detailed review of the operator's security documentation and protective measures established for delegators. We scrutinize implemented security protocols, conducted audits, and evaluate the staking infrastructure from a security standpoint. Operationally, we focus on validator maintenance practices and designs concerning AVS selection.

  • On-chain Performance: We track the operator's on-chain records, which provide crucial insights into their historical performance and behavioral patterns.

Utilizing this framework, we have conducted due diligence on Validation Cloud and P2P.org, the initial operators with whom YieldNest has begun forming a business relationship to leverage their whitelabel restaking service. The collective findings from both examinations support YieldNest's decision to delegate to these node operators, acknowledging their demonstrated operational proficiency. However, YieldNest Risk has advised maintaining vigilance and attentiveness to specific areas of concern, such as the lack of transparency in certain service features and potential risks associated with infrastructure centralization.

This evaluation methodology will be consistently applied to other professional operators in YieldNest's onboarding pipeline, ensuring a standardized and thorough assessment process. The operators currently in the pipeline include Google, T-Mobile, Figment, Nethermind, and Everstake.

2.2 Accelerated Operator Onboarding

For the intermediate time, since slashing and rewards are not fully live yet, YieldNest intends to maximize its exposure to potential early-user loyalty rewards by pointing all of its EigenPods to P2P.org, A41, and Kiln [all AVS]. They subsequently plan to build out a whitelabeled version of operators and AVSs, as described above, in preparation for slashing conditions at a later date.

Recognizing the necessity for agile decision-making, particularly concerning prompt delegation to operators due to business imperatives and systemic dynamics, we have provisioned for YieldNest to delegate restaked assets to additional Operators without comprehensive due diligence under certain circumstances. This approach is deemed viable exclusively in a no-slashing environment, with the stipulation that the selected node operators must meet specific standards, including comparable market presence, reputation, and prominence to the currently approved operators.

The accelerated operator onboarding strategy includes the following operators:

Drawing parallels to the expedited AVS onboarding process, we strongly recommend that operator selections be subject to rigorous re-evaluation once slashing mechanisms are activated on EigenLayer.

Introduction

This document will present an initial AVS screening and node operator methodology we use to inform our advisory to YieldNest in the temporary absence of slashing conditions. This will serve as the basis for the strategy decisions YieldNest may employ in this early stage which give credence to its initial operator and AVS selections. We supply the community with concise overviews of AVSs currently live on EigenLayer which may be referred to for an initial review of YieldNest's AVS exposure. We also point out professional node operators being considered for onboarding and the due diligence process in selecting operator exposures.

We plan to subsequently perform a comprehensive risk assessment of the most promising AVSs so that, when slashing conditions are introduced, YieldNest is prepared to adjust its AVS selection such that it optimizes its risk exposure. See our EigenDA AVS Risk Assessment for reference to the depth and breadth of our upcoming AVS risk analyses.

See here a list of YieldNest Risk AVS briefs. These are offered as an initial vetting of available AVSs, and are included in YieldNest's initial AVS exposure strategy:

See here a list of YieldNest Risk Node Operator assessments. These operators are intended to make up the initial whitelabel operator partners and are expected to grow over time:

  • Validation Cloud (Report coming soon)

  • P2P (report coming soon)

Section 1: AVS Selection

1.1 Expedited AVS Selection

The first section of this memorandum is intended to provide advisory on expedited AVS selection. The AVS ecosystem on EigenLayer currently includes more than ten active projects, each requiring high levels of shared security. Many more are in testnet phase with limited functionality and sometimes immature product offering.

Rewards Distribution

A significant challenge within this landscape is the lack of transparency concerning the economics of reward distribution. This ambiguity persists across both developmental projects and those operational on mainnet, primarily because reward mechanisms on EigenLayer have not yet been activated. Restakers are anticipated to receive a variety of tokens as compensation for providing security; however, these expected returns are currently confined to the future potential value derived from token airdrops. This delay in reward activation temporarily eliminates the need for a resource-intensive reward management process, presenting a unique, albeit temporary, advantage.

Slashing Conditions

One of the primary benefits of the current phase in EigenLayer's development is the absence of active slashing. This no-slashing period provides a significant opportunity for restakers to engage with multiple AVSs without incurring opportunity costs, maintaining a favorable risk-reward balance. Restakers gain exposure to potential yields from AVS-originated rewards, which are anticipated to be activated before slashing mechanisms according to recent updates from the EigenLayer team.

Initial AVS Screening Strategy

Considering the current environment, it is advisable for YieldNest to capitalize on this opportunity by adopting a more liberal approach to AVS onboarding. This strategy is viable only within the no-slashing phase, allowing YieldNest to maximize exposure to a variety of active AVSs with minimal risk. However, it is critical to implement certain risk mitigation tactics to safeguard against future changes in the operational landscape of AVS.

A thorough, retroactive review should be conducted in alignment with the methodologies described later in this memorandum. This review will identify any contradictions or concerning risk factors within the selected AVSs. Should the slashing mechanism be activated, it is imperative that each AVS undergoes a comprehensive risk assessment to determine its suitability relative to YieldNest’s risk preferences and strategic objectives.

1.2 AVS Screening Methodology

This part of the memorandum outlines a proposed methodology for a quick preliminary assessment of AVSs on EigenLayer. In the rapidly evolving ecosystem of EigenLayer, numerous services are launched with varying levels of readiness for market deployment. It is crucial to identify those services that merely ride the wave of EigenLayer's growing popularity, possibly without sufficient readiness to reliably serve customers and partners. We aim to refine the process of identifying the most promising AVSs by considering multiple indicators of project diligence.

Prevalence of Centralization Vectors

Upon an in-depth review of EigenDA—the inaugural AVS deployed on EigenLayer—we have identified a prevalent risk of centralization in newly introduced projects. Primarily driven by the necessity to secure funding, correct coding errors, and enhance smart contracts or address security concerns, the control of these projects often remains with a select few. Notably, EigenDA, a leading example among EigenLayer AVSs, exhibits similar traits. Despite the recent introduction of the native EIGEN token, EigenLayer itself has not progressed significantly towards decentralization—a goal stated on their development roadmap.

EigenLayer's team wields significant influence over protocol development trajectory, shouldering the critical responsibilities of designing and implementing core features and upgrades. Compounding this risk is the reality that, despite EigenLayer's promotion of an open marketplace for AVSs, the initial selection and support processes are not entirely permissionless. Instead, they are curated to a certain extent by the EigenLayer team, introducing an element of centralized oversight. Moreover, we must remain cognizant of the inherent risk that larger operators, leveraging economies of scale, could potentially dominate the market, leading to an undesirable centralization of validation power.

The centralization concerns discussed above raise pertinent questions about the level of trust users place in the EigenLayer team. Currently, the community appears to trust their decisions on the protocol design and operational implementations. This situation typifies early-stage AVS businesses where centralization is unavoidable; however, the character and reputation of the individuals holding power, along with the trust placed in them by investors, are critical.

Absence of Slashing

The strategy for selecting AVSs on EigenLayer can afford to be moderately relaxed due to the absence of slashing mechanisms. EigenLayer's mainnet launch announcement has shed light on the forthcoming activation of the penalizing mechanism. Although the slashing has not yet been fully activated, it is scheduled to be implemented later this year once the EigenLayer marketplace stabilizes and further security measures are in place.

Without the threat of financial penalties for misconduct, operators and restakers are not currently held financially accountable for any infractions. This presents YieldNest with the unique opportunity to integrate various services without the risk of slashing repercussions. However, this advantage is temporary as the activation of slashing on EigenLayer is anticipated in the future and should logically follow the provision of rewards to operators. This situation necessitates that our proposed method for shortlisting AVSs is adaptable and subject to review once slashing becomes operational.

Initial AVS Screening Process

The screening process for AVSs should incorporate rigorous open-source data validation across several critical categories. We employ this methodology in the AVS briefs linked at the top of this document. Relevant checklist items are described below:

  • Unique Selling Proposition: What specific challenges within the target blockchain sector does AVS aim to resolve? What unique solutions and functionalities does AVS employ?

  • Economic Model: What crypto-economic mechanisms does the AVS implement to sustain its ecosystem and incentivize participation? How does AVS intend to pay for rented security?

  • Points Program: Does AVS currently operate any points or rewards programs to enhance engagement and users/partners loyalty?

  • Builders: Who comprises the project team? What are their backgrounds and reputations?

  • Backers: Who are the investors and announced partners of the project, if any?

  • Centralization: Which elements of the system are centralized, and who controls them?

  • Security: Has the project undergone a comprehensive security audit? Is there an ongoing active bug bounty program?

  • Maturity: How long has the project been operational? When was the codebase deployed, and how frequently are updates committed?

  • Opt-Out: Under what conditions node operators are allowed to exit from AVS validation?

  • Regulatory Complexity: Differentiate between the requirements (legal structure, licenses, compliance, etc.) imposed over infrastructure AVSs and these engaging with novel business models or financial-related activities

This checklist is tailored specifically for the expedited AVS selection process and serves as an initial screening tool. The evaluation criteria included in this checklist do not delve into the depth and complexity characteristic of a comprehensive risk assessment. The screening process is streamlined to provide preliminary insights, which are less detailed than those derived from full-scale evaluations.

The effectiveness of the screening relies heavily on the availability and reliability of public data. Items on the checklist are checked against publicly accessible information, which may not provide a complete picture of the AVS’s risk profile.
The use of this checklist is not intended, nor should it be used, as a substitute for the full-scale risk reports produced by the YieldNest Risk Team.

1.3 AVS Categories

To help inform YieldNest on the eventual curation of AVS exposures within a suitable basket, we present an initial approach to AVS categorization, whereby YieldNest may strive to diversify its exposure to frontrunners in each category. Categorization is also generally useful for conceptualizing the landscape of emerging services.

1. Rollup Services

Within the EigenLayer ecosystem, each sub-category under Rollup Services represents a specialized function or set of functions that can be offered by a specific AVS. These protocols leverage the cryptoeconomic security provided by restaked ETH.
The modular nature of these services enables the development of highly customizable and scalable blockchain applications.

  • Data Availability: this service ensures that all necessary data for transaction validation and execution is readily accessible and stored in a manner that can be reliably retrieved.

  • Sequencing: this service organizes and orders transactions into blocks, providing a reliable sequence for transaction processing and validation. It ensures that transactions are processed in the correct order, which is crucial for maintaining the integrity of the blockchain.

  • Verification: this service involves the process of confirming the accuracy and validity of transactions and blocks. Verification ensures that all transactions are legitimate and comply with the network's rules and protocols

  • Finality and State Proofs: finality provides mechanisms to ensure that once a transaction is confirmed, it cannot be reversed or altered. Finality guarantees that transactions are permanent and immutable after a certain point. State proofs are cryptographic proofs that validate the state of the blockchain at a specific point in time, ensuring the integrity and finality of the blockchain state. These proofs allow participants to verify the correctness of the blockchain state without needing to trust a central authority.

  • Rollup-as-a-Service (RaaS): this service offers a turnkey solution for deploying and managing rollup instances. RaaS provides scalability and efficiency for blockchain applications, allowing developers to implement rollups without the need for extensive infrastructure management

2. Coprocessors

Coprocessors are specialized modules designed to offload and handle specific computational tasks, often enhancing the performance and efficiency of blockchain networks. They typically involve advanced cryptographic operations and are focused on improving privacy, security, and computational efficiency. Sub-categories of coprocessors include off-chain, parallel, multi-party, and other tech related to computation. Use cases may include general computation, AI, database operations, and EVM computations.

Coprocessors can be categorized based on their security design or by their intended use case:

  • ZK coprocessors: specialized modules designed to enhance the scalability and efficiency of blockchain networks by leveraging zero-knowledge proofs.

  • Database coprocessors: specialized hardware or software modules designed to accelerate database operations by offloading specific tasks from the main CPU to improve performance and efficiency.

  • Trusted execution environments (TEE): secure enclaves are isolated environments where data can be encrypted, but computations can still be performed on them. The key idea is to isolate the data and computation so even privileged system processes can't access it.

  • Secure multi-party computation (MPC): a cryptographic protocol that distributes a computation across multiple parties where no individual party can see the other parties’ data.

  • Fully Homomorphic Encryption (FHE): permits computations on encrypted data without ever decrypting it, making it stable even with highly intensive computation.

3. Interoperability

Interoperability services enable communication and data transfer between different blockchain networks. These protocols ensure that various blockchain ecosystems can interact, share resources, and operate together, improving the overall utility and flexibility of decentralized applications.

Blockchain interoperability may be specific to value transfers or may be generalized to interoperability of any arbitrary data:

  • Cross-Chain token bridges: bridge networks that allow the secure transfer of tokens between networks.

  • Cross-Chain messaging protocol: Generalize bridge networks that allow the secure transfer of arbitrary data between networks, for example to make smart contract calls and facilitate data exchange.

4. Web3 Infrastructure

This category covers all types of networks that outsource cryptoeconomic security (trust) from Ethereum in the form of restaked ETH. These networks leverage the security and trust of the Ethereum ecosystem by utilizing restaked ETH to secure their operations, ensuring robustness and decentralization.

Decentralized networks may encompass the consensus layer, blockchain service provider, and application layer:

  • Secured networks: decentralized networks that operate as secure Layer 1, Layer 2, or sidechain solutions but outsource security (trust) from Ethereum (restaked ETH). All networks that require distributed validator mechanisms. This includes secured Layer 2s like Cyber, Xterio, and DODOchain "MACH"

  • Oracles: decentralized networks that provide reliable and tamper-proof external data to smart contracts, bridging information between blockchain and real-world. This includes eOracle and OpenLayer.

  • DePIN: decentralized networks that coordinate and manage real-world endeavors via on-chain token incentives. Possible use cases include car-sharing, peer-to-peer solar power trading, and 5G or WiFi connectivity.

5. AVS Tooling

This category may include any AVS designed to support other AVSs.

  • Inter-AVS services: any service wherein an AVS provides services to other AVSs, including tools and services designed to facilitate interaction and collaboration between different AVSs.

  • Developer Services: tools and frameworks that assist developers in building, testing, and deploying AVSs, providing resources such as SDKs, APIs, and documentation.

  • Management and Monitoring Services: services for managing payments to restakers and operators, helping operators with node management, and monitoring.

  • Security Services: systems delivering essential security functionalities to decentralized protocols, instrumental in thwarting potential exploits and safeguarding staked assets, often combining off-chain monitoring and on-chain responses.

Section 2: Node Operator Selection

2.1 Operator Selection

YieldNest's approach to delegating restaked assets to node operators should be strategically designed to optimize network efficiency and security while ensuring and potentially maximizing reward distribution. Although the current absence of active slashing mitigates certain risks for restakers, the selection of operators remains crucial due to their pivotal role in the restaking ecosystem.

YieldNest's focus on professional operators is well-founded, as these entities typically possess sophisticated infrastructures capable of scaling operations and maintaining a high uptime assurance. Such service providers have implemented cutting-edge security protocols to safeguard staked assets and maintain the integrity of the (re)staking process. By offering expert management and continuous monitoring of staked assets, these professional operators significantly reduce the risks associated with restaking, such as potential slashing events or downtime penalties.

To this end, we have developed an assessment framework for evaluating restaking service providers based on multiple criteria:

  • Operator Fundamentals: We conduct a thorough examination of the service offering, its operational longevity, and the profile of investors and backers supporting the entity.

  • Business Sustainability: The node operator's business model undergoes scrutiny, including an evaluation of revenue streams and strategic industry partnerships. This information provides valuable insights into the long-term sustainability of the operator's business operations.

  • Regulatory Compliance: We investigate the operator's legal status, paying particular attention to jurisdiction-specific conditions and the resulting obligations to customers. This analysis helps ascertain the likelihood of adverse regulatory environments that could jeopardize the operator's service offerings and clarifies user assurances.

  • Security Protocols: Our assessment encompasses a detailed review of the operator's security documentation and protective measures established for delegators. We scrutinize implemented security protocols, conducted audits, and evaluate the staking infrastructure from a security standpoint. Operationally, we focus on validator maintenance practices and designs concerning AVS selection.

  • On-chain Performance: We track the operator's on-chain records, which provide crucial insights into their historical performance and behavioral patterns.

Utilizing this framework, we have conducted due diligence on Validation Cloud and P2P.org, the initial operators with whom YieldNest has begun forming a business relationship to leverage their whitelabel restaking service. The collective findings from both examinations support YieldNest's decision to delegate to these node operators, acknowledging their demonstrated operational proficiency. However, YieldNest Risk has advised maintaining vigilance and attentiveness to specific areas of concern, such as the lack of transparency in certain service features and potential risks associated with infrastructure centralization.

This evaluation methodology will be consistently applied to other professional operators in YieldNest's onboarding pipeline, ensuring a standardized and thorough assessment process. The operators currently in the pipeline include Google, T-Mobile, Figment, Nethermind, and Everstake.

2.2 Accelerated Operator Onboarding

For the intermediate time, since slashing and rewards are not fully live yet, YieldNest intends to maximize its exposure to potential early-user loyalty rewards by pointing all of its EigenPods to P2P.org, A41, and Kiln [all AVS]. They subsequently plan to build out a whitelabeled version of operators and AVSs, as described above, in preparation for slashing conditions at a later date.

Recognizing the necessity for agile decision-making, particularly concerning prompt delegation to operators due to business imperatives and systemic dynamics, we have provisioned for YieldNest to delegate restaked assets to additional Operators without comprehensive due diligence under certain circumstances. This approach is deemed viable exclusively in a no-slashing environment, with the stipulation that the selected node operators must meet specific standards, including comparable market presence, reputation, and prominence to the currently approved operators.

The accelerated operator onboarding strategy includes the following operators:

Drawing parallels to the expedited AVS onboarding process, we strongly recommend that operator selections be subject to rigorous re-evaluation once slashing mechanisms are activated on EigenLayer.