Import Externally-Deployed AVS

Importing Externally-Deployed AVS into WIZARD is currently still work in progress

Overview

An externally-deployed AVS (Active Validator Set) must adhere to a set of standardized interfaces and practices to ensure compatibility within the EigenLayer ecosystem and AltLayer. This document outlines the requirements for these AVS contracts, guaranteeing that they work seamlessly with other components expecting AVS conformity. Additionally, an optional allowlist feature using IOperatorAllowlist can be implemented to further restrict which operators can register.

Version Requirement

At the moment, developers are required to use version v0.2.1-mainnet-rewards of the EigenLayer Middleware. Ensure that your AVS contract adheres to this version for proper functionality and compatibility.

1. Interface Compliance

Every AVS must implement the IServiceManager interface. This ensures that the AVS can be indexed, managed, and interacts properly with both EigenLayer and AltLayer services. Below are the details for the primary interfaces:

IServiceManager

The IServiceManager interface forms the main point of interaction for an AVS to push updates to the EigenLayer rewards system. It is an extension of IServiceManagerUI and includes functionalities to create reward submissions and manage operator interactions.

• Source File: IServiceManager

IServiceManagerUI

This interface outlines the required user interface functionalities that every AVS should provide. It includes the following functionalities:

• Updating the metadata URI

• Registering and deregistering operators with the AVS

• Fetching restaked strategies for operators

• Providing the list of restakable strategies

• Source File: IServiceManagerUI

Optional: IOperatorAllowlist

To further enhance security and control over which operators can interact with the AVS, the IOperatorAllowlist interface can be optionally implemented. This allows the AVS to manage a list of approved operators who can register and participate. AVS that do not wish to impose restrictions on operators can ignore this feature.

• Source File: IOperatorAllowlist

You can easily inherit and use the OperatorAllowlist implementation from the template provided in this repository.

Benefits of IOperatorAllowlist

• Restricts which operators can register, providing better security and control over participation.

• Operators can be added or removed from the allowlist dynamically through the AVS interface.

2. Metadata Requirements

The AVS metadata must be stored at a URI accessible through updateAVSMetadataURI. The JSON file at this URI should follow the example structure below:

{
  "name": "Example AVS",
  "website": "https://example-website.xyz/",
  "description": "This is an example of an AVS",
  "logo": "https://example-bucket.s3.amazonaws.com/logo.png",
  "twitter": "https://twitter.com/examplehandle"
}

Each field is required and should accurately reflect the AVS service.

3. Signature Validation

The contract must handle operator registration and deregistration securely by validating the signatures properly using the ISignatureUtils interface. Ensure:

• Signatures include a salt and expiry to avoid replay attacks.

• Signature validation logic complies with the ISignatureUtils.SignatureWithSaltAndExpiry structure.

4. Compatibility with AVS Directory

Your AVS contract must be able to communicate with the AVSDirectory contract. This involves:

• Correctly forwarding operator registration and deregistration calls to the AVSDirectory.

• Ensuring your contract’s structure and state are compatible with AVSDirectory expectations.

5. Examples

You can find examples in here.

By adhering to these standards, externally-deployed AVS contracts will be able to maintain full compatibility with both the EigenLayer and AltLayer ecosystems, ensuring smooth operations across all services and interfaces.