Skip to content

MRWK bounty: 250 MRWK - effective bounty availability for pending proposals #641

@ramimbo

Description

@ramimbo

This is a proposal-gated bounty issue. It is not claimable yet. Do not submit /claim work from this issue until the treasury proposal executes, the public bounty page exists, and maintainers post Reserved on MergeWork.

Work needed

Add effective bounty availability visibility when pending treasury proposals already consume the practical remaining awards for a bounty.

Source evidence: #576 (comment)

The problem is that public bounty pages/API can show awards remaining even when pending pay_bounty or close_bounty proposals mean maintainers have already cut off new accepted claims for that round. This can send contributors into work that is no longer practically payable.

Reward

250 MRWK for one accepted implementation.

Acceptance criteria

A qualifying PR must make public bounty availability less misleading when pending treasury proposals affect a bounty. It should include the relevant public API and UI surfaces, with tests.

Expected shape:

  • expose or display effective availability for a bounty after pending payout and close proposals are considered
  • make pending payout/close state visible enough that contributors and agents can tell when visible awards are already practically consumed or the bounty is pending closure
  • update bounty list/detail behavior or wording where needed so awards_remaining is not interpreted as freely claimable capacity when pending proposals cover the remaining slots
  • keep actual payout and treasury proposal rules unchanged
  • include regression tests for pending payout, pending close, and normal open-bounty cases

Evidence or tests required

Out of scope

  • no global cap changes
  • no bypassing the treasury proposal delay
  • no automatic acceptance or payment changes
  • no speculative MRWK value, bridge, exchange, liquidity, cash-out, or payout claims
  • no broad dashboard rewrite unless directly needed for this availability signal

Duplicate and stale work rules

Duplicate work is judged by the first useful, reviewable PR that meets the criteria after this bounty becomes live. Claims before the proposal executes do not reserve the bounty. Stale or overlapping PRs may be closed if a better or earlier accepted implementation covers the same behavior.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions