WouldExceedMaxBlockCostLimit

The transaction would push the current block beyond its compute unit budget if included. The block is full.

Two variants of this error

The account-level limit exists to prevent a single hot account (like a popular AMM pool) from consuming all block capacity.

Common causes

1. High network congestion. During heavy load, blocks fill up and lower-priority transactions get rejected.
2. Hot account contention. Many transactions compete for the same writable account, hitting the 12M CU per-account limit.
3. Transaction requests too many CUs. A transaction with a high SetComputeUnitLimit is harder to fit into a nearly-full block.

How to fix

1. Add priority fees. Use SetComputeUnitPrice to increase your transaction’s priority. Higher-priority transactions are included first.
2. Reduce requested CUs. Set SetComputeUnitLimit to the minimum your transaction actually needs. Simulate first to find the exact amount, then add a 10–20% buffer.
3. Retry with backoff. This is a transient error — the next block may have capacity.
4. Use Stake-Weighted QoS (SWQoS). Transactions forwarded through staked validators get guaranteed bandwidth. This requires sending to a staked RPC node.

FAQ

What is the maximum compute budget per block? 48 million compute units per block, with a maximum of 12 million CUs per writable account per block.

How does priority fee help? The scheduler sorts transactions by their priority fee (compute unit price). Higher-fee transactions are included first when block space is limited.

Is this different from “Program failed to complete”? Yes. “Program failed to complete” means your transaction exceeded its own CU limit during execution. Block cost limit means the block as a whole cannot fit your transaction.

Updated: 2026-10-21