Actively Validated Service (AVS)

The name changed, the object did not

EigenLayer's current developer documentation defines an Autonomous Verifiable Service as a decentralized service built on Ethereum that provides custom verification mechanisms for off-chain operations.¹ The older expansion, actively validated service, is what the term was introduced as and what the wider ecosystem still uses in blog posts, dashboards and integration docs.

The example list moved as well, which matters more than the acronym. EigenLayer's own page now gives rollup services, co-processors, cryptography services and zero-knowledge proof services as the shape of what gets built, and frames the only hard requirement as evidence of the off-chain execution being posted on-chain so the service can be verified.¹ Anyone quoting a 2024-era list of sidechains, bridges and keeper networks is quoting a page that has been rewritten underneath them.

Three parts, and two of them are not onchain

An AVS is composed of on-chain contracts for verification and an off-chain network of operators who execute the service and post evidence of that execution back to those contracts. Tasks can be initiated by contract, by direct communication with operators, or through an aggregator, and the split between off-chain execution and on-chain verification is left entirely to the developer. If operators perform properly the AVS can distribute rewards autonomously; if they perform maliciously their delegated stake can be slashed autonomously and the operator can be removed from the operator set.¹

The reason a founder builds this way is bootstrapping. Consensys frames EigenLayer as a marketplace between restakers seeking additional yield and services seeking cryptoeconomic security, with pooled security letting one balance of restaked ETH back many services at once.⁴ Standing up an independent validator set means acquiring capital that has better-paying alternatives. Pooled security lets a new service rent what it would otherwise have to buy.

Each service writes its own slashing rules, and they need not be provable

EigenLayer states that its slashing function is maximally flexible: services may slash any operator with stake delegated within their operator sets, and may design their protocols to slash for any reason. It says directly that slashing does not have to be objectively attributable, meaning provable onchain, while encouraging services to publish clear process around how their conditions work.²

Operators carry the diligence burden for that. The protocol tells them they are responsible for fully understanding the slashing conditions and risks of an AVS before opting into an operator set and allocating stake, because once allocated those funds may be slashable under whatever conditions the service set.³ Stakers who delegated to that operator inherit the outcome without having read anything.

In our view this is the single most important sentence for anyone building on top: the AVS slashing condition is the product's actual risk document, and it is written by a third party the depositor never contracted with.

Redistribution changed who benefits from a slash

Slashed funds were originally burned. Under redistributable operator sets, introduced by ELIP-006, they can instead be transferred to a redistribution recipient the AVS specifies when the set is created, a role the AVS controls and cannot change afterwards.³ A seven day resolution delay sits between the slash and the transfer, and natively restaked ETH is excluded from redistribution entirely, staying locked in the EigenPod contract instead.²

EigenLayer names the consequence itself: there is a larger incentive to slash when redistribution is enabled, and redistributable sets may offer higher rewards which should be weighed against the increased risk.³ A penalty that pays somebody is a different instrument from a penalty that burns. Any depositor-facing product built on redistributable sets now has a counterparty who profits from the depositor being penalised, and that belongs in the disclosure rather than in a governance forum thread.

This page is reference material for design work. It is not investment advice and not a recommendation about any protocol or asset.