You have probably heard the term “AVS” tossed around in restaking conversations, and it might sound like just another piece of crypto jargon. But Actively Validated Services are actually a simple idea underneath the acronym: any system that needs validators to keep it honest can, in theory, “borrow” security from a pool of staked crypto instead of building its own validator network from scratch.
In this guide you will learn what Actively Validated Services are in plain English, how they connect to restaking, what kinds of services fit the AVS model, the risks they carry for both operators and delegators, and the questions to ask before you put any of your own stake behind one.
id=”what-are-avs”>What Are Actively Validated Services?
An Actively Validated Service, usually shortened to AVS, is any blockchain-based service that relies on a set of validators to do a job — and that gets its security from the same pool of staked capital that secures the underlying network. The word “actively” matters: unlike simply holding staked tokens passively, the validators (or operators) securing an AVS have to actually do work. They run software, submit attestations, relay data, or perform whatever task the service defines.
Think of it this way. A new blockchain network normally needs two things to be secure: its own token, and a large set of validators willing to stake that token. Bootstrapping both from zero is expensive and slow. An AVS flips the problem: instead of launching its own validator set, the service plugs into an existing one. Validators who already stake their assets on a base layer can opt in to secure the new service too, and the service gets economic security it did not have to build alone.
The core bargain is simple. Validators earn additional rewards for the extra work they take on. The service gets security. The stakers behind those validators — the delegators — get a share of the rewards in exchange for accepting additional risk, because the same stake can now be slashed by more than one protocol. Slashing, where misbehaving or offline validators lose part of their stake as a penalty, is the mechanism that keeps everyone honest, and it is also the mechanism that makes restaking and AVS participation genuinely risky. If you want the fuller picture of those risks, read our companion guide Restaking Risks Explained: 6 Dangers to Know.
How AVS Connect to Restaking
AVS and restaking are two halves of the same idea. Restaking is the mechanism: you take assets that are already staked on a base layer and “reuse” them to secure additional services. AVS is what those additional services are called. You cannot really talk about one without the other, because restaking only exists so that AVS have something to draw security from.
Here is how the flow typically works, described at a general level since the exact mechanics vary between designs:
- Staking comes first. Someone locks up crypto on a base layer (for example, ETH on Ethereum) to secure that network. This is ordinary staking.
- Opt-in to restaking. The staker or their validator chooses to make that same stake available to secure additional services. The stake is now “restaked.”
- Operators take on work. Validators become operators for one or more AVS. They run the AVS software alongside their base-layer duties, and they attest to the AVS’s operations.
- Rewards flow down. The AVS pays fees or emissions for the security it receives. Operators keep a commission, and the rest flows to the stakers whose capital backs them.
- Slashing conditions stack. This is the critical part: the same stake is now exposed to the slashing rules of the base layer and of every AVS it secures. More services means more ways to lose money.
That last point is the one most newcomers underestimate. In traditional staking, your downside is bounded by one protocol’s rules. In restaking, a bug in an AVS you have never heard of — or an operator you delegated to making an honest mistake — can cost you a portion of your stake even if the base layer never slashed you. This is why our restaking safety checklist for beginners stresses starting small and understanding every slashing condition before delegating.
It is also worth understanding that participation is optional. Nobody is forced to restake. The base-layer staking rewards exist with or without AVS, and the extra yield from securing AVS is compensation for extra risk — not free money. Anyone presenting it as risk-free is either confused or selling something.
Categories of AVS, Explained Generally
Not every service needs an AVS, but several broad categories fit the model naturally. These are general categories, not endorsements of any specific project — the field changes fast, and any list of named protocols would be outdated quickly.
Bridges and messaging layers
Cross-chain bridges need a set of parties to vouch that something happened on one chain so that another chain can act on it. That is exactly the kind of “active validation” the AVS model describes. A bridge secured by restaked capital is cheaper to bootstrap than a bridge with its own validator set, though it inherits all the risks of both systems.
Oracles and data feeds
Oracles bring off-chain or cross-chain data on chain — prices, event outcomes, randomness. They need validators to attest that the data is correct. Using restaked validators for this job can make a data feed economically secure much earlier than it could on its own.
Sequencers and ordering services
Some networks and applications need a trusted party to order transactions or produce blocks. An AVS-style operator set can provide that ordering service, with slashing punishing operators that censor or reorder unfairly.
Keeper and automation networks
DeFi protocols often need someone to perform routine on-chain actions: liquidating undercollateralized loans, executing scheduled trades, updating parameters. A decentralized network of operators performing these “keeper” tasks is a natural AVS, because correctness can be defined and bad behavior can be slashed.
Compute and verification networks
Some designs let operators perform off-chain computation — running models, verifying proofs, checking data availability — and attest to the results on chain. The AVS model fits because the work is verifiable after the fact, so validators that lie can be penalized.
What these categories share is a pattern: work that must be done, results that can be checked, and misbehavior that can be punished. If a service cannot clearly define what “correct behavior” looks like, it cannot be an AVS, because slashing requires objective rules.
AVS vs Traditional Validation
To see what is actually new here, compare the AVS model with how networks have traditionally secured themselves.
| Factor | Traditional validation | Actively Validated Services |
|---|---|---|
| Source of security | Network’s own token, staked by its own validators | Restaked capital from an existing base layer |
| Bootstrapping cost | High — needs its own token distribution and validator set | Lower — plugs into an existing validator pool |
| Validator work | One protocol’s duties | Base layer plus every AVS opted into |
| Slashing exposure | One set of rules | Stacked — each AVS adds its own slashing conditions |
| Yield | Base staking rewards only | Base rewards plus AVS fees (higher, but riskier) |
| Failure blast radius | Contained to the one network | Can cascade — one AVS failure can hit shared stake |
The trade-off is the whole story. AVS make new services cheaper to launch and potentially more secure at birth than they would be alone. But they concentrate risk: the same pile of capital now backstops many systems, so a failure in one place can ripple into others. Whether that is a good deal depends on how many AVS the stake secures, how correlated their failure modes are, and how much of a premium the extra yield actually pays.
Risks for Operators and Delegators
Operators and delegators face different versions of AVS risk, and it helps to keep them separate.
Risks for operators
Operators run infrastructure. For each AVS they secure, they run additional software, maintain uptime, and respond to the AVS’s operational demands. Every extra service is another thing that can break, misconfigure, or get exploited. An operator securing five AVS has five times the operational surface area of one securing a single chain — and downtime or errors in any of them can trigger slashing.
There is also a subtle correlation risk. If many operators run the same AVS software with the same default configuration, a single bug can slash a large fraction of the operator set at once. Diversity of clients and setups is a defense, but it is not always present in young ecosystems.
Risks for delegators
Delegators — people who stake with an operator — are one step removed from the machinery but share the downside. If your operator gets slashed by an AVS, your stake shrinks too. You chose the operator, but you did not choose the AVS bug, and you may not even know which AVS your operator secures unless you check.
Compounding this, restaking is still young. Slashing conditions for some AVS may be poorly tested, governance of AVS parameters may be centralized, and insurance or backstops may not exist. The honest summary is that delegators are paid extra yield to accept risks that are hard to fully quantify — which is fine as long as you treat the yield as risk compensation, not as a savings rate.
Questions to Ask Before Touching an AVS
If you are considering delegating to an operator that secures AVS, or running an operator yourself, these questions separate careful participants from hopeful ones:
- What exactly can slash me? Read the slashing conditions for each AVS, not just the base layer. If you cannot find them written clearly, that is itself an answer.
- How many AVS does this operator secure? More services means more stacked risk. An operator securing a dozen experimental AVS is a different bet than one securing two mature ones.
- Who governs the AVS? Centralized control over slashing parameters or upgrades means your stake depends on a small group’s decisions.
- Has the AVS code been audited, and by whom? Audits do not guarantee safety, but the absence of any audit is a red flag.
- What is the withdrawal timeline? Restaked positions often have longer unbonding periods. Make sure you know how long your capital would be locked if you change your mind.
- Am I being paid enough for this risk? Compare the extra yield against the stacked slashing exposure honestly. If the premium is thin, the base-layer staking return alone may be the saner choice.
- Can I explain this to a friend? If you cannot describe what the AVS does and how you could lose money, you are not ready to participate.
FAQs
The Bottom Line
Actively Validated Services are a clever answer to a real problem: new blockchain services need security they cannot afford to build from scratch, and restaked capital is sitting there ready to provide it. The model is elegant, but it concentrates risk — one pile of stake backstopping many systems — and it is still young enough that the failure modes are not fully mapped.
For beginners, the sensible stance is curiosity without commitment: understand what an AVS is, read the slashing conditions of anything you consider, and remember that extra yield is payment for extra risk. Start with plain staking, and only step into AVS once you can explain exactly how you could lose money.
This guide is for education only — not financial advice.
