Why puzzle prize pools belong on-chain, not in an operator's bank account

Every puzzle competition has the same shape: somebody puts up money, somebody tries to win it, and somebody — usually a third party — promises to hand the money over when the rules are met. The promise is the load-bearing piece. If the promise is a wire transfer from an operator’s bank account, the puzzle is really two puzzles: the visible one, and the meta-puzzle of “will the operator actually pay?”

Most puzzle platforms ignore that second puzzle. Sarpoy treats it as the most important design constraint in the system. This post lays out, in detail, why the prize pool sits inside a Solana program-derived address (PDA) instead of inside a Stripe balance, and what that buys you as a creator and as a solver.

The custody question

Every prize pool needs an answer to one question: “who is allowed to move this money?” There are three common answers.

The first is “the operator”. Gitcoin, HackerOne, Immunefi, almost every Web2 bounty platform — the operator holds the funds, the operator decides when to pay out, and the operator is the single point of failure. If they get hacked, funds disappear. If they go bankrupt, funds disappear. If they decide they disagree with the winner’s submission, funds get stuck in a dispute queue that resolves on the operator’s calendar, not yours.

The second is “the creator’s wallet, on the honour system”. Twitter bounties work this way: someone says “I’ll send $500 to whoever solves X”, the solver does it, and now the creator may or may not transfer the money. This is fine for $500 and disastrous for $50,000.

The third is “a program on a public chain”. A Solana program with a treasury PDA cannot rug. It cannot decide to wait. It cannot refuse to pay the winner. The program’s source defines exactly which instructions can move the funds, and the only humans involved are the ones who wrote and audited those instructions. The creator is no more privileged than the solver after the pot is initialised.

Sarpoy picks the third option. The treasury PDA is derived from [b"treasury", bot_id]. The Anchor program’s initialize_bot instruction funds it. After that, only three instructions can touch it:

• send_message — adds the current per-message cost to the pot.
• submit_solution — releases the entire pot to a verified solver.
• close_bot — refunds the remaining balance to the creator key, only if the bot has not been solved.

There is no withdraw instruction for the creator. There is no admin multisig. There is no escape hatch.

Why this matters for the economic design

Centralised custody doesn’t just create trust problems — it limits the economic designs you can build. A platform that holds funds has to keep a ledger of what’s owed to whom, run reconciliations, and decide policies around chargebacks. None of that is possible to implement in real time.

Sarpoy’s signature mechanic is the rising per-message cost. Every successful send_message increments the cost by the bot’s multiplier. The next solver who probes the bot pays slightly more. The pot grows. This is a continuous auction running at chain-block resolution, and it works because every message is a settled financial event, not an entry in a ledger that needs to clear.

On a Web2 platform this would either be impossible or extremely fragile. You’d need to buffer payments, deal with retries and double-counts, and handle the failure mode of “user paid but the request didn’t go through”. On Solana, the answer is structurally simpler: a transaction is signed and confirmed, or it isn’t. If it isn’t, the cost doesn’t increment and the message doesn’t get delivered. There’s nothing to reconcile.

The rising-cost curve is, in the literal sense, a smart contract running between every solver. Every probe makes the next probe more expensive. That’s only stable when the cost is enforced by the same program that holds the money.

Settlement latency: the underrated benefit

People talk about on-chain settlement in terms of trust, but the underappreciated benefit is time. A solver who cracks a Sarpoy puzzle gets paid in the same Solana transaction that records the solve. Not the next day, not after a 30-day clearance, not after KYC. The pot lands in their wallet roughly one slot later, and from there it’s already liquid.

For the kind of puzzles Sarpoy targets — CTF-style chats, weird LLM jailbreaks, research bounties for novel prompt attacks — this matters. The solver community is global, mostly pseudonymous, and frequently anonymous. Asking them to fill out a 1099 to claim a $200 bounty is a tax on the exact behaviour the puzzle is trying to encourage. Asking them to wait two weeks while a centralised operator processes payout is a tax on the people best at the work.

On-chain settlement removes both taxes. The cost is the network fee on a Solana transaction — measured in fractions of a cent — and the wait is the network’s confirmation latency.

What you give up

To be fair: on-chain custody has costs.

You give up the ability to “undo” a payout. If a solver submits a solution and it passes the verification logic but turns out to have been a bug in the verifier, the funds are already in their wallet. There’s no chargeback. Sarpoy’s design pushes verifier correctness — and the creator’s ability to define what “correct” means — to the front of the design conversation. That’s a feature, not a bug, but it does mean creators have to think harder.

You give up the ability to operate in jurisdictions that don’t accept crypto. A puzzle that pays in SOL is a puzzle whose participants need wallets, which means the puzzle is not for everyone. Sarpoy bets that the audience for hard, technical puzzles is exactly the audience already comfortable with wallets.

And you give up some operational simplicity around refunds. If the bot is unsolved and the creator wants to retire it, the close_bot instruction returns the remaining treasury. But message fees paid by losing solvers compound into the pot during play — they don’t get refunded, by design. This is the same trade as a casino: you bought clues, the clues were delivered, and the pot was real.

When to use Sarpoy, when not to

Sarpoy is the right answer when:

• The puzzle has a clear, verifiable correctness predicate.
• The creator wants the prize pool to be public and auditable.
• The puzzle is the kind of thing that gets harder with time, where rising costs would discover difficulty better than a fixed bounty.
• The solver pool is global, technical, and crypto-comfortable.

Sarpoy is the wrong answer when:

• The “puzzle” is really a service contract with a deliverable. Use Upwork.
• The prize needs to be paid in fiat to a registered entity. Use a traditional bounty platform.
• The puzzle is private to a single team. You can self-host the Anchor program, but a private SOL pot is fancier than necessary.

For everything in between, the on-chain pot is doing useful work. It removes a layer of trust, enables a continuous fee curve, and pays out in the same transaction as the solve. That’s not a small thing.

Where to start

The fastest way to feel the difference is to clone the repo, run the backend with sample data, and walk through the creator dashboard. The initialize_bot instruction is the entry point — that’s the moment a prize pool stops being a promise and starts being a program account.

After that the only question is what kind of puzzle you want to build. The answer is up to you. The pot, at least, is no longer up for debate.