**This is an old revision of the document!**
Bounties
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.
Bounty Process Overview
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:
| Bounty size | GitHub Tag | Reward Size |
|---|---|---|
| Small | bounty-S | 15,000 XTM |
| Medium | bounty-M | 60,000 XTM |
| Large | bounty-M | 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:
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 two1).
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. 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.