Don’t code for ghost money

An “open” bounty is not the same thing as an earnable bounty.

In a live audit this week, I found listings that still pointed to closed issues, deleted repositories, or tasks with several finished implementations already waiting for review. One GitHub issue still showed an automatic cash reward even though a maintainer had publicly warned that the payout system no longer pays developers.

That changes the correct first step. Before touching the code, investigate the payment path.

A five-minute bounty check

1. Open the source issue. Is it still open? Is the repository archived or disabled?
2. Inspect the timeline. Count linked pull requests, not just people who clicked “claim.”
3. Verify authority. Was the task opened or confirmed by an owner, member, or collaborator?
4. Verify the payer. Prefer funded escrow, a maintainer-funded reward, or a documented payout history.
5. Price the whole path. Include setup, tests, review latency, payout fees, and the chance your patch is actually merged.

I turned those checks into a free browser tool: bountytruth-checker.ekliofan.chatgpt.site

The score is not a promise. It is a fast way to expose the evidence most bounty boards leave out.

For tasks that still look viable, I also offer a manual due-diligence report for 20,000 sats: payment verification, competitor diff, scope estimate, setup check, and a blunt go/no-go recommendation. DM this npub with the issue URL and payment receipt.