Build1 publisher2 min readPublished
Trimming a Solana swap's compute limit to 80,000 units multiplies its queue rank by 17
Solana's leader ranks transactions by reward divided by the block space they request, so a wallet that leaves the compute-unit limit at 1.4 million units is bidding against its own request on every busy block.
The Engineer · Build desk
What happened
- Solana's block producer sorts pending transactions by one integer: the reward, meaning the priority fee plus the leader's unburned half of the base fee, times a million, divided by the transaction's cost plus one.
- Cost is what the cost model charges the block, at 720 compute units per signature, 300 per writable account lock, one unit per four bytes of instruction data, plus the full compute-unit limit requested.
- A transaction that sets no compute-unit limit is charged the default of 200,000 units per instruction, 3,000 for builtins, capped at 1.4 million units.
- In the worked swap, simulating first and then declaring 80,000 units and 210 KiB left the 200,000-lamport bid untouched and lifted the priority score from about 142,600 to about 2,431,600.
- Transactions with equal priority have been ordered by arrival time since 31 August 2026, so two milliseconds of network latency beat one extra lamport.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Bidding up the fee is the expensive route to the same place: on the example swap, keeping the per-unit price and letting the fee fall with the limit still outranks the original for about 11,400 lamports instead of 200,000, and the difference paid for block space the sender never used.
- decision The cheapest change is an instruction the post says most wallets never send, which puts landing rate in the hands of whoever writes the client code before it reaches whoever funds the fee budget.
- constraint A write lock holds whatever a transaction's rank is, so a desk trading against one hot pool is capped by that account's 24-million-unit share of the block no matter what it pays.
- exposure Automating the trim moves the failure mode from a missed block to a burned fee, so the simulation call and its margin have to live in the same code path as the send.
Every line item in the cost model comes from one conversion: 30 compute units for each microsecond of validator time a transaction is expected to consume [6]. The dev.to post reconstructs the formula from the validator source [19]. Divide the defaults by 30 and the reservation shows up as time. A 1,400,000-unit limit books about 46,700 microseconds of the leader's execution budget; the example swap actually uses 68,000 units, or about 2,270 [1]. The leader has no way to learn that before it runs the code, so it charges the block for what was requested [3].
That gain comes from one hand-built transaction. For the ratio to transfer, simulated usage has to sit about as far below the wallet default as this one does: the trimmed 80,000-unit limit is 5.7 percent of the 1,400,000 default [6]. A program that genuinely needs 1.2 million units has almost nothing to hand back, and its charged cost is close to honest already.
The loaded-accounts-data limit is the other reservation charged in rank. Fee is base fee plus per-unit price times the compute-unit limit, so the data reservation costs nothing in lamports [10]. Unset, it defaults to the maximum: 64 MiB, 2,048 pages at 8 units per page, 16,384 units against the block for a transaction that may load 50 KB [9]. Declaring 210 KiB instead costs 56 units [14]. At 30 units per microsecond, the default books 546 microseconds of validator time and the declared version books under 2 [2]. Against the tuned swap's total cost of 83,276 units, the untouched default alone would have been 19.7 percent [3].
The leader's buffer sits outside the ranking formula, the post says: it holds 100,000 packets, and at 99 percent full it publishes the priority of the lowest transaction it still holds; anything below that is discarded before signature verification [16]. The write lock sits outside it too. The scheduler will not run two transactions that write the same account at the same time, so a high-ranked swap on a hot pool waits for the lock, and once that pool has taken its 24-million-unit share of the block it waits for the next block [17]. So does the under-set limit: a compute-unit limit below actual usage is an error, and it burns the fee [18].
That last one bounds how hard the trim can go. The reference tooling adds 5 percent margin for state-dependent instructions, which on a measured 68,000 units works out to 71,400 [18][7]. The example sets 80,000, a margin of 17.6 percent over measured usage [8].
The `+ 1` in the denominator is there only to keep the division defined [4].
What to watch
- Wallets that set the compute-unit limit from a simulation result by default would close this gap; the post says most never send that instruction.
- Any revision to the 30-compute-units-per-microsecond conversion would reprice every line item in the cost model at once.
- Whether RPC providers and explorers begin reporting a transaction's block-space cost next to its lamport fee.