Actively Validated Service (AVS)

What Is an Actively Validated Service?

An Actively Validated Service (AVS) is a system that needs distributed validation to function but does not run its own layer-1 blockchain. Examples include oracle networks that deliver off-chain price data, bridges that relay messages between chains, data availability layers that store rollup transaction data, and sequencers that order transactions for rollups. Each of these services requires a set of operators performing work and a mechanism to punish misbehavior.

The term was coined by EigenLayer, the first major restaking protocol on Ethereum. In 2025, EigenLayer rebranded AVSs as "Autonomous Verifiable Services," though the original name remains widely used across the industry and the underlying mechanics are unchanged.

Before restaking, every new service that needed decentralized validation had to bootstrap its own validator set from zero. This meant issuing a new token, attracting stakers, and hoping enough economic value accumulated to make attacks expensive. During the early phase, security was thin and the service was vulnerable. AVSs solve this cold-start problem by borrowing security from Ethereum's existing validator base, which already secures hundreds of billions of dollars in value.

How It Works

The AVS model relies on restaking: the practice of reusing staked ETH (or liquid staking tokens) as collateral for additional services beyond Ethereum consensus. The lifecycle involves three parties: stakers, operators, and the AVS itself.

1. Stakers deposit ETH into EigenLayer through an EigenPod (for beacon chain ETH) or via the StrategyManager (for liquid staking tokens like stETH or rETH). This restaked ETH remains securing Ethereum but is also made available as collateral for AVSs.
2. Operators register on EigenLayer and receive delegated stake from stakers through a double-opt-in process managed by the DelegationManager contract. An operator can receive delegations from many stakers.
3. Each AVS deploys a ServiceManager smart contract that defines its validation tasks and slashing conditions. Operators choose which AVSs to serve by joining AVS-defined Operator Sets, explicitly opting their stake into the slashing rules of each service.
4. Operators perform the AVS's required work: attesting to data availability, relaying cross-chain messages, providing oracle price feeds, or whatever the service requires. Their restaked ETH backs their honest behavior.
5. If an operator violates the AVS's slashing conditions, the AVS can submit a slashing proof to EigenLayer's core contracts. Slashed funds are burned or redistributed depending on the protocol's configuration.

Unique Stake Allocation

A key design feature is Unique Stake Allocation, which allows operators to designate specific portions of their stake as slashable by only one AVS at a time. This isolates risk: a slashing event on one AVS does not automatically reduce the security available to others. An operator with 100 ETH restaked might allocate 30 ETH to an oracle AVS, 30 ETH to a data availability AVS, and keep 40 ETH unallocated.

Slashing Mechanics

EigenLayer launched slashing on mainnet in April 2025. Each AVS defines its own conditions for what constitutes a slashable offense. For a data availability AVS, failing to store and serve requested data might trigger slashing. For an oracle AVS, submitting a price that deviates significantly from the consensus value would be punishable.

The slashing process is objective: it relies on on-chain proofs rather than subjective governance votes. This is critical because the security model depends on the certainty that misbehavior will be punished. If slashing is discretionary, the economic guarantees weaken.

Contract Architecture

The core EigenLayer contracts that enable AVSs include:

// Core EigenLayer contract interfaces

// Handles native ETH restaking via beacon chain
EigenPodManager → EigenPod (one per staker)

// Handles LST deposits (stETH, rETH, etc.)
StrategyManager → Strategy (one per asset type)

// Manages staker-to-operator delegation
DelegationManager (double opt-in: staker + operator)

// AVS-specific: defines tasks, slashing, rewards
ServiceManager (deployed per AVS)
  → registers operators into Operator Sets
  → defines slashable offenses
  → distributes rewards via RewardsCoordinator

Examples of Live AVSs

As of mid-2026, approximately 40 AVSs are live on EigenLayer's mainnet, with over 190 partners in the broader ecosystem. The most notable include:

EigenDA

EigenDA was the first AVS to launch and serves as a data availability layer for rollups. Instead of posting full transaction data to Ethereum (which is expensive), rollups can store data with EigenDA operators who are backed by restaked ETH. EigenDA targets throughput of 100 MB/s, far exceeding the capacity of Ethereum's native blob transactions.

Omni Network

Omni Network provides cross-chain messaging between Ethereum rollups. As different rollups fragment Ethereum's liquidity and user base, Omni allows applications on one rollup to communicate with contracts on another. Omni operators validate cross-rollup messages, and their restaked ETH ensures honest relay.

Hyperlane

Hyperlane is a permissionless interoperability protocol that allows developers to deploy cross-chain messaging to any blockchain without requiring governance approval. As an AVS, Hyperlane operators validate message integrity across chains, with slashing as the enforcement mechanism for dishonest relaying.

Other Notable AVSs

• Lagrange: provides ZK-based cross-chain state proofs, enabling trustless verification of state on one chain from another
• Eoracle: a decentralized oracle network that delivers real-time data streams, secured by restaked ETH rather than a proprietary token
• Brevis: a ZK coprocessor that combines zero-knowledge proofs with cryptoeconomic security for verifiable off-chain computation
• Witness Chain: coordinates decentralized physical infrastructure networks (DePIN) using Proof of Location and Proof of Diligence mechanisms

Why It Matters

The AVS model addresses a fundamental problem in crypto infrastructure: the cost of security. Before restaking, every new decentralized service needed to convince enough token holders to stake enough value to make attacks uneconomical. This created a chicken-and-egg problem: services needed security to attract users, but needed users to attract enough stake.

By pooling Ethereum's existing economic security, AVSs can launch with meaningful protection from day one. As of mid-2026, approximately 4.36 million ETH (around $18 billion) is restaked through EigenLayer across roughly 1,900 active operators, giving new AVSs access to a deep pool of economic security without issuing a single token.

This approach parallels how Bitcoin layer-2 networks borrow security from Bitcoin's proof-of-work chain rather than establishing independent consensus. The principle is the same: reuse existing security rather than fragmenting it across hundreds of independent networks. For Bitcoin-native infrastructure like Spark, the design philosophy of inheriting security from the base layer resonates directly, even though the specific mechanisms (restaking vs. anchoring to Bitcoin) differ.

Risks and Considerations

Compounding Slashing Risk

When operators serve multiple AVSs simultaneously, their stake is exposed to slashing conditions from each one. Even if each AVS individually has a low probability of triggering a slash, the combined probability grows. An operator restaked across five AVSs, each with a 1% chance of slashing, faces roughly a 5% compound risk. Unique Stake Allocation mitigates this by isolating collateral per AVS, but not all operators use it, and the total available security per AVS decreases as allocation is split.

Operator Concentration

In practice, a small number of large operators attract the majority of delegated stake. This concentration creates systemic risk: if a dominant operator suffers a slashing event or goes offline, a disproportionate share of AVS security is affected simultaneously. The same concern applies to proof-of-stake networks generally, but restaking amplifies it because the same operator may secure dozens of AVSs at once.

Slashing Condition Design

Each AVS defines its own slashing rules, and poorly designed conditions create serious problems. Conditions that are too aggressive may punish honest operators for benign failures (network latency, temporary downtime). Conditions that are too lenient provide insufficient deterrent. Ambiguous conditions create uncertainty that discourages operator participation.

Worse, a flawed slashing contract could be exploited: an attacker might manipulate inputs to trigger false slashing of honest operators, stealing or destroying their stake. Because slashing is enforced at the smart contract level, bugs in slashing logic can have irreversible financial consequences.

Cascading Failures

Because many AVSs share the same pool of restaked ETH, a major slashing event on one AVS can cascade. If a large operator is slashed, their reduced stake weakens security across every other AVS they serve. Additionally, liquid restaking tokens (LRTs), which represent restaked positions, are often used as collateral in DeFi protocols. A significant slashing event could cause LRT depegs, triggering liquidation cascades in lending markets that accept these tokens as collateral.

Smart Contract Layering

The AVS stack involves multiple layers of smart contracts: the base staking contract, the restaking protocol, any liquid staking or liquid restaking wrappers, the AVS ServiceManager, and potentially bridges or DeFi integrations on top. Each layer adds attack surface. A vulnerability in any single layer can compromise the entire stack, and formal verification of the combined system is significantly harder than verifying each component individually.

AVS vs. Traditional Validator Sets

The following comparison highlights the tradeoffs between launching a service with its own validator set versus using the AVS model:

Related Concepts

• Liquid restaking: tokenized representations of restaked positions, enabling DeFi composability with AVS-secured collateral
• Liquid staking: the predecessor concept where staked ETH is tokenized, forming the foundation that restaking builds upon
• Data availability: one of the most common AVS use cases, ensuring rollup transaction data remains accessible
• Oracle networks: decentralized data feeds that can operate as AVSs rather than maintaining independent validator sets
• Cross-chain bridges: another natural AVS use case, where restaked security replaces bridge-specific validator sets

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.