Success Fees

[cavemanloverboy]

Success Fees

Motivation

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.

We introduce success fees: fees that are charged only if a transaction succeeds. Searchers and traders already do this out-of-protocol today (Jito bundles, Harmonic, etc.). This proposal brings success-conditional fees into the protocol as a first-class citizen.

Proposal

Add an optional success fee to transactions: a flat lamport amount (not lamports per CU), paid only if the transaction succeeds.

Success fees are a complement to priority fees, not a replacement. A transaction MAY specify both. Priority fee remains the upfront signal for ordering and inclusion; success fee is for expressing a bid tied to opportunity size — when an opportunity of size S appears, the number of CUs used to capture it is irrelevant. Schedulers can use the success fee to inform their ordering rules.

There is no reasonable in-protocol alternative other than doing nothing and keeping out-of-protocol solutions. This solution, however, is distinct from existing out-of-protocol solutions because there is no total revert protect (users still pay the failure fee).

Mechanism

Fee components

Success fee stacks on top of the transaction's existing fees — whatever the network already charges today (base fee, priority fee, and resource fee under SIMD-0553 if active, etc.). We call those existing charges the failure fee: what you pay when the transaction is included but does not successfully collect a success fee. On full success, you pay existing fees + success fee.

Success fee is collected through the block revenue pipeline and is subject to SIMD-0123 commission rules.

Pre-execution balance check — unchanged

The fee payer balance check at packing / pre-execution time is unchanged. It covers existing fees only, not the success fee. A transaction whose balance covers existing fees but not the success fee is still valid for inclusion.

Success fee collection — post-execution

After all instructions complete with transaction status OK, the runtime attempts to debit the success fee from the fee payer.

• Debit succeeds → transaction is successful; fee payer pays existing fees plus success fee.
• Debit fails (fee payer cannot afford the success fee) → transaction is marked failed with a new error InsufficientFundsForSuccessFee. On-chain state is reverted (same reversion rules as today — e.g. insufficient funds for rent), nonce still advances, and the fee payer is charged existing fees only (no success fee).

This is the same class of outcome as existing post-execution balance failures, and is consistent with how out-of-protocol success fees (tips) behave today.

When success fee is not charged:

• Execution failure (status not OK) → existing fees only.
• Loading failure / fee-only path (SIMD-0191) → existing fees only.
• InsufficientFundsForSuccessFee → existing fees only, state reverted.

Leaders see the declared success fee at pack time and MAY use it for ordering / inclusion alongside priority fee. Payment is not guaranteed until the post-execution debit succeeds (the fee payer may spend down balance during execution). Same pattern as other post-execution balance checks.

Simulation

simulateTransaction MUST surface InsufficientFundsForSuccessFee when the post-execution debit would fail — same as any other transaction error today.

Who benefits

Stakers and validators. Bots and searchers can move success-conditional value in-protocol instead of through out-of-protocol solutions, so that all REV flows through normal block rewards. Bots and searchers can also send directly to validator instead of having to send to a third party.

At first order there is no change to the validator revenue model. Second-order: retail may shift from upfront priority fee to success fee (higher income variance for leaders); bots will likely increase success fees and prefer the in-protocol path over out-of-protocol tips.

Wallets can display success fees the same way they already display out-of-band success fees today.

Security Considerations

Unlike bundle paths with total revert protection (where a failed tx may not even pay the normal fee), a transaction that fails still pays failure fee. Therefore, we do not expect the same level of crank arb spam that we see with out-of-protocol solutions... and any associated write account lock DoS that we see through these avenues.

Drawbacks / complexity

Two fee knobs (priority + success) — but no more complexity than the existing out-of-protocol tip / bundle solutions traders already use.

Open design questions

• Wire format: new Compute Budget instruction, TxV1 TransactionConfigMask field, or something else? Default success fee = 0 when unset.
• TxV1 real estate: we may need a new transaction field; if TxV1 (SIMD-0385) has no room (i haven't looked lol), this may require TxV2.

Compatibility with in protocol ordering + async execution

This section is only for the eager core protocol enthusiasts among us. In the past some of us had discussions about how success fees are not compatible with in protocol ordering + async execution. The primary counterargument was essentially: "how do we sort if we do not know execution results? If we only sort by priority fee, there is no incentive to add a success fee".

I am the person that originally brought up this point and killed the momentum to pass success fees, but I've realized that this not a valid counterargument. To see why, consider the following scenario of a blockchain with multiple game-theoretic-optimizing searchers at play:

1. There is a retail user transaction which pays some priority P, which will change some market's state that will generate some capturable value V.
2. Searchers are only willing to bid priority with budget V. If P < V, then they only need to pay priority P-ε to succesfully backrun, and they capture V-P+ε.
3. If there are multiple searchers all with priority=V-P+ε, tie breaking can be done via:
   a. Success Fee. The searcher which bids the highest success fee (rationally, up to V-P+ε).
   b. Lexicographically ordered whitened signature (xor of all signatures in question, minus the candidate txn signature)

This form of tie breaking via success fee does two things (compared with the baseline of not doing it):

1. more value captured by the network and distributed to validators and stakers
2. prevents PoW type signature mining.

[HGuillemet]

I agree with your first impression: validators cannot prioritize according to rewards only collected if the tx succeeds.

In your example, you assume that searchers have access to a mempool (and Temporal now contributes to normalize this).
In a prio-fees-only world without mempools, validators / stakers will naturally earn ~ V.

I'd prefer a solution that technically addresses mempools and spams rather than supporting them.

[cavemanloverboy]

To point 1: even for transactions with reasonably low success rate, sorting by total fee isn't that unreasonable. any txns that come first that failed will have all market state reverted and original opportunity with value V will still be present.

in fact, you could even sort by total fee in async with protocol ordering and everything would be fine. you'd just front load a lot of failed txns that don't mess with any markets but paid resource fees :D

as for mempools, i don't think orderflow auctions will ever go away, and it's possible to create nonfrontrunnable systems. in the endgame, the user sees either no impact or positive impact (value captured and rebated)

[HGuillemet]

Ordering by total fees opens the door to abuses. For instance you mentioned account lock DoS: even with the proposed system, you still can receive txs consuming 1.4M CU , paying no prio fee, or 1 µL/CU, and gigantic success fees that will always fail. Your resource fees proposal would make this kind of attack more costly, but them it depends on the value at stake.

[cavemanloverboy]

1. such transactions are includable today

2. sorting by prio fee would put these transactions at the end instead of at the beginning. For some failure F and success S, executing in order FS vs SF results in the same end state.

[HGuillemet]

Right, but with many F you may well never include S. S is from a legit user and its execution is denied, and it would bring more reward to validator. Or did I miss something ?

[dimandotsol]

#109 (comment)

So this thing was supposed to be part of 123

But as I understand it, while working on 123 they cut it out from there and then conveniently forgot about it

On the other hand https://discord.com/channels/428295358100013066/673718028323782674/1398307418936709140

But I’m not entirely sure what Trent meant by “and being worked on”; maybe he just thought it was still part of 123…

[cavemanloverboy]

time to take it across the finish line brother

static tips only though