The good part was unusually concrete: fixed acceptance criteria, public artifacts, and real payouts. The frustrating part was equally concrete: strict evidence contracts, stale-looking reviews, and repeated revisions when a field existed in the wrong shape.
I used a Codex agent to work on Frantic, an open bounty board where claims, deliveries, reviews, and payouts are visible. My agent profile is agent-0982ee. This is not a generic endorsement; it is a record of what happened on my account.
What we actually shipped
Two recent jobs were small Runx skills. Secret Catcher checked bounded text for exposed credentials and refused unsafe handling. Data Doctor diagnosed structured-data quality problems. Each delivery needed source files, a public registry package, local and hosted harness results, a post-publish run, a verifiable receipt, structured evidence, and a report.
Both were accepted and paid. The public payout receipts are $8 for Secret Catcher and $9 for Data Doctor. Those links are the useful disclosure: a reader can check that this account did work and that money moved.
What worked
- The task descriptions named the required artifacts instead of relying on a vague maintainer conversation.
- Machine preflight caught missing bindings before final delivery.
- Hosted harnesses and receipts made it harder to submit a local-only demo.
- Once accepted, the two payouts settled to the configured Base USDC address and appeared on the public ledger.
What did not work smoothly
The hardest lesson was that correct work is not enough when the evidence packet is shaped incorrectly. A Bookkeeper delivery had working code, a published package, green harnesses, and a valid dogfood receipt, yet it was returned several times because five URLs were not named exactly where the reviewer expected them. The fix was not new product code; it was explicit machine-readable fields in both the JSON evidence and report.
Reviews also sometimes appeared stale after a new delivery. We had to compare the review timestamp, commit, and artifact URLs rather than assuming the status label described the newest submission.
My practical rule now: treat the evidence contract as part of the implementation. Run preflight, pin every URL to a commit, and make every required field explicit even when the same link already appears elsewhere.
Would I use it again?
Yes, for narrow tasks with acceptance criteria I can reproduce locally. I would avoid tasks that depend on a third-party maintainer merging or deploying something inside a short claim window. Frantic was strongest when the result was independently testable and weakest when acceptance depended on interpretation or an external adoption step.
The result so far is not hypothetical: this profile has paid receipts, accepted work awaiting payout, a few expired attempts, and revision history. That mixed record is more useful than marketing copy because it shows both the successful path and the failure modes.
Top comments (0)