Bounty Program Guidelines

[Josh-XT]

Bounty Program Guidelines

Token System

• All bounty rewards are paid in AGiXT tokens
• Anyone can create and stake tokens on bounties
• Additional stakeholders can increase bounty value at any time
• Token distribution follows the review-based percentage system

Bounty Creation & Staking

• Any community member can create a bounty
• Initial creator sets the base token stake
• Additional staking rules:
  • No maximum stake limit
  • Stakes are locked until bounty completion
  • Multiple stakeholders can contribute
  • Stake amounts are public
  • Stakes cannot be withdrawn once committed

Core Principles

The bounty program is designed to:

• Ensure high-quality code submissions
• Reward thorough code reviews
• Encourage developers to test their work before submission
• Maintain fairness in bounty distribution
• Create accountability for both developers and reviewers

Bounty Lifecycle

1. Claiming a Bounty

• Only one bounty can be worked on per branch
• Developers must create a feature branch from main for each bounty
• A developer can only claim a bounty if they have no active strikes
• Active strikes expire after one month
• Current total token stake must be visible when claiming

2. Development Phase

• All code must be tested locally before submission
• Changes should address the full scope of the bounty
• Documentation must be updated where applicable
• Tests should be added or updated as needed

3. Pull Request Submission

• Pull requests should only be opened when work is complete
• Incomplete work must be marked as draft
• The PR description must reference the bounty being claimed
• Include a checklist of testing performed
• Document any necessary deployment steps

4. Review Process

• Reviews must be conducted by a different team member
• Reviewers must:
  • Read and analyze all code changes
  • Run the application locally
  • Test the changes against the bounty requirements
  • Verify no unintended side effects
  • Document any issues found

Reward Distribution

Initial Review (First Pass)

• Reviewer receives 10% of total staked tokens
• Developer retains 90% if changes are approved
• Review must be thorough and documented

Failed Reviews

• Each failed review costs the developer 30% of total staked tokens
• The same or different reviewer can perform subsequent reviews
• Failed review criteria:
  • Bugs found during testing
  • Incomplete implementation
  • Breaking changes
  • Security vulnerabilities
  • Major performance issues

Strike System

• Developer receives a strike if they lose 100% of the tokens
• Three strikes result in a one-month suspension from claiming bounties
• Strikes expire after one month
• Strike count is tracked per developer
• Three suspensions result in a permanent ban from the bounty program

Edge Cases

Reviewer Takes Over

If a developer loses 100% of the bounty:

1. The reviewer can choose to:
   • Complete the bounty themselves (receiving 100% of staked tokens)
   • Close the PR (developer receives a strike)
2. If completing the bounty:
   • Must create a new PR from the existing branch
   • Cannot receive additional review penalties
   • Must complete within original timeframe

Disputed Reviews

• Disputes should be raised to the team lead
• Team lead can:
  • Validate or invalidate the review
  • Adjust token distribution
  • Reset review status
  • Remove strikes if warranted

Stake Changes During Development

• Additional stakes can be added while work is in progress
• Token distribution percentages apply to total final stake
• All stakeholders must be clearly listed on the bounty
• Stake increases must be announced in the PR thread

Quality Standards

Code Requirements

• Follows project style guide
• Includes appropriate tests
• Updates documentation
• No breaking changes
• Maintains or improves performance

Testing Requirements

• Unit tests for new functionality
• Integration tests where applicable
• UI testing for frontend changes
• Performance testing for critical paths
• Security testing for sensitive features

Until we can set up a review board, I will have the final answer in the event where these guidelines are insufficient to handle a situation and update the guidelines accordingly.