Skip to content

Bound the sponsored priority fee instead of the compute unit price - #4959

Merged
squadgazzz merged 4 commits into
mainfrom
solana-orderbook/cap-sponsored-priority-fee
Sep 22, 2026
Merged

squadgazzz merged 4 commits into
mainfrom
solana-orderbook/cap-sponsored-priority-fee

Conversation

@squadgazzz

@squadgazzz squadgazzz commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

Description

The funder pays the transaction fee on a sponsored order, and part of that fee is the priority fee the client chooses. So a placement decides how much of the funder's balance it spends, and POST /api/v1/orders is public.

The priority fee is compute unit price * compute unit limit. Today only the price is capped, which leaves the product free: a price comfortably under the cap, paired with the maximum limit, still costs the funder 0.0014 SOL per order. The number worth bounding is the fee itself, so that is what this bounds.

It comes from config because congestion is not predictable from code and raising the ceiling should not need a release. The default of 100000 lamports is two cents at 200 dollars per SOL, and close to a thousand times what a real sponsored creation pays: the last one on chain paid 113 lamports of priority fee, S9LaNbET8j53nUB1FP3JJAHi..., total fee 10113 against a 10000 base for two signatures.

Changes

  • [sponsoring] max-priority-fee-lamports, default 100000, replaces the compute unit price cap
  • The price and the limit are read together and the implied fee is checked once. A transaction declaring no limit is priced at the network's compute ceiling, since it may consume up to it
  • A repeated compute-budget instruction is rejected, since the runtime rejects it too and the value we read would never be the one that runs

How to test

New unit tests and an updated integration test. The integration case pairs a price below the old cap with a limit that breaks the new ceiling, so the current code accepts it and this one refuses it.

@squadgazzz
squadgazzz marked this pull request as ready for review September 22, 2026 16:04
@squadgazzz
squadgazzz requested a review from a team as a code owner September 22, 2026 16:04
@squadgazzz
squadgazzz force-pushed the solana-orderbook/cap-sponsored-priority-fee branch from 6e7830e to d398507 Compare September 22, 2026 16:28
Comment on lines 137 to 141
/// Roughly a thousandth of a cent at 200 dollars per SOL, and four orders of
/// magnitude above what wallets set today.
fn default_max_priority_fee_lamports() -> u64 {
100_000
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might be off.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100,000 lamports = 0.0001 SOL = $0.02 at $200/SOL.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked a real one on chain, https://explorer.solana.com/tx/S9LaNbET8j53nUB1FP3JJAHib8QK2p7KtrKYAVctaTTxXJVqXyGqAfxQfUTmcPrVaMj9XoyyxnvVsgvQrNnFRfn pays 113 lamports of priority fee (total 10113, base 10000 for two signatures).

So the default is around 1000x today's traffic, not what I wrote in the comment. Kept 100000 though, since wallets raise the price 10x to 100x under congestion, and I would rather overpay 2 cents than reject real placements on a bad day. Comment fixed.

@squadgazzz
squadgazzz added this pull request to the merge queue Sep 22, 2026
Merged via the queue into main with commit 7ed15fd Sep 22, 2026
24 of 25 checks passed
@squadgazzz
squadgazzz deleted the solana-orderbook/cap-sponsored-priority-fee branch September 22, 2026 19:59
@github-actions github-actions Bot locked and limited conversation to collaborators Sep 22, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants