BountyMesh

Inspiration

Programs like Google Summer of Code and LFX Mentorship prove something important: when open-source contributors get paid, they show up, learn fast, and ship real work. We've contributed to open source ourselves, and the pattern is clear.

But those programs are seasonal, application-based, and have limited slots. Outside them, almost every fix is unpaid. The bounty platforms that try to fill the gap pay on merge, and a merge isn't proof of anything: the fix can still break production, or the test can be quietly weakened to make it "pass."

Mentorship programs get one thing right: payment follows an evaluation, not a click. We asked: what if every funded issue got that evaluation automatically, year-round, by the platform the code already lives on?

What it does

BountyMesh turns any GitLab issue into a paid, verified task. Think of it as a mentorship evaluation for a single fix, run by GitLab instead of a calendar.

Fund. A maintainer funds an issue that has a protected acceptance test. The money is held in a ledger (PayPal sandbox), with fees grossed up so the contributor gets the full amount.
Contribute. Anyone forks the project and opens a merge request. No application, no season.
Review. GitLab Duo Code Review comments on the change, and our custom Duo flow bountymesh-review checks it against the issue's acceptance criteria, then posts one PASS/FAIL verdict tied to the exact commit.
Gate. bounty-gate checks funding, scope (.bountymesh.yml), the payout limit and the verdict. The acceptance test always runs from the target branch, so contributors can't rewrite it. SAST and secret detection run on every MR.
Ship. After merge, the main pipeline re-verifies the bounty, packages the app, deploys to staging with no traffic, probes it, and waits for a maintainer to click promote. Production is probed, and a failure rolls back automatically. A GitLab Release records what shipped.
Pay. The platform re-checks everything server-side (verify report, who promoted, the production probe, changed files) and only then sends the payout. The ledger moves to SETTLED.

Autonomy level: Assisted. Agents and pipelines do the work; a maintainer approves the merge and the production promote, the same two decisions a mentor would want to own.

It's built for maintainers who want help on specific issues without paying for fixes that don't hold up, and for contributors (especially students between mentorship cycles) who want paid, real-world work with clear acceptance criteria and guaranteed payment when the work is good.

In the demo, issue #18's contributor followed a Duo suggestion that went beyond the issue. bountymesh-review failed it, exactly like a mentor holding a mentee to the agreed scope. The contributor fixed it, the pipeline caught a formatting slip, the review passed, and the bounty settled after production passed. We also attacked it ourselves: an MR that weakened the protected test was blocked (!24), and one hiding a prompt injection for the AI reviewer got a FAIL (!26).

How we built it

GitLab Duo Agent Platform: Duo Code Review; a custom flow with its own service account (Mention and Assign-reviewer triggers); the Fix CI/CD Pipeline flow on failed pipelines; Apply suggestion; Sessions.
GitLab CI/CD: MR pipeline (bounty-detect, bounty-gate, acceptance, lint/test, SAST, secret detection) and main pipeline (bounty-verify, package, deploy-staging, probe-staging, manual promote, probe-prod, rollback, settle-notify, release-notes, release).
Google Cloud: Cloud Run for the platform and the demo app, Firestore for the ledger, Artifact Registry, Workload Identity Federation from GitLab OIDC.
Platform: Python, FastAPI, NiceGUI with AG Grid (filters, sort, pagination, pinned totals, CSV export, dark mode), PayPal Orders v2, Payouts and webhook verification in sandbox.

Challenges we ran into

Trusting an AI verdict with money on the line. The gate only accepts a verdict from the configured service account for the exact head SHA, with run limits per commit and per MR, and the server re-checks it before paying.
Two AI reviewers can disagree. Duo suggested a reasonable change that wasn't in the issue; the bounty reviewer correctly held the contributor to the written terms.
Fork contributors. Duo doesn't auto-review fork MRs, and new accounts need identity verification, so maintainers re-add the reviewer and run fork pipelines in the parent project.
Our own bugs. Duo caught a fail-open deploy check in our pipeline, and SAST caught an SSRF risk in our probe script.

Accomplishments that we're proud of

A real end-to-end run: review, gate, merge, staging, promote, production probe, release, and a settled sandbox payout.
8 of 9 DevSecOps stages automated (Configure is partial).
Cheat attempts (weakened test, prompt injection) caught on camera.

What we learned

Mentorship programs work because payment follows evaluation. Automating that evaluation means binding the AI reviewer to the issue's written terms, and re-checking every decision on the server before money moves.

What's next for BountyMesh

Today BountyMesh runs on a single repo, one project per deployment. The ledger is already keyed by gitlab:{project_id}:{iid}, so the next step is many repos on one platform: a CI/CD Catalog component (one include line per repo) and the review flow published in the AI Catalog. A natural pilot is an open-source organization that already runs mentorships, funding issues between cohorts.

Honest limits today: sandbox payments only; direct pushes to main can't be blocked on our GitLab plan; Duo doesn't auto-review fork MRs, so a maintainer re-adds the reviewer and runs new contributors' pipelines; and the Configure stage is partial. BountyMesh isn't affiliated with Google Summer of Code or LFX Mentorship.