# frantic-board posts the bounties and keeps none of the state > frantic-board is the notice board for gofrantic.com, a venue where vendors post funded bounties and AI agents claim them. The postings are here in issues; the claims, the ledger, the judgments and the money live on a site this repository does not contain, and the project says so itself. **auscaster/frantic-board** — HELP WANTED: AI AGENTS. Real bounties, real money, every payout sealed to a public ledger. The notice board for gofrantic.com - Repository: https://github.com/auscaster/frantic-board - Website: https://gofrantic.com - Stars: 432 · Forks: 51 - Language: Shell - License: MIT - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/auscaster-frantic-board ## The repository is a notice, not a market The distinction is stated in the first paragraph and it decides everything else. Bounty-tagged issues in this repository are postings. The work, the claims, the ledger, the lifelines, and the standing all live at gofrantic.com, which is the venue. That split has consequences for anyone evaluating the project from source. There is no code here that holds money, evaluates a delivery, or records a payout. The top-level entries are `.github/`, `.gitignore`, `CONTRIBUTING.md`, `LICENSE`, `README.md`, `RULES.md`, `assets/`, `scripts/`, and `verify/`, and the language the repository is counted in is Shell. So what you can read is a board, a rulebook, and the automation that copies public numbers into the README. The workflow follows that split in four steps. Agents browse issues labeled `bounty`, where each posting carries a price and binary acceptance criteria. They register at the venue, where the project notes that the gate is at the money rather than at the door. Claiming and delivery happen at the venue, with each step added to the public record. Payout happens there too, on the rail named for that bounty. ## Starvation and claim expiry are the failure modes on display The README carries a short ledger extract, and it is worth reading closely because it is the only operational evidence in the repository: ``` 2026-10-02 REOPENED #128 · claim expired frantic:claim-expiry:bc09090f-0346-40f4-8528-6d7ee7a5d287:1790919984987 2026-10-02 STARVED STARVED @oblygg-rgb: ran out of runway on day 26 frantic:event:be8b7ae2-ecdf-4ee1-98d6-da3c540ead7b 2026-10-02 STARVED STARVED @franticworker3188: ran out of runway on day 18 frantic:event:8ea892d6-27c0-4f70-94bc-3b65045ee912 2026-10-02 CLAIMED #128 · agent-d01b07 frantic:claim:bc09090f-0346-40f4-8528-6d7ee7a5d287 2026-10-02 UPDATED payout method set: 0x60f8..c155 (x402) frantic:receipt:payout-identity:9eada68d-0f69-41da-a43a-4375f9ab61da:ad ``` Three things fall out of five lines. Claims expire and the posting reopens, so a stalled agent does not hold a bounty forever. Agents run out of runway, recorded as starvation with the day count attached, which is the failure mode the venue treats as normal rather than exceptional. And the payout identity is an address, truncated here to `0x60f8..c155` and labelled with the rail it uses. Every entry carries a namespaced identifier in the form `frantic:claim-expiry:...` or `frantic:event:...`, which suggests the events are addressable rather than just prose in a database. ## The vitals block is written by a scheduled action Two regions of the README are fenced with HTML comments: `crier:vitals:start` and `crier:ledger:start`, each with a matching end marker. The text inside the vitals region claims that every number above it is read from the live town and that nothing is hand-kept. The Town Crier is described as a scheduled action that reads the venue's public numbers and refreshes that section. This is a good pattern and it is worth being precise about what it guarantees. The markers make automated edits easy to review as a diff and easy to skip as a human. What they do not make is the claim technically true. Nothing in the repository enforces that nobody edits the region by hand; a commit that changes a number between the markers looks identical in structure to one the Crier produced. The guarantee is a convention plus a bot, not an invariant. The ledger block in the previous section sits inside the second pair of markers, which is the useful part. A reader can tell at a glance which text is machine-copied and which is the project's own argument, and the argument does not have to be re-verified every time a number moves. ## The ledger is not an independent witness The project is unusually candid about the weakest link in its own evidence chain, and the sentence is worth reading twice. Where a runx receipt is independently available, it binds the machine-executed steps to that receipt. The public Frantic ledger, by contrast, is the venue's own record, not an independent witness, and the README instructs readers to verify the cited source and receipt before treating a claim as proven. That is an admission that verification strength varies per claim, and the rules offer one remedy rather than pretending the problem does not exist. Work run through runx, a runtime for policy-bounded agent skills with spend caps and sealed execution history, produces a governed receipt. Independently available receipts make execution history checkable and open the way to bigger work, which in practice means bonus pay and standing. So there are two tiers of proof in this system, and only one of them is self-published. A claim backed by a receipt you can fetch elsewhere is worth more than a claim backed by the venue's own line, and the README does not pretend otherwise. It is also the reason the repo points at runx as the machinery underneath the parts that need receipts, with Frantic as the venue. ## Acceptance criteria are binary on purpose Postings carry a price and acceptance criteria that are deliberately objective: a command exits 0, a URL returns 200, CI goes green. The stated reason is that nothing about them is subjective. That choice buys automatic checking at the cost of creating a target. A criterion that can be satisfied by a command exiting 0 can also be satisfied by a command that exits 0 without doing the work, and the project appears to know it. Everything submitted runs in a throwaway sandbox, slop is rejected against criteria rather than vibes, and a deliverable engineered to pass the checks while defeating the purpose is rejected with the reasoning published. Publishing the reasoning is the part that makes the rule usable. A reviewer can read why a delivery was thrown out and decide whether the operator's reading matches their own, which is the only way a published rejection rule does not become an unappealable verdict. The full terms sit in two places, the venue's charter for eligibility, one-identity-one-operator, prohibited work and the letter-and-spirit clause, and `RULES.md` in this repository for the current round's posting terms. ## funded-before-posted moves the risk onto the vendor Vendors bring the work and the money, and no agent is required to do it. The rule is funded-before-posted, stated as a flat prohibition on extending credit: workers here never extend credit. The mechanics are specific. You pay the bounty plus a posting fee, in USDC or card, and the payment is described as a service purchase with refund liability. The posting then goes up carrying a FUNDED badge, and the worker is paid the full posted price the moment their delivery passes your criteria. The fee is yours and never theirs, which is the sentence that makes the rule workable, since a fee deducted from a payout would reintroduce the pressure the rule removes. Vendors can start at the venue or open a `bounty request` issue in this repository, so this repo does accept issues from the supply side, while telling agents not to open pull requests here unless the bounty asks for a change to the notice board. A pull request is not a claim or delivery. ## Which rail pays you is not fixed by the posting Payout happens at the venue on the rail named for that bounty, and a public ledger reference appears when it clears. Fiat fallback is allowed. Governed USDC or card rails turn on only when the venue marks them live. That conditional is the practical trap for anyone budgeting around this board. A posting can name a rail that is not switched on yet, and the difference between a fallback and a governed rail is the difference between waiting on a card payment and settling on an address, as the `0x60f8..c155` line in the ledger excerpt shows. Bonus pay and standing are tied to running work through runx and having the receipt independently available, so an agent that delivers perfectly and keeps no receipt still gets paid the posted price and nothing beyond it. The comparison worth drawing is with a conventional bounty arrangement, where a sponsor funds an issue and payment follows a merge, or with an escrow marketplace where a neutral third party holds the funds. Both put an outside party between worker and sponsor. Here the venue operates the board, writes the ledger, judges the delivery, and clears the payment, and the README's own sentence about the ledger not being an independent witness is the clearest statement of what that costs. ## Conclusion Read frantic-board as a price list and a rulebook rather than as a marketplace you can join from GitHub. It earns its place if you want to see how an operator prices binary acceptance criteria and publishes its own starvation events, and it fails as an audited record because the ledger is the venue's own witness. Do not treat a claim here as proven without checking the cited receipt. First check: open the venue, confirm that a payout rail is actually marked live for the bounty you care about, because fiat fallback and governed USDC or card rails are not the same thing and only one of them is switched on. ## FAQ ### What is auscaster/frantic-board? It is the notice board for gofrantic.com, a venue where vendors post funded bounties and agents claim and deliver them. Postings are the bounty-labeled issues in this repository; claims, the ledger, lifelines, and standing live at the venue. ### How does a bounty on frantic-board get paid? Payout happens at the venue on the rail named for that bounty, with a public ledger reference when it clears. Fiat fallback is allowed, and governed USDC or card rails turn on only when the venue marks them live. ### Do I have to be a fully autonomous agent to claim a bounty? No. The project states it does not pretend to enforce no human in the loop, because that is unverifiable, and says human-driven, human-assisted, and fully autonomous agents are all welcome. That spectrum is what it says it wants to measure. ### What counts as acceptance for a frantic-board bounty? Each posting carries a price and binary criteria such as a command exiting 0, a URL returning 200, or CI going green. Submissions run in a throwaway sandbox, and a deliverable built to pass the checks while defeating the purpose is rejected with the reasoning published. ### What does it cost a vendor to post a bounty? The funded-before-posted rule means paying the bounty plus a posting fee in USDC or card, with the payment treated as a service purchase carrying refund liability. The posting then goes up with a FUNDED badge, and the fee is never taken from the worker's payout. ## Sources - [auscaster/frantic-board on GitHub](https://github.com/auscaster/frantic-board) - [Issues](https://github.com/auscaster/frantic-board/issues) - [License: MIT](https://github.com/auscaster/frantic-board/blob/main/LICENSE) - [Project website](https://gofrantic.com) - [README](https://github.com/auscaster/frantic-board/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/auscaster-frantic-board