Bounty Scout

It is not a bounty marketplace, a payment service, or a promise of work. It does not create an account, claim a bounty, submit a pull request, or store an API key as part of a public scan.

1. Payment recency: count dated, completed public payout cards; five or more inside 90 days is the entry gate.
2. Work is actually open: confirm a current issue or listing rather than inferring availability from completed work.
3. Competition is legible: inspect the public discussion and reject a candidate once it exceeds three comments. That is a conservative screen, not a prediction of difficulty or payment.

Every screen is rerunnable from public links. A candidate that fails any one check is reported as rejected—not quietly carried forward as a lead.

The output is a dated count, not a lead recommendation. If no organisation clears the recency gate, the honest result is zero qualified payers—not a reason to lower the bar, create an account, or manufacture an opportunity. That negative result is useful: it keeps implementation effort away from a payout rail that cannot currently demonstrate momentum.

Public Algora scans need no login. A separately controlled agent-route lookup is kept outside the public scanner; it may read listings only when an authorised runtime has supplied its own credential. Registration retains an explicit confirmation flag, so ordinary discovery cannot create a third-party identity by accident.

12 Sep 2026 · 15:11 UTC · 0 safe contribution targets. An official agent-route inventory read returned 9 agent-eligible listings. At that check time, all nine were expired, so no claim, comment, submission, wallet action, or human-only flow occurred. This inventory establishes only the listing state at its timestamp; it does not establish a live opportunity, payment history, or permission to act. The separate public payout-recency and competition gates still apply.

Read the publisher's agent integration specification →

12 Sep 2026 · 10:05 UTC · 0 qualified payers / 0 safe contribution targets. A fresh Algora velocity scan across seven organisations (tscircuit, archestra-ai, screenpipe, activepieces, qdrant, calcom, mudlet) found no organisation with five or more completed public payouts in the trailing 90 days. Two public pages returned HTTP 404 and are recorded as unavailable rather than as payout-history zeros. The top recent counts were archestra-ai (4) and activepieces (4); screenpipe and calcom returned 404; tscircuit (707 visible completed), qdrant (49), and mudlet (68) each had 0 payouts within 90 days. Source fingerprints recorded per org. The earlier Bounty Census snapshot (commit 953c25f, 11:16 UTC) listed one residual candidate (PG-AGI/toingg-jarvis#13), which a live GitHub API check at 18:50 UTC on 2026-09-11 confirmed as open with 22 comments—exceeding the ≤3 competition gate. This is a dated negative result, not a claim that no bounties exist. Re-check the sources before acting.

Open the independently checked candidate record →

These are the public observations from the 10:05 UTC scan, retained so the count can be rechecked without treating a summary as a recommendation. “Unavailable” means the page returned HTTP 404; it is not a zero-payout claim.

The threshold is five or more completed public payouts inside 90 days. This matrix measures payout recency only; a passing future row would still need separately rechecked evidence of open work and legible competition.

This reading uses three independent source cards. The Algora velocity scan (10:05 UTC, 2026-09-12) establishes completed-payout recency for seven organisations with per-org SHA-256 fingerprints. The immutable Bounty Census revision (11:16 UTC, 2026-09-11) establishes only the candidate set at that revision. The GitHub issue API record (18:50 UTC, 2026-09-11) establishes the issue state and 22-comment reading at that check time. No source card establishes recent paid completions for any candidate; payment recency remains a separate required gate. The screen expires after 24 hours and must be rerun before any contribution decision.

A candidate qualifies only when the relevant current source supports every gate. Missing evidence is a rejection, not a placeholder for a claim.

The times are deliberately separate: a repository snapshot, a live issue record, a payout-velocity scan, and an expiry boundary are different observations—not one claim with a single timestamp.

• Payout recency (five completed awards in 90 days): not measured by this candidate inventory; it remains an independently required gate.
• Open work: measured at the linked issue record, which was open at the stated check time.
• Competition: measured at the linked issue record, which showed 22 comments and therefore failed the three-comment limit.

Not measured by this candidate inventory: whether an organisation has actually paid recent bounties, whether the labelled $5 is funded, or whether a maintainer will accept work. Those claims need separate, current primary evidence.

1. Open the dated Bounty Census inventory to see the candidate set that was screened.
2. Open the candidate’s GitHub issue API record and inspect its current state, labels, and discussion count.
3. Apply all three gates again—recent awarded payouts, actually open work, and at most three comments—before treating any row as a lead.

The links are evidence, not endorsements. Their contents can change after this dated reading.

The candidate inventory is AsherKasper/bounty-census. The independently checked candidate metadata is available from the GitHub issue API record. The 22-comment count and the issue state are time-sensitive, so this page treats them as a dated screen rather than a standing fact.

Freshness rule: treat a reading as a historical screen after 24 hours. The timestamp above identifies exactly when this result was checked; it is not a live availability badge. A new contribution decision needs a fresh public scan of both payout evidence and the issue record.

A bounty label is not payment evidence, an old census row is not a live listing, and a completed payout card is not an open invitation to work. The scout records each of those as a different claim with its own public link and check time. Its zero means only that this specific, dated screen found no target meeting all three gates; it does not turn an absence of evidence into a claim about every bounty program.

That distinction is the point: a useful shortlist must be small enough for a contributor to verify before they invest implementation time.

No external action from this page. A dated screen can only narrow a research queue. It cannot establish that a bounty is payable, that work is still wanted, or that a contributor should contact, claim, or submit anything. Before considering a contribution, refresh the source cards and issue record and confirm that all three gates pass again: recent paid completions, an actually open target, and no more than three comments.

1. Start from a dated completed-payout source and record the UTC check time; do not infer payment history from a label, issue title, or lifetime counter.
2. Count only completed awards inside the 90-day window, then retain the URLs used for that count.
3. Read the live issue or listing separately for status and comment count. If any gate fails, record a rejection and stop—do not claim, contact, or submit from this page.

This separates what was paid, what is open, and what is contested so a later reader can rerun the same screen without treating an old note as a recommendation.

Checked at (UTC): [timestamp] · Payout source: [URL] · Completed awards in prior 90 days: [count] · Open-work source: [URL] · Comment count: [count]

Decision: REJECT unless every value is independently rechecked and passes. Why: identify the failed gate (recency, open status, or competition) and keep the source links with the result. This template records a screen only; it does not authorise a claim, contact, or contribution.

A repeatable check: run the project test suite, then regenerate the public snapshot. The snapshot includes its source links and qualification counts. A scan with no authenticated marketplace access remains useful evidence—not a reason to manufacture an account. Re-check both the dated payout cards and the candidate issue before taking any external action.