# YieldNest AVS Risk Assessment Framework - Draft Notes ==Svetlin: Reorganised the file, below are the draft sections that you may amend/expand as you wish== ### Section 1: AVS Fundamentals 1.1. General Description 1.1.1 Business model > Define the core functions of the Actively Validated Service (AVS), detailing its primary business model and how it intends to generate revenue or value. Key elements to explore include the specific problems the AVS addresses, its product-market fit, and its targeted customer base. Describe how the service differentiates itself in the market and any unique value propositions it offers. 1.1.2 Organisational structure > Analyze the organizational framework of the AVS, identifying key founders, team members, and any entities responsible for its development and maintenance. Outline any significant roles or responsibilities within the organization. 1.1.3 Third-party relations > Evaluate the network of relationships that the AVS maintains with investors, advisors, and other significant parties that might influence the protocol. Discuss any strategic partnerships or integrations with other networks or protocols. Highlight how these relationships impact the AVS’s development and market positioning. 1.1.4 History > Examine the history of the protocol, focusing on its development timeline, major milestones, and any significant events that have shaped its trajectory. 1.1.5 Competition > Assess the competitive landscape by identifying direct competitors and their relationship to the AVS, including any potential conflicts or synergies. Cover any overlap in funding sources, such as venture capital firms that have invested in multiple competing services. 1.2 System Architecture 1.2.1 System Overview > Describe the main components of the AVS, including both on-chain and off-chain elements. Detail the operational mechanics of the protocol and how it interacts with security providers and other blockchain networks. 1.2.2 Architecture Diagram > Provide a detailed architecture diagram that visualizes the information described in 1.2.1. Include an infographic-style explanation of key components, illustrating how they interconnect and function within the overall system. ### Section 2: Performance ==**TODO** @Marin== ### Section 3: Technology Risks 3.1. Smart Contract Risk 3.2. Slashing Risk 3.3. Depeg Risk > Examine the risk associated with the depegging of underlying staked assets due to potential compromises in their smart contracts. Focus on the consequences of such events, including possible mass liquidations. ### Section 4: Operational Risks 4.1. Rehypothetication Risk > Explore the historical performance and assess the failure probability of validators within the network, especially focusing on those whose failure could impact multiple protocols relying on shared security. Consider historical data and patterns of validator performance to evaluate potential risks and system resilience. 4.2. Collusion Risk > Analyze the possibility of collusion among validators, where a group could potentially gain majority control and thus pose a significant security threat to the protocol. 4.3. Centralization Risk > Discuss how the freedom of choice in selecting protocols for optimal yields might lead to centralization. This section should also clarify the decision-making process regarding yield selection — whether these decisions are made democratically by the community or are controlled by a few individuals. 4.4. Security Risk > Evaluate the security measures implemented to prevent, detect, and respond to incidents, ensuring that the crypto-economic security guarantees are met. If public data available, review the internal control mechanisms and risk management procedures in place. 4.5 Liquidity Risk > Explore if there is adequate restaked liquidity within the system to maintain the security. ### Section 5: Counterparty Risks 5.1. Tokenomics > Evaluate the tokenomics of the AVS, focusing on the multifunctional roles of tokens such as governance, funding, incentives, and as a payment method for protocol expenses. Given the yield expectations through restaking, the native token's intensives should be critically analyzed. Consider how these tokenomics affect user behavior, network security, and overall ecosystem sustainability. 5.2. Solvency 5.2.1. Revenue > Detail the various sources of income for the AVS, such as transaction fees, service charges, or any other revenue streams. Understanding these sources is crucial for evaluating the financial viability and sustainability of the service. 5.2.2. Pay-offs > Describe how the protocol compensates for economic security, including the types of payments (e.g., ETH, AVS native tokens) and the conditions associated with alternative tokens used as payment. This includes any restrictions or special terms applied to these alt tokens. 5.3. Legal 5.3.1. Legal Structure > Explore whether there is a designated legal entity responsible for operating specific components or the entire AVS protocol. Detail the responsibilities of such entities and include a search for publicly available information regarding their formation. 5.3.2. Legal Arrangements > Detail the formal agreements between the AVS and its validators. Discuss the specific obligations and considerations of both validators and the AVS under these agreements, as well as any warranties provided. 5.3.3. Regulatory Risk > Analyze the regulatory environment relevant to the AVS's business model and legal structure. Identify potential changes in regulations and evaluate the risk of the AVS being subjected to regulated activities under the national laws of any country, which could impose strict requirements on its operations. === ## High level (johnny) We need to evaluate AVSs from two perspectives: 1. Restaker perspective - choosing AVSs (**our focus**) 2. AVS perspective - choosing stakers and node operators (**not our focus**) As far as i know, we dont have AVS customers at the moment, so #2 can be taken care of at a later date, when relevant. The framework we're looking to build for #1 should provide all the relevant info that will help a restaker choose whether on not he is willing to opt into a specific AVS. In order to achieve the above goal, we'll need to understand the **risk profile** and **reward profile** of a specific AVS. ### AVS Risk Profile Risks associated with opting into an AVS: 1. **smart contract risk** - AVS code may not behave as intended (i.e. have bugs), which could lead to slashing without NOs misbehaving. 2. **Coordinated Misconduct Among NOs** - economically viable when NOs can profit more by misbehaving than they would lose from slashing (e.g. attack system profits 100 ETH and slashing causing a loss of 99 ETH ---> 1 ETH profit). 3. TODO? ==@Svetlin:== 3. Slashing Risk is observed as stand-alone category or under the hood of Smart Contract Risk? General SC Risk introduces multiple exploit vectors. 4. Depeg Risk - in the event of compromised underlying LST/LRT token contract, mass liquidation events may occur 5. Counterparty Risk - Solvency (Financial) Risk and Legal Risk may be incorporated into the Counterparty section Mitigations associated with the above risks: 1. **smart contract risk** - TODO (TEEs/anti-slasher, veto committee, audits, best practices, insurance fund, ?) 2. **Coordinated Misconduct Among NOs** - TODO (make sure funds at stake are more than funds at risk, legal obligations, ?) ### AVS Reward Profile TODO (below Revenue section could fit here) ------------- ------------- ------------- ### Revenue #### Sources of AVS return ![image](https://hackmd.io/_uploads/S100eGPl0.png) Steakhouse projects Restaking Operating Affordability Ratio (ROAR) ROAR = AVS Cash Earnings / Total Restaking Fees Due AVS Cash Earnings = Profitability x Efficiency x TVL = AVS Earnings / Sales x Sales / Assets x Assets #### AVS pay-offs How do the restakers get paid - ETH or AVS native tokens? What are the conditions imposed over alt tokens used as payment method? ### AVS Selection Methodology 1. Existence of insurance fund - related to Solvency Risk 2. Are the agreements with NO formalised (signed-off contract)? What are the warranties under these agreements? 3. Decision-making power - who is in charge of selecting parties to provide security to? 4. High-level overview of AVS business model - target customers, product market fit, financial metrics relevant to yield distribution ==== === Decentralisation check list ==@Svetlin: Where is best suited?== Tech level - publicly accessible service without restrictions or privileges implemented for certain counterparties, third-party contributions are allowed, certain functions can be taken by entities different from the core team, diversed accessibility through multiple user interfaces Governance level - distributed voting power, governance processes are public and transparent, protocol roadmap is decided upon by the community, DAO-granted mandate for entering into agreements Operational level - open source code, public security audits, comprehensive project documentation, multifaceted ongoing development funding, no control or sufficient influence is exercised by a single party or small circle of individuals/entities Evaluation of facts and circumstances: (a) the roles of persons and entities and how those persons and entities interact with each other and how those roles and relationships may evolve over time; (b) the ability of persons and entities, such as developers or foundations or DAOs, to control or influence a product, service, or activity offered, provided, or engaged in, including through actions that would impact a smart contract, protocol, or any particular product, service, or activity offered, provided, or engaged in, whether by setting or adjusting parameters, controlling user funds or assets, altering transactions, or controlling access or information with respect to the product, service or activity, entering into agreements that impact the product, service, or activity, or exercising some other control or influence; (c) whether there are others exercising control or influence over the product, service, or activity, such as venture capital firms, large investors, or governance/voting token holders or voters;