Building EigenLayer AVS: Operators & Contracts

Learning Goal: Learn how to develop Actively Validated Services (AVS) on EigenLayer. Understand the underlying mechanics of shared security, design and deploy Solidity-based Service Manager and Registry smart contracts, implement off-chain operator network clients using the Eigenlayer Go/Rust SDK, and orchestrate cryptographic BLS signature aggregation.

Prerequisites

  • Solid Foundation in Solidity: Writing, compiling, and deploying basic ERC-20 and governance-style smart contracts.
  • Basic Go or Rust Programming: Comfort reading and writing asynchronous concurrent network programs.
  • General Cryptography Basics: Familiarity with public-private key cryptography, hashing, and command-line execution interfaces.

Estimated Total Study Time

  • 24 Hours (including hands-on sandbox coding, architectural designs, and deployment walkthroughs)

Module 1: Ethereum, Solidity, and Proof of Stake Essentials

This prerequisite module consolidates the foundational building blocks of decentralized architecture. You will review how the Ethereum Virtual Machine (EVM) operates, write basic smart contracts in Solidity, and dissect the economic security architecture of Proof of Stake (PoS), specifically focusing on validator slashing rules and Liquid Staking Tokens (LSTs).

Recommended Videos

  • Why this video: This video builds a clear intuition for how Ethereum functions as a decentralized state machine. It provides the essential conceptual background for understanding why smart contracts are immutable and how they executionally anchor off-chain computations.

  • Why this video: A comprehensive, fast-paced dive into Solidity. It is crucial for mastering state variables, structs, mappings, visibility modifiers, and external function calls, which you will use directly when writing AVS Service Manager and Registry contracts.

  • Why this video: A concise explanation of slashing. Understanding the explicit economic penalties for double-signing or validator negligence is critical since EigenLayer extends this exact cryptoeconomic security model to secure third-party modules.

  • Why this video: This animation establishes a strong mental model of Liquid Staking Tokens (LSTs) and Liquid Restaking Tokens (LRTs). It visually bridges the gap between base-layer Ethereum validation and restaking-derived yields.

Knowledge Checkpoint

  • Understand how state changes are committed to the EVM and the gas implications of transaction execution.
  • Write, compile, and deploy a simple Solidity contract utilizing custom structs and public state mappings.
  • Articulate the technical and economic difference between native staking (32 ETH via Beacon Chain) and Liquid Staking Protocols (LSTs).
  • Define what "slashing" is, and list the classic physical validator behaviors that trigger it.

Module 2: Introduction to EigenLayer and Restaking

This module introduces EigenLayer as a platform for decentralized trust. You will learn about the foundational whitepaper concepts, how the protocol unbundles the trust layer of Ethereum, and the mechanics of restaking assets through smart contract interactions.

Recommended Videos

  • Why this video: Sreeram Kannan, the founder of EigenLabs, breaks down the core thesis behind pooled security. He explains how bootstrapping a new trust network is the most massive hurdle for protocol builders and how EigenLayer fundamentally solves this problem.

  • Why this video: An elite-level technical discussion featuring key Ethereum core developers and Sreeram Kannan. It outlines how restaking bridges validator assets to smart-contract-controlled parameters like EigenPods, detailing the technical boundaries of programmatic stake delegation.

  • Why this video: A clear, high-level walkthrough of the restaking architecture that demonstrates the pipeline of opting-in to secure multiple protocols and receiving modular incentives in return.

Knowledge Checkpoint

  • Explain the concept of "pooled security" and why it is economically superior to starting a standalone consensus layer.
  • Define the architectural role of an EigenPod and how it modifies withdrawal credentials on the consensus layer.
  • Understand the mechanism of delegated staking: how a restaker chooses and assigns their capital to a specific operator node.
  • Identify the core system risks of restaking, including centralization risks and the potential for cascading slashing loops.

Module 3: Actively Validated Services (AVS) Architecture

This module explains the structural components of an Actively Validated Service (AVS). You will dissect the design space of an AVS, analyze its modular components, and learn how developers, operators, and restakers interact to enforce custom verification logic.

Recommended Videos

  • Why this video: A focused, step-by-step developer introduction explaining exactly what an AVS is. It covers how custom consensus services (like decentralized oracles, zero-knowledge proofs, or bridges) are structured visually and logically.

  • Why this video: A succinct, concentrated explanation of how EigenLayer operates as an extensible framework to validate arbitrary, custom mathematical, computational, or database operations.

  • Why this video: Walkthrough of a real-world integration context. This hackathon presentation details how multi-system infrastructures link with EigenLayer middleware to secure non-EVM execution layers.

Knowledge Checkpoint

  • Draw a block diagram showing the flow of data between a Client User, the AVS Service Manager, the Off-chain Operator network, and the Aggregator.
  • Distinguish between the target use cases of oracles, bridges, sequencing layers, and coprocessors, and explain how each fits into the AVS model.
  • Understand how restakers back specific operators and how that delegation creates a direct cryptoeconomic security ceiling for the AVS tasks.
  • Explain how an AVS defines its custom "slashing conditions" for malicious operator behaviors.

Module 4: Designing the On-Chain Service Manager

In this module, you will learn how to design, write, deploy, and manage the core smart contract interfaces of an AVS on Ethereum. Since direct codebase video tutorials for these specific contracts are scarce in public pools, this module provides the architectural framework and code patterns you need to implement.

Recommended Videos

  • Why this video: This video introduces Scaffold-Eth and Hardhat. It is the premier resource for learning how to deploy multi-contract architectures, link libraries, and write unit tests for complex smart contract relationships.

Video Pool Architectural Gap & Implementation Guide

Currently, there is a lack of high-quality video walkthroughs specifically coding an EigenLayer ServiceManager from scratch. To bridge this gap, study the architectural roadmap below to implement your on-chain component:

  1. Inheriting Interfaces: Your AVS ServiceManager contract must inherit from EigenLayer's base contracts. Specifically, look at IServiceManager and import the core registry layouts:
    // Import dependencies from layr-labs/eigenlayer-middleware
    import "@eigenlayer-middleware/contracts/interfaces/IServiceManager.sol";
    import "@eigenlayer-middleware/contracts/ServiceManagerBase.sol";
    
  2. Task Creation Protocol: Implement a state variable that increments with every new computational task requested:
    struct Task {
        uint32 taskCreatedBlock;
        bytes inputData;
        bytes signatures;
    }
    mapping(uint32 => bytes32) public taskCommits;
    
  3. Task Dispatch: Create a function createNewTask(bytes calldata inputData) that emits a NewTaskCreated event. The off-chain operator network listens for this event to execute computations.
  4. Signature Verification: Implement a verification loop that takes the aggregate signature returned by the network, cross-references it with the registered operators' weights inside the Registry system, and verifies the task execution's cryptoeconomic validity.

To explore existing production templates, search for:

"EigenLayer ServiceManager contract development Solidity" or inspect the official repository @layr-labs/eigenlayer-middleware on GitHub.

Knowledge Checkpoint

  • Explain the structural relationship between the DelegationManager, RegistryManager, and ServiceManager contracts.
  • Write a custom Solidity function to track and emit AVS tasks with unique, verifiable identifiers.
  • Understand how to configure a Hardhat/Foundry deployment script to initialize contract proxy configurations for AVS state management.
  • Detail how a contract registers and keeps track of operator addresses and their active stake weights.

Module 5: Building the Off-Chain Operator Network & SDK

This module covers the off-chain components of the AVS architecture. You will learn how to write client software that tracks dispatched tasks, processes the required off-chain computations, and submits verifiable signatures back to an aggregator or smart contract.

Recommended Videos

  • Why this video: An in-depth demonstration of setting up an active operator node on a Virtual Private Server (VPS). It provides direct insights into the configuration, environment setup, and system resource management required to run active AVS validation clients.

  • Why this video: A discussion on why developers use Go for building high-performance decentralized consensus client engines. It underscores why the official EigenLayer SDK is primarily built in Go to optimize network latency and concurrency.

Video Pool Architectural Gap & Implementation Guide

Because deep technical walkthroughs of writing Go/Rust code using the EigenLayer SDK are not widely available in video format, use the following developer blueprint to write your off-chain client:

  1. Client Setup: Initialize your Go program, importing the eigenlayer-middleware SDK modules. Create an Ethereum client connection using ethclient.Dial().
  2. Event Listener: Implement an asynchronous subscription block to listen for NewTaskCreated log events emitted by the deployed ServiceManager contract:
    // Listen for task events
    query := ethereum.FilterQuery{
        Addresses: []common.Address{serviceManagerAddr},
    }
    logs := make(chan types.Log)
    sub, err := client.SubscribeFilterLogs(context.Background(), query, logs)
    
  3. Execution Logic: When an event arrives, parse the data payload, perform the required custom task processing (e.g., calculations or data validation), and generate the computational output.
  4. Task Signing: Sign the resulting computational digest using the operator's private key. Ship this cryptographic signature to the Aggregator server via a secure JSON-RPC or gRPC channel.

To find more developer documentation and templates, search for:

"Eigenlayer SDK Go code walkthrough" or analyze the basic structure of the incredible-squaring repository in the Layr-Labs repositories on GitHub.

Knowledge Checkpoint

  • Understand the off-chain architecture of an operator client node and how it handles concurrency.
  • Configure environment variable files (.env) safely to manage operator ECDSA and BLS private keys.
  • Draft a Go or Rust network loop capable of connecting to an RPC node, parsing smart contract event logs, and outputting execution outputs.
  • Explain the structural and network communication differences between the operator node client and the centralized/decentralized AVS task aggregator.

Module 6: Cryptography: BLS Signatures and Operator Registration

In this final module, you will dive into the underlying cryptography used by EigenLayer for highly scalable validation. You will study how multiple independent operator signatures are combined into a single, compact proof to reduce on-chain verification costs, and explore the mathematical curves that support this aggregation.

Recommended Videos

  • Why this video: An elite technical deep dive into the Boneh-Lynn-Shoup (BLS) signature scheme and the BLS12-381 pairing-friendly elliptic curve. This video explains how individual signatures on G1 are aggregated and validated on G2, which is the exact mathematical foundation used by EigenLayer AVS networks.

Video Pool Architectural Gap & Implementation Guide

To bridge the gap concerning practical implementations of BLS key registration and aggregation inside EigenLayer projects, study this mathematical and structural pipeline:

  1. The BLS Key Registration Pipeline: Before verifying tasks, operators register their public keys on-chain via the Registry system. During this step, the operator registers both an ECDSA key (used for standard transaction execution and management) and a BLS key (used for task validation and aggregate signatures). This mapping links their cryptoeconomic identity to their off-chain computational signatures.
  2. The Aggregator Protocol Lifecycle:
    • Step A: An AVS task is emitted on-chain.
    • Step B: NN operators listen, perform calculations, and sign the task output using their BLS private keys, generating individual signatures (sis_i).
    • Step C: Operators send their private signatures (sis_i) alongside their identifiers to a central off-chain Aggregator.
    • Step D: The Aggregator runs the BLS mathematical aggregation routine, combining individual signatures into a single aggregate BLS signature: S=i=1ksiS = \sum_{i=1}^{k} s_i
    • Step E: The Aggregator generates an associated bitmap indicating which operators signed. It then submits this single signature (SS) and the bitmap to the ServiceManager contract, saving enormous amounts of on-chain gas.

To supplement this cryptographic architecture, search for:

"BLS signature aggregation EigenLayer AVS" or refer to standard pairing-friendly libraries like kiln-finance/bls or herumi/bls.

Knowledge Checkpoint

  • Explain the key advantage of BLS signature aggregation over standard ECDSA signatures in systems with large validator counts.
  • Understand why BLS signatures can be combined into a single flat proof and how that proof is verified against aggregated public keys.
  • Map out the on-chain registry mapping process that links an operator's standard Ethereum address to their BLS public key.
  • Detail the role of the Aggregator in collecting signatures, generating bitmasks, and submitting proofs back to the AVS contracts.

Course Map


Key People Index

  • Sreeram Kannan
    • Context: Founder of EigenLabs and Director of the UW Blockchain Lab. He is the lead researcher and architect behind the concepts of restaking, shared security pools, and decentralized AVS design.
  • Vitalik Buterin
    • Context: Co-founder of Ethereum. His work on consensus protocols, PoS scaling, and economic security models provides the foundational logic for modular scaling solutions and restaking frameworks.
  • Terence Tsao
    • Context: Consensus Client Developer at Offchain Labs. His research and engineering focus on performant, production-ready Go architectures provides the standard design patterns for decentralized off-chain nodes.

Final Self-Assessment

Complete this comprehensive developer checklist to verify your mastery of developing and deploying an Actively Validated Service (AVS) on EigenLayer:

  • EVM Basics: You can confidently explain the difference between execution on standard EVM layers and validating tasks on custom consensus layers.
  • Liquid Restaking Mechanics: You can detail exactly how EigenPods intercept Beacon Chain withdrawals to enforce programmatic slashing rules on restaked ETH.
  • AVS Components: You can map out all core actors in the AVS ecosystem, including Operators, Restakers, Developers, and the Aggregator.
  • Contract Compilation: You have compiled a Solidity ServiceManager contract that inherits from ServiceManagerBase without any compiler errors.
  • Event Dispatch: Your Service Manager contract correctly logs custom events whenever a new validation task is created.
  • On-Chain Verification: You can write a Solidity verification routine that parses an aggregate signature and cross-references it with operator registry stakes.
  • Off-Chain Client: You can program an asynchronous listening node in Go or Rust that detects on-chain task requests.
  • Environment Security: Your off-chain client stores operator private keys securely in environment variables and never exposes them to standard output.
  • BLS Core Math: You can explain how the BLS12-381 elliptic curve allows multiple signatures to be aggregated into a single verifiable point.
  • Registry Mapping: You understand the transaction flow that registers an operator's BLS public key alongside their standard address in the AVS registry.
  • Aggregator Coordination: You can write or trace the logic of an off-chain aggregator node that collects individual operator signatures and outputs a single combined signature.
Explore Further

Related Blockchain & Crypto Roadmaps

View All