Success fees: the proposal to pay validators only when your transaction lands

Every Solana developer has watched a user pay for nothing: a swap that slipped past its tolerance, a mint that lost the race, an arb that got beaten by one slot. The transaction failed, the state reverted, and the priority fee was charged anyway. That asymmetry is not a bug. It is how the fee model works today, and it quietly shapes where sophisticated flow goes on Solana. A new proposal in the Solana Improvement Documents repo wants to change it: Success Fees, posted July 3, 2026 by cavemanloverboy and surfaced in the July 9 Solana Changelog.

One framing note before the mechanics: this is a GitHub discussion, not a numbered SIMD. There is no draft document, no implementation, and no governance activity yet. It is the idea-stage of the pipeline. But the author has form (he also wrote the open SIMD-0553 fee restructure, and builds tools we have covered before), and the thread has already attracted the kind of objections that decide whether proposals survive. It is worth understanding now.

Click to zoom

The fee model today: you pay for inclusion, not outcome

Three charges can apply to a Solana transaction today, and all of them are unconditional on execution result:

• Base fee: 5,000 lamports per signature, split between burn and the leader.
• Priority fee: a per-compute-unit price set via a Compute Budget instruction, multiplied by your CU limit. Since SIMD-0096 passed governance, 100% of it goes to the leader (it was previously half burned). We covered how to set it well in our priority fees guide.
• Jito tips: out-of-protocol transfers to tip accounts, usually inside bundles that revert atomically, which is exactly why they behave like success fees. If the bundle fails, nothing lands and no tip is paid. See Jito block engine demystified.

The author's motivation paragraph states the problem precisely: "Today's priority fee is charged when the transaction is included, whether or not it succeeds. That means a trader who wants to pay a large fraction of an on-chain opportunity cannot confidently do so via priority fee, as a failed swap still pays the full priority fee." If a 10 SOL arb appears, you cannot bid 8 SOL through the priority fee, because losing the race would cost you 8 SOL for nothing. So that bidding happens elsewhere: Jito bundles, and paid transaction-landing services like Temporal's Nozomi and Harmonic. The value leaks around the protocol instead of through it.

What the proposal actually adds

A transaction MAY declare a success fee: a flat lamport amount, not a per-CU price. The logic is deliberate. When an opportunity of size S appears, the number of compute units used to capture it is irrelevant; you want to bid against S, not against your CU count. The mechanism:

• Optional, default zero. A transaction can carry both a priority fee and a success fee. Nothing changes for transactions that do not opt in.
• Debited post-execution. The pre-execution balance check is unchanged and covers existing fees only. After all instructions complete with status OK, the runtime attempts to debit the success fee from the fee payer.
• If the debit fails, a new error (InsufficientFundsForSuccessFee) is returned, state reverts, the nonce still advances, and only the existing fees are charged. simulateTransaction must surface the error, so wallets and SDKs can catch it before broadcast.
• On failure, you pay what you pay today. Execution failures and fee-only loading failures (SIMD-0191) charge existing fees only, which the author calls the failure fee. There is no revert protection: unlike a Jito bundle, the failed transaction still lands on chain.
• Never burned. The success fee is collected through the block revenue pipeline and is subject to SIMD-0123 commission rules, meaning it flows to the leader and is shareable with stakers.

How the fee gets declared is explicitly open: a new Compute Budget instruction, a field in the TxV1 transaction format (SIMD-0385), or something else. The author notes TxV1 may not have room, which could push this toward a future TxV2.

What it would change for builders

If you write trading systems, the pitch is direct: bid the opportunity, not the gas. A searcher who currently splits flow between Jito bundles and tip services could express success-conditional pricing in a plain transaction to any leader, not just ones running specific sidecar infrastructure. In the author's words, this "brings success-conditional fees into the protocol as a first-class citizen," and searchers "can also send directly to validator instead of having to send to a third party."

If you run a validator or delegate stake, the appeal is that revenue currently captured by out-of-protocol middlemen would ride normal block rewards and SIMD-0123 distribution. And if you build wallets or SDKs, you would eventually need to simulate for InsufficientFundsForSuccessFee and decide how to expose a second fee knob to users, though for ordinary payments and mints the correct setting is simply zero.

Failed transactions are not a niche concern. A 2025 study of failed Solana transactions presented at FSE ("Why Does My Transaction Fail?") attributed the bulk of failures to bots, with bot-initiated transactions failing at rates near 58%. Those failures pay full priority fees today, which is precisely the behavior a success-conditional bid would let honest flow route around.

Fee type        When charged        Amount basis       Destination
─────────────   ─────────────────   ────────────────   ─────────────────────
Base fee        on inclusion        per signature      split burn / leader
Priority fee    on inclusion        CU price x limit   leader (SIMD-0096)
Jito tip        on bundle success   flat, out-of-      tip accounts ->
                (atomic revert)     protocol           validators/stakers
Success fee     post-execution,     flat lamports      block revenue ->
(proposed)      only on status OK                      leader + stakers
                                                       (SIMD-0123 rules)

The objection that matters

The sharpest comment in the thread, from maurodelazeri, cuts at the design's middle ground: "Is success fee an ordering signal or not?" If leaders ignore it for ordering, it is pointless. If they order by it, then a fee that is visible at pack time but only maybe collectible after execution is a gameable signal. His conclusion: it "must be reserved/escrowed at pack time and released/refunded on failure. The current version sits in the bad middle: visible to the leader, allowed to affect ordering, but not reserved."

An earlier commenter, HGuillemet, sketched the attack: transactions that request huge CU budgets, attach a tiny priority fee and a gigantic success fee that will never actually pay out, and lock contended accounts while contributing nothing. The author's counters are that such spam is includable today anyway, that failed transactions revert market state so the opportunity survives for the next bidder, and that leaders could keep sorting primarily by priority fee, using success fees only as a tie-breaker among searchers. As of this writing the escrow objection has no reply in the thread.

There is also a lineage question hanging over the discussion. In-protocol tipping was proposed by Jito back in SIMD-0109, was expected to fold into SIMD-0123, and was cut. One commenter wants that finished rather than reinvented; the author agrees, with the constraint "static tips only." However it lands, the direction of travel is the same: success-conditional payment is moving from sidecar infrastructure toward the protocol.

Where this sits in the fee-reform stack

Success Fees does not arrive alone. The same author's SIMD-0553 (open since June) would restructure the base fee into a 2,500-lamport inclusion fee paid fully to the leader plus a burned resource fee scaled by requested compute. Success Fees explicitly stacks on top of whatever fee regime is active. Add SIMD-0123's block revenue distribution and the picture is a fee market being rebuilt around two principles: validators get paid for the work they do, and bidders pay for the outcome they get. Worth noting the interest on the label: cavemanloverboy works with Temporal, whose Nozomi service sells transaction landing today, so this is a proposal from inside the market it would reshape, and arguably one that would compete with it.

For now, nothing changes on mainnet. Watch the discussion for whether the escrow question gets a real answer; that, more than anything, will decide if this becomes a numbered SIMD.

Resources

• SIMD discussion #573: Success Fees: the proposal and the full comment thread
• solana-foundation/solana-improvement-documents: the SIMD repo; see also PRs 553 (resource and inclusion fee), 123 (block revenue distribution), 109 (the original tipping proposal), and 191 (fee-only transactions)
• Solana Changelog, July 9, 2026: where the proposal surfaced
• @cavemanloverboy: the author
• Why Does My Transaction Fail? (FSE 2025): the study on failed-transaction economics
• Related on devrels.xyz: priority fees in 2026, Jito block engine demystified, and Solana MEV and Paladin