The AVS Registration and Deregistration Standard defines the on-chain lifecycle of an Actively Validated Service within the EigenLayer ecosystem. It specifies the exact interface, state transitions, and event emissions required for an AVS to register with the core protocol middleware and, critically, to deregister either voluntarily or through forced ejection. This standard is the foundational contract for the operator-AVS relationship, as registration is the prerequisite for an AVS to begin receiving cryptoeconomic security from restaked assets and for operators to opt into serving it.
Protocols
AVS Registration and Deregistration Standard
Defines the canonical lifecycle for Actively Validated Services (AVSs) on EigenLayer, covering registration, voluntary deregistration, forced deregistration, state transitions, and operator notification requirements.
introduction
AVS LIFECYCLE SPECIFICATION
What is the AVS Registration and Deregistration Standard?
Canonical specification defining the state transitions and interface requirements for an Actively Validated Service (AVS) to join and leave the EigenLayer protocol.
The standard governs the entire lifecycle: from the initial registerOperatorToAVS call that binds an operator's staked delegation to a service, through the active commitment phase where slashing conditions can be enforced, to the deregistration path. Deregistration is a particularly sensitive state transition that can be initiated by the operator or forced by the AVS, triggering a withdrawal delay and unbonding period for the allocated stake. The specification must ensure that deregistration events properly notify all dependent systems, freeze the relevant security allocation, and prevent a service from unilaterally exiting with active slashable offenses without a waiting period, thereby protecting stakers from abrupt security withdrawal.
For AVS developers and node operators, this standard is the primary integration point for shared security. A non-standard registration flow can lead to operators being unable to commit stake, rewards failing to accrue, or slashing conditions being unenforceable. For risk teams and LRT protocols, the deregistration logic is a critical parameter: the unbonding duration and forced-ejection conditions directly impact liquidity models and composability in DeFi. Chainscore Labs can review an AVS's registration and deregistration implementation against this canonical specification to identify state transition errors, verify correct event emission for off-chain indexers, and model risk scenarios where a forced deregistration could cascade through dependent protocols.
AVS LIFECYCLE MANAGEMENT
Specification at a Glance
Operational impact of the AVS registration and deregistration standard on service lifecycle, operator commitments, and security allocation.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
AVS Registration | Canonical on-chain registration creates a new AVS record, enabling operator discovery and commitment. | AVS developers, governance participants | Verify registration logic matches the canonical interface and emits correct events for indexers. |
Operator Registration | Operators opt in to serving a specific AVS, creating an on-chain commitment that allocates attributable security. | Node operators, AVS developers | Review commitment logic to ensure operators cannot over-allocate stake beyond their delegated amount. |
Voluntary Deregistration | AVS or operator can initiate a graceful exit, triggering unbonding and user notification requirements. | AVS developers, operators, stakers, wallets | Validate that deregistration triggers correct unbonding flow and does not leave stale commitments on-chain. |
Forced Deregistration | Protocol-enforced removal due to slashing, inactivity, or governance action, with immediate security reallocation. | Operators, stakers, risk teams, governance | Model forced deregistration scenarios to test slashing exposure and ensure staker notification works as expected. |
State Transition Integrity | AVS and operator states must transition atomically between Active, Deregistering, and Deregistered without intermediate invalid states. | Middleware maintainers, AVS developers, auditors | Audit state machine for reentrancy, front-running, or race conditions that could leave the protocol in an inconsistent state. |
Event Emission | Standardized events for Registration, Deregistration, and state changes are critical for off-chain indexers, wallets, and explorers. | Wallet teams, data indexers, explorer services | Confirm event signatures and payloads match the canonical spec so off-chain services can track AVS and operator status correctly. |
Slashing Interaction | Deregistration must interact correctly with ongoing slashing disputes, ensuring a malicious operator cannot exit to evade penalties. | AVS developers, slashing veto committee, risk teams | Test deregistration paths against active slashing conditions to verify that stake remains frozen until disputes are resolved. |
Composability with LRTs | Liquid restaking tokens must correctly reflect the registration state of underlying operators to avoid misrepresenting slashing risk. | LRT protocols, DeFi integrators, wallets | Review LRT contract logic to ensure it queries the canonical registration contract and handles deregistration events without value leakage. |
technical-context
AVS LIFECYCLE ENFORCEMENT
State Machine and Lifecycle Transitions
Formal state model governing how an AVS moves between registered, deregistered, and forced-exit states within EigenLayer's middleware.
The AVS Registration and Deregistration Standard defines a strict state machine that governs the lifecycle of every Actively Validated Service integrated with EigenLayer. An AVS begins in an unregistered state and transitions to REGISTERED after a successful on-chain registration call, which records the service in the core protocol's middleware contracts. From this active state, an AVS can voluntarily transition to DEREGISTERED by initiating a deregistration sequence, or it can be forcibly moved to a FORCED_DEREGISTERED state by governance or slashing veto mechanisms under predefined failure conditions. Each transition carries immediate consequences for operator commitments and staked security allocation.
The operational impact of these transitions is immediate and binding. When an AVS enters a deregistered state, all operators committed to that service are notified on-chain, and the attributable security allocated to the AVS is released back to the shared pool. The standard mandates that deregistration triggers a withdrawal of operator commitments, which can cascade into reward distribution halts and unbonding queue entries for restakers. For AVS developers, the critical engineering concern is handling the FORCED_DEREGISTERED path, which can be triggered without the AVS's consent if slashing conditions are met or if the Slashing Veto Committee upholds a challenge. This path may also impose penalties on the AVS's bond or reputation score within the EigenLayer ecosystem.
Builders integrating with EigenLayer must model their off-chain services to handle asynchronous state transitions. An AVS node that continues to serve requests after an on-chain deregistration event risks operating without cryptoeconomic backing, creating a security gap that could be exploited. Chainscore Labs reviews AVS registration logic and deregistration risk scenarios to ensure that service implementations correctly synchronize with on-chain state, handle forced-exit paths gracefully, and notify operators through the required API channels. Teams preparing for mainnet should validate their state machine implementation against the canonical interface to avoid liveness failures or unintended slashing exposure.
ACTOR-SPECIFIC IMPACT ANALYSIS
Who Is Affected and How
AVS Developers
AVS developers are the primary implementers of this standard. They must ensure their on-chain contracts correctly implement the registration and deregistration interface, including proper state transitions and operator notification logic.
Key actions:
- Audit registration logic to confirm it rejects operators who do not meet the AVS's minimum stake or opt-in requirements.
- Implement deregistration flows that handle both voluntary operator exits and forced removals, ensuring slashing conditions are properly evaluated before releasing stake.
- Test operator notification mechanisms to guarantee off-chain services are reliably informed of state changes.
Failure to align with the canonical standard can lead to operators being unable to join, stuck stake, or inconsistent security assumptions. Chainscore can review your AVS contract's registration and deregistration logic against the specification to identify edge cases before deployment.
implementation-impact
LIFECYCLE MANAGEMENT
Integration and Implementation Impact
The AVS Registration and Deregistration Standard defines critical state transitions that affect operator set management, security allocation, and service continuity. Teams integrating this standard must handle registration logic, forced deregistration scenarios, and operator notification requirements correctly.
01
AVS Registration Logic Implementation
Teams must implement the canonical registration interface to allow operators to opt into serving an AVS. This includes handling stake allocation verification, commitment declaration, and on-chain state transitions. Incorrect implementation can lead to operators being unable to register or, worse, appearing registered without valid security backing. AVS developers should validate that their registration flow correctly interacts with the core protocol's operator set management and does not introduce race conditions between registration and stake updates.
02
Voluntary Deregistration and Grace Periods
Operators must be able to voluntarily deregister from an AVS, but this process typically involves a mandatory unbonding or notice period to protect service continuity. AVS developers need to implement the correct escrow and completion logic for these deregistration requests. Failure to enforce the required delay can expose the AVS to security gaps where an operator withdraws stake before completing outstanding attestation duties. Wallets and dashboards should clearly display in-progress deregistrations and remaining lock-up periods.
03
Forced Deregistration and Slashing Triggers
The standard defines conditions under which an AVS can forcibly deregister an operator, typically as a consequence of a slashing event or a failure to meet service-level requirements. Integration teams must build the dispute resolution and slashing API calls that trigger this state transition. This requires careful coordination with the Slashing API Standard (ELIP-0001) to ensure that a slashing determination correctly propagates to the operator's registration status and stake allocation.
04
Operator Notification and Event Monitoring
Every registration state transition must emit standardized on-chain events that off-chain services can consume. Operator clients, monitoring dashboards, and AVS management tools need to index these events to track which operators are currently active, pending deregistration, or forcibly removed. Builders should implement robust event listeners that handle reorgs and chain reorganizations to avoid displaying stale or incorrect operator status, which could lead to misallocated security assumptions.
05
Multi-AVS Commitment Management
Operators often serve multiple AVSs simultaneously. The registration standard must be integrated with the Operator Set Architecture (ELIP-0002) to correctly track an operator's total commitments and remaining stake capacity. When an operator deregisters from one AVS, their freed stake may become available for other services. Integration logic must prevent double-counting of stake and ensure that deregistration from one AVS does not inadvertently affect the operator's standing with other services.
06
Chainscore Registration and Deregistration Review
Chainscore Labs can review your AVS registration and deregistration implementation for correctness against the canonical standard. Our assessment covers state transition logic, operator notification handling, forced deregistration scenarios, and integration compatibility with the broader EigenLayer middleware stack. We help AVS developers, operators, and wallet teams ensure that lifecycle management code is secure, spec-compliant, and ready for production.
AVS LIFECYCLE STATE TRANSITIONS
Risk and Compatibility Matrix
Operational and integration risks introduced by the canonical AVS registration and deregistration standard, including state transition triggers, operator notification requirements, and forced deregistration scenarios.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Voluntary Deregistration | AVS can initiate its own deregistration, triggering a state change that must be consumed by all integrated contracts. | AVS developers, operator clients, middleware maintainers | Verify that operator clients correctly handle the deregistration event by ceasing work and updating internal state to prevent slashing on a defunct service. |
Forced Deregistration | A governance or veto committee can forcibly deregister an AVS, potentially without prior notice to operators. | Operators, stakers, slashing veto committee | Implement monitoring on the deregistration event to trigger immediate, automated withdrawal of operator commitments and alert stakers of a change in attributable security. |
Operator Notification | The standard defines a specific notification interface that must be called on operator contracts during registration state changes. | AVS developers, operator client teams | Ensure the AVS contract correctly calls the operator notification hook during both registration and deregistration. Failure to do so may leave operators unaware of their service status. |
State Transition Ordering | The sequence of state transitions (e.g., Active -> Deregistered) is canonical and must be respected by all middleware. | Middleware maintainers, AVS developers | Audit state machine logic to prevent re-registration of a deregistered AVS without going through the correct re-initialization path, which could corrupt operator set data. |
Slashing During Deregistration | Unclear specification for slashing conditions on offenses committed before but proven after a deregistration event. | Risk teams, AVS developers, operators | Model the risk of post-deregistration slashing. If the standard is ambiguous, implement a dispute resolution window that survives deregistration to finalize any pending attributable security events. |
Indexer and Explorer Impact | Off-chain indexers and block explorers must correctly interpret on-chain AVS lifecycle states to display accurate service status. | Data teams, wallet teams, explorer developers | Update indexing logic to track the full lifecycle state machine. An AVS marked as 'Deregistered' must not appear as an active service in any user-facing interface. |
LRT and DeFi Composability | A forced deregistration of an AVS can instantly change the risk profile and yield source for LRTs and DeFi protocols using that service. | LRT protocols, DeFi integrators, risk managers | Build circuit breakers that pause deposits or rebalance assets upon receiving a deregistration event from a constituent AVS to protect users from stranded or concentrated risk. |
AVS REGISTRATION AND DEREGISTRATION STANDARD
Operator Readiness Checklist
Operators integrating with the AVS Registration and Deregistration Standard must validate their node configuration, monitoring, and operational procedures against the canonical state transitions. This checklist helps operators confirm readiness to handle registration, voluntary deregistration, and forced deregistration events correctly.
Confirm that your operator client constructs registration transactions that conform to the canonical AVS Registration interface. This includes correct encoding of operator identity, commitment parameters, and any AVS-specific metadata required by the standard.
- What to check: Transaction payload structure, signature format, and gas parameters.
- Why it matters: Malformed registration transactions will fail on-chain, preventing your operator from serving the AVS and potentially causing missed rewards or slashing exposure if you are expected to be active.
- Readiness signal: Successful registration transaction on testnet that emits the expected
OperatorRegisteredevent with correct parameters.
resource-links
EIGENLAYER STANDARD SOURCES
Source Resources and Canonical References
Use these sources to validate the current AVS registration and deregistration lifecycle, contract interfaces, middleware assumptions, and operator-facing workflows. Teams should pin versions and confirm status against canonical EigenLayer repositories before implementing production logic.
04
Standard Text, ELIP Status, and Version Control
Treat the canonical specification text and its proposal status as separate from implementation code. Before adopting the AVS registration and deregistration standard, record whether the relevant standard is draft, accepted, superseded, or implemented in deployed contracts. Operators and AVS teams should also track incompatible revisions, required migration windows, and whether older registration flows remain supported. If a proposal registry or final specification is referenced by governance, verify the current status directly against that source before changing production systems.
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
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
AVS LIFECYCLE FAQ
Frequently Asked Questions
Common questions about the AVS Registration and Deregistration Standard, covering state transitions, operator notification requirements, and integration considerations for AVS developers and operators.
The standard defines a canonical state machine for every AVS. The core states are:
- Registered: The AVS contract is recognized by the core protocol and operators can begin opting in.
- Active: The AVS is fully operational, accepting operator commitments, and subject to slashing conditions.
- Deregistered (Voluntary): The AVS developer initiates a graceful shutdown, triggering operator notification and unbonding workflows.
- Deregistered (Forced): Governance or a slashing veto mechanism forcibly removes the AVS, typically due to a critical failure, malicious behavior, or a security council decision.
Each transition must emit a standardized event so that off-chain indexers, wallets, and operator clients can react programmatically. Teams should verify the exact event signatures and parameter encoding against the canonical ELIP specification.
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
“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.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
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.