You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want governance to be able to specify/change the uptime its incentives go to. Allowing governance to simultaneously incentivize multiple uptimes is something we will not be supporting at this time due to a blowup of implementation and interface complexity.
Along a similar vein, now that internal incentives have all transitioned to volume splitting/group-based incentives, separating the two is another source of scope blowup. This is primarily due to the incredible architectural complexity introduced by breaking the 1:1 link between pools and internal gauges, which important core logic leans on.
Thus, the simplest path forward seems to be to just have internal incentives and volume splitting act in unison, and have the uptime they trigger be a param updatable by governance.
Note: While it is technically feasible to refactor this and make necessary state changes in upgrade handler to, the additional scope and security risk introduced by this change seems to not be worth it at this time for a feature that would likely get minimal/no usage in the short to medium term.
The implications of such changes would be far-reaching – for example, CreateGroup would need to specify a list of uptimes, but only for CL pools etc, which would break the Group interface in a messy way and would require important parts of the volume splitting feature to be refactored.
Suggested Design
Introduce a gov param in the incentives module that tracks the uptime internal incentives should be using. Note that the intention is to have this fall back to the default value of 1ns (no uptime).
Validation logic should ensure that the gov param is one of the supported uptimes (constant list imported from CL module). Note that this is distinct from authorized uptimes, which is a CL gov param that should not apply here. In other words, governance should be able to distribute internal incentives to uptimes that are not authorized for external incentive creators to use.
Acceptance Criteria
Gov param is added and has sanity checks
The text was updated successfully, but these errors were encountered:
Background
We want governance to be able to specify/change the uptime its incentives go to. Allowing governance to simultaneously incentivize multiple uptimes is something we will not be supporting at this time due to a blowup of implementation and interface complexity.
Along a similar vein, now that internal incentives have all transitioned to volume splitting/group-based incentives, separating the two is another source of scope blowup. This is primarily due to the incredible architectural complexity introduced by breaking the 1:1 link between pools and internal gauges, which important core logic leans on.
Thus, the simplest path forward seems to be to just have internal incentives and volume splitting act in unison, and have the uptime they trigger be a param updatable by governance.
Suggested Design
Introduce a gov param in the incentives module that tracks the uptime internal incentives should be using. Note that the intention is to have this fall back to the default value of 1ns (no uptime).
Validation logic should ensure that the gov param is one of the supported uptimes (constant list imported from CL module). Note that this is distinct from authorized uptimes, which is a CL gov param that should not apply here. In other words, governance should be able to distribute internal incentives to uptimes that are not authorized for external incentive creators to use.
Acceptance Criteria
The text was updated successfully, but these errors were encountered: