🔍 I Reviewed 23 Crypto Bounty Programs — Here Are the Red Flags Nobody Talks About
TL;DR: Most bounty program guides teach you how to submit PRs. None of them teach you how to spot the programs that will never pay you. After wasting weeks on dead-end bounties, I built a checklist. Here it is — with real names, real numbers, and zero sugarcoating.
I Wasted Weeks on Bounties That Never Paid
Let me save you some time.
Three months ago, I went all-in on crypto bounty programs. The pitch is seductive: find open issues, submit a pull request, get paid in tokens. Simple, right? I thought so too. I found repos with flashy bounty labels, reasonable-sounding maintainers, and reward amounts that made my eyes light up.
I submitted PRs. I waited. And then... nothing.
No merge. No review. No payment. Just a closed PR and a lesson I had to learn the hard way.
After that experience, I went deeper. I didn't just chase bounties — I started auditing them. I reviewed 23 bounty programs across GitHub, looking at everything from PR merge rates to on-chain payment history. What I found was uncomfortable: a significant chunk of these programs are somewhere between "poorly managed" and "outright scam."
This isn't a "how to get rich with bounties" post. This is the post I wish someone had written before I started.
The Problem With Bounty Guides
Search for "crypto bounty programs" and you'll find dozens of guides. They all say the same thing:
- Find a bounty on GitHub or a bounty board
- Read the issue description
- Submit a PR
- Get paid 🎉
Step 4 is where the fantasy collapses. Nobody talks about what happens when the maintainer ghosts you. Nobody mentions that "merged" doesn't mean "paid." And absolutely nobody warns you that some of these programs are designed to harvest free labor.
The bounty ecosystem has a verification problem. Most contributors treat "PR submitted" as "work done" and "PR merged" as "money earned." Both assumptions are dangerous.
I learned this the expensive way.
🚩 The Red Flags Checklist
After reviewing 23 programs, here's the checklist I now use before spending a single minute on any bounty. Memorize it. Bookmark it. Tattoo it on your forearm if you have to.
🚩 Star Count < 5 With Dozens of Open Issues
This is the first thing I check, and it takes three seconds.
A repo with 1 star and 47 open issues isn't an "early-stage project with lots of opportunity." It's a ghost town with a to-do list. Real projects with real budgets attract at least some community attention. When I see a bounty-laden repo that can't crack double-digit stars, I close the tab.
The math is simple: if a project can't attract GitHub stars, it probably can't attract funding. And if it can't attract funding, where exactly is the bounty money coming from?
🚩 PR Close Rate > 80% With Zero Merges
This one requires actual investigation, but it's the most reliable red flag I've found.
Here's how it works: a repo posts bounties, contributors submit PRs, and the maintainer closes every single one without merging. Sometimes there's a comment like "not quite what we're looking for." Sometimes there's nothing. The effect is the same — free labor extracted, zero compensation delivered.
I use the GitHub API to check this. A quick query to /repos/{owner}/{repo}/pulls?state=closed tells you everything. If you see a wall of closed PRs and the merged_at field is null on all of them, run.
🚩 Bounty Amounts That Are Too Good to Be True
"$500 for a documentation fix." "1000 RTC for a simple bug patch."
When bounty amounts are wildly disproportionate to the complexity of the work, there are two possibilities: either the project is flush with cash and desperate for contributors, or the tokens are worthless and the bounties will never be paid.
In my experience, it's the second one about 90% of the time. A token with no liquidity, no exchange listing, and no on-chain transaction history isn't a payment — it's a fantasy. Always check if the token actually trades somewhere before you invest hours into a bounty.
🚩 Repository Created Less Than 3 Months Ago
New repos aren't inherently suspicious. But new repos with aggressive bounty programs? That's a different story.
Establishing a bounty program requires infrastructure: a budget, a payment process, a review workflow, and maintainers who actually show up. A project that's 6 weeks old rarely has any of that sorted. What they do have is enthusiasm, a whitepaper full of buzzwords, and a burning desire for free code.
I give new projects a 3-month minimum before I'll consider contributing for bounties. If the project is still active, still paying, and still merging PRs after 90 days, I'll take a closer look.
🚩 Maintainers Who Never Respond
Before I submit any PR, I leave a comment on the issue. Something simple: "Hey, I'd like to work on this. Any guidance?"
If I don't get a response within a week, I move on. Not because I'm impatient, but because a maintainer who can't reply to a comment definitely isn't going to review my PR, merge it, or process a payment.
Silence is the loudest red flag in open source.
🚩 KYC Requirements for a $50 Bounty
I've encountered bounty programs that require Know Your Customer verification — government ID, proof of address, the works — for bounties worth less than a nice dinner.
Look, KYC has its place. Regulated financial services need it. But a GitHub bounty program asking for your passport to pay you $30 in a token that doesn't trade on any exchange? That's not compliance theater — it's data harvesting with extra steps.
My rule: if the bounty is under $500 and they want KYC, I'm out. No exceptions.
Case Studies: Four Programs, Four Lessons
Theory is nice. Here's what these red flags look like in practice.
Case Study 1: RustChain (Scottcjn) — The "Merged But Never Paid" Trap
The setup: RustChain looked legitimate. Multiple repositories under the same org (rustchain-bounties, Rustchain, rustchain-mcp). Active issue creation. Bounty labels with specific reward amounts.
What happened: I submitted a PR. It got merged. I felt that little rush of accomplishment — I did it, I earned a bounty. Then I checked the wallet.
Balance: 0.0 RTC.
I checked again. And again. Used the blockchain explorer. Used the API. Nada. The PR was merged, but no payment was ever sent. When I dug deeper, I found that across all three RustChain repositories, the pattern was identical: merge the PR, never pay the bounty.
The lesson: A merged PR is not proof of payment. I cannot stress this enough. The only proof of payment is a transaction hash and a wallet balance that actually changed. RustChain taught me the most expensive lesson in this entire investigation: PR merged ≠ paid.
Case Study 2: Claude-Builders-Bounty — The Numbers Don't Lie
The setup: This one was almost impressive in its audacity. Thirty pull requests submitted by various contributors. Every single one closed. Zero merged. The repository had exactly 1 star.
What happened: I didn't submit to this one — I investigated it after seeing the pattern. Thirty contributors put in real work. Thirty contributors got nothing. The maintainer closed PRs with vague feedback or no feedback at all. The single star? Probably their own account.
The lesson: When you see a repo with a 100% PR close rate and essentially zero community engagement, you're not looking at a tough review process. You're looking at a content mill that uses bounty labels to attract free labor. The numbers tell the story: 30 PRs closed, 0 merged, 1 star. That's not a bounty program. That's a scam with a GitHub account.
Case Study 3: La-Tanda-Web — The New Account Special
The setup: Found this through a bounty aggregator. Looked promising at first glance — decent issue descriptions, reasonable bounties.
What happened: Before submitting, I did what I always do now: I checked the account. The GitHub organization had been created less than 30 days prior. The maintainer accounts were equally fresh. When I submitted a PR anyway (for science), a bot closed it within 24 hours with an automated message about "account verification requirements."
The lesson: Brand-new accounts posting bounties are a gamble. The repos might be legitimate experiments, but the odds of actually getting paid are close to zero. A 30-day-old account hasn't had time to establish trust, secure funding, or build a payment workflow. They're asking you to trust them before they've earned it. New account + bounties = skip.
Case Study 4: Expensify — Legitimate But Impossible
The setup: Expensify is a real company. Not a scam. But their open source contributions tell an important story.
What happened: Eight PRs from external contributors. Eight closed. Zero merged. Maintainers were professional — they left comments, explained reasoning. But the bar was so high that outsiders couldn't clear it.
The lesson: Not every closed-PR situation is a scam. Some programs are legitimate but hostile to outside contributors. Before investing time, check if external PRs have ever been merged. If no, you're wasting your time.
How to Actually Verify a Bounty Program
Enough doom and gloom. Here's the practical toolkit I use to separate real programs from time sinks.
1. Check On-Chain Payment History
If a bounty program pays in crypto, there should be a blockchain record. Find the project's treasury wallet (usually in their docs or a pinned issue) and look it up on a block explorer.
What you're looking for:
- Regular outgoing transactions to different addresses
- Transaction amounts that roughly correspond to bounty sizes
- Transaction dates that align with merged PR dates
No blockchain record = no payments. Period.
2. Use the GitHub API to Check PR Merge Rates
This takes 30 seconds and tells you more about a program than any marketing page.
# Get the last 100 closed PRs
curl -s "https://api.github.com/repos/{owner}/{repo}/pulls?state=closed&per_page=100" | \
jq '[.[] | {number, title, merged_at}]'
Count how many have merged_at: null. If it's above 80%, that's a program that closes PRs without merging them. Could be high standards. Could be a scam. Either way, the odds are against you.
For a quicker check:
# Count merged vs closed
MERGED=$(curl -s "https://api.github.com/repos/{owner}/{repo}/pulls?state=closed&per_page=100" | jq '[.[] | select(.merged_at != null)] | length')
TOTAL=$(curl -s "https://api.github.com/repos/{owner}/{repo}/pulls?state=closed&per_page=100" | jq 'length')
echo "Merge rate: $MERGED / $TOTAL"
If the merge rate is 0%, don't walk away — run.
3. Audit the Issue History
Click on the bounty-labeled issues and scroll through the comments. You're looking for:
- Maintainer responses: Are they engaging with contributors or shouting into the void?
- Completed bounties: Can you find any issue labeled "bounty" that was actually closed with a merged PR and a payment confirmation?
- Contributor feedback: Has anyone commented "received payment" or posted a transaction hash?
If the issue history is a graveyard of abandoned conversations and closed-but-unpaid bounties, that tells you everything you need to know.
4. Check the Maintainer's Profile
Click on the maintainer's GitHub profile. Look at:
- Account age: Less than 3 months = proceed with extreme caution
- Contribution history: Do they contribute to other projects, or is this their only repo?
- Other projects: Are they running bounties elsewhere? What's the track record?
A maintainer with a 2-year-old account, contributions across multiple projects, and a history of merged PRs is categorically more trustworthy than a 3-week-old account with a single bounty-laden repo.
5. Search for Payment Proof
Search for evidence that the program pays: check Discord/Telegram for payment confirmations, search Twitter for "{project} bounty paid", look for blog posts where contributors share their experience. No payment proofs = data.
What Actually Works: Signs of a Legitimate Program
After reviewing 23 programs, I found that legitimate bounty operations share common traits:
Transparent payment history. Good programs don't hide their payments. They publish transaction hashes, maintain a public ledger of bounties paid, or at minimum have community members who can vouch for getting paid.
Active, responsive maintainers. They reply to comments. They review PRs within a reasonable timeframe. They leave constructive feedback on closed PRs instead of just hitting the close button.
Reasonable bounty amounts. The rewards match the complexity of the work. A documentation fix pays less than a core feature implementation. The amounts are denominated in tokens that actually trade on real exchanges.
Established track record. The project has been around for more than a few months. There's a history of merged PRs from external contributors. The GitHub repo shows genuine development activity beyond bounty issues.
Clear contribution guidelines. The CONTRIBUTING.md file exists and makes sense. There's a defined process for claiming bounties, submitting work, and receiving payment. The rules are written down, not made up on the fly.
Community presence. There's a Discord, a forum, or some space where contributors talk to each other. You can find people who've actually been paid. The community is small but real.
The Iron Rules
Let me distill everything into three rules I now live by:
Rule #1: PR merged ≠ paid. A merged PR is a necessary condition for payment, not a sufficient one. The only thing that counts as payment is a confirmed transaction to your wallet. Everything else is just noise.
Rule #2: Wallet balance is the only scoreboard. I don't track "PRs submitted" or "issues resolved" as metrics anymore. I track one thing: did my wallet balance change? If the answer is no, I didn't earn anything. Submitted ≠ earned.
Rule #3: Trust the numbers, not the marketing. A slick README and a Medium article don't mean anything. PR merge rates, on-chain transactions, community engagement, and account history tell you the real story. Always verify before you invest time.
Final Thoughts
Not all bounty programs are scams. Real opportunities exist, and some developers make meaningful income. But the ecosystem is polluted with programs ranging from negligently managed to deliberately exploitative.
The bounty space reminds me of early freelancing platforms — massive opportunity, massive risk, little protection. The difference? Freelancing platforms have dispute resolution. With GitHub bounties, your only recourse is a strongly-worded comment no one will read.
Do the homework. Check the chain. Verify merge rates. Look for payment proof. If something feels off, trust that instinct.
Your time is worth more than a closed PR and an empty wallet.
I reviewed 23 programs so you didn't have to. If this saved you time, share it with someone who's about to submit their first bounty PR. They'll thank you later.
Got your own bounty horror story? Drop it in the comments. The more data we share, the harder it becomes for scam programs to operate.
Tags: #crypto #bounty #opensource #web3 #github
💡 Further Reading: I experiment with self-hosting, privacy stacks, and open-source alternatives. Find more guides at Pi Stack.
Top comments (0)