Merge branch 'main' of github.com:MadelineAu/eigenlayer-docs into eigenlayerContracts

Author: MadelineAu

.github/CODEOWNERS

@@ -1,2 +1,2 @@
-* @dabit3 @wesfloyd @bryangreen @shrimalmadhur @antojoseph @NimaVaziri @scotthconner @MC1823315 @nelsonijih @QuinnLee @mmurrs @non-fungible-nelson
+* @dabit3 @wesfloyd @bryangreen @shrimalmadhur @antojoseph @NimaVaziri @scotthconner @MC1823315 @nelsonijih @QuinnLee @mmurrs @non-fungible-nelson @MadelineAu
 

docs/developers/Concepts/_category_.json

@@ -0,0 +1,4 @@
+{
+  "position": 1,
+  "label": "Concepts"
+}

docs/developers/Concepts/avs-developer-guide.md

@@ -0,0 +1,45 @@
+---
+sidebar_position: 1
+title: AVS Overview
+---
+
+
+## What is an Autonomous Verifiable Service (AVS)?
+
+An Autonomous Verifiable Service (AVS) on EigenLayer is a decentralized service built on Ethereum that provides custom verification mechanisms of off-chain operations. Please see the [Intro to EigenLayer](https://docs.eigenlayer.xyz/eigenlayer/overview/) for background context on the broader EigenLayer ecosystem.
+
+An AVS is composed of on-chain contracts for verification and an off-chain network of Operators. Operators execute the service on behalf of the AVS and then post evidence of their execution on-chain to the AVS contracts. Tasks can be initiated via on-chain contracts, off-chain via direct communication with the Operators, or via a task aggregator entity.
+
+The design of the off-chain execution and on-chain verification is entirely flexible based on the needs of the AVS developer. 
+- If the Operators perform tasks properly, the AVS can autonomously distribute rewards.
+- If the Operators perform tasks maliciously, their delegate stake can be slashed autonomously by the AVS, and the Operator can be removed from the Operator set. 
+
+ Please see the original EigenLayer whitepaper [EigenLayer: The Restaking Collective](/docs/eigenlayer/overview/whitepaper.md) for further background on AVS design.
+
+![AVS Architecture](/img/avs/avs-architecture-v2.png)
+
+
+## Why Build an AVS?
+
+Launching new Web3 projects requires substantial time and effort to bootstrap capital and operators. Builders should focus on their core product differentiators rather than bootstrapping economic security. Building an Autonomous Verifiable Service (AVS) on EigenLayer offers enhanced security, decentralization, and cost efficiency by utilizing Ethereum’s staking mechanism through restaking. This allows developers to focus more on their product’s core value and innovation without the significant overhead of setting up a new consensus mechanism or validator networks from scratch.
+
+The key benefits of building an AVS on EigenLayer include:
+- Security via Restaking: leverage Ethereum’s staking mechanism to secure your service.
+- Focus on your project's unique value: spend less time and resources accumulating economic security from scratch.
+- Bootstrap your Operator network: quickly access a large network of experienced Operators.
+- Decentralization and Trust: build on trust-minimized, decentralized infrastructure.
+- Composability: seamlessly integrate with the broader Ethereum ecosystem.
+
+
+## What Can You Build as an AVS?
+
+The scope of AVS design is broad. It includes **any off-chain service** that can be verified on-chain. This flexibility allows AVS developers to design custom verification mechanisms suited to the unique requirements of their service. The only requirement is that some evidence for the off-chain service’s execution is posted on-chain to enable verification of the service.
+
+Examples of these services include rollup services, co-processors, cryptography services, zk Proof services, and more.
+
+![AVS Categories](/img/avs/avs-categories.png)
+
+
+## Get in Touch
+
+If you would like to discuss your ideas to build an AVS on EigenLayer, submit your contact information via [this form](https://share.hsforms.com/1BksFoaPjSk2l3pQ5J4EVCAein6l) and we'll be in touch shortly.

docs/developers/HowTo/_category_.json

@@ -0,0 +1,4 @@
+{
+  "position": 1,
+  "label": "How To"
+}

docs/developers/avs-opset-slashing.md renamed to docs/developers/HowTo/avs-opset-slashing.md

@@ -1,6 +1,6 @@
 ---
 sidebar_position: 4
-title: AVS Operator Set and Slashing of Unique Stake
+title: Implement Slashing of Unique Stake
 ---
 
 
@@ -106,3 +106,28 @@ AVS may integrate the AllocationManager via:
 * Specify an additional AVSRegistrar contract that applies business logic to gate Operator registration to an Operator Set.
 
 To ensure community and incentive alignment, it is generally expected that AVSs will conduct off-chain outreach to communicate the purpose and task/security makeup of their Operator Sets with their Operators and Stakers prior to beginning registration.  This likely would include any potential hardware, software, or stake requirements. It is up to the AVS to decide task distribution within an Operator Set.
+
+##  Best Practices
+
+### Operator Set Design
+
+An Operator Set is a grouping of different types of work within a single AVS. Each AVS will have at least one Operator Set. The EigenLayer protocol does not enforce criteria for Operator Sets, however there are a few best practices to consider.
+
+Plan to logically group your AVS tasks (and verification) into separate Operator Sets. First organize your Operator Sets according to which conditions you wish to distribute Rewards for. These conditions could include:
+* Unique business logic.
+* Unique Stake (cryptoeconomic security) amount and types of token required to be allocated from Operators.
+* Slashing conditions.
+* Ejection criteria.
+* Quantity of Operators and criteria for operators allowed.
+* Hardware profiles.
+* Liveness guarantees.
+
+More detail on Operator Sets are available [here](https://docs.eigenlayer.xyz/eigenlayer/operator-guides/operator-sets#operator-sets-currently-in-testnet) and implementation details are available [here](https://docs.eigenlayer.xyz/developers/avs-opset-slashing).
+
+
+
+### Slashing Design and Veto Committees
+
+The EigenLayer protocol allows each AVS builder to design their own slashing conditions. One popular design is to utilize a governance mechanism with slashing such that a committee can review a proposed (or queued) slashing request. That slashing request can then be either fulfilled or vetoed by a committee of domain experts, governance council or multisig address for the AVS. Please see the [vetoable slasher example implementation](https://github.com/Layr-Labs/eigenlayer-middleware/blob/feat/slashing-release-branch/src/slashers/VetoableSlasher.sol) for reference.
+
+Please be sure that your slashing process can be resolved within the DEALLOCATION_DELAY time window. This is the amount of blocks between an Operator queuing a deallocation of stake from an Operator Set for a strategy and the deallocation taking effect. This will ensure that the slashing event is carried out for the Operator before their stake is deallocated.

docs/developers/avs-permissionlesss.md renamed to docs/developers/HowTo/avs-permissionlesss.md

@@ -1,6 +1,6 @@
 ---
-sidebar_position: 8
-title: Permissionless Token Strategies
+sidebar_position: 7
+title: Add ERC-20 Tokens as Restakable Asset
 ---
 
 # Permissionless Token Strategies

docs/developers/deployment-testnet-mainnet.md renamed to docs/developers/HowTo/deployment-testnet-mainnet.md

@@ -1,6 +1,6 @@
 ---
-sidebar_position: 9
-title: Preparing for Testnet and Mainnet Deployment
+sidebar_position: 6
+title: Prepare for and Deploy to Testnet and Mainnet
 ---
 
 
@@ -15,13 +15,13 @@ title: Preparing for Testnet and Mainnet Deployment
    - Communication channels that will be utilized for AVS upgrades.
    - Describe Operator monitoring tooling available, such as GraFana dashboards, log files or similar.
 
-3. Follow the [AVS Developer Security Best Practices](./avs-developer-best-practices.md) and [Key Manage Considerations for Developers](./avs-developer-best-practices.md#key-management-recommendation-for-developers).
+3. Follow the [AVS Developer Security Best Practices](../Reference/avs-developer-best-practices.md) and [Key Manage Considerations for Developers](../Reference/avs-developer-best-practices.md#key-management-recommendation-for-developers).
 
 4. Implement the [Node Specification](https://docs.eigenlayer.xyz/eigenlayer/avs-guides/spec/intro) for your Operator executable package.
 
 5.  Follow the [Testnet Dashboard Onboarding instructions](https://docs.eigenlayer.xyz/eigenlayer/avs-guides/avs-dashboard-onboarding).
 
-6. Implement Rewards distributions per the instructions [here](./rewards.md).
+6. Implement Rewards distributions per the instructions [here](rewards.md).
 
 
 ## Preparing and Deploying to Mainnet

docs/developers/how-to-build-an-avs.md renamed to docs/developers/HowTo/how-to-build-an-avs.md

@@ -1,11 +1,11 @@
 ---
-sidebar_position: 3
+sidebar_position: 2
 title: Build Your Own AVS
 ---
 
 This section will walk you through the process of designing and building your own AVS from scratch. It is intended to take you from an idea to a working local prototype.
 
-Before proceeding, please review the previous sections on [AVS Overview](./avs-developer-guide.md), [EigenLayer Overview](/docs/eigenlayer/overview/README.md) and the [Quick Start example](./quickstart.md) to become familiar with the basic concepts.
+Before proceeding, please review the previous sections on [AVS Overview](../Concepts/avs-developer-guide.md), [EigenLayer Overview](/docs/eigenlayer/overview/README.md) and the [Quick Start example](quickstart.md) to become familiar with the basic concepts.
 
 
 ## Step 1: AVS Design

docs/developers/avs-dashboard-onboarding.md renamed to docs/developers/HowTo/onboard-avs-dashboard.md

@@ -1,6 +1,6 @@
 ---
-sidebar_position: 7
-title: AVS Dashboard Onboarding
+sidebar_position: 5
+title: Onboard to AVS Dashboard
 ---
 
 

docs/developers/quickstart.md renamed to docs/developers/HowTo/quickstart.md

@@ -1,6 +1,6 @@
 ---
-sidebar_position: 2
-title: Quick Start Example
+sidebar_position: 1
+title: Get started
 ---
 
 ## Hello World AVS: Local Deployment
@@ -84,7 +84,7 @@ function respondToTask(
 }
 ```
 
-Please find a complete list of the requirements to implement an AVS at [Build Your Own AVS: Step 2 Idea to Code](/docs/developers/how-to-build-an-avs.md#step-2-idea-to-code-building-and-deploying-your-avs-locally).
+Please find a complete list of the requirements to implement an AVS at [Build Your Own AVS: Step 2 Idea to Code](/docs/developers/HowTo/how-to-build-an-avs.md#step-2-idea-to-code-building-and-deploying-your-avs-locally).
 
 ### Contract Deployment Scripts
 

docs/developers/rewards.md renamed to docs/developers/HowTo/rewards.md

@@ -1,6 +1,6 @@
 ---
-sidebar_position: 8
-title: AVS Rewards
+sidebar_position: 3
+title: Implement Rewards
 ---
 
 ## Overview

docs/developers/support.md renamed to docs/developers/HowTo/support.md

@@ -1,6 +1,6 @@
 ---
-sidebar_position: 4
-title: Developer Support
+sidebar_position: 8
+title: Get Support
 ---
 
 If you have any questions or comments throughout the AVS development process, you can get support by reaching out to us using the Intercom button on the bottom right side of this page or <a href="javascript:void(0)"  id="intercom_trigger_eldocs" >clicking here</a>. We will promptly follow up with support!

docs/developers/Reference/_category_.json

@@ -0,0 +1,4 @@
+{
+  "position": 1,
+  "label": "Reference"
+}

docs/developers/avs-developer-best-practices.md renamed to docs/developers/Reference/avs-developer-best-practices.md

@@ -24,7 +24,7 @@ These SDKs are wrappers on top of common EigenLayer AVS operations designed to s
 
 ### Developer Tooling
 - [Othentic](https://www.othentic.xyz) - Library of components for AVS builders.
-- [Layer](https://www.layer.xyz/) - Containerized Actively Validated Services (CAVS) via Web Assembly.
+- [Layer](https://www.layer.xyz/) - Containerized Autonomous Verifiable Services (CAVS) via Web Assembly.
 - [AltLayer Wizard](https://wizard.altlayer.io/) - AVS-as-a-Service platform.
 - [Gadget](https://github.com/webb-tools/gadget) - A framework for building modular AVS and Tangle Blueprints.
 

docs/developers/resources.md renamed to docs/developers/Reference/resources.md

@@ -5,7 +5,7 @@ title: Contract Addresses and Docs
 
 ## EigenLayer Core Restaking Contracts
 
-The EigenLayer core contracts are located in this repo: [`Layr-Labs/eigenlayer-contracts`](https://github.com/Layr-Labs/eigenlayer-contracts). They enable restaking of liquid staking tokens (LSTs) and beacon chain ETH to secure new services, called AVSs (actively validated services).
+The EigenLayer core contracts are located in this repo: [`Layr-Labs/eigenlayer-contracts`](https://github.com/Layr-Labs/eigenlayer-contracts). They enable restaking of liquid staking tokens (LSTs) and beacon chain ETH to secure new services, called AVSs (Autonomous Verifiable Services).
 
 ### Deployment Addresses
 

docs/developers/avs-developer-guide.md

@@ -11,7 +11,7 @@ title: FAQ
 
 No, EigenLayer is not a DeFi protocol. EigenLayer is a platform to bootstrap new proof of stake (PoS) systems. Through the EigenLayer protocol, users CANNOT engage in any financial activities such as swapping and lending. 
 
-However, for the decentralized services built on top of EigenLayer (we call them AVSs, Actively Validated Services), these services could be DeFi applications themselves or support key functionalities in other DeFi protocols. These AVSs are external to the EigenLayer contracts.
+However, for the decentralized services built on top of EigenLayer (we call them AVSs, Autonomous Verifiable Services), these services could be DeFi applications themselves or support key functionalities in other DeFi protocols. These AVSs are external to the EigenLayer contracts.
 
 Moreover, another class of protocols built on top of EigenLayer is called liquid restaking token (LRT). They function similarly to liquid staking tokens. They are permissionlessly built on EigenLayer. We urge users to do their own research before interacting with LRTs.