What Are AVSs in Restaking Ecosystems? How Shared Security Becomes Programmable

AVSs (Actively Validated Services) are external systems that borrow economic security from Ethereum stakers through restaking, allowing new protocols to inherit trust without building their own validator sets.

• AVSs extend Ethereum’s security beyond consensus into data availability, bridges, oracles, and middleware.
• They rely on restaked ETH to enforce correctness through slashing conditions.
• AVSs separate security provision from application logic.
• Restaking ecosystems introduce new trust, risk, and incentive tradeoffs.
• AVSs are central to Ethereum’s emerging shared-security economy.

Understanding Restaking Before AVSs

Restaking allows Ethereum validators or liquid stakers to reuse their staked ETH to secure additional systems beyond Ethereum’s base consensus. Instead of staking ETH only to validate blocks, participants opt into additional commitments that carry extra rewards — and extra slashing risk.

This model treats Ethereum’s economic security as a shared primitive. AVSs are the systems that consume that security.

AVSs represent a shift from blockchains securing themselves to security becoming a reusable, programmable resource. Understanding AVSs is essential for evaluating restaking risk, capital efficiency, and the future structure of Ethereum’s ecosystem.

What Is an AVS?

An Actively Validated Service is any off-chain or on-chain system that relies on restaked ETH to enforce correctness, availability, or ordering guarantees.

AVSs do not produce Ethereum blocks. Instead, they define their own validation rules and rely on restakers to enforce them. If validators violate those rules, they can be penalized at the Ethereum staking layer.

In essence, AVSs externalize trust. They replace bespoke validator sets with Ethereum’s existing economic security.

Why AVSs Exist

Before AVSs, new infrastructure protocols faced a difficult choice. Either they launched as independent networks with weak security, or they embedded themselves tightly into Ethereum’s execution layer, sacrificing flexibility.

AVSs emerged to solve this tension. They allow protocols to remain modular while still inheriting strong security guarantees. This dramatically lowers the cost of launching new infrastructure and encourages experimentation.

How AVSs Work in Practice

AVSs define a set of validation tasks and corresponding slashing conditions. Restakers opt in to these tasks by signaling consent through restaking protocols such as EigenLayer.

Once opted in, validators are obligated to perform AVS-specific duties. These may include verifying data availability, validating cross-chain messages, or enforcing ordering rules. Failure to comply can result in slashing of restaked ETH.

Ethereum itself does not interpret AVS logic. It only enforces economic penalties when misbehavior is proven.

AVSs vs Layer 2 Rollups: Different Roles in Ethereum’s Modular Stack

Although AVSs and Layer 2 rollups both rely on Ethereum for security, they address fundamentally different scaling and infrastructure problems. Layer 2s focus on executing user transactions efficiently, while AVSs provide specialized services that support or enhance other blockchain systems.

AVSs and Layer 2 rollups are complementary components of Ethereum’s modular architecture rather than competing designs. In practice, many rollups are expected to rely on one or more AVSs for services such as decentralized sequencing or enhanced data availability, reinforcing Ethereum’s role as a shared security layer.

Types of AVSs Emerging Today

Although all AVSs share the same security model—relying on restaked Ethereum security—their functions vary widely. The diversity of AVSs reflects a broader trend in Ethereum’s modular architecture: security is becoming a shared primitive that can be applied to many different infrastructure layers, not just transaction execution.

One of the earliest and most intuitive categories of AVSs focuses on data availability. These AVSs ensure that off-chain or auxiliary data remains accessible and verifiable over time. While Ethereum itself provides strong data availability guarantees, publishing all data on Layer 1 can be expensive. Data availability AVSs aim to provide cheaper alternatives while still anchoring security in Ethereum’s staking layer. Their role is particularly relevant for rollups that want to reduce costs without fully trusting a centralized data provider.

Another important category includes decentralized sequencing and ordering services. Today, most Layer 2 rollups rely on centralized sequencers to order transactions. Sequencer AVSs attempt to decentralize this function by having restaked validators collectively enforce fair ordering, censorship resistance, or proposer rotation. Rather than executing transactions themselves, these AVSs define rules for how transactions should be ordered and penalize validators that violate those rules. This makes them a natural complement to rollups rather than a replacement.

Cross-chain messaging and bridge validation is another area where AVSs are emerging. Secure communication between chains has historically relied on multisigs or small validator sets, making bridges one of the weakest points in the ecosystem. AVSs can replace these bespoke trust assumptions with Ethereum-backed economic security. By using restaked ETH to validate messages or state transitions across chains, these AVSs aim to reduce the systemic risk associated with cross-chain infrastructure.

AVSs are also being explored in the context of oracle validation and middleware services. While traditional oracles rely on reputation systems or token-based incentives, an AVS-based oracle can enforce correctness through slashing. Validators are economically punished for providing incorrect data, aligning incentives more directly with security outcomes. This model is particularly attractive for high-stakes financial applications where incorrect data can have cascading effects.

Finally, some AVSs target specialized middleware functions that do not fit neatly into existing categories. These include services for MEV management, threshold cryptography, or coordination layers that support multiple rollups simultaneously. In these cases, the AVS model allows highly specialized infrastructure to exist without fragmenting security across dozens of small validator sets.

Taken together, these categories illustrate that AVSs are not a single product class but a general pattern. They represent a way of externalizing trust and reusing Ethereum’s economic security across a wide range of infrastructure services. As restaking ecosystems mature, the number and specialization of AVSs are likely to increase, further reinforcing Ethereum’s role as a shared security backbone rather than just a settlement layer.

Governance and Upgrade Risk in AVSs

AVSs often rely on governance mechanisms to upgrade validation logic or slashing rules. This introduces governance risk similar to that seen in Layer 2s.

If governance is centralized or poorly designed, AVS security guarantees weaken regardless of how much ETH is restaked. Shared security does not eliminate the need for careful governance design.

Despite their promise, AVSs raise unresolved questions. Can slashing be enforced reliably at scale? Will restakers properly price correlated risk? How much complexity can Ethereum’s security model absorb before it becomes fragile?

These questions remain open, and their answers will shape the evolution of restaking ecosystems.

The Future of AVSs

AVSs are still early. Over time, we can expect clearer standards for slashing, improved risk isolation, and greater institutional participation. Whether AVSs become foundational infrastructure or remain niche tools depends on how well these challenges are addressed.