Solana developers have proposed increasing the network’s block compute limit from 48 million to 50 million units to handle more transactions and enhance network efficiency.
According to details shared on GitHub via a Solana improvement document, this incremental increase aims to improve transaction processing without compromising the network’s performance.
Andrew Fitzgerald, a software developer at Anza and the proposal’s author, mentioned on X that the idea is still in draft form. This indicates that further refinements could occur before final approval.
The proposal
A block limit is a safeguard, ensuring that most network participants can keep pace with activity by restricting how much work can fit into a block. The incremental increase to 50 million compute units (CU) adds capacity while preparing client systems for future performance enhancements.
The proposed change focuses only on increasing the Max Block Units to create more capacity for non-vote transactions. The Max Writable Account Units remain unchanged since no immediate need exists to boost individual account capacity. This approach provides additional parallel processing capability without disrupting the system’s balance.
Meanwhile, the proposal noted that a significant jump to 96 million compute units is not feasible at this stage. Such a move could introduce unforeseen challenges, particularly for infrastructure supporting the network’s users.
Instead, Solana plans to raise these limits gradually as its technology evolves to ensure seamless performance.
Community welcomes move
Market observers pointed out that the update illustrates Solana’s commitment to measured growth, prioritizing network stability while pushing the boundaries of blockchain scalability.
Mert Mumtaz, CEO of Helius Labs, noted that the proposal reflects Solana’s commitment to scalability. He stated that the adjustment supports higher performance and would enable the network to process more transactions without sacrificing stability.
Mumtaz also described the move as a calculated step that lets developers monitor its impact on block execution time before considering further increases.
