Useful Links

• Rewards documentation

• RewardsCoordinator.sol GitHub documentation

• Boosted rewards blogpost

• Offchain rewards calculations

Introduction

EigenLayer has recently activated AVS rewards, a significant step down the path to a self-sustaining restaking ecosystem. This change has been a key part of EigenLayer's roadmap and its arrival is a significant unlock which has been welcomed from all corners of the AVS ecosystem. This raises the following questions:

1. Why is the ecosystem pleased by this?

2. What problem is this supposed to solve?

3. How is that achieved?

4. How does this affect the risk profile of restaking through EigenLayer?

This note will address these questions.

AVS Rewards Theory

Why distribute rewards?

EigenLayer is a system designed to unlock underutilized capital to extend cryptoeconomic security to applications that traditional incentivization structures have yet to provide for. Before these rewards went live, there was no incentive to provide capital beyond purely speculative points programs (which may or may not entitle those restaking to governance tokens) without any revenue being driven to those restaking their assets on EigenLayer.

With the arrival of AVS rewards, restakers will receive direct revenue from those applications their staked assets help to secure. For the first time, applications will be able to compensate those risking slashing on their assets. This is a major departure from EigenLayer's initial configuration and the beginning of a sustainable economic system with an appropriate risk-adjusted return profile.

While it is true that these rewards are "boosted" (i.e. supplied by EigenLayer developers) for now, AVS revenue will supplement these boosted rewards in due time.

How did EigenLayer design a system to achieve this goal?

EigenLayer's smart contract system designed a workflow to distribute rewards based on "(i) the relative stake weight of each Operator's Stakers and (ii) a globally-defined commission given to the Operator." This has been achieved through Merkle Trees using both onchain and offchain calculations. It works in the following way:

Source: LlamaRisk

1. The AVS submits a request to a smart contract that coordinates which addresses have restaked which assets for which period of time.

2. This request is received offchain and rewards entitlement calculations are made - proof of which is consolidated to a Merkle Tree.

3. Smart contracts post these offchain calculations onchain and the distribution is claimable after a predetermined time period.

4. Restakers and operators claim their rewards programmatically.

This system design enables stakers and operators to claim rewards based on their contributions using both onchain and offchain dependencies.

Smart Contract Analysis

Implementation

The RewardsCoordinator contract is designed to manage the distribution of ERC20 token rewards to operators and stakers. The contract does not perform any price conversion or adjustment based on the value of the tokens. It simply distributes the exact amount of tokens that were submitted.

Here's a detailed breakdown of its workings, essential functions, roles, and permissions.

Important Functions

• createAVSRewardsSubmission allows AVS to submit rewards that will be distributed among their stakers. The rewards are transferred to the contract and later distributed based on Merkle proofs. Only authorized submitters can call the function. This function can be paused, however, for successful distributions, pause status MUST NOT be set.

• createRewardsForAllSubmission is similar to the previous one but permits distribution to all stakers across the system, not limited to a single AVS. The same non-pausing conditions apply. This function is callable only by addresses with the isRewardsForAllSubmitter permission.

• processClaim enables stakers/operators or their authorized claimers to claim rewards based on Merkle proofs. The claim is checked against stored Merkle roots to ensure validity. Only the valid claimer, which can be the earner or a designated claimer, can call the function.

• setClaimerFor allows the staker / operator to set a different address as their authorized claimer.

• submitRoot is callable only by rewardsUpdater and submits a new Merkle root (DistributionRoot) for reward distribution. The root is activated after a specified delay.

• disableRoot allows the rewardsUpdater to disable a pending Merkle root before it is activated, typically in case of errors.

Roles

• Owner configures critical contract parameters, such as the activation delay, global operator commission, and permissioned roles like the rewardsUpdater. The owner role is initially set during contract initialization and can be transferred. EigenLayer: Executor Multisig is the current owner of the contract.

• RewardsUpdater (set by contract owner) can submit new Merkle roots for reward distributions and disable pending roots if needed.

• RewardsForAllSubmitter can submit rewards that are distributed across all stakers, not just those under a specific AVS. Require whitelisting by the contract owner.

• Pauser manages pausing of key contract functions to prevent execution during specific scenarios (e.g., under attack or maintenance).

• Claimer - authorized to claim rewards on behalf of a staker / operator.

Rewards Merkle Tree

The Rewards Merkle Tree is a cryptographic structure employed to ensure the integrity and verifiability of reward claims against a DistributionRoot. When a new root is submitted, it encapsulates all RewardsSubmissions collected from AVSs since the previous DistributionRoot. This tree efficiently consolidates data on earners and their cumulative earnings across various reward tokens. Claimers can strategically choose which token leaves to validate and claim, allowing for precise control over the accumulated earnings they wish to collect. Each successful claim triggers the transfer of the respective tokens to the specified recipient address.

Source: EigenLayer Merkle Tree documentation

The computation of rewards is managed through an off-chain data pipeline. This pipeline periodically snapshots the core contract's state at intervals defined by SNAPSHOT_CADENCE, which is currently set to once daily. These snapshots, combined with any ongoing rewards activities, help calculate the daily earnings for each earner. The rewards are then accumulated and posted on-chain by the RewardsUpdater.

Offchain Computation

The rewards calculation process occurs offchain, relying on a series of SQL queries and data transformations performed on a Postgres database. A detailed explanation is published on EigenLayer HackMD.

The rewards calculation process operates in a three-stage pipeline, executed daily.

• Data extraction: begins by pulling data from on-chain event logs and storing it on dedicated tables. To ensure data integrity, the extracted event data is reconciled against both Remote Procedure Call (RPC) data and an external data provider.

• Data transformation: Once the raw data is extracted, the next stage involves transforming it into daily snapshots, representing the state of the onchain data at specific intervals (every 24 hours) and are rounded up to the nearest day at 00:00 UTC. An exception is made in cases of operator and AVS deregistrations, which are rounded down.

• Reward calculation: considers all relevant snapshots within a specified range (e.g., Day 1 to Day 7) and aggregates the rewards accordingly.

The calculation is demonstrated below

Source: EigenLayer Rewards Calculation

The calculation is straightforward and entitles each depositor to a "stakeWeight", which is the product of how much assets are staked over which period of time. Rewards are then allocated evenly according to "stakeWeight".

An invariant in the reward calculation ensures that the total reward distributed to all earners must not exceed the reward provided for the submission. Even in cases of truncation errors or precision loss during calculations, the system remains financially sound.

Price Oracle

RewardsCoordinator contains no direct mechanism or implementation for determining the price of the rewards based on external market data. Additionally, there is no reference to an oracle service being used within this contract.

When rewards are submitted (either via createAVSRewardsSubmission or createRewardsForAllSubmission), the amount of ERC20 tokens to be distributed is predefined by the entity submitting the rewards. This amount is a fixed number of tokens, without any internal contract mechanism to adjust based on token price fluctuations.

The contract does not perform any price conversion or adjustment based on the value of the tokens. It simply distributes the exact amount of tokens that were submitted.

Is this reward system being used?

0x8f9 (an example address) has started submitting roots and respectively claiming rewards. It has made 3 root submissions so far to the RewardCoordinator.sol contract. This is evidence on a smart contract level that the rewards process has started.

Source: Etherscan

In turn, RewardCoordinator.sol is sending small amounts of WETH to those calling the Process Claim method after a period of "rewards mock" tokens were distributed as a test. This indicates the reward process is functional and already seeing good use.

Source: Etherscan

Are there limits to rewards distribution?

RewardsCoordinator.sol does not explicitly specify a minimum reward amount. The maximum amount that can be distributed in a single submission is capped by MAX_REWARDS_AMOUNT, subject to modification in the various AVS use cases.

In terms of time, rewards submission should occur within 70 days. Activation delay is set to 7 days, however the maximum waiting period stakers/operators should consider is 16 days, including calculation delay (2 days) and root submission cadence (7 days) on top of a week-long activation delay.

Risks

Having proven that the Rewards system is operational, let's examine why users may hesitate before calling the Process Claim method. The potential risks in this process are many and diverse. While these risks apply to rewards only (and not capital at risk for those staking), receiving no reward despite taking risk may make the economics of using AVS impossible for some users.

Access control risk

The RewardCoordinator contract possesses numerous privileged roles such as activation delay, global operator commission, and transferability of the owner. This presents risks to the rewards that are supposed to be distributed and should be considered. For example, operator commission or activation delay modifications may result in no rewards being passed to stakers. Contract ownership of RewardsCoordinator is held by a GnosisSafe multisig "Eigen Executor", which is used for no purpose other than signing transactions. While still clearly centralized, this is indicative of good development practices and that this risk is taken very seriously.

Scalability of incentive structure

As identified in the introductory blog post, EigenDA is initially distributing 10 ETH per month which is funded not from the AVS itself. $EIGEN tokens may also be used as rewards - likely in the form of future stakedrops for ecosystem participants. This is important to consider as the incentive to restake on the AVS is not self-sustaining at this time. While subsidizing early technological developments to encourage use is an established strategy, the subsidy must eventually end and this can result in drastically reduced usage of the product itself. This risk could ultimately be the reason restaking does not fulfill its vision, even if it is not realized for many years. Those claiming their rewards should be mindful of where the rewards come from and how long they must wait for them to be self-sustaining.

Offchain risk

Reward math is calculated offchain. This leaves room for potential undetectable arbitrary changes that may compromise the incentive (i.e. reward) paid to stakers and operators. While developers have explained how the calculations are made and at what time they are published onchain , there is still trust involved in this process. This risk is not mitigated and therefore remains a potential point of failure in the reward system. Given the possibility of modification to offchain calculations without notice, there could hypothetically be a guaranteed reward floor set to incentivize restaking. This in turn could be sybil attacked, resulting in users dividing their staked assets across many different addresses to receive an outsized return of rewards compared to if they had restaked all of their assets on one address. This is seen with "airdrop farming" and comes at the expense of larger individual addresses.

Smart contract risk

As with any smart contract, there is technical risk. Any number of variables may operate in an unintended function resulting in a potential loss of rewards owed to restakers and node operators. This risk has been mitigated with a contract-specific audit with no critical or high findings. To have an audit for a specific contract is indicative of a high-quality development team that takes risk seriously. EigenLayer also has a $2M bug bounty for which this reward system is in scope. This is indicative of good mitigations taken in the face of smart contract risk.

AVS directory risk

The AVS using this reward structure could fail to register with the AVS directory, resulting in no rewards being passed to stakers or operators. This risk is small and primarily related to the incompetence of the AVS operator, but it should not be entirely ruled out.

Taxable event considerations

Disclaimer: YieldNest Risk is entirely unfamiliar with any reader's jurisdictional taxation regime and provides no assurance in this regard. Nothing in this article constitutes legal, accounting, tax or specific investment advice.

While not a risk per se, restakers should pay careful attention to jurisdictional requirements relating to claiming rewards. Given that users must claim the rewards themselves that are generated at no realized financial cost (instead a technical, opportunity, and risk cost), there are questions relating to their taxation eligibility. For example, are rewards not yet claimed eligible for taxation? It may be optimal to wait until the moment a user is ready to divest from their reward token to minimize the tax burden. Then again, if the reward is earned at 0 direct cost basis, would the eligible amount of tax be higher if they left the reward unclaimed until the last minute? Different jurisdictions have vastly different taxation regimes and users should be mindful of them.

Closing

This piece has looked at the implementation of AVS Rewards on EigenLayer, its significance, and identified potential risks. It finds that the solution is functional and has been developed in a responsible manner but that ultimately offchain dependencies and questions relating to sustainability should be closely paid attention to.

If you'd like to discuss this with LlamaRisk analysts, please join our public channel @LlamaRisk on Telegram.