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
Current Uptime Incentive accumulators used are
time.Nanosecond
time.Minute
time.Hour
time.Hour * 24
time.Hour * 24 * 7
time.Hour * 24 * 7 * 2
Early usage has suggested that 1 minute has a minor impact on the width of liquidity, and 1 hour is often too long for new pools with the current frontend design as forfeited incentives are not visible.
Conversely, longer periods are not used as frequently - the one 14 day uptime in use expires 3rd May, all others use 1 min, 1 hour or 1 day.
Suggested Design
Suggesting the addition of a new accumulator between 1 minute and 1 hour
Either 5 min or 15 min.
Ideally another accumulator between 1 hour and 1 day (6 hours) would be available too, however I understand that additional accumulators are resource intensive.
This could be offset by removing 7 and 14 day Uptimes.
We need logic in uptime handler,
refund if gov prop is created before migration
this creates linear overhead
adding a new uptime
size in terms of scope
Acceptance Criteria
New uptimes able to be set/approved by governance to be set
Existing incentives not broken (This may require a gov prop to remove new 7 and 14 uptimes if required)
The text was updated successfully, but these errors were encountered:
Background
Current Uptime Incentive accumulators used are
time.Nanosecond
time.Minute
time.Hour
time.Hour * 24
time.Hour * 24 * 7
time.Hour * 24 * 7 * 2
Early usage has suggested that 1 minute has a minor impact on the width of liquidity, and 1 hour is often too long for new pools with the current frontend design as forfeited incentives are not visible.
Conversely, longer periods are not used as frequently - the one 14 day uptime in use expires 3rd May, all others use 1 min, 1 hour or 1 day.
Suggested Design
Suggesting the addition of a new accumulator between 1 minute and 1 hour
Either 5 min or 15 min.
Ideally another accumulator between 1 hour and 1 day (6 hours) would be available too, however I understand that additional accumulators are resource intensive.
This could be offset by removing 7 and 14 day Uptimes.
We need logic in uptime handler,
Acceptance Criteria
New uptimes able to be set/approved by governance to be set
Existing incentives not broken (This may require a gov prop to remove new 7 and 14 uptimes if required)
The text was updated successfully, but these errors were encountered: