This veto committee can be considered to be training wheels for new AVSs onboarding onto EigenLayer. The AVSs can use this veto committee to assure EigenLayer restakers that they will not be subject to malicious slashing or inaccurate slashing due to bugs, as there is always a fallback to the committee which can veto the slashing. Meanwhile, AVS developers can battle-test the codebase associated with the AVS. Once mature and getting enough trust from restakers, an AVS can stop using the veto committee as a fallback. The trust assumptions for using the veto committee are that the AVS must trust the veto commitee will not veto a correct slashing, while the stakers restaking in EigenLayer must trust the veto committee will veto any unjustified slashing by the AVS.

AVSs that want to build on top of EigenLayer and use the veto committee must be admitted by the veto committee. The onboarding process may require security audits and other diligence by the members of the committee, including checking the system requirements for operators to serve the AVS. 3.6 Designing Modules for Maximal Security Also Minimizes Centralization Risk We note that the most security is obtained when all of the ETH that has been restaked with EigenLayer is used to secure a given AVS. However, there are two impediments to this: (1) whether the expected revenue of the AVS outweighs the operational costs for operators; and (2) whether operators have enough computational resources to participate in validating for the AVS. We propose two possible patterns by which a module can be designed in order to alleviate these concerns.

1. Hyperscale AVS: In a hyperscale AVS, the total computational workload is divided across all N participating operator nodes. This feature is called horizontal scaling, or scale-out in distributed computing. One prominent example of a hyperscale module is a hyperscale data availability protocol, where the total amount of data is chunked into N chunks each of size 2/N of the original data. Thus the total cost of storing the data is as though only 2 nodes store it. We note that in a hyperscale AVS, the throughput requirements of each node can be small while the system itself can achieve high throughput by aggregating performance across many nodes. Furthermore, hyperscale AVSs have lesser incentives for centralized validation than existing blockchain systems today. This is because, in existing blockchains (which are not horizontally scaled), the validation cost can be fully amortized by a central operator, as a state transition once known to be valid can be used by all operator keys. How

2. Lightweight: There are also examples of tasks which are redundantly performed by all the operators yet the cost of performing these tasks is very low, and the computing infrastructure required is also very low. For example, attesting on a certain message based on running a light client, verifying zero-knowledge proofs, running light nodes of other blockchains, and running oracle price feeds are lightweight actively validated services that can be run on EigenLayer. We note that by designing a suite of hyperscale and lightweight AVSs which produce most of the yield available on EigenLayer, we can ensure that even home validators in Ethereum can obtain most of the economic benefit of EigenLayer, thus minimizing centralization pressures on Ethereum staking. 4 A World with EigenLayer