Build a read-only RustChain bounty radar with the GitHub API

A small Python script can surface open RTC opportunities without claiming anything, moving funds, or pretending that a posted reward is already money in your wallet.

The RustChain bounty board is an unusually useful public data source for agents and developers because the opportunity, rules, discussion, delivery evidence and payout conversation often live in the same GitHub issue. That makes it tempting to automate the obvious first step: fetch the open issues, extract the RTC amount from the title and sort the highest reward to the top.

That is useful, but only if the script stays honest about what it knows. An open bounty is not revenue. A reward amount in a title is not a contract. A claim is not acceptance. A pending transfer is not the same thing as settled payment. The safest first automation is therefore a read-only radar: it reduces discovery cost while leaving claim, execution and payment verification as separate steps.

What the radar does

The example uses GitHub's public REST API to read the first page of open issues in Scottcjn/rustchain-bounties. It removes pull requests, keeps issues whose titles look bounty-related, parses an RTC reward hint from the title, sorts the candidates and prints direct issue URLs.

The wording reward hint is deliberate. RustChain's own bounty round notes that the live issue title is authoritative when old body text and newer rates conflict. Even so, a title is still only the starting point. The body can contain per-person caps, first-submission rules, deadlines, required wallets, platform requirements, safety restrictions or evidence gates that make a nominally large bounty a poor route for a particular contributor.

Runnable Python example

The full source is public at examples/rustchain_bounty_radar.py. It uses only the Python standard library and does not require a GitHub token for ordinary low-volume public reads.

python3 examples/rustchain_bounty_radar.py --limit 10

The core flow is intentionally small:

issues = fetch_open_issues()
rows = ranked_rows(issues)
for row in rows[:10]:
    print(row["reward_hint_rtc"], row["title"], row["url"])

The script also fails loudly on network, timeout or JSON errors. Returning an empty list after a failed API call would be dangerous because an outage would become indistinguishable from “there are no opportunities today.” That pattern matters anywhere automation is used to make money-related decisions: missing data should not quietly become a confident zero.

Why read-only comes first

It is easy to bolt on a second step that comments /claim automatically. That is usually the wrong first move. Claim semantics differ by issue. Some bounties are first-complete rather than reserved. Some require a live off-platform URL. Some require a distinct environment, a real hardware test, an existing accepted contribution, a wallet, or a human counterparty. A generic auto-claim loop can create duplicate work and damage trust long before it earns anything.

A better separation is:

RadarVerifierExecutorSettlement check

The radar asks, “What appears open?” The verifier asks, “Is this still payable, non-duplicate, safe and actually executable by me?” The executor produces the required artifact or test. The settlement check answers the only question that can move the revenue ledger: “Did the payment provider or chain actually settle?”

Three filters to add before acting

1. Eligibility

Read the current issue body and latest maintainer comments. Check whether the bounty is one-per-person, first-complete, capped, expired, already awarded, or waiting for a specific prerequisite. Search for your own prior claim before starting new work.

2. Execution boundary

Separate tasks that are fully reproducible in code from tasks that need a real person, real hardware, identity verification, a social account, a financial transfer or another party's participation. An agent should not silently substitute a simulation when the bounty asks for a real-world event.

3. Evidence boundary

Keep a strict ladder. A GitHub comment proves that a comment exists. A maintainer acceptance proves acceptance. A transaction or payment record proves money movement only when it is actually settled. These are different evidence classes and should never be collapsed into one “success” flag.

How this becomes a useful agent tool

Once the read-only layer is reliable, the next safe extension is not mass claiming. It is structured verification. For each candidate, store the source issue, reward hint, current state, last maintainer update, deadline, cap, required evidence, execution dependencies and a short reason to continue or cut. That turns a noisy bounty list into a queue of bounded decisions.

From there, an agent can rank opportunities by more than nominal RTC. A 100 RTC task that requires hardware you do not have is effectively worth zero. A 15 RTC task with a clear public API, reproducible test and open slot may be much closer to money. The useful score is therefore something like:

opportunity value ≈ payout × eligibility × completion probability × acceptance probability
                    ─ time cost ─ external dependency risk

This is the same reason the example deliberately stops after discovery. The first working automation should make the next decision cheaper without pretending to have completed it.

Source and scope

This tutorial covers the public RustChain bounty repository and its GitHub issue surface. The example is read-only: it does not create a RustChain wallet, sign a transaction, mine RTC, claim a bounty, comment on an issue or assert that any listed reward will be paid. Always use the live issue and maintainer state as the source of truth before doing work.