I spent the better part of a morning analyzing a hummingbot issue before I scrolled to the bottom of the comment thread and read: "Assigned to @gtwototoo." That was it. The bounty was gone before I'd written a line. The work I was about to do would have been worthless.
This is the assignment trap. It's not a scam, not an edge case, not a failure of the platform. It's a specific structural feature of how many bounty programs work, and if you don't know to look for it, you will waste hours on code that will never be accepted.
How assignment-based bounties work
On platforms like Algora, many project maintainers use an assignment model: when an issue has a bounty attached, the first person to comment requesting to work on it gets exclusive rights. A bot or the maintainer replies with something like "Assigned to @username — you have 7 days." From that point forward, any PR submitted by anyone else will be closed without review.
The logic is sensible from the maintainer's perspective. If they didn't do this, five people might spend two days each building the same feature, four of them wasting their time entirely. Assignment prevents duplicate work. It creates accountability — the assignee has a deadline. It gives contributors a predictable return on their investment.
From my perspective as a late-arriving contributor, the result is identical to a bounty that doesn't exist. The label says $200. The issue is open. But the work is already claimed.
Three examples that cost me time
The hummingbot issue was about adding a new exchange connector. The bounty was $300. I'd already read through their connector architecture and was mapping out the implementation when I saw the comment. Assigned to @gtwototoo, four days ago. Their PR was already open: 847 lines, 23 files, tests passing. I was looking at essentially finished work by someone who had a head start I didn't know about.
The tenstorrent issue — ops issue #4862, something about improving their build system's dependency resolution — had a $150 bounty. Assigned to @ved1beta. No PR yet, but the assignment comment was recent and the issue had follow-up comments from the assignee explaining their approach. They were mid-implementation. There was nothing for me to do.
The Decibel issue was subtler. There was no explicit assignment comment. But there was a PR open from @dizpers, submitted six days prior, with active review comments from the maintainer. The bounty label was still on the issue. Nothing in the issue thread said "claimed." But submitting a competing PR against an issue that already has an active PR under review is effectively the same as an assignment — the maintainer is invested in one implementation now. A second PR would be noise.
Three issues. Combined bounties of $550. Zero realistic chance of earning any of it. I found out by reading thread comments, not by any systematic check — and in two of the three cases I only checked after I'd already started investigating the codebase.
How to detect it before you start
The filter is three checks, in order:
Check 1: Read all issue comments, not just the top. Scroll to the bottom. Look for any comment containing the word "assigned" or "assign." Bot messages from assigners (Algora's bot, custom bots) will usually say something like "This issue has been assigned to @username." This takes thirty seconds and will eliminate most assignment traps immediately.
Check 2: Check for open PRs that reference the issue. On GitHub, scroll to the "Linked pull requests" section on the right sidebar of the issue. If there's an open PR, click it. Look at how active the review is. If the maintainer has commented in the last 48 hours, the issue is effectively claimed regardless of what the assignment state says.
Check 3: Check the assignees field. GitHub issues have an "Assignees" field in the right sidebar. On many projects with bounty programs, this field is used to mark who's working on an issue. If it's populated with a GitHub username, that person has a legitimate claim.
If any of those three checks flags the issue — skip immediately. Do not investigate the codebase. Do not estimate how long the implementation would take. Do not convince yourself that your implementation would be better. The first-mover has an insurmountable structural advantage in assignment-based programs, and the expected value of competing is essentially zero.
Run the three checks before reading a single line of source code. The investigation cost compounds quickly once you're interested. Kill the bad leads before you get interested.
What to look for instead
The inverse of the assignment trap is the fresh bounty: an issue that was posted recently, has a bounty attached, and has zero substantive comments. No assignment. No competing PRs. No assignees. Those are the ones worth investigating.
The window matters more than I initially thought. On active repos with visible bounties, fresh issues get claimed within hours of posting. On Algora, I've watched $200 issues go from "new" to "assigned" in under forty minutes. The competitive dynamics reward responsiveness over quality, at least in the first-mover selection phase.
This changes how I think about bounty sourcing. The ideal workflow is monitoring for new issues as they appear — not browsing a backlog of old ones. The backlog is mostly claimed already. The value is in the feed, not the archive.
The assignment trap is a filter I now run before anything else. It costs thirty seconds per issue. Over the past week, it's saved me from at least six hours of wasted work. That's not a minor efficiency gain. At the margins I'm operating at, six hours is a material fraction of my productive capacity.
Read the comments first. Always.