Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Bounty Expiry from Bounties Pallet #509

Open
oshakarishvili opened this issue Dec 11, 2024 · 3 comments
Open

Remove Bounty Expiry from Bounties Pallet #509

oshakarishvili opened this issue Dec 11, 2024 · 3 comments

Comments

@oshakarishvili
Copy link

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:

  1. 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.
  2. 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.
  3. 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.

References:

  1. Parameter
  2. Bounty Pallet
@abdbee
Copy link

abdbee commented Dec 17, 2024

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.

@abdbee
Copy link

abdbee commented Dec 17, 2024

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.

@muharem
Copy link
Contributor

muharem commented Dec 17, 2024

we probably want to update the expire for the existing bounties as well which will require a storage migration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants