{
  "id": 1775170,
  "title": "How We Built a Safe GitHub Bounty Lifecycle for MyZubster",
  "url": "https://urgent.news/2026/08/18/how-we-built-a-safe-github-bounty-lifecycle-for-myzubster",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-18T18:39:20.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/danielioni/how-we-built-a-safe-github-bounty-lifecycle-for-myzubster-a2"
  },
  "original_language": "en",
  "account": "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.\n\nThe 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.\n\nTo 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.\n\nDuring 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.\n\nTo 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.\n\nThe 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.\n\nThe 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.\n\nDespite 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.",
  "summary": "How We Built a Safe GitHub Bounty Lifecycle for MyZubster MyZubster is evolving into a distributed ecosystem of repositories, services, automation, hardware projects, AI components, and contributor workflows. As the number of repositories and contributors increased, one problem became increasingly important: How do we automate bounty workflows without accidentally treating a GitHub event as proof…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}