The rising-cost curve: how Sarpoy's fee multiplier prices puzzle difficulty in real time

Static bounties have a pricing problem nobody talks about: the person setting the bounty almost never knows the right number. They pick something that feels generous, the puzzle either gets cracked in an hour or sits untouched for a year, and the post-mortem is always “we should have priced it differently”. By then it doesn’t matter.

Sarpoy’s per-message fee multiplier is a direct response to that problem. Instead of asking the creator to guess the right bounty, the system asks the market to discover it message by message. Hard puzzles get expensive to probe; easy puzzles get drained before they’re expensive. Difficulty prices itself.

This post is a deep dive on why the multiplier exists, how it actually behaves, and how to think about setting it for your bot.

The pricing problem in centralised bounties

Imagine you’re posting a $10,000 bounty for a security exploit on HackerOne. Your options are:

1. Underprice it. Researchers don’t bother; you get crickets.
2. Overprice it. Researchers bother; you blow your budget on a class of bugs that turned out to be cheap.
3. Get lucky and hit the right number. This happens maybe one time in ten, on a good day, in a category you understand well.

Most bounty platforms try to solve this with “levels” (low/medium/high/ critical) but those are just coarse buckets. They still require the operator to guess where the puzzle lives, and they still don’t move once the bounty is published.

The deeper issue is that bounty pricing is a one-shot decision against a distribution of solver effort that you can’t see in advance. The honest answer to “how much is this puzzle worth?” is “I don’t know — let me see what solvers will pay to attempt it.”

Sarpoy’s answer is: let them tell you.

How the multiplier works

Every bot has three on-chain fields that matter for pricing:

• base_cost — the cost of the first send_message instruction, in lamports.
• cost_multiplier — the lamports added to the cost after each successful message.
• current_cost — the current cost. Starts at base_cost. Increments by cost_multiplier every successful message.

The Anchor program enforces all three. Solvers can read the current cost from the bot account before they decide to send a message. The cost update happens atomically with the payment, so there’s no race condition between “I think the cost is X” and “the cost has now risen to Y”.

Concretely: a bot launches with base_cost = 0.005 SOL and cost_multiplier = 0.001 SOL. The first message costs 0.005 SOL. The second costs 0.006 SOL. The tenth costs 0.014 SOL. The hundredth costs 0.104 SOL — twenty times the starting price.

The pot grows correspondingly. By message 100, the cumulative fees paid in are 0.005 + 0.006 + … + 0.104 = about 5.45 SOL on top of whatever initial pot the creator funded.

Why this prices difficulty

Consider two puzzles.

Easy puzzle. Smart solver tries it, cracks it in three messages. Pays 0.005 + 0.006 + 0.007 = 0.018 SOL. Takes home the initial pot plus the small accumulated fees. The market said: this puzzle is worth about 0.018 SOL of probing.

Hard puzzle. Solvers attempt it, fail, give up. Other solvers see the pot growing, see the current cost climbing, and have to decide: “Is the puzzle worth the next 0.05 SOL to probe?” If they believe yes, they keep going and the cost keeps rising. If they believe no, the puzzle sits with its accumulated pot until someone changes their mind.

Notice what the second case is doing: it’s running a continuous auction on the right to probe further. The market is telling the creator, in real time, how hard the puzzle actually is. Information that would have taken weeks of post-mortem analysis on a static bounty platform shows up in the bot’s chat log within hours.

The honest failure modes

The rising-cost curve isn’t a free lunch. Some real risks:

Coordination failure. A puzzle that’s actually solvable by coordinated effort (e.g., a chain of clues distributed across multiple solvers) doesn’t benefit from rising costs — each individual solver is incentivised to free-ride on someone else’s probing. Multi-party puzzles need different mechanism design.

Whale capture. A solver with deep pockets can keep probing past the point where the marginal expected value goes negative, hoping to brute-force. For puzzles where the answer is in a small search space, this is a problem. Set the multiplier high enough that brute force becomes economically irrational.

Creator regret. If you set the multiplier too high and solvers bounce off the first wall of cost, the puzzle dies. The pot sits there. You can close_bot and refund yourself, but you’ve also publicly demonstrated that your puzzle wasn’t interesting at the price you set. There’s a reputational cost.

Sniping at the end. A puzzle nobody touches for a week and then gets cracked in five minutes by a watcher who waited for the cost to stay low — this is fine, actually, but it can feel demoralising for solvers who tried earlier.

How to set the multiplier

There’s no formula. There are heuristics.

For an easy puzzle (5-15 messages expected to crack): Pick a low base cost (0.001 SOL) and zero or near-zero multiplier. Flat-rate messaging keeps the puzzle approachable.

For a medium puzzle (20-80 messages expected): Pick a moderate base cost (0.005 SOL) and a multiplier that makes the 50th message cost roughly 3-5x the first. So if base is 0.005, set multiplier to ~0.0003. The curve will exclude casual probers without choking off serious ones.

For a hard adversarial puzzle (100+ messages, expert-level solvers): Pick a higher base cost (0.01 SOL) and a steeper multiplier (~0.005). The cost at message 100 will be ~0.51 SOL, which is real money even for whales. This is the right curve for “only people with a real strategy will keep going”.

For a public bounty (open-ended, indeterminate effort): Use a mild multiplier (~0.0001). You want the cost to rise enough to fund interesting probing without pricing anyone out early.

Once you’ve launched, you can’t change the multiplier — it’s fixed at initialize_bot time. So pick carefully, but don’t agonise. The whole point of the design is that the market will discover the actual difficulty regardless of where you start.

What the math implies in aggregate

If the multiplier is m, the cost of the nth message is base + (n-1) * m. The cumulative fees paid by message n are n * base + m * n * (n-1) / 2. The pot grows quadratically with the number of messages.

This has a nice consequence: a puzzle that takes 100 messages to crack pays out roughly 100x the work of a puzzle that takes 10 messages, not 10x. The reward structure naturally favours patience and depth. That’s exactly the kind of solver behaviour the system wants to encourage.

A closing observation

The rising-cost curve is a tiny piece of code — three fields in an account, two lines in send_message. But it’s doing a lot of work. It removes the pricing problem from the creator’s to-do list. It pushes difficulty discovery onto the market. It turns the chat log into a real-time information stream about how hard the puzzle is. And it does all of that without any off-chain coordination.

That’s the kind of small mechanism that ends up being the defining feature of a system. Static bounty platforms can’t replicate it without abandoning their custodial model. Sarpoy gets it almost for free, because the program already controls the money. The rest is just one increment per instruction.

The multiplier is the answer to a question most platforms don’t even know they’re asking. It’s a quiet thing. But it changes everything downstream.