How We Built a Safe GitHub Bounty Lifecycle for MyZubster

MyZubster is expanding into a network of interconnected repositories, services, automation, hardware projects, AI components, and contributor workflows. With this growth, managing bounty workflows in a secure and automated manner became a top priority. To prevent treating GitHub events as proof of payment, verification, or settlement, the development team implemented a real-time GitHub bounty lifecycle system.

The bounty lifecycle follows a specific order: PROPOSED → VALIDATED → APPROVED → FUNDED → ACTIVE → SUBMITTED → UNDER_REVIEW → VERIFIED → REWARD_RECORDED → SETTLEMENT_PENDING → SETTLED. The critical aspect is that GitHub automation only controls a small portion of this process. GitHub can automatically move a bounty through APPROVED → assignment → ACTIVE → linked PR → SUBMITTED → review → UNDER_REVIEW, but it stops there.

To ensure seamless integration across MyZubster's 17 first-party repositories, the team configured repository webhooks for three key events: issues, pull_request, and pull_request_review. The central endpoint receiving these webhook deliveries is POST /api/github-bounties/webhook. The backend, built with Node.js and Express, validates GitHub webhook signatures using X-Hub-Signature-256 with an HMAC-SHA256 secret. Any unsigned requests are rejected.

During the deployment process, a surprising bug was discovered: PM2 was running with an outdated environment variable. This issue caused GitHub webhook deliveries to return 401 Unauthorized, effectively disabling the real-time automation layer. Restarting the application with the updated environment variable resolved the problem, highlighting that secrets are not just a storage issue, but also a process lifecycle concern.

To further strengthen the system, the team implemented end-to-end testing using a temporary bounty with type:bounty, status:approved, reward:none, and evidence:required. This test exercised the bounty lifecycle automation without involving any financial state. The testing process involved assigning the issue, creating a non-draft pull request, submitting a pull request review, and moving through the various stages: ACTIVE → SUBMITTED → UNDER_REVIEW.

The team emphasized that GitHub events do not automatically result in status:verified, status:reward-recorded, or settlement:* changes. Merely merging a repository does not equate to bounty verification or payment completion. The system remains separate, treating MYZ as an internal platform accounting/reward unit, and external assets such as XMR or other tokens require independent settlement verification.

The next step in the MyZubster roadmap is to introduce safe auto-merge for eligible bounty pull requests. However, this will not be a generic system that blindly approves and merges PRs. Eligible PRs will require conditions such as a green CI, complete required checks, minimum approved reviews, no requested changes, no blocking labels, no sensitivity:high, and no review:manual.

For multi-review bounties, at least two independent approvals will be required before automatic merge becomes possible. Branch protection and repository rulesets will help enforce these conditions.

Despite these advancements, the architecture maintains a hard boundary between merge and payment: AUTO MERGE → code integrated → STOP. This boundary ensures that merge does not automatically result in verification, reward recording, or settlement. Each of these stages remains separate and distinct, ensuring a safer and more secure bounty lifecycle system.