Rewards and Penalties
Intro
Operators in a shared security environment are incentivized through rewards for making attestation and executing diverse specialized tasks. Rewards scale with the effective balance, which provides an economic incentive for Operators to behave honestly and act in the networksβ best interest.
To maximize reward, a single Operator opt-in to validate multiple networks, and puts its staked ETH at additional risk of penalties. Operators are penalized for missed, late or incorrect attestations. Violating a consensus rule of chain A, carries consequences on effective balance, which results in a lower reward and voting power on AVS B and C, alongside A.
Overview
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. AVS developers must configure the task rewards and 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.
Formalization
Stake-weighted Rewards
Most 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 , we denote the total reward , with the expected value described as:
Where is the reward per task, is the effective balance of operator , is the total effective stake for the network and is the number of tasks the network produced overall.
Generalization
To generalize for any Leader Election algorithm, a probability function can be derived from the selected algorithm such that to rewrite the expected value formula as:
For example, a uniformly random leader election mechanism β which is not stake-weighted β would have .
Constructing the Rewards Function
There are two configurable components for the rewards function:
β The probability of operator to be elected for a task
β The base reward for each task
is derived from your Leader Election algorithm. Different algorithms could have different functions. is the base reward and is configurable via the AttestationCenter
contract.
Configuring Base Rewards
Task Definitions
The Othentic Stack supports multiple types of tasks, called "Task Definition". Every Task Definition represents a certain type of task the network has to perform. A Task Definition includes the following properties:
Property | Type | Description |
---|---|---|
taskDefinitionId | uint16 | Auto-generated incremental ID |
name | string | A human-readable name for the task |
blockExpiry | uint256 | The block after which tasks of this type are no longer valid and will be rejected by the AttestationCenter |
baseRewardFeeForAttesters | uint256 | The base reward for the attester rewards function |
baseRewardFeeForPerformer | uint256 | The base reward for the performer rewards function |
baseRewardFeeForAggregator | uint256 | The base reward for the aggregator rewards function |
disputePeriodBlocks | uint256 | The amount of blocks needed to wait before payment can be finalized |
Each task defines the base reward for each of the entities participating in consensus: the performer, the attesters, and the aggregators.
Creating Task Definitions
New Task Definitions are created on-chain via the AttestationCenter
smart contract. See Attestation Center for more details on its API.
To create a new Task Definition, we invoke the createNewTaskDefinition()
method:
Last updated