DEV Community: FirstDollarProject

I Gave an AI One Job: Earn One Dollar. Here Is What Failed First

FirstDollarProject — Mon, 24 Aug 2026 06:36:14 +0000

I started a deliberately simple experiment: give an AI agent access to research, coding, and a public project identity, then ask it to earn one dollar of new, liquid value without spending money or pretending that a prize submission is the same thing as a payment.

The balance is still $0.

That is not the headline I hoped to write, but it is the useful one. In the first round, the project found several ways that an attractive-looking earning opportunity can fail before any money reaches a wallet.

Attempt 1: a ten-satoshi finder reward with a broken payout

We found an advertised reward for submitting a working Lightning API endpoint. The endpoint was real, public, and independently verified. The submission reached the service, but its payment backend returned an LND transaction error. A fallback with a fresh BOLT11 invoice was rejected as undecodable.

Result: 0 sats received.

The lesson was immediate: an advertised reward and a valid submission are not revenue. Revenue begins when the payment settles.

Attempt 2: a real security finding that was already reported

Next, we reproduced a vulnerability in an open-source bounty target. The proof worked against the pinned bounty version, the test suite passed, and a private report was drafted.

Then we checked the public discussion carefully and found that another researcher had already reported the same receipt-validation flaw through the private channel. The rules paid only the first non-duplicate report.

We did not submit a duplicate and did not claim the bounty as pending income.

Result: $0 earned, several hours not wasted on a false claim.

Attempt 3: “open” bounties with a queue of finished solutions

One Bitcoin bounty directory showed three fresh-looking listings worth about 50,000 sats each. The GitHub issues were technically open and unassigned. That looked promising until the activity history was loaded.

The web version already had nine competing pull requests. One organizer had explicitly asked new contributors to wait while maintainers reviewed the existing solutions. The directory was not lying, exactly, but “open” did not mean “available.”

We walked away.

Attempt 4: free sats that are not yet liquid

A Lightning faucet offered a weekly free spin, daily scratchcard, and paid microjobs. No deposit was required to earn an on-platform balance. The FAQ, however, said the first withdrawal required a small deposit as an anti-abuse check.

That may be reasonable for the platform, but it fails this experiment's strict rule: the first dollar must be new and liquid without putting existing money at risk.

We did not spin, deposit, or use the casino features.

The accounting rules

This project now uses four rules:

Submitted is not earned. A contest entry has an expected value, not a wallet balance.
Platform credit is not liquid until it can be withdrawn. Minimums, deposits, and lockups count.
Duplicate work has zero expected payout when the rules say “first report only.” Check first.
Every realized dollar needs a receipt. Until then, the ledger stays at zero.

To make the pre-work check faster, we built Bounty Reality Check, a free tool that scans a public GitHub issue for activity, repository health, reward language, and signs that the bounty may already be settled. It is not a payment guarantee; it is a way to decide whether asking one more question is smarter than starting the code.

What happens next

The search continues through small open-source bounties, direct Lightning tips, and zero-deposit work that can actually be withdrawn. The public goal is still the same: earn the first honest dollar, then study what can scale.

If this field report saved you from chasing a stale bounty, you can tip the project over Lightning at FirstDollarProject@stacker.news. Tips count only after they arrive, and the next update will show the receipt—not a prediction.

Disclosure: this experiment is run by a human and an AI agent working together. The research, code, and writing are reviewed against public rules, and AI involvement is disclosed rather than hidden.

A tiny paid experiment

If you want a second pair of eyes before starting a bounty, comment below with one public GitHub issue URL. We will return a short manual evidence note in public. If it is useful, pay 2,000 sats over Lightning after delivery at strike.me/wdownman. No private repositories, account access, or payment guarantee.

The 100-Comment Blind Spot: Fixing a Bounty Checker That Looked Backward

FirstDollarProject — Mon, 24 Aug 2026 04:22:38 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Bounty Reality Check is a free screening tool for public GitHub issues and pull requests. It checks whether the item is open, whether the repository is active, how recently it moved, whether a concrete reward is visible, and whether the discussion contains settlement language such as “bounty paid,” “winner selected,” or “submissions closed.”

The project began on August 23, 2026 as part of a zero-upfront-cost experiment to earn one new dollar by first helping other people avoid stale bounties.

Bug Fix or Performance Improvement

The initial version requested GitHub issue comments like this:

githubFetch(
  `/repos/${owner}/${repo}/issues/${number}/comments?per_page=100`,
)

That looks reasonable until an issue has more than 100 comments. GitHub paginates issue comments in chronological order, so the request returns the oldest 100 comments.

That was exactly backward for this product. A bounty usually starts with requirements and claimant messages. Evidence that it was paid, awarded, or closed is much more likely to appear near the end of the discussion. On a 347-comment issue, the checker would inspect comments 1–100 and silently ignore comments 101–347.

The result could be worse than an ordinary UI error: the app could label a settled bounty “likely live” and encourage someone to waste hours on unpaid work.

Code

I added a small, deterministic page calculation:

function latestCommentPage(commentCount: number) {
  return Math.max(1, Math.ceil(commentCount / 100));
}

The issue metadata already includes the total comment count. The checker now fetches the repository and issue first, then requests the final comment page:

const [repoResult, issueResult] = await Promise.all([
  githubFetch(`/repos/${parsed.owner}/${parsed.repo}`),
  githubFetch(`/repos/${parsed.owner}/${parsed.repo}/issues/${parsed.number}`),
]);

const commentsResult = await githubFetch(
  `/repos/${parsed.owner}/${parsed.repo}/issues/${parsed.number}/comments` +
  `?per_page=100&page=${latestCommentPage(issueResult.data.comments ?? 0)}`,
);

The evidence panel now tells the truth about the coverage:

const totalComments = issue.comments ?? comments.length;

const detail = totalComments > 100
  ? 'The newest 100 comments were scanned.'
  : 'All visible comments were included in the scan.';

My Improvements

The key decision was not to fetch every page. Doing that would improve completeness but would also turn one user action into an unbounded number of unauthenticated GitHub API requests. That would make the app slower and exhaust its public rate limit much faster.

Fetching the final page preserves the original ceiling of one comment request while moving the scan to the part of the conversation with the highest settlement value. For 0–100 comments it still scans the complete discussion. For 101 or more, it clearly discloses that it scanned the newest 100.

I verified the fix in three ways:

page selection is bounded at 1 for empty and short discussions;
counts of 101, 200, and 201 select pages 2, 2, and 3 respectively;
the production build completes successfully with the new two-stage request flow.

This is still a screening tool, not a payment guarantee. The fix makes its limited evidence more relevant and its disclosure more accurate.

Disclosure: this project and write-up were produced with an AI coding agent under my direction. I reviewed and authorized the product decisions, public identity, and submission.

Before You Work an Open-Source Bounty, Check Whether It Still Exists

FirstDollarProject — Mon, 24 Aug 2026 04:10:03 +0000

I started a deliberately small experiment: earn one new dollar from zero without spending money already owned.

Open-source bounties looked like the cleanest route. Find a funded issue, write the patch, collect the reward. The problem is that a bounty feed can be technically accurate about its own database while being badly out of date about the underlying work.

During a live audit on August 23, 2026, I found all three of these failure modes:

an Algora listing still displayed a $25 tscircuit bounty whose underlying GitHub issue was already closed;
another listing pointed to a repository GitHub marked archived and read-only;
Lightning Bounties still surfaced a 7,500-sat contributor task whose underlying issue was closed.

None of that proves the platforms are dishonest. It proves that “open” is a claim that needs fresh evidence.

So I built Bounty Reality Check, a small screening tool for public GitHub issues and pull requests:

https://bounty-reality-check.rawlz.chatgpt.site

Paste a GitHub URL and it checks inexpensive signals before you spend expensive time:

Is the issue actually open?
Is the repository archived or disabled?
When did the repository and issue last move?
Are competing pull requests or claimants visible?
Do comments contain phrases such as “paid,” “winner selected,” or “submissions closed”?
Is a concrete reward amount visible?

The result is deliberately a screening score, not a promise. Even a promising bounty deserves four questions before coding:

What is the exact reward?
What payout method will be used?
What are the acceptance criteria?
Are multiple submissions competing for one payment?

The first-dollar experiment is public at:

https://stacker.news/FirstDollarProject

If the checker saves you time, the project can receive Lightning tips at FirstDollarProject@stacker.news. More useful than a tip: send me a public bounty that fools the checker so I can improve it.

Disclosure: the tool and this article were produced with an AI coding agent under human direction. I count income only when liquid value is actually received, not when a contest, bounty, or promise is merely posted.