Eigenlayer operators run AVS software and commit delegated stake to service obligations
Eigenlayer operators run AVS software and allocate delegated stake to service commitments through operator sets. Choosing an operator means comparing the AVSs it serves, the relevant operator sets, and effective allocations for your deposited assets. A large delegation balance does not show how much collateral backs each service. Admission requirements, reward splits, and allocation changes also affect the choice. The operator address connects these commitments to your delegation, so its active configuration matters.
Selecting an Operator for an AVS Commitment
Operator selection starts with the strategy you will delegate and the AVS commitment you want that stake to support. Compare operators serving fewer AVSs with those serving more using each candidate's effective allocation to the relevant set. Broader participation can add reward opportunities and software obligations. Service count alone cannot establish the collateral backing this particular commitment.
- Match the deposited asset's strategy to the strategies the operator set accepts.
- Confirm the operator's membership and effective allocation for that set.
- Separate active allocations from pending changes, including their effect blocks.
- Read the set's task requirements and slashing conditions alongside relevant operator performance.
- Compare the applicable reward split and pending rate changes for the same reward mechanism.
For a strategy the set accepts, current membership and a nonzero effective allocation establish the live slashable commitment. A pending increase establishes a scheduled change.
Delegation, Operator Sets, and Strategies
Delegation connects a restaker's deposited balances to an operator, while operator sets organize the service work those balances can secure. An AVS, or autonomous verifiable service, groups operators into sets to perform tasks backed by restaked assets.
The Delegation Relationship
The core DelegationManager associates each staker address with one operator at a time. Delegation covers that address's deposited strategies together, without a separate operator choice for each asset. This makes the operator's wider commitments relevant even when the search began with one service. Assets in a strategy follow the chosen operator's allocations for that strategy. The operator's maximum magnitude limits the combined allocation magnitudes for that strategy. Slashing lowers this maximum, and extremely low remaining magnitudes can cause losses during delegation. A zero slashing factor for any deposited strategy blocks delegation. An external operator controls the service selection and allocations supporting those commitments.
Service Admission and Asset Strategies
An operator set belongs to an AVS and has an identifier and configured strategies, which track deposited assets within restaking accounting. An AVS can create sets for different tasks, hardware profiles, or stake requirements. Its registrar can reject an operator who fails admission conditions despite successful core registration. Membership and allocation remain distinct: an operator can register without allocating or allocate before registering.
What Does Allocated Stake Secure?
Allocated stake secures commitments for the relevant operator set and defines the collateral that set can slash under its rules.
Total Stake and Unique Stake
Total stake measures all stake delegated to an operator for the relevant strategy. Unique stake reserves each allocated portion of a strategy for slashing by one operator set. The allocation proportion and delegated balance together determine the amount backing that set. Changing the balance can change that amount while the proportion stays unchanged. A total delegation figure can include capital outside the relevant set's exclusive allocation.
A bounded allocation limits the portion a set can slash; it does not establish fair enforcement. The AVS defines fault conditions and its slashing process. Different services can impose different obligations or assess faults differently. Allocation size alone misses whether the operator can meet those duties.
Effective Allocations and Pending Changes
Allocation increases follow the operator's configured delay, while updates to that delay follow the protocol's configuration delay. A zero allocation delay can allow an increase to become effective immediately. Delegating to an operator with an already active slashable allocation exposes the corresponding strategy immediately. The waiting period does not restart for each new delegator.
How Do Operator Commissions Affect AVS Rewards?
Operator commissions determine how applicable service rewards divide between an operator and its eligible delegators. With operator-directed rewards, the AVS assigns rewards using its chosen reward allocation logic; the split sets the commission on each operator's attributed reward allocation. Eligible restakers share the remainder according to stake weights, strategy multipliers, and eligible delegation time. The commission percentage alone cannot establish a return on deposited principal.
AVS-wide rewards and operator-set rewards can use different splits. The applicable rewards mechanism determines whether the distribution uses an AVS split, a set split, or a default. Updates to operator-configured AVS and operator-set splits have an activation delay, so pending commissions can differ from active rates. A fair fee comparison uses matching reward mechanisms and effective settings. Reward token values and the service's funded reward periods also affect the economic comparison.
AVS Capacity and Control of Keys
Software and Task Requirements
AVS software creates obligations beyond registering an address or receiving stake. Hardware profiles and liveness requirements vary across operator sets. Storage duties and computation workloads place different demands on infrastructure. Performance information is useful when it identifies the task and measurement period. Software maintenance and resource isolation also matter when several clients share infrastructure. More delegated stake cannot supply missing compute capacity or correct a faulty deployment. Excessive container privileges and sensitive volume mounts can expose host resources to compromised AVS software. Resource limits, isolated workloads, and restricted network access reduce the impact. These controls address software execution risk alongside cryptoeconomic penalties.
Core Permissions and AVS Signing
Core permissions govern allocation, service registration, and commission changes, while AVS signing keys authenticate service messages under each AVS's signing requirements. User Access Management lets operators appoint addresses for particular core contract functions. Appointees can have restricted permissions; admins have broader authority. Keeping core control keys separate from AVS clients reduces exposure to software compromise. In redistributing sets, compromised registration and allocation authority can expose delegated stake to malicious commitments.
Open Delegation and Operating Your Own Address
Open delegation requires no approver signature when an operator has no delegation approver; an approval-gated operator requires valid authorization for new delegation. Both paths use the core delegation relationship; approval changes admission, while service membership and allocations determine commitments. An approval policy can make a candidate unavailable to a particular address. Approval does not establish service performance or restrict exposure to one chosen AVS.
Operating your own registered address keeps service selection and client operation under your control. External delegation assigns those responsibilities to the chosen operator. Direct operation adds software, monitoring, and key management duties, so the AVS's requirements determine whether the operating setup fits. Under either arrangement, the AVS determines admission and task rules; self-operation does not bypass them.
What Changes When an Operator Leaves an AVS?
Deregistration removes membership in the relevant operator set, while allocated stake can remain slashable during the post-deregistration window. Deregistration does not automatically deallocate the stake reserved for that set. Operators and AVSs can initiate deregistration, so participation can change through either party. Remaining allocations and the end of residual slashability matter alongside the membership record. Deallocation reduces an allocation, with a delay when the existing allocation remains slashable. A non-slashable reduction can take effect without that delay. Remaining allocations can become slashable again after valid re-registration.
Changing a restaker's operator involves a separate undelegation process, which queues deposited shares for withdrawal under the applicable delay. The core redelegation function can combine undelegation and new delegation in one call. Queued shares only back the new operator after completion as shares. They can retain exposure to the previous operator's slashable commitments during the withdrawal window. A changed operator assignment does not immediately move all existing stake.
What to know about Eigenlayer operators
Must I Own Restaked Tokens to Register as an Operator?
Core operator registration does not require owning restaked tokens or meeting a protocol-wide delegated stake minimum. Registration establishes the operator address; useful participation still follows each AVS's requirements. A service can require an allocation or enforce its own admission conditions, so permission to register does not establish eligibility for every operator set.
Can an Operator Rotate Admin Keys Without Changing Its Address?
Admin key rotation can preserve the original operator account address and its identifier. User Access Management separates account identity from the admin addresses controlling it. The operator must maintain at least one admin, and adding or removing admins changes account authority. This core permission model does not automatically rotate the signing keys individual AVS clients use.
Who Can Force a Restaker to Undelegate From an Operator?
An operator, its delegation approver, or an authorized admin or appointee can force an external restaker to undelegate. The action removes the operator assignment and queues the restaker's deposited shares for withdrawal. It does not send those assets to the operator. For an operator accepting open delegation, forced undelegation alone does not prevent the restaker from delegating back.
Are Testnet Operator Commitments Equivalent to Mainnet Commitments?
Testnet participation does not establish an operator's mainnet registration, allocations, or reward eligibility. Each environment has its own deployed contracts and compatible components. Some delay parameters also differ between testnet and mainnet. Performance during testing can inform an infrastructure assessment, while the mainnet commitment must correspond to its actual mainnet operator and service state.
Will Operator Registration Lock My Own Restaked Funds Permanently?
Operator registration makes the address permanently self-delegated in core, while allowing withdrawal of its restaked funds under the applicable process. An operator address cannot undelegate from itself to choose an external operator. Using separate restaking and operating addresses avoids coupling those roles. Withdrawal delays and any applicable slashing still affect the assets leaving the registered operator address.
Is an Operator's Display Name Its Onchain Identity?
The registered account address identifies the operator in core contract records. Display names and metadata describe that address and can change without changing the operator's commitments. A metadata update does not itself alter allocations or membership. Matching the address across delegation, set registration, and reward records prevents a familiar label from standing in for a different operator.