Eigenlayer
Eigenlayer operators join AVS operator sets under service-specific admission rules
Updated on
Eigenlayer operators run AVS software and join operator sets under service-specific admission rules. An AVS, or Autonomous Verifiable Service, uses these sets to organize operators and their economic commitments. Registration with the base protocol establishes an operator account; each service separately controls admission. Delegated stake supports a set through allocations from the strategies the set includes.
An operator may manage several sets with different tasks, software requirements, and collateral policies. The protocol keeps registration, delegation, and allocation separate, so each set's configuration determines how those parts combine into an enforceable commitment.
A recorded stake allocation supplies slashable backing only when its strategy and the operator's registration state meet the set's conditions.
Operator sets specify responsibilities and eligible strategies
An AVS identifies each operator set using its own address and a set identifier. That pair distinguishes sets even when different services reuse the same identifier. Each set groups operators for particular responsibilities and lists the strategies it includes. Strategies provide asset-specific accounting for the backing stake. Joining one set does not grant membership in the AVS's other sets, even when the same operator runs software for the wider service.
What registration does an operator need before joining an AVS?
An operator must register its account in DelegationManager before registering for an AVS operator set. The account must have no existing delegation before calling registerAsOperator. The function establishes operator status and self-delegation. Base registration does not enroll the address in individual services. Earlier AVSDirectory integrations recorded service-level membership, a legacy registration model. That record does not establish membership in an AllocationManager operator set.
Registration also initializes the operator's allocation delay, measured in blocks. Allocation increases take effect after that configured delay. The initial delay setting becomes effective during base registration, while later changes follow a separate configuration delay. A recorded increase may therefore remain pending when a registrar evaluates admission. An AVS requiring active backing can distinguish that pending commitment from an allocation already in effect.
AllocationManager handles set registration through registerForOperatorSets. The caller names the AVS, the target set identifiers, and any data its registrar requires. Each set must exist, and the operator must satisfy the protocol's membership checks. The AVS registrar then applies the service's admission logic within the registration call. A failed registration leaves allocations from earlier successful transactions in place.
If the registrar rejects admission, the registration transaction reverts. Publishing operator metadata or running the software does not override that decision.
PermissionController lets operators authorize other accounts to perform supported contract actions. Appointees receive permission for specified functions on specified contracts, while administrators can manage permissions and call all integrated functions. Once an explicit administrator is accepted, the operator address must also be listed as an admin to retain admin authority. An appointment can separate routine set management from the account holding operator identity. Those permissions govern on-chain actions; they do not establish hardware readiness or service-specific signing-key compatibility. An AVS can require additional admission data through its registrar, so its software and contract requirements still govern participation.
Delegation supplies stake, while allocation assigns exposure
Delegation credits an operator with stakers' shares in each strategy, and allocation assigns part of that backing to a particular set. The allocated quantity is a magnitude, a proportional accounting value rather than a token payment. Its fraction of the operator's maximum magnitude determines the allocation's proportion of that strategy's delegated backing. DelegationManager tracks the shares; AllocationManager tracks the commitments against them. Stakers retain their withdrawal rights, while operators control allocations to service commitments. This arrangement lets an operator distribute backing across several accepted services without treating every delegated share as committed to every service.
For a given strategy, total allocated magnitude cannot exceed the operator's maximum magnitude. Unique stake allocation prevents overlapping set claims on the same allocated portion. Slashing reduces the relevant allocation and maximum magnitude under the protocol's accounting. Delegated balances can also change as stakers deposit or withdraw. A fixed allocation proportion therefore does not promise a fixed token amount forever. Pending increases reserve magnitude before they become active, and delayed deallocations keep magnitude encumbered until they take effect.
Service penalties require eligible, active backing and a slashable registration state. Task-specific slashing conditions determine which conduct exposes that backing to a penalty.
Can an allocation back a set that excludes its strategy?
A set cannot slash an allocation from a strategy outside its included strategy list. The core modifyAllocations call can record such an allocation, however. Strategy compatibility and registrar acceptance therefore remain separate from recording a magnitude. If the AVS later adds the strategy, an existing active allocation can become slashable when the operator also has a slashable registration state.
In this hypothetical example, a base-registered operator has delegated stake and an active allocation to the selected set from a strategy it excludes. Its software meets the service's requirements. The set includes a different strategy, and its registrar requires active backing from an included strategy before admission.
The operator compares the set's included strategies with the strategy supporting its existing allocation. The recorded commitment contributes no qualifying stake to this set. Compatible AVS software does not change the collateral mismatch.
The operator stops before submitting set registration because this registrar's stake requirement remains unmet. Admission requires an active allocation from a strategy the set includes, together with registrar acceptance. Relaxing the registrar's admission rule alone would not make the excluded strategy slashable by the set.
How do service requirements shape operator work and pay?
An AVS defines operator duties and reward conditions for its sets. Tasks can involve computation, proof verification, or signature aggregation, depending on the service. Its software determines the required resources and signing arrangements. Operator-directed rewards can reflect performance or other service criteria. Rewards based on unique stake use allocated backing as a distribution input. Each reward mechanism applies its own registration and strategy eligibility rules over the reward period. Set membership alone creates no fixed payout or protocol-wide income rate.
Deregistration preserves a separate allocation state
Deregistering from an operator set does not automatically deallocate its stake. Membership ends, while the protocol retains the allocation record. An operator can remain slashable during the post-deregistration window the DEALLOCATION_DELAY parameter defines. That window restricts immediate re-entry into the same set. A successful removal therefore does not mean the operator has freed the allocated magnitude for another commitment.
Deallocation changes the assigned magnitude through modifyAllocations. A reduction to currently slashable backing follows the protocol's deallocation delay. A reduction to backing already outside the slashable conditions can take effect immediately. Removing a strategy after an operator queues a delayed deallocation does not accelerate that pending change. Membership and allocation records can therefore show different stages of departure, depending on when each change takes effect. These states concern set commitments, while staker withdrawals follow their own completion rules.
Re-registration requires the previous slashable registration window to expire and the registrar to accept the operator again. Eligible, active allocations left in place can become slashable again without a new increase when the operator calls registerForOperatorSets.
What to know about Eigenlayer operators
Do Eigenlayer operators need to run an Ethereum validator?
Operating an AVS does not inherently require running an Ethereum validator. An operator can receive delegated stake from restakers who handle Ethereum validation separately. The selected AVS determines its own node duties and infrastructure requirements. Operator registration and participation concern service work, while Ethereum validation concerns the production and verification of Ethereum blocks.
Must an operator supply its own stake before base registration?
Base operator registration does not require an operator-funded deposit. The registration function establishes operator status and self-delegation, including any existing deposited shares. Service admission can impose a stake requirement, and delegated stake can supply backing through eligible strategies. A service requiring allocated collateral may therefore refuse an otherwise registered account.
How can an operator approve new delegations selectively?
An operator can configure a delegation approver to authorize incoming delegations. With a nonzero approver address, a new delegator must provide a valid approval signature. The signature carries an expiry and uses a salt the protocol prevents from being reused. This approval controls incoming stake; it does not replace an AVS registrar's separate admission requirements.
Can an operator account later delegate its deposits to another operator?
A registered operator remains self-delegated and cannot undelegate its operator account. Its own deposits therefore do not move to another operator through ordinary delegation changes. The account can still withdraw deposited assets under the applicable withdrawal rules. Leaving an AVS operator set changes service participation and does not reverse base operator registration.
Does updating operator metadata change contract permissions?
Updating operator metadata does not grant contract authority or change set membership. The update emits a metadata event, while PermissionController manages authority for integrated functions. Naming an appointee in a public description does not give that account permission to call those functions.
Who can remove an operator from an AVS operator set?
The operator or the AVS can initiate deregistration, including through an appropriately authorized account. The target set must exist, and the operator must currently belong to it. The protocol's registration-and-deregistration pause must permit the call. Authority for an unrelated AVS does not authorize removal from the selected service's set.
Can an operator join several sets of the same AVS in one call?
The registerForOperatorSets call accepts multiple set identifiers for the same AVS. The listed sets must satisfy the protocol's checks, and the registrar must accept the registration. A reverting registrar call causes the transaction to fail as a whole. This batching capability does not enroll the operator in sets belonging to unrelated services.
What prevents an operator from changing the same allocation again immediately?
An unfinished pending modification blocks another update to the same operator, strategy, and set combination. The contract reports ModificationAlreadyPending while the effective allocation still contains that pending change. The restriction applies to the individual allocation entry. Once it ends, available magnitude and other protocol checks still govern further modifications.