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
The current implementation of the Bounty Expiry and Renewal feature in the Bounties pallet introduces notable inefficiencies and challenges, particularly due to its reliance on poorly designed UIs and the cumbersome processes it enforces.
Problem Statement:
UI-Driven Challenges: The feature heavily depends on manual interactions through UI. In its current state, these interfaces are prone to issues, causing curators to miss extension calls inadvertently.
Inappropriate Curator Activity Signal: The expiry mechanism does not serve as a meaningful signal for curator activity. It often penalises curators unnecessarily rather than encouraging effective management of bounties.
Permissionless Slashing: The ability for anyone to slash curators after an expiry adds unnecessary friction. Curators then need to go through the approval process again via OpenGov, adding delays to bounty ops and redundant steps.
Proposed Solution:
The removal of extend_bounty_expiry to eliminate redundant steps and unnecessary burdens on curators, while instead relying on more effective indicators of curator activity, such as the number of bounties opened, finalised, and rewarded, reports submitted, and milestones achieved. In cases where slashing of curators is necessary, this can be addressed through OpenGov proposals, allowing token holders to collectively decide on such actions.
I agree with @oshakarishvili . Bounty expiry is never a good indicator of curatorial activities.
It would perhaps be best to adjust the Bounties Pallet such that runtimes that don't want an expiry can set BountyUpdatePeriod to 0 and have their bounties never expire. Runtimes that want an expiry can still set the value to what they want. That way, the Bounties Pallet will serve both cases and remain backward compatible with any other runtimes using it.
Another option that won't require changes to the runtime code is to keep the expiry but refresh update_due for the bounty's status every time a child bounty is opened. That way, the bounty never expires as long as at least one child bounty is opened before its update period elapses.
The current implementation of the Bounty Expiry and Renewal feature in the Bounties pallet introduces notable inefficiencies and challenges, particularly due to its reliance on poorly designed UIs and the cumbersome processes it enforces.
Problem Statement:
Proposed Solution:
The removal of
extend_bounty_expiry
to eliminate redundant steps and unnecessary burdens on curators, while instead relying on more effective indicators of curator activity, such as the number of bounties opened, finalised, and rewarded, reports submitted, and milestones achieved. In cases where slashing of curators is necessary, this can be addressed through OpenGov proposals, allowing token holders to collectively decide on such actions.References:
The text was updated successfully, but these errors were encountered: