To encourage community participation and reward good work on the protocol, bounties are established from time to time. A Tari Improvement Proposal 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.

The bounty board lists all open bounties across Tari repositories. A scanner checks a configured set of repositories in the tari-project GitHub organization about once an hour for issues that a repository maintainer has tagged with a sizing label:

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. 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.

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.

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. 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 section.

Contributions that involve no code, or code already merged elsewhere, are rewarded through the 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, 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.