We’re excited to announce the release of EigenLayer’s very first EigenLayer Improvement Proposal (ELIP): the Eigen Labs Rewards v2 ELIP!
What are ELIPs?
EigenLayer Improvement Proposals (ELIPs) are the primary mechanisms for proposing new features and upgrades to the EigenLayer core contracts. ELIPs are version-controlled design documents that detail the motivation, technical specification, rationale, implementation path, and impact evaluation of specific proposals impacting core contracts. The ELIP process is being introduced to provide the EigenLayer ecosystem with more transparency and clarity on upcoming changes.
What is Rewards v2?
The Rewards v2 ELIP addresses gaps in the current implementation of EigenLayer rewards by giving AVSs more tools for more flexible, operator-directed rewards with on-chain attribution, in addition to a few quality of life improvements.
So what?
With the release of the Rewards v2 ELIP, we’re inviting everyone in the EigenLayer community to participate by reviewing the proposal and sharing your feedback in the comments below. Your input will help us refine the proposal to ensure it aligns with user needs and expectations.
Regarding the fees that operators can adjust themselves:
In the proposal, it is mentioned that operators are able to set fees from 0% to 100%. I strongly recommend establishing a minimum commission rate (I would recommend 5% ), as we have seen several times in the Cosmos ecosystem how this scenario plays out:
It will inevitably lead to a race to the bottom.
It does not encourage the establishment of best practices.
Bad actors can easily join the set and attract a lot of stake.
It becomes even harder for new operators to join the network.
It’s also in the AVS’s best interest to have operators who provide good and reliable resources.
By implementing a minimum commission rate, eigenlayer can ensure that operators are fairly compensated for their services, which encourages them to maintain high-quality infrastructure and support. This also helps prevent malicious actors from undermining the network by offering unsustainably low fees to attract delegations, only to compromise the network’s integrity later.
Establishing a minimum commission rate promotes a healthier ecosystem by fostering competition based on service quality rather than just fees. It also lowers the barrier to entry for new operators, who might otherwise struggle to compete with established entities offering zero or minimal fees. By allowing AVSs to distribute rewards based on several factors like performance and reliability, it’s even more important to give operators the ability to excel in these areas.
The proposal seems logical to me, but I do have a couple of questions.
The removal of direct-to-staker incentives might impact smaller AVSs or stakers, as they lose a key tool for incentivising participation and engagement. How do you see this change affecting smaller participants in the long run? Do you agree that the proposed structure could ultimately lead to a less inclusive ecosystem?
@matt.nelson, team, hello! Great to see the introduction of the new design of rewards functionality and thanks for addressing the main concerns for stakers, operators and AVSs.
I have a question if there any limit for the operator fee change per 1 time? Eg, an operator can’t change their fee by as much as they want, but can only chenge their fee by X% per month. Or operators have a full flexibility over the change?
We support ELIP 001 and believe the Rewards v2 upgrade will be a net positive for the ecosystem. The increased flexibility for operator-directed rewards and operational improvements (e.g., batched claiming) will increase the EigenLayer ecosystem’s ability to serve various scenarios and drive greater AVS adoption.
Hey @blockrotator. Yes, that is correct. ELIPs are not and will not required for requesting grants. There will be separate proposal processes for grants in the future.
Without more context on what kind of standards you’re referencing, I can’t speak specifically to that question!
As a protocol, EigenLayer aims to remain unopinionated in enforcement of parameters that it does not have a pressing need to regulate in a broader policy of protocol federalism: these decisions are passed on to the AVS to maximize the potential for innovation. The addition of a protocol-enforced fee rates adds additional complexity and contract scope while limiting potential use cases of the platform:
Enforcing minima or maxima at the protocol level could simply force AVSs out-of-band for extreme use cases, E.G. supply side incentives requiring no Operator action (0%), direct-to-operator incentives utilizing no stake (100%).
Operators may be able to create out-of-protocol agreements requiring fee rates of both 0% and 100% E.G. LRTs that wish save gas and aggregate all rewards to either the Staker address (0%) or contract-wrapped Operator addresses (100%).
Presently, if deemed necessary for the performance of their service, AVSs can create policies around their own local minimum or maximum fee rates that can be enforced via SLAs with ejection of operators failing to conform. Operators are under no obligation to support services with market rates insufficient to cover their costs. If we find there to be sufficiently high demand from AVSs, this enforcement could be added as a protocol feature in the future.
In addition, AVSs can create weight functions that use any parameters they want to determine Operator weights, including nonlinear weighting, weight caps, fee rates, historical performance, etc. The functionality provided in this ELIP allows them to reward Operators independently of both weight and stake. We believe that this rewards functionality is sufficiently flexible to allow AVSs to create incentive models that reward Operator for desired behavior without the need for arbitrary constraints.
Supportive - this ELIP feels well-formed and is a net positive for the ecosystem. Two notes:
Quorum Commissions - it seems operators will not be able to set different commissions for separate quorums within the same AVS. Ex: an operator on EigenDA would need to have the same commission for both quorum-0 and quorum-1. This may be worth considering in a future ELIP.
Min/Max Commission - I’m in favor of keeping this wide open (0% - 100%) across EigenLayer as a whole to maximize flexibility for AVSs. AVSs can set their own min/max values, and it feels best to not restrict them at this nascent stage. However, there are valid concerns raised above and ample history to learn from. If deemed worthy, this is best addressed as a separate ELIP.
The rewards functionality you are mentioning will be available with Operator Sets, check out ELIP-002 for more on this. Operator Sets are an enshrinement of Quorums in the core protocol.
Hey @Griff ! The current ELIP process is detailed in (new!) docs on docs.eigenfoundation.org. ELIP-001 is currently in review by the Protocol Council. The ELIP is now in the final stage of the process, and therefore ready for Protocol Council review. The Council will publish its evaluation of the ELIP and decision this week. If approved, the upgrade will be merged.
In this early stage, Eigen Foundation and Eigen Labs are the only entities that can accept proposals for improvements to the EigenLayer core contracts. The ELIP process is being introduced to provide the EigenLayer ecosystem with more transparency and clarity on upcoming changes. Bear with us as we get started
The Eigen Labs team currently communicates upcoming ELIPs with ecosystem participants (@matt.nelson can elaborate), but I think it’s a great idea to coordinate some public channels with the Protocol Council moving forward. We’ll make it happen!
A transaction to execute the previously-queued timelock action was proposed to the Protocol Council multisig. This initial proposal was performed using Zeus, a tool developed by EigenLabs to aid in deployments and administrative actions (soon to be open source!). It followed the logic in the scripts within this folder. The previously-queued action can be found in the event logs of this transaction.
Protocol Council members proceeded to sign the proposed action via the (Gnosis) Safe UI, with the last (i.e. 3rd) signer executing the action.
