Differences

This shows you the differences between two versions of the page.

--- processes:bounties [2026/09/24 14:53] – created fox
+++ processes:bounties [2026/09/28 18:28] (current) – possum
@@ Line 1: / Line 1: @@
 # Bounties
-To encourage community participation and reward good work on the protocol, bounties are established from time to time. A [Tari Improvement Proposal](https://rfc.tari.com/TIP-0001_tari_improvement_proposals) describing policy and budget elements for bounties is planned, but not yet written. This document describes the **process** of how bounties are tracked and rewarded. This document is for reference to all who are interested in claiming bounties and anyone who may be administrating bounties, and should be updated as the methods change.
+To encourage community participation and reward good work on the protocol, bounties are established from time to time. A [Tari Improvement Proposal](https://rfc.tari.com/TIP-0001_tari_improvement_proposals) describing policy and budget elements for bounties is planned, but not yet written. This document describes the **process** of how bounties are tracked and rewarded. It is for reference to anyone interested in claiming bounties and anyone administering them, and should be updated as the methods change.
 ## Bounty Process Overview
-[The bounty board](https://github.com/tari-project/bounties) maintains a listing of all open bounties across Tari repositories. It automatically scans issues across all repositories in the [tari-project GitHub organization](https://github.com/tari-project/) once daily for those tagged by repository maintainers with the `bounty` label and an appropriate sizing label, as described in this table:
+[The bounty board](https://github.com/tari-project/bounties) lists all open bounties across Tari repositories. A scanner checks a configured set of repositories in the [tari-project GitHub organization](https://github.com/tari-project/) about once an hour for issues that a repository maintainer has tagged with a sizing label:
 | Bounty size | GitHub Tag | Reward Size |
@@ Line 11: / Line 11: @@
 |Small|`bounty-S`|15,000 XTM|
 |Medium|`bounty-M`|60,000 XTM|
-|Large|`bounty-M`|150,000 XTM|
+|Large|`bounty-L`|150,000 XTM|
 |Extra Large|`bounty-XL`|450,000 XTM|
-Bounties require a Pull Request with a description that GitHub recognizes will fix the issue. The easiest way to do this is to add the line:
+The sizing label is what the scanner keys on. Only repository maintainers can apply labels, so an issue anyone can open only becomes a bounty when a maintainer labels it. If your repository is not on the bounty board, ask the bounty administrator to add it.
-`
+To claim a bounty, open a Pull Request that references the issue. The standard way is to add the line:
+```
 Fixes #XXX
-`
+```
-Where `XXX` is the issue number somewhere in the PR description. Upon merge, the bounty is queued for reward. **You should include your XTM payment address in the PR description as well.** The bounty program administrator will then have the award appear on their dashboard, and will perform a payout run sometime within the next week or two[^1].
+where `XXX` is the issue number, somewhere in the PR description. **Include your XTM payout address in the PR description as well**, on its own line. If no address is found when the PR merges, the bounty bot will post a comment on the PR asking for one. Only an address posted from the PR author's own GitHub account is accepted; addresses posted by anyone else are ignored.
+Once a maintainer merges the PR, the bounty is queued for payout. The bounty administrator sees it on their dashboard, confirms the payout address, and runs a payout batch, usually within a week or two. Payouts are recorded manually; the bot queues, a person pays.
 ## Retro Bounties
-Contributors may request a retro bounty for a contribution, or maintainers may advocate for one on a contributor's behalf. The process for a retro bounty varies depending on whether a pull request has already been merged for the contribution. If a pull request is still open, a retro bounty can be added by creating a new issue for the contribution and having a maintainer tag it with the appropriate tags as described in the [bounty process overview](#bounty-process-overview). The contributor should then include the `Fixes #XXX` line also described in that section into the PR description. Once the PR is merged, it is handled as any other bounty.
+Contributors may request a retro bounty for a contribution, or maintainers may advocate for one on a contributor's behalf. There are three routes, depending on the state of the work.
-In the case that a contribution has already been merged, or the kind of contribution isn't a code contribution (such as a vulnerability report without an included fix, or some special community contribution), see the [special contributions](#special-contributions) section.
+**The pull request is still open.** A maintainer creates a new issue for the contribution and applies a sizing label as described in the [bounty process overview](#bounty-process-overview). The contributor adds the `Fixes #XXX` line to the PR description. Once merged, it is handled like any other bounty.
+**The pull request is already merged, in a repository on the bounty board.** A maintainer applies the `retro-bounty` label plus a sizing label (`bounty-S`, `bounty-M`, `bounty-L` or `bounty-XL`) directly to the merged pull request. No issue is needed. The scanner picks it up and queues a payout for the PR author. Note that the labels go on the pull request, not on an issue.
+**The contribution is not code, or was merged somewhere the scanner does not watch** (for example a vulnerability report without a fix, or community work), see the [special contributions](#special-contributions) section.
 ## Special Contributions
+Contributions that involve no code, or code already merged elsewhere, are rewarded through the [special contributions](https://github.com/tari-project/special_contributions/) repository. This lets the standard bounty process run without changes to the main repositories.
+Issues in this repository are created by repository maintainers only, on request from a Core Contributor or the council. The maintainer creates an issue describing the contribution and applies a sizing label. The scanner recognizes only issues carrying one of these labels, and only maintainers can apply them.
+**Do not create issues or pull requests in this repository unless a maintainer has asked you to. Unlabeled issues and unsolicited pull requests are not tracked and will not be paid.**
+Once the issue exists, the contributor opens a Pull Request following [the pattern of previous pull requests](https://github.com/tari-project/special_contributions/pulls?q=is%3Apr+state%3Amerged), with `Fixes #XXX` in the description and their XTM payout address on its own line. A maintainer merges it. The bounty is then queued for payout [as described in the overview](#bounty-process-overview).
-[^1]: Some more details about the dashboard and how it works would be helpful here, as well as details about how the payment process actually works-- This author understand it's somewhat manual.