Active development Sarpoy is under active development — APIs and on-chain layouts may change. Follow on GitHub →
S Sarpoy
← back to blog
· #llm· #ai-safety· #incentives

LLM red-teaming bounties have a custody problem. On-chain settlement is the cleanest fix.

The growing market for prompt-injection bounties and jailbreak prizes is mostly run on the honour system. That doesn't scale. Here's why settling LLM bounties on-chain — and specifically through a Sarpoy-style program — solves a real problem in the AI safety community.

There’s a quiet boom in LLM red-teaming bounties. A frontier lab posts a Twitter thread offering $5,000 to anyone who can extract a system prompt. A jailbreak Discord runs weekly competitions with prizes paid out of a captain’s wallet. A safety research org runs a “prove our model is vulnerable to X” bounty with payouts processed manually by an ops person.

This works for now. It scales badly.

The bottleneck isn’t the puzzles. The community generates fascinating adversarial prompts daily. The bottleneck is the settlement layer: who pays, when, with what proof, and what happens when the operator disagrees with the winner about whether the attack actually worked.

On-chain settlement — and specifically a Sarpoy-style settled program — is the cleanest fix to this problem. This post lays out why.

The current state of LLM bounty operations

Survey a dozen running LLM bounties today. You’ll find a recurring pattern:

  • Custody is informal. The prize money is in someone’s wallet, on a Stripe account, or in a corporate budget line. It’s not escrowed.
  • Verification is manual. A human reads the submission, decides whether it counts, and either approves the payout or doesn’t.
  • Payout is delayed. Bank transfers take days. Stripe payouts take days. International payments take longer. Tax forms add weeks.
  • Disputes are political. When the participant disagrees with the operator about whether their submission won, there’s nobody to appeal to. The operator’s word is final because the operator has the money.

Each of these is fine in isolation when the bounty is small and the participants trust the operator. When the bounty is large and the participant pool is global, every one of them becomes a real problem.

A skilled red-teamer in São Paulo extracting a prompt injection from an OpenAI model has no leverage over the lab’s payments team. If they get stiffed, they have no recourse. If the payout takes six weeks, they eat the float. If the lab decides their attack was a “duplicate” of one already known internally, they have no way to verify the claim. The asymmetry is brutal.

This was tolerable when AI safety was a small community of people who knew each other by name. It is not tolerable as the field opens up to thousands of contributors who don’t have personal relationships with lab ops staff.

What on-chain settlement actually changes

Move the bounty into a Sarpoy-style program — treasury PDA, fee curve, atomic settlement — and the four problems above turn into a single property of the program:

  • Custody is the program. The PDA holds the funds. Nobody can move them outside the instruction set. The operator can’t rug; the participant can’t double-claim.
  • Verification is the instruction. The submit_solution instruction either fires or doesn’t. The verification predicate is whatever the program checks — a creator review, an oracle signature, a deterministic script. Whatever it is, it’s public.
  • Payout is the same transaction as the verification. The participant gets the funds in the same block that confirms the solve. There’s no delay.
  • Disputes are constrained by code. The program can only do what its instructions allow. If you want a dispute window, you write one into the program. If you don’t, there isn’t one. The rules are visible before anyone participates.

This isn’t a hypothetical improvement. It’s a structural fix to a class of operational problems that AI safety bounty operators currently solve by being extra trustworthy individuals. Trust is expensive to maintain at scale. Code is cheap.

Why the rising-cost curve specifically helps LLM bounties

LLM red-teaming has an unusual property: the work is largely exploratory. You can’t predict in advance how many prompts it will take to crack a model. Sometimes it’s two. Sometimes it’s two hundred. Sometimes it’s never.

A static $5,000 bounty doesn’t price this. Either the bounty is too generous (somebody got lucky on prompt three and made $5k for ten minutes of work) or too stingy (somebody spent a week probing and got $5k for what was effectively a full-time research project).

Sarpoy’s rising-cost curve handles both ends. The early prompts are cheap, so the lucky-guess case doesn’t lock anyone out. The late prompts are expensive, so the patient-research case pays the patient researcher proportionally to their effort — they funded the eventual reward themselves, through their fees.

This is the right shape for LLM bounty work. The market is telling you, in real time, how hard the attack is. By the time someone cracks it, the pot is sized to the difficulty.

What about verification quality?

The hardest objection to on-chain LLM bounties is: how do you verify the solve? An exploit isn’t always binary. A jailbreak might “kind of work” — the model produces an answer that’s adjacent to the disallowed content but not quite there. Who decides?

Sarpoy’s program is agnostic. The submit_solution(is_correct) instruction takes a boolean. Whoever holds the verification key sets it. The question is who that should be.

Three reasonable answers:

  • The creator. The lab that posted the bounty reviews submissions and signs. This is fast but reintroduces the trust problem — the creator can refuse to sign winners.
  • An oracle. A third-party committee or automated evaluator holds the signing key. This is slower but removes the creator’s discretion. Useful for high-stakes bounties.
  • An on-chain predicate. Some bounties really are binary — “produce a transcript containing the literal string X” — and can be verified by a deterministic check in the program itself. The cleanest case, when you can get it.

Sarpoy lets you pick. The program holds the funds; you wire up the verification model that makes sense for your bounty.

Why labs should care

If you’re an AI safety org, an LLM lab, or a foundation that funds adversarial research, the operational case for on-chain bounties is essentially: it removes your ops people from the critical path.

Right now, your payments team is the bottleneck. Every $500 bounty requires a wire, a tax form, a compliance review, and an internal approval. The participant waits. Your team’s time is consumed.

Put the bounty in a Sarpoy-style program and the ops cost collapses. Initialise the bot, fund the pot, plug in your verification predicate, and let the program run. Payouts happen automatically. Your team’s time goes back to research.

For high-frequency bounties — weekly competitions, ongoing incentives for novel attacks — this is the difference between “we’d like to run more of these” and “we can’t afford the operational overhead”.

What gets harder

The flipside is real: on-chain bounties exclude participants who don’t have wallets. For some audiences (academic security research, regulated safety work) that’s a non-starter. You can’t pay a university researcher in SOL.

Sarpoy isn’t trying to be the only bounty rail. It’s trying to be the right rail for the crypto-comfortable global pool of red-teamers — which is, increasingly, where the cutting edge of attack research lives.

If you’re running a bounty for the academic community, keep your existing rails. If you’re running a bounty for the wild pool of researchers on Discord and X, give them a settlement layer that respects their time. That’s what Sarpoy is for.

Where this goes

The market for adversarial AI work is growing faster than the operational tooling around it. Bounties will continue to multiply. Without better settlement infrastructure, every new bounty inherits the custody problem.

On-chain settlement isn’t a niche feature. It’s the boring infrastructure that will let this market scale past the point where personal trust between operators and participants holds it together. Sarpoy is one cut at that infrastructure. There will be others. The interesting question isn’t whether on-chain settlement wins — it’s whether the AI safety community adopts it quickly enough to ride the next wave of bounty volume without breaking.

Either way, the custody problem isn’t going anywhere. The sooner the community admits that, the sooner the right infrastructure shows up.

Next step

Try the code, not just the writing

The Sarpoy monorepo is the fastest way to feel any of this. Clone it, run the backend with sample data, and walk through the creator dashboard. Twenty minutes, no commitment.

Open the repo