Smart Contract Integration
Documentation for Smart Contract Integration in the EigenLayer-AVS system.
Purpose and Scope#
This page documents the smart contract architecture and integration within the EigenLayer-AVS system. It covers the system's interaction with EigenLayer contracts for AVS operations, the implementation of Account Abstraction (ERC-4337) for smart wallet management, and the contract mechanisms for operator registration and task management. For details on how operators interact with these contracts, see Operator.
Contract Architecture Overview#
The EigenLayer-AVS system integrates with blockchain networks through a multi-layered contract architecture deployed across multiple networks with consistent addresses. These contracts enable decentralized task execution, account abstraction, and EigenLayer restaking capabilities.
Title: EigenLayer-AVS Contract Architecture Overview
Sources:
Smart Contract Components#
The system relies on three main contract subsystems:
1. EigenLayer AVS Contracts#
These contracts enable integration with EigenLayer's restaking protocol:
| Contract | Purpose |
|---|---|
| AVS Service Manager | Main entry point for AVS operations |
| Registry Coordinator | Coordinates operator registration across multiple registries |
| BLS APK Registry | Manages BLS public keys for operators |
| Index Registry | Maintains indices for efficient operator lookup |
| Stake Registry | Tracks operator stake amounts and delegations |
| Operator State Retriever | Utility contract for querying operator state |
Operators register with these contracts as part of the onboarding process, as shown in the registration code.
Sources:
2. Account Abstraction (ERC-4337) Contracts#
The system implements Account Abstraction through:
| Contract | Purpose | Address Example |
|---|---|---|
| AAConfig | System configuration contract | 0x5327443cF04e6E8c3B86BDBbfaE16fcB965b7564 |
| Wallet Implementation | Core smart wallet logic | 0x552D410C9c4231841413F6061baaCB5c8fBFB0DE |
| Factory Proxy | Deployable proxy that creates new smart wallets | 0xB99BC2E399e06CddCF5E725c0ea341E8f0322834 |
| Factory Implementation | Actual implementation of wallet factory | 0x5692D03FC5922b806F382E4F1A620479A14c96c2 |
| Paymaster | Handles sponsored transactions | 0xB985af5f96EF2722DC99aEBA573520903B86505e |
These contracts maintain consistent addresses across multiple networks including Base Sepolia, Sepolia, Base, Ethereum, Soneium, and Minato.
Sources:
3. Task Management Contracts#
These contracts manage the task execution pipeline:
| Contract | Purpose |
|---|---|
| Task Manager | Tracks and manages task execution status |
| AP Config (AAConfig) | Manages operator aliases and system configuration |
The AP Config contract is particularly important for operator identity management, allowing operators to declare alias addresses.
Sources:
Network Deployment#
The EigenLayer-AVS contracts are deployed with consistent addresses across multiple networks:
| Network | Type | Function |
|---|---|---|
| Ethereum | Mainnet | Primary production environment |
| Base | Mainnet | Layer 2 production environment |
| Soneium | Mainnet | Additional production environment |
| Sepolia | Testnet | Testing environment for Ethereum |
| Base Sepolia | Testnet | Testing environment for Base |
| Minato | Testnet | Testing environment for Soneium |
Sources:
Transaction Flow and Fee Management#
The system uses ERC-4337's account abstraction pattern for transaction management:
Title: ERC-4337 Transaction Flow
Sources:
Bundler System#
The system uses a bundler implementation called Voltaire that submits UserOperations to the EntryPoint contract:
| Network | Bundler Address | Type |
|---|---|---|
| Ethereum Mainnet | 0x6A99324303928aF456aA21f3C88dc58E812D9B40 | EOA |
| Base Sepolia | 0xE164dd09e720640F6695cB6cED0308065ceFECd9 | EOA |
Sources:
Pre-funding Requirements#
Smart wallets require pre-funding with ETH to cover transaction fees:
| Network | Recommended Pre-fund (ETH) |
|---|---|
| Ethereum | 0.4 |
| Sepolia | 0.4 |
| Base | 0.001 |
| Base Sepolia | 0.00005 |
Sources:
Operator Registration Process#
Operators must register with the EigenLayer AVS contracts to participate in the network:
Title: Operator Registration with EigenLayer AVS
The registration process involves:
- Generating a salt and expiry timestamp
- Providing BLS keypair information
- Specifying quorum numbers (typically
[0]) - Supplying an optional socket string for network communication
Sources:
Alias Management#
Operators can declare alias addresses through the AP Config contract, allowing for operational security by separating staking keys from operational keys:
Title: Operator Alias Declaration Process
The alias management functionality includes:
- Creating or importing an ECDSA key pair
- Reading the key using a secure passphrase
- Declaring the alias address to the AP Config contract
- Optional undeclaring of an alias when no longer needed
Sources:
Integration Patterns#
The system integrates with these contracts through several common patterns:
Direct Contract Interaction#
Components directly call contract methods for operations like registration, alias declaration, and task management.
Title: Direct Contract Interaction Pattern
Sources:
Contract State Retrieval#
The system queries contract state to verify registration status and retrieve configuration:
Title: Contract State Retrieval Pattern
Sources:
Conclusion#
The smart contract integration in the EigenLayer-AVS system provides a foundation for decentralized task execution with account abstraction capabilities and EigenLayer security guarantees. The contracts are deployed consistently across multiple networks, enabling both production and testing environments. Operators interact with these contracts for registration and alias management, while the system handles transaction flow according to the ERC-4337 standard.
Sources:
Feature this wiki to auto refresh weekly
Try DeepWiki on your private codebase with Devin