Interoperability & cross-chain

actively validated service (AVS)

An actively validated service is any system that needs its own pool of validators doing real work and putting capital at risk to be honest — and that, in the restaking model, borrows those validators from a base layer instead of recruiting its own. The term comes from EigenLayer: an AVS is a module (an oracle network, a bridge, a data-availability layer, a fast-finality layer, a sequencing service) secured by operators who have restaked ETH and agreed to its slashing rules.

The point of the AVS concept is to separate 'what security a service needs' from 'where that security comes from'. Historically, building anything that required Byzantine-fault-tolerant validation meant launching a new chain or token and convincing validators to stake it — an enormous cold-start barrier. With AVSs, a builder defines the service's tasks and its slashing conditions (the provable misbehaviors that should burn stake), registers it on the restaking layer, and rents security from operators who are already capitalized. Operators run the AVS's off-chain software, perform its duties, and earn fees for doing so honestly.

This turns security into a shared, rentable commodity and dramatically lowers the barrier to launching trust-dependent infrastructure. The flip side is the same as restaking's: each AVS adds its own slashing surface to the shared stake, AVSs vary wildly in how well-designed and audited their slashing logic is, and a poorly-built AVS can endanger capital that secures many other things. The honest framing is that AVSs make decentralized trust cheap to summon, but the soundness of any given AVS is only as good as its own task and slashing design.

Not every AVS is equally safe just because it rides on restaked ETH. The shared stake is real, but an AVS whose slashing conditions are weak, unaudited, or non-objective can fail to actually punish misbehavior — security is only as strong as the service's own design.

Also called
AVS