What Are AVSs? EigenLayer's Actively Validated Services Explained

An AVS, or actively validated service, is any protocol or piece of infrastructure — like an oracle network, a bridge, or a data availability layer — that uses EigenLayer's restaking mechanism to borrow economic security from already-staked ETH, rather than bootstrapping its own separate validator set and token from scratch. AVSs are the demand side of the restaking model: they're the services that actually consume the security restakers opt in to provide.

Why AVSs need borrowed security in the first place

Building a new decentralized network — say, a new oracle system or a new bridge — traditionally requires attracting a large, independent set of validators or node operators willing to stake real capital to secure it, which is slow, expensive, and hard to bootstrap from zero, especially for a new project with no established token or reputation.

EigenLayer's insight was that a huge amount of security already exists in the form of staked ETH securing Ethereum itself, and if some of that value could be reused ("restaked") to also back a new service's correctness, that new service wouldn't need to build an entirely separate security base — it could effectively rent Ethereum-scale economic security from day one.

How an AVS actually gets secured

Node operators who've opted into EigenLayer's restaking, using either natively restaked ETH or liquid restaking tokens, choose to also opt into securing one or more specific AVSs. In doing so, they agree to the AVS's specific rules — typically running additional software, performing specific validation duties for that service, and accepting the AVS's own slashing conditions, which are separate from and in addition to Ethereum's base staking slashing conditions.

If a restaker misbehaves according to the AVS's rules — for example, signing off on an incorrect oracle price, or failing to perform required duties — a portion of their restaked value can be slashed, specifically as a penalty tied to that AVS, independent of their base ETH staking status.

Types of AVSs

AVSs span a wide range of infrastructure needs:

• Oracle networks that need economically secured, correct price reporting.
• Data availability layers that need guarantees data was actually published and is retrievable.
• Bridges and interoperability layers, which historically have been frequent targets of major exploits and could benefit from stronger, more expensive-to-attack economic security, discussed generally in our crypto bridges explainer.
• New rollups or specialized chains that want to bootstrap security quickly rather than building their own validator set from nothing.

AVS risk compared to standard staking

Aspect	Standard ETH staking	Restaking to secure an AVS
Slashing conditions	Well-established, narrowly defined (double-signing, downtime)	AVS-specific, potentially less mature or well-tested
Number of risk sources	One (the base protocol)	Multiple, one per AVS opted into
Track record	Years of live, battle-tested history	Newer, shorter track record per AVS
Reward	Base staking yield	Base yield plus AVS-specific rewards

Why not all AVSs carry the same risk

Because operators can choose which specific AVSs to secure, and different AVSs have very different slashing conditions, maturity, and audit history, restaking risk isn't a single uniform number — it depends entirely on which AVSs a given restaker (or the liquid restaking protocol managing their position) has opted into. A restaking position concentrated in one or two newer, less-vetted AVSs carries meaningfully more risk than one diversified across several established, well-audited AVSs with a longer track record.

Operator sets and delegation

Most individual restakers don't select AVSs directly. Instead, they delegate their restaked position to an operator — a node runner who chooses which AVSs to secure on the delegator's behalf, in exchange for a cut of the AVS rewards earned. This adds a further layer of trust: the operator's own competence and honesty (running the required software correctly, staying online, avoiding slashable behavior) sits between the restaker's capital and the AVSs it ultimately secures. Choosing a well-established operator with a strong uptime record and transparent AVS selection is as important as understanding the underlying AVS risk itself, since operator error can trigger slashing even if every AVS involved is sound.

What this means for restakers

Anyone restaking, directly or through a liquid restaking token, should understand which specific AVSs their position is exposed to, since that's where the actual incremental risk — beyond base ETH staking — comes from. This is worth checking before assuming a liquid restaking token's advertised extra yield is simply "free" upside on top of normal staking, a point covered more generally in our liquid restaking vs liquid staking comparison.

Bottom line

AVSs are the services that consume EigenLayer's restaked security, letting new infrastructure bootstrap economic security by borrowing it from already-staked ETH rather than starting from scratch. This is a genuinely useful solution to a real bootstrapping problem, but it introduces AVS-specific slashing risk on top of base staking risk, and that risk varies significantly depending on which specific AVSs a restaker's capital ends up securing.