Developer reviewing smart contract architecture diagrams on a glass wall in a modern WeWork space, standing desk in background, natural industrial aesthetic, candid engineering moment.
Protocols

AVS Node Interface Specification

The standard API contract that every Actively Validated Service (AVS) must implement to communicate with EigenLayer core middleware. Tracks versioned interfaces, breaking changes, and compatibility requirements.
introduction
CANONICAL MIDDLEWARE CONTRACT

What is the AVS Node Interface?

The standard API contract that every Actively Validated Service must implement to communicate with EigenLayer core middleware, defining operator registration, task response, and slashing conditions.

The AVS Node Interface is the canonical on-chain API contract that bridges EigenLayer's restaking core with Actively Validated Services (AVSs). It standardizes how AVSs register with the protocol, receive operator commitments, distribute task definitions, and process operator responses. For any service to inherit cryptoeconomic security from EigenLayer, its smart contracts must conform to this interface, making it the single most critical specification for AVS developers and the middleware maintainers who ensure protocol-wide compatibility.

The interface defines a strict set of functions for operator registration, deregistration, and signature verification, often leveraging BLS signature aggregation for scalable attestations. It also encodes the hooks through which slashing conditions are enforced, linking operator misbehavior to the penalty logic in the core protocol. A breaking change to this specification can invalidate existing AVS deployments, requiring coordinated upgrades across all dependent services. The specification is versioned and tracked through the EigenLayer Improvement Proposal (ELIP) process, with ELIP-0001 and ELIP-0002 providing foundational standards for the slashing API and operator set architecture that build upon this base interface.

For AVS developers, strict compliance with the current interface version is a non-negotiable requirement for mainnet activation. Operator clients must implement the corresponding off-chain logic to watch for new task events and submit responses according to the defined API. A mismatch between an AVS's deployed interface and an operator's client version leads to silent failures, missed rewards, and potential slashing. Chainscore Labs can provide an interface compliance review and migration planning to help teams navigate breaking changes, ensuring that AVS contracts and operator software remain compatible with the evolving EigenLayer middleware.

AVS NODE INTERFACE SPECIFICATION

Quick Facts

Key operational and compatibility facts about the canonical API contract between AVSs and EigenLayer core middleware.

AreaWhat changesWho is affectedAction

Interface Versioning

Versioned API contract with potential for breaking changes between versions.

AVS developers, operator clients, middleware maintainers.

Pin integration to a specific version and monitor the ELIP registry for new versions.

API Surface

Defines the exact methods an AVS must expose for task creation, operator responses, and aggregation.

AVS developers implementing the service contract.

Implement the interface exactly as specified; review for compatibility with your AVS logic.

Operator Communication

Standardizes how operators receive tasks from an AVS and submit signed responses.

Node operators running AVS client software.

Ensure your operator client conforms to the response format and signature scheme required by the spec.

Middleware Compatibility

A non-compliant AVS will fail to register or operate correctly with EigenLayer core contracts.

AVS developers and protocol architects.

Run a full integration test against the target middleware release before mainnet deployment.

Slashing Integration

Specifies how an AVS signals an on-chain slashing condition based on operator responses.

AVS developers, risk teams, and operators.

Review the slashing condition interface to ensure it correctly maps to your service's attributable faults.

Upgrade Path

Breaking changes to the interface require coordinated migration of all dependent AVSs and operator clients.

All AVS developers and node operators.

Plan for a migration window and backward compatibility testing when a new interface version is proposed.

Compliance Review

An interface compliance review identifies deviations that could cause liveness failures or slashing risks.

AVS developers preparing for audit or mainnet launch.

Engage Chainscore for a formal interface compliance review against the canonical specification.

technical-context
AVS NODE API CONTRACT

Technical Mechanism and Interface Surface

The canonical API contract that every Actively Validated Service must implement to communicate with EigenLayer core middleware, defining the versioned interface surface for operator registration, task execution, and slashing conditions.

The AVS Node Interface Specification defines the mandatory on-chain and off-chain API contract that an Actively Validated Service must expose to participate in the EigenLayer protocol. This specification is the primary integration surface between the core middleware contracts and the heterogeneous set of AVS logic. It standardizes how an AVS declares its service, registers operators, distributes tasks, accepts operator attestations, and triggers slashing requests. The interface is versioned, and breaking changes to its methods, event signatures, or expected state transitions can force coordinated upgrades across all operators serving that AVS and any middleware that routes messages to it.

The specification covers several critical interaction domains. For operator lifecycle management, it defines the registerOperator, deregisterOperator, and associated event emissions that the core DelegationManager calls to notify an AVS of stake allocation changes. For task distribution, it standardizes the off-chain API surface—often a gRPC or REST endpoint—that operator nodes query to fetch new work, alongside the on-chain commitment and proof verification methods that validate operator responses. The slashing interface, formalized in ELIP-0001, is a core component: it specifies how an AVS calls freezeOperator and presents a slashing request to the SlashingManager, including the required evidence format and dispute window parameters. The specification also defines the AVS's metadata endpoint, which returns its service name, software version, and a cryptographic hash of its current implementation, enabling operators to detect mismatches.

For AVS developers, strict adherence to this specification is a liveness and security requirement. A non-compliant registerOperator implementation can prevent operators from opting in, while an incorrect slashing interface can make penalties unenforceable, undermining the service's attributable security. Operator client maintainers must map this specification to their internal node logic, handling version negotiation and graceful degradation when an AVS upgrades. Middleware and indexing services parse the standard events to track operator commitments across the ecosystem. Chainscore Labs can provide interface compliance review against the canonical specification, assess the impact of version migrations on operator sets, and plan upgrade paths that minimize downtime and slashing risk.

INTERFACE COMPLIANCE IMPACT

Affected Actors

AVS Developers

AVS developers are the primary implementers of the Node Interface Specification. Any version bump or breaking change requires direct code modifications to the service's off-chain node software to maintain compatibility with EigenLayer core contracts.

Key Actions:

  • Audit the service's RPC handlers against the latest canonical specification.
  • Update API endpoints, serialization logic, and error codes to match the new interface.
  • Re-deploy and coordinate node upgrades with operators to avoid liveness failures or slashing.

Chainscore can provide a structured interface compliance review, identifying gaps between your current implementation and the target specification before you deploy.

implementation-impact
INTERFACE COMPLIANCE AND BREAKING CHANGES

Implementation Impact and Migration Triggers

Changes to the AVS Node Interface Specification create direct implementation work for AVS developers, operator clients, and middleware maintainers. Each version bump or method deprecation triggers a compliance review cycle.

02

Operator Client Migration

Operator node software must be updated to call new methods and handle revised response schemas when the AVS Node Interface changes. A deprecated task response format will cause signature verification failures, preventing operators from fulfilling AVS duties and earning rewards. Operator teams need a clear migration window and should test against a staging AVS deployment before the specification's activation deadline. Running an outdated client against a compliant AVS results in liveness faults.

03

Middleware Compatibility Verification

EigenLayer's core contracts act as the intermediary between stakers, operators, and AVSs. A change to the AVS Node Interface often requires a corresponding upgrade to the middleware's DelegationManager or AVSDirectory contracts to correctly route calls and validate signatures. Middleware maintainers must verify that new interface methods are properly permissioned and that the slashing veto committee's API remains coherent with the updated specification.

04

Slashing and Dispute Resolution Impact

The AVS Node Interface defines how AVSs submit slashing requests and how operators can challenge them. A change to the dispute resolution method signature or the evidence struct can break the Slashing Veto Committee's ability to review and reverse penalties. Any modification to these methods must be accompanied by a governance proposal updating the veto committee's operational contract. Failure to align these interfaces creates a window where slashing can occur without a functioning appeal process.

05

Reward Distribution Logic Update

If the interface specification modifies how AVSs report operator performance or distribute rewards, downstream LRT protocols and DeFi integrators must update their reward calculation and claiming logic. A new rewards accumulator contract or a change in the Merkle proof format will break composability for protocols that automatically compound or distribute AVS yield. Integrators should monitor ELIPs that touch the rewards interface and prepare indexer and smart contract updates.

AVS NODE INTERFACE VERSIONING AND BREAKING CHANGE RISK

Compatibility and Risk Matrix

Evaluates the operational impact of changes to the AVS Node Interface Specification on different actors in the EigenLayer ecosystem and recommends verification and migration actions.

AreaWhat changesWho is affectedAction

API Method Signatures

Addition, deprecation, or modification of required RPC methods for AVS node communication.

AVS Developers, Operator Client Maintainers

Review changelog for deprecated methods. Update client implementations to support new signatures before the activation deadline.

Serialization Format

Changes to the data encoding scheme (e.g., protobuf, SSZ) for messages between the AVS node and EigenLayer middleware.

Middleware Maintainers, AVS Developers

Verify that serialization libraries are updated. Test message parsing against the new format to prevent node crashes or attestation failures.

Slashing Condition Reporting

New or modified fields in the data structure used to report slashable offenses to the core protocol.

AVS Developers, Operators, Risk Teams

Ensure slashing logic correctly populates new fields. Operators must understand how new reporting data affects their attributable security profile.

Operator Registration Flow

Changes to the handshake or authentication sequence when an operator node connects to an AVS.

Operator Client Developers, Node Operators

Update node client connection logic. Test registration against AVS testnets to confirm compatibility and avoid operator downtime.

Reward Claim Interface

Modification to the API for submitting reward proofs or claiming accumulated fees.

AVS Developers, LRT Protocols, DeFi Integrators

Audit reward claim logic for compatibility. Downstream protocols must update their integration to correctly parse new reward claim events.

Event Emission Schema

Breaking changes to the structure or indexing of on-chain events emitted by the AVS node interface.

Data Teams, Wallets, Explorers

Update subgraph and indexer logic to parse new event schemas. Wallets must adjust transaction decoding to display accurate user-facing information.

Health Check Endpoint

Changes to the required health check endpoint or its expected response format.

Node Operators, Monitoring Tool Developers

Update monitoring dashboards and alerting rules to query the new health endpoint. Failure to do so will result in false-positive downtime alerts.

Version Negotiation Protocol

Introduction or modification of a protocol for nodes to negotiate a compatible interface version.

Operator Client Maintainers, AVS Developers

Implement the version negotiation handshake. Verify behavior against canonical test vectors to ensure nodes can connect to AVSs running different versions.

INTERFACE SPECIFICATION READINESS

AVS Developer Compliance Checklist

A practical checklist for AVS development teams to verify compliance with the canonical AVS Node Interface Specification before deploying to testnet or mainnet. Each item maps to a specific interface requirement and identifies the signal that confirms readiness.

What to check: Verify that the AVS implements the required createAVSDesignation and updateAVSMetadataURI functions exactly as specified in the interface, including correct parameter types and return values.

Why it matters: These functions are the primary handshake between the AVS contract and EigenLayer core middleware. Non-compliant implementations will fail to register or update, preventing operator discovery and assignment.

Readiness signal: Successful local fork test showing the AVS contract address appears in the core protocol's AVS registry after calling createAVSDesignation, with metadata URI correctly retrievable.

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

EVM ecosystems

  • Ethereum logo
    Ethereum
  • Arbitrum logo
    Arbitrum
  • Optimism logo
    Optimism
  • Polygon logo
    Polygon
  • Avalanche logo
    Avalanche
  • Cronos logo
    Cronos

Non-EVM ecosystems

  • Solana logo
    Solana
  • Sui logo
    Sui
  • Aptos logo
    Aptos
  • Hedera logo
    Hedera
  • Stellar logo
    Stellar
  • NEAR logo
    NEAR

Additional ecosystems

  • Polkadot logo
    Polkadot
  • Cosmos logo
    Cosmos
  • TON logo
    TON
  • Cardano logo
    Cardano
  • Algorand logo
    Algorand
  • Tempo logo
    Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

AVS NODE INTERFACE COMPLIANCE

Frequently Asked Questions

Common questions from AVS developers and operators about implementing, verifying, and maintaining compatibility with the AVS Node Interface Specification.

Conformance verification requires a multi-layered approach:

  • Interface compliance: Confirm your implementation exposes all required methods with exact function signatures, parameter types, and return values defined in the canonical specification. Missing or incorrectly typed methods will cause middleware integration failures.
  • Event emission: Verify that all mandatory events are emitted at the correct lifecycle points (registration, deregistration, task completion, slashing). Missing events break off-chain indexing and operator monitoring.
  • State transition correctness: Test that your AVS contract transitions through states exactly as specified—particularly around registration, opt-in, and slashing flows. Incorrect state transitions can lead to stuck funds or failed slashing enforcement.
  • Test suite execution: Run the official EigenLayer middleware compatibility test suite against a local or testnet deployment. Passing all tests is the strongest signal of conformance.
  • Canonical source check: Always verify against the versioned specification in the ELIP registry, not against third-party documentation or example code that may be outdated.

Chainscore can perform a structured interface compliance review, including differential analysis between your implementation and the canonical specification, and provide a remediation roadmap for any gaps identified.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.
L
Lee Erswell
CEO, Telos Foundation
how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

01

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

02

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

03

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

04

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Start a build

Need a blockchain engineering team?

Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.