feat: draft IEmissionsController
#1678
Conversation
| /// @notice Removes a distribution. | ||
| /// @dev Only the Incentive Council can call this function. | ||
| /// @dev Ref: Implied by "updateDistribution" and general management of distributions. | ||
| /// @param index The index of the distribution to remove. | ||
| function removeDistribution(uint256 index) external; |
There was a problem hiding this comment.
Open question: Should this mark the distribution as "removed" or outright remove the distribution from storage. Intuition tells me we should simply mark it as removed so it can still be easily audited/introspected in the future (and avoids need for swap/pop enumerable set pattern).
| /// @notice Returns all distributions. | ||
| /// @return An append-only array of Distribution structs. | ||
| function getDistributions() external view returns (Distribution[] memory); |
There was a problem hiding this comment.
Append only pending above question. May need to correct.
| RewardsForAllEarners, | ||
| OperatorSetTotalStake, | ||
| OperatorSetUniqueStake, | ||
| EigenDA, |
There was a problem hiding this comment.
Isn't EigenDA just one of the old reward types? createAVSRewardsSubmission
There was a problem hiding this comment.
My interpretation is the intent of that ref is to give the possible types of rewards submissions that can be made? Could be wrong though
| struct Distribution { | ||
| uint256 weight; | ||
| DistributionType distributionType; | ||
| bytes strategiesAndMultipliers; |
There was a problem hiding this comment.
Not an array? Have used that in the past
| /// @notice Removes a distribution. | ||
| /// @dev Only the Incentive Council can call this function. | ||
| /// @dev Ref: Implied by "updateDistribution" and general management of distributions. | ||
| /// @param index The index of the distribution to remove. | ||
| function removeDistribution(uint256 index) external; |
| /// @dev Ref: "Incentive Council Functions: addDistribution(weight{int}, distribution-type{see below}, strategiesAndMultipliers())" | ||
| /// @param weight The weight of the distribution. | ||
| /// @param distributionType The type of distribution. | ||
| /// @param strategiesAndMultipliers Encoded strategies and multipliers. |
There was a problem hiding this comment.
Will there be any error handling on the weight? I assume it's a proportion in BPS?
There was a problem hiding this comment.
Yeah should've specified in comments, weights are in bips (since easier to manually write out vs wad).
| } | ||
|
|
||
| /// @notice Configuration for the EmissionsController. | ||
| /// @dev Ref: "The amount of EIGEN minted weekly (inflation rate) is set by governance..." |
There was a problem hiding this comment.
So my understanding of the ELIP is that we have:
- A top-level inflation rate (eg 8%)
- Either eth-directed, Eigen-directed, or discretionary reward (eg. x% to ETH)
- A per-DistributionType type of above. x1% to rewards all stakers
How is 2 specified? It seems like we only do 3?
| /// @notice Triggers the weekly emissions. | ||
| /// @dev Ref: "The ActionGenerator today is a contract ... that is triggered by the Hopper. When triggered, it mints new EIGEN tokens..." | ||
| /// @dev Permissionless function that can be called by anyone when `canPress()` returns true. | ||
| function pressButton() external; |
There was a problem hiding this comment.
We might have to batch this if the size of the distribution array becomes too large... something to think about for implementation
There was a problem hiding this comment.
Good callout, yeah will need to ensure the button is always "pressable".
| /// @notice Triggers the weekly emissions. | ||
| /// @dev Ref: "The ActionGenerator today is a contract ... that is triggered by the Hopper. When triggered, it mints new EIGEN tokens..." | ||
| /// @dev Permissionless function that can be called by anyone when `canPress()` returns true. | ||
| function pressButton() external; |
There was a problem hiding this comment.
Also, what happens if one of the many reward tx's fail?
There was a problem hiding this comment.
Do we need a try-catch for that or do we ensure it doesn't fail at all? How does the current Hopper handle that?
Motivation:
We need approval on initial design of the upcoming incentives council feature release. Historically, we've used EigenHopper for token emissions. Now we're looking to make some improvements.
Modifications:
EigenHoppercontracts into a single new contract.Result:
Single consolidated interface with hopper functionality and proposed ELIP-012 functionality.