Liveness of AVS

Imagine the following scenario:

Someone has created an AVS that requires 2/3s (by power) of validating nodes to be live. For example, a Tendermint consensus.

At first, a few individual validators opt in. Maybe there is 1000 ETH securing the AVS.

Then, a larger holder controlling many validators opts in to this AVS. They control another 3000 ETH, or 75% of the power in the AVS.

It seems to me that this large holder now has the ability to stop the AVS at will (or keep it running but censor all txs, or just censor some, etc).

Is this the case? Are any mitigations possible? As commonly acknowledged, proving liveness faults is very difficult, if not impossible.


hey @Jehan

you are correct in the sense that censorship is not slashable, if you are a service thinking that the scenario you just said have chances to happen, here is what eigenlayer let you do :

when you write the registration contract of your service within the evm, you can specify what type of stakers can opt in.
it turns out you can encourage only decentralized validators like native restakers, rocket pool restakers and even more when distributed validator technology like obol will be live.
here is the link from yesterday’s space if you want to dive deeper :

thus, it will decrease significantly the risk of collusion/attack and increase the censorship resistance of your service.

because if a majority of a decentralized group of nodes agree on the same input/state or whatever then it’s valuable.

→ eigenlayer finally allows to give a price/value to decentralization which can have sooo much power to increase permissionless innovation

hope that helps,


I agree with what @sam.omw1 has said above, but would add that for some services like DA, rollups using the middleware always have the option of pessimistically falling back to Ethereum’s native DA. I believe this is how Mantle is building their rollup!

In the case of a validator signature threshold like you mentioned, this is not possible. In this case, governance would likely need to intervene to remove the malicious validators, which means that the middleware and all that rely on it need to build in the correct escape hatches and other mechanisms in order to do this upgrade in a trust minimized manner.

Of course, this is not as elegant as the usual paradigm of automatically handling liveness failures like Ethereum’s consensus or handling it via hard forks as in Tendermint. However, as we scale and extend Ethereum through rollups and restaking at the smart contract layer, we are actively researching ways to maintain a high standard in our upgradability/governance assumptions while trying to minimizing burden for users and developers.

Looking forward to discussing this more!


awsome work i appricate your work