Stablecoin bounty rails • proof packet • 22 May 2026

issues.cash can add USDC bounty support without turning every issue into a payment negotiation.

This buyer-specific packet responds to dlbnco/issues.cash#42. The issue is currently just a title, and the first replies already show the predictable failure mode: solvers ask for payout address, amount, trigger, and chain before a PR can be safely started.

Commercial offer: a fixed A$690 stablecoin bounty rails readback, or a A$2,400 implementation room if the maintainers want the PR built with tests.

Book readback Source issue

What the current thread proves

Observed gap	Why it matters	Minimum fix
Issue title only: “Support stablecoin bounties”	Solvers cannot tell whether this is a funded task, product roadmap item, or unpaid feature request.	Add explicit bounty amount, network, asset, claim trigger, expiry, and maintainer approval path.
Solver comments immediately ask for amount/payment terms	Payment negotiation clutters public issues and creates inconsistent expectations.	Move payout terms into first-class bounty metadata and render them on issue cards.
Wallet addresses appear in comments before scope is confirmed	Addresses are fine when public, but they are weak receipts and easy to copy/paste incorrectly.	Use claim records with recipient address, chain, asset, amount, winning PR, and timestamp.
No duplicate-solver signal	Stablecoin support will attract more “I can do this” comments unless the system shows saturation.	Expose linked-submission count and duplicate-risk hints before a solver starts.

Suggested bounty states

draft

funding_pending

funded_open

claimed

submitted

accepted

paid

expired_refundable

type StablecoinBounty = {
  asset: "USDC";
  chainId: 8453 | 137;
  amountAtomic: string;
  escrowAddress?: `0x${string}`;
  payoutTrigger: "merged_pr" | "maintainer_acceptance";
  winnerAddress?: `0x${string}`;
  winningPullRequest?: string;
  paidTxHash?: `0x${string}`;
};

Claim copy that prevents ambiguity

This issue is a funded stablecoin bounty.

Amount: 100 USDC
Network: Base
Acceptance: maintainer merges one PR that satisfies the acceptance criteria
Payout: within 7 days of merge to the winner's public address
Duplicate rule: first accepted PR wins; later duplicate PRs are not eligible unless requested
No KYC/legal terms are added by claiming this bounty.

PR-ready acceptance criteria

Add bounty metadata fields for asset, chain/network, amount, payout trigger, expiry, and recipient address.
Render stablecoin bounty terms on issue/task cards before a solver comments or starts a PR.
Require maintainers to confirm funded amount and payout trigger before showing a task as paid.
Record a public payout receipt containing winner, PR, amount, network, and transaction hash after payment.
Expose a duplicate-risk signal based on linked submissions/PRs so agents avoid saturated bounties.
Add tests for missing amount/network, invalid recipient address, duplicate submission, and paid receipt rendering.

Why this is worth doing now

issues.cash already sits in the “GitHub issue becomes paid task” lane. Stablecoin support can be a conversion feature, but only if the protocol removes ambiguity before solvers start work. The narrowest sellable deliverable is not “add crypto”; it is a clear, testable bounty lifecycle that lets maintainers publish USDC terms and lets agents filter safe work without negotiating in every thread.