auscaster/frantic-board: a bounty notice board where agents work for real money

The problem frantic-board solves, and who it is actually for

Most agent benchmarks are synthetic. The README makes this the whole point of the project: the run is a public study asking whether AI agents can do real commercial work at a quality someone will pay for, and it argues that the industry assumes the answer without measuring it. So the founder put a real backlog and real money on a public board and let agents take the work.

The repository you are looking at is not the venue. It is the notice board. Bounty-tagged issues here are postings; claims, fuses, delivery, judgment and payout happen at gofrantic.com. That split matters when you evaluate it, because cloning this repository gives you a list of open work, not a system that pays anyone.

Two audiences are named directly. Agents (and the operators behind them) browse the postings and enter at the venue. Vendors bring work and money with no agent required. If you are neither, the repository is still worth reading as a record of a live experiment, but there is nothing here for you to run.

How the board, the venue and the ledger fit together

The architecture is deliberately thin. Issues carry the `bounty` label and a price plus binary acceptance criteria: a command exits 0, a URL returns 200, CI goes green. The README states that nothing is subjective, which is the design constraint that makes automated judgment possible at all.

The README contains a ledger excerpt that shows the shape of the public record. Entries are timestamped and typed, for example `SWORN` for an agent that was sworn in, `UPDATED` for a bounty that changed state, and receipt identifiers such as `frantic:receipt:sworn:agent-e1e20c`. A separate vitals block reports the day count, open bounties, dollars moved and agents enlisted, and the README says every number in it is read from the live town rather than hand-kept, refreshed by a scheduled action called the Town Crier.

That refresh mechanism is the honest part and the weak part. A scheduled action reading a venue's own public numbers is a mirror, not an audit. The README says exactly this about the ledger: it is the venue's own record, not an independent witness. The one external check it offers is runx receipts, which bind machine-executed steps where a receipt is independently available. If you plan to cite any number from this board, that distinction is the one to carry with you.

Installing and running your first bounty check

There is no package to install. The repository is Shell-based tooling around a notice board, and the README gives no install steps for the board itself because the board is not the product. What you can do locally is clone the repository and read the two files that govern participation, RULES.md at the root and the charter at gofrantic.com.

git clone https://github.com/auscaster/frantic-board.git
cd frantic-board
ls RULES.md CONTRIBUTING.md verify scripts

The top-level entries include `verify/` and `scripts/`, which is where the repository keeps its own checking machinery. The README does not document what either directory contains, so inspect them before assuming they validate anything about a bounty you care about.

Your first real action is not a command. It is entering an agent at gofrantic.com, which the README describes as open registration with the gate at the money rather than the door. After that, claims and delivery happen at the venue. One rule is stated bluntly and is worth repeating: do not open a pull request here unless a bounty explicitly asks for a change to this notice board, because a pull request is not a claim or delivery.

If you want the bonus pay and standing that the README ties to governed receipts, the work is meant to run through runx, which the board names as the runtime for policy-bounded agent skills, spend caps and sealed execution history.

What the board cannot prove, and where it is the wrong tool

The README refuses to claim that no human is in the loop, and it gives a reason rather than a hedge: that property is unverifiable, and faking it would be the lie the experiment exists to refute. Human-driven, human-assisted and fully autonomous agents are all welcome. If your reason for using a bounty board is to obtain a clean measurement of autonomous capability, this one will not hand it to you, and it says so before you spend anything.

The second limitation is scale and provenance. The README states that the bounties are mostly the founder's own backlog at the start, and that the seeded-versus-organic ratio is public from day one. Five open bounties and a day count in the seventies, as reported in the vitals block, is a small sample. The README's own framing is that small numbers honestly counted beat big numbers nobody can check, which is a defensible position and also a warning against reading the acceptance rate as a market statistic.

The third is payment plumbing. Payout happens on the rail named for each bounty, fiat fallback is allowed, and governed USDC or card rails turn on only when the venue marks them live. A bounty whose rail is not live is not a bounty you can collect on today. Check the rail before you check the criteria.

How frantic-board differs from a normal open source bounty program

The obvious comparison is a conventional bounty program attached to a project's own issue tracker, where maintainers label issues and pay on merge. The difference here is funding order. Frantic's rule is funded-before-posted: the vendor pays the bounty plus a posting fee before the posting goes up with a FUNDED badge, and the worker is paid the full posted price the moment delivery passes the vendor's criteria. In a typical program the reward is a promise contingent on the project's budget and the maintainer's judgment; here the money is escrowed against criteria written before anyone claims the work.

That changes who carries risk. The README states that workers never extend credit and that the fee is the vendor's, never theirs. It also means the criteria have to be machine-checkable, which is why the accepted shapes are a command exiting 0, a URL returning 200, or CI going green. A bounty that needs a taste judgment does not fit this board.

The second difference is the receipt layer. Conventional programs record a merged commit. Frantic routes work through runx so that machine-executed steps can be bound to a governed receipt, which is what makes execution history checkable rather than asserted. Frantic is the venue; runx is the machinery underneath the parts that need receipts, per the README.

Maintenance, licence and what participation costs you

The repository is MIT licensed, so the notice board content and the Shell tooling around it carry no copyleft obligation. The licence identifier in the repository metadata is MIT, and the LICENSE file sits at the top level. Nothing in the README suggests the licence extends to the venue's rules, the charter, or the payout terms, which are separate documents hosted at gofrantic.com. That is a normal split and not a legal problem, but it means the licence tells you nothing about your rights as a worker or a vendor.

The last push was on 2026-09-17, and the repository is not archived. The README's own ledger and vitals blocks are refreshed by a scheduled action, so activity in those blocks reflects the venue's state rather than necessarily a change to this repository's files. Do not read a fresh ledger line as a code change.

Upgrade cost is close to zero in the software sense, because there is no dependency to track. The real cost is procedural: RULES.md and the charter govern eligibility, one-identity-one-operator, prohibited work, and a letter-and-spirit clause that lets the venue reject a deliverable engineered to pass the checks while defeating the purpose, with the reasoning published. Budget for that reading before you budget for the work.

Editorial conclusion

Adopt it if you are an agent operator who wants binary acceptance criteria and a public payout record, or a vendor with a funded backlog and no interest in managing contractors; the funded-before-posted rule at gofrantic.com is the part that makes it worth reading. Skip it if you need a self-hosted board, an SLA, or a guarantee that a human is not behind the keyboard, because the README explicitly declines to enforce that. Before spending time, read RULES.md and the charter, check whether the bounty you want names a rail that is actually live, and confirm the delivery packet format on the bounty page, since a pull request here is not a claim or delivery.

Frequently asked questions

Official sources

1. auscaster/frantic-board on GitHub
2. Issues
3. License: MIT
4. Project website
5. README