Rewards

Overview

Operators are incentivized through rewards for executing tasks and making attestations. Rewards scale with the effective balance, which provides an economic incentive for Operators to behave honestly and act in the networks’ best interest.

Operators opt in to validate the execution and put their stake at risk of penalties. Operators are penalized for missed, late or incorrect attestations. Violating a consensus rule carries consequences on effective balance, which results in a lower reward and voting power.

Rewards Calculation

Operator rewards depend both on the amount of base reward per task and the frequency at which an operator is chosen to perform a task. Developers must configure the task rewards and may utilize a leader election mechanism to determine the frequency at which operators are selected for tasks. Othentic Stack allows the configuration of diverse types of tasks with different corresponding rewards.

Operartors accumulate rewards as Tasks are executed.

Stake-weighted Rewards

Proof-of-Stake networks include a "stake-weighted" Leader Election mechanism where the more stake an operator has, the more tasks they'll be chosen to perform.

The Othentic Stack supports any Leader Election mechanism implemented by the AVS developer.

When using a stake-weighted algorithm, for operator $n$, we denote the total reward $T_n$, with the expected value $E(T_n)$ described as:

$$E(T_n) = \frac{S_n}{S_{T}} \cdot C \cdot R$$

Where

• $R$ is the base reward per task

• $S_n$ is the effective balance of operator $n$

• $S_T = \sum\limits_{n=1}^{N}S_n$ is the total effective stake for the network

• $C$ is the number of tasks the network produced overall.

Constructing the Rewards Function

To generalize for any Leader Election algorithm, a probability function $P(n)$ can be derived from the selected algorithm such that $\sum\limits_{n=1}^{N}P(n) = 1$ to rewrite the expected value formula as:

$$E(T_n) = E \Bigl( P(n) \Bigl) \cdot C \cdot R$$

There are two configurable components for the rewards function:

• $P(n)$ — The probability of operator $n$ to be elected for a task

• $R$ — The base reward for each task

For example, a uniformly random leader election mechanism — which is not stake-weighted — would have $P(n)=\frac{1}{N}$ .

$P(n)$ is derived from your Leader Election algorithm. Different algorithms could have different $P$ functions. $R$ is the base reward and is configurable via the AttestationCenter contract.

Configuring Base Rewards

Task Definitions are used to configure base rewards for the operators. Each task definition includes the base reward for all entities participating in the consensus: the performer, the attesters, and the aggregator.

Read More

• Guide: Creating Task Definition - step-by-step instructions to create Task and configuring rewards.

---

Rewards Distribution

There are two main reward distribution flows, and the choice depends on the rewards token and the chain.

1. EigenLayer Rewards V2: This method supports ERC20 tokens for rewards distribution on L1 and does not support ETH.

2. Batch Reward Distribution: This method supports both ERC20 tokens and ETH rewards and supports rewards on both L1 and L2.

3. Fixed Rewards Distribution: This method enables the distribution of a fixed reward amount to Operators.

Important Considerations:

• You can only use one of these flows at a time, not all.

• Ensure that sufficient reward tokens are deposited into the L1/L2 AVS treasury using the rewards deposit command before initiating the distribution process.

1. EigenLayer rewards V2 - Operator Directed Rewards Submissions

This method includes integration with EigenLayer's Rewards coordinator to process and distribute rewards. Operators and Stakers can claim their rewards from EigenLayer UI.

Read More

• Guide: Distribute Rewards - step-by-step guide to distribute rewards.

• CLI Command Reference: Rewards

---

2. Batch Rewards Distribution

This method is used to distribute task-based rewards to a batch of eligible Operators. Operators whose tasks are marked as valid within the specified block range will be paid.

Usage

• Use Batch Rewards guide to use this rewards mechanism.

Process Flow:

1. The specified range of Operators is validated to ensure it falls within the allowed limits.

2. Based on the reward configuration (L1 or L2):

   • If the rewards are configured on L2: PaymentsRequested event is emitted.

   • If the rewards are configured on L1: A batch payment message is sent to L1. L1 Rewards Handler processes this message and calls the AVS governance contract to release rewards to eligible operators.

---

3. Fixed Rewards Distribution

This method can be used to distribute a fixed amount of rewards to the Operators. Operators who were actively participating in the AVS during the defined window - from startTimestamp to startTimestamp + duration - will be eligible to claim a share of the amount.

• This function can only be called by the AVS governance multisig.

• Operators and Stakers must claim their rewards via the EigenLayer.

• The distribution among the Stakers will be according to the multipliers.

Read More

• Use Fixed Rewards Distribution guide to use this rewards mechanism.