Introduction

EigenLayer is a protocol that allows developers to build Autonomous Verifiable Services (AVSs) by supplying “decentralized trust.” These services are autonomous because anyone can participate and continue running them, and the correct operations of these services are verifiably enforced onchain. Examples of AVSs include oracles, bridges, and co-processors.

AVSs can augment their service by providing cryptoeconomic guarantees, making it an attractive offering for builders and users. EigenLayer is designed to be a minimal part of the stack, allowing developers to focus on the core and differentiating business logic that their AVS provides. This means that any generalized distributed system can be built on EigenLayer. This document will detail two core and common AVS archetypes, task and epoch-based, to guide developers as they begin designing their AVS.

Task and epoch-based AVS archetypes exist today within the AVS ecosystem and accommodate a vast set of use cases. These archetypes are differentiated by the type of work the service is providing, specifically how that unit of work is generated, tracked, and settled. You can think of these as conceptual blueprints that help developers quickly align their AVS’s needs with a working model. The models shape how you’ll approach:

• Ingestion: How users initiate a request (e.g., event emission from a smart contract vs HTTP traffic).
• Coordination: How Operators ingest and execute requests.
• Verification & Settlement: How Operators have their work for the request attributed.

Task Based

Task-based models are those where discrete units of work (i.e., an individual task) are committed to by Operator(s). These can be thought of as function-like services (e.g., AWS Lambda), where the lifecycle of a service request is scoped to the task. The Incredible Squaring repo is an example of a task-based model.

Flow

The canonical flow of this archetype can be summarized as follows:

1. Users submit a request for a task to be done, either onchain or offchain (consumer).
2. Operators listen for requests and complete the work (producer).
3. The AVS handles the settling of that task, either offchain (HTTP response) or onchain (submission to smart contract).
4. The attribution of the Operator’s work for the task can be verified, informing of rewards or punitive measures like slashing or Operator eviction/jailing.

Ingestion

Task instantiation can either be done onchain by calling an external function that emits an event consumed by the AVS or offchain by calling an HTTP endpoint (Figure 1). There are trade-offs here based on centralization, UX, and cost. By submitting tasks offchain, there are UX and cost benefits, at the expense of decentralization (e.g., censorship risk). To mitigate censorship risk, AVSs can expose a permissionless fallback, inside a contract (which may incur a fee for DoS prevention, if the cost of work >> cost of tx).

To support offchain ingestion, AVSs can introduce an orchestrator actor that can ingest requests and route to Operators, based on the task type, which could be separated by Operator Sets and by stake weight (which is a signal for Operator performance and reputation). The orchestrator can be thought of as a reverse proxy that can manage request routing and load balancing. By doing this, users do not need to submit a transaction, removing the burden of cost, polling (tx confirmation and receipt), and latency.

Workloads

AVSs may also customize how the task workload is handled. For example, 1 of N, where one Operator does work, like Lagrange’s Prover Network, or an M of N style where M operators do work, such as the Incredible Squaring example. The choice of handling is a matter of the cost of the workload and how much cryptoeconomic security is needed. A 1 of N model is more suitable where the work is expensive and timely. Whereas, an M of N model is better suited for lighter workloads and where large cryptoeconomic security is needed.

The EigenLayer Go and Rust SDKs provide a BLS Aggregation Service to support stake-weighted consensus when using the M of N model (Figure 2). Typically, this is implemented as an aggregator pattern, where an aggregator actor disperses work to be done by Operators. At a high level, the flow is as follows:

1. The aggregator is informed of work to be done and disperses a work request to Operators by sending a request.
2. Operators receive the request, do some work, and sign over the hash of the result, sending a response to the aggregator.
3. The aggregator receives the responses and settles the result onchain upon reaching the BLS signature threshold (based on stake-weight) over a hash.
4. Downstream actions can then be done.

AVS Task Models

Below are AVSs that are using the task-based model:

• Lagrange: A prover network that requires a 1 of N liveness guarantee to generate proofs.
• EigenDA: EigenDA uses an N of N tasked based model. Operators provide data availability guarantees over proportional chunks of data based on their relative stake weight in the network.

Epoch Based

Epoch-based models are those where the units of work are continuous, where an Operator performs work over some period, called an epoch. These can be thought of as process-based services (e.g., AWS Fargate). This archetype is more suitable when an AVS offers a service where work is done more frequently and continuously. For example, for an AVS that serves an RPC for a chain, it doesn’t make sense to attribute the work or require a user to submit a transaction on a per-request basis.

Flow

The canonical flow of this archetype can be summarized as follows:

1. An epoch starts (can be defined arbitrarily, either onchain or offchain).
2. User(s) submit requests to the AVS.
3. Operators fulfill requests.
4. Epoch ends.
5. The attribution of the Operator(s) work over the epoch can be verified, informing of rewards or punitive measures like slashing or Operator eviction/jailing.

Ingestion

Epoch workloads are more continuous, making an offchain model for work consumption the better approach, such as the orchestrator pattern as mentioned above. Keeping the RPC Chain AVS in mind, Operators Sets could define the chain ID being served, and the orchestrator could route requests based on this.

The attribution of work under the epoch model is more continuous and less granular, making attribution more difficult than the task model. A way to resolve this is by using a watcher network (another Operator Set in your AVS), which is a set of Operators tasked with monitoring the health and performance of Operators providing the service of the AVS (Figure 3). For example, the watcher network could enforce SLA’s over the Operators, such as latency and the number of successful requests (e.g., # of 200 responses) over the duration of the epoch, by periodically pinging them. The watcher network could then make its results available on EigenDA at the end of the epoch, which could then be used for downstream actions, such as slashing or reward distribution.

AVS Epoch Models

Below are AVSs that are using the epoch-based model:

• Infura’s DIN: An RPC AVS using an epoch model with a watcher network to onboard new operators (RPC providers) and enforce SLAs over epochs.
• Gaia: A decentralized inference AVS using the epoch model to detect model outliers using statistical analysis.

Conclusion

Task and epoch-based models offer a useful starting point for designing your AVS. They help frame questions around how work is initiated, who performs it, how it’s verified, and when it’s settled. These archetypes aren’t prescriptive - they’re patterns that reflect what’s working today and can be adapted or composed depending on your use case. As the AVS ecosystem continues to grow, these models will evolve and likely uncover more archetypes.

This post is one in a series of posts that will dive deeper into AVS designs. This post has covered patterns that trade off centralization for lower complexity. Future posts will dive deeper into the progressive path to decentralization that AVSs can adopt, such as decentralizing the aggregator actor.

Coming Soon

A key to unlocking the design space of AVSs is reducing developer friction through an improved DevEx. Eigen Labs is working hard to improve this, with revamped documentation and a new framework called DevKit built for rapid prototyping, task-based (and eventually epoch-based) template generation, deployment management, and much more. Stay tuned!

Have an AVS idea? Talk to our team and start building right away.