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

The bounty board maintains a listing of all open bounties across Tari repositories. It automatically scans issues across all repositories in the tari-project GitHub organization once daily for those tagged by repository maintainers with the bounty label and an appropriate sizing label, as described in this table:

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:

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

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 having a maintainer create a new issue for the contribution and tagging it with the appropriate tags as described in the 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.

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

Contributions which don't involve code or which have already been merged have a special repository that allow us to follow the standard process without any code changes to the standard repositories. These use the special contributions repository. Upon request by a Core Contributor or the council, the bounty program administrator (at the time of writing, Possum, who is metalaureate on GitHub) may create a task on the repository and tag the issue with the appropriate bounty tags as described in the bounty process overview.

The person being awarded the bounty must then create a Pull Request following the pattern of previous pull requests in the repository, and using the Fixes #XXX line in the PR description as described in the bounty process overview. The bounty administrator can then merge this pull request, and your payout will proceed as described in the overview.