Jump Trading’s Firedancer team has proposed eliminating Solana’s fixed compute unit block limits, allowing validators to dynamically scale transaction capacity based on their hardware performance rather than arbitrary protocol restrictions. The SIMD-0370 proposal would create market-driven incentives where block producers continuously upgrade equipment to pack more transactions and earn higher revenues. The proposal follows Solana’s overwhelmingly approved Alpenglow consensus upgrade, which received 99.60% validator support with 149.3 million SOL voting in favor. Alpenglow introduces skip-vote mechanisms that make fixed block limits redundant by automatically bypassing blocks that take too long to execute. Under the current system, network capacity is artificially constrained by compute unit limits rather than actual validator capabilities. Firedancer argues that this creates perverse incentives, where superior hardware provides no competitive advantage, thereby stifling innovation and network growth. However, despite its innovative sound, the proposal has sparked some community debate, with critics warning about potential centralization. They argued that validators with expensive hardware could dominate, while smaller operators struggle to keep pace. Others question compatibility with future multiple concurrent proposer designs that may require synchronized execution limits. Hardware Arms Race Could Transform Network Economics The proposal would create a competitive flywheel, where block producers must continuously improve their performance to maximize transaction fees and maintain their market share. Validators running slower client software would face reduced profitability, incentivizing rapid adoption of performance improvements across the ecosystem. Firedancer developers argue that superior validator clients would capture larger market shares as operators seek higher rewards.Source: GitHub This competition would drive faster innovation cycles compared to manual limit increases that require community consensus and lengthy implementation periods. The system relies on Stackelberg competition dynamics where block producers signal network capacity through slightly larger blocks, coordinating upgrades without explicit communication. Validators unable to process these larger blocks would skip them, creating natural feedback loops that prevent excessive block sizes from forming. Critics raise concerns about centralization pressures as geographic proximity to block producers provides execution advantages. Additionally, validators requiring expensive hardware upgrades to remain competitive could exclude smaller operators from the network entirely. Community members questioned whether new validators could sync from snapshots if block complexity increases rapidly. The proposal acknowledges these risks but argues that replay performance typically exceeds block production speed, maintaining reasonable barriers for network participation.Source: GitHub Technical Hurdles Challenge Implementation Timeline Being a new proposal, developer discussions have also revealed significant concerns about compatibility with future protocol upgrades, particularly multiple concurrent proposer architectures that may require block limits for asynchronous execution. The Firedancer team argues these features remain uncertain and should not constrain current improvements. Community feedback also highlighted potential failure modes during rapid capacity scaling, including scenarios where advancing execution speeds could push networks below critical vote thresholds. Some developers suggested epoch shortening as mitigation, though this approach carries additional complexity. The proposal requires careful coordination of timeout mechanisms across different validator implementations, as execution abortion methods vary significantly between clients. Current designs must ensure proper block dissemination through networking stacks without creating bottlenecks or propagation failures. Several validators expressed support for removing artificial constraints while demanding comprehensive testing frameworks before implementation. The timing coincides with pending Solana ETF approvals, as seven major asset managers filed updated S-1 forms with regulators in late September. ETF analyst Nate Geraci suggested approvals could arrive by mid-October, potentially driving institutional demand for SOL tokens. The REX-Osprey Solana Staking ETF already launched with $33 million in trading volume and $12 million in first-day inflows, demonstrating growing institutional interest. Looking forward, the removal of compute limits will be a fundamental shift toward market-based capacity scaling, which contrasts with Ethereum’s fee auction model and Bitcoin’s fixed block sizes. Although new, a successful implementation could enhance Solana’s speed and make it retain its status as a high-performance blockchain, which Ethereum and BNB Chain have been threatening lately. However, implementation risks require careful management to preserve network stability, which is not yet guaranteed, based on the current state of the community discussionJump Trading’s Firedancer team has proposed eliminating Solana’s fixed compute unit block limits, allowing validators to dynamically scale transaction capacity based on their hardware performance rather than arbitrary protocol restrictions. The SIMD-0370 proposal would create market-driven incentives where block producers continuously upgrade equipment to pack more transactions and earn higher revenues. The proposal follows Solana’s overwhelmingly approved Alpenglow consensus upgrade, which received 99.60% validator support with 149.3 million SOL voting in favor. Alpenglow introduces skip-vote mechanisms that make fixed block limits redundant by automatically bypassing blocks that take too long to execute. Under the current system, network capacity is artificially constrained by compute unit limits rather than actual validator capabilities. Firedancer argues that this creates perverse incentives, where superior hardware provides no competitive advantage, thereby stifling innovation and network growth. However, despite its innovative sound, the proposal has sparked some community debate, with critics warning about potential centralization. They argued that validators with expensive hardware could dominate, while smaller operators struggle to keep pace. Others question compatibility with future multiple concurrent proposer designs that may require synchronized execution limits. Hardware Arms Race Could Transform Network Economics The proposal would create a competitive flywheel, where block producers must continuously improve their performance to maximize transaction fees and maintain their market share. Validators running slower client software would face reduced profitability, incentivizing rapid adoption of performance improvements across the ecosystem. Firedancer developers argue that superior validator clients would capture larger market shares as operators seek higher rewards.Source: GitHub This competition would drive faster innovation cycles compared to manual limit increases that require community consensus and lengthy implementation periods. The system relies on Stackelberg competition dynamics where block producers signal network capacity through slightly larger blocks, coordinating upgrades without explicit communication. Validators unable to process these larger blocks would skip them, creating natural feedback loops that prevent excessive block sizes from forming. Critics raise concerns about centralization pressures as geographic proximity to block producers provides execution advantages. Additionally, validators requiring expensive hardware upgrades to remain competitive could exclude smaller operators from the network entirely. Community members questioned whether new validators could sync from snapshots if block complexity increases rapidly. The proposal acknowledges these risks but argues that replay performance typically exceeds block production speed, maintaining reasonable barriers for network participation.Source: GitHub Technical Hurdles Challenge Implementation Timeline Being a new proposal, developer discussions have also revealed significant concerns about compatibility with future protocol upgrades, particularly multiple concurrent proposer architectures that may require block limits for asynchronous execution. The Firedancer team argues these features remain uncertain and should not constrain current improvements. Community feedback also highlighted potential failure modes during rapid capacity scaling, including scenarios where advancing execution speeds could push networks below critical vote thresholds. Some developers suggested epoch shortening as mitigation, though this approach carries additional complexity. The proposal requires careful coordination of timeout mechanisms across different validator implementations, as execution abortion methods vary significantly between clients. Current designs must ensure proper block dissemination through networking stacks without creating bottlenecks or propagation failures. Several validators expressed support for removing artificial constraints while demanding comprehensive testing frameworks before implementation. The timing coincides with pending Solana ETF approvals, as seven major asset managers filed updated S-1 forms with regulators in late September. ETF analyst Nate Geraci suggested approvals could arrive by mid-October, potentially driving institutional demand for SOL tokens. The REX-Osprey Solana Staking ETF already launched with $33 million in trading volume and $12 million in first-day inflows, demonstrating growing institutional interest. Looking forward, the removal of compute limits will be a fundamental shift toward market-based capacity scaling, which contrasts with Ethereum’s fee auction model and Bitcoin’s fixed block sizes. Although new, a successful implementation could enhance Solana’s speed and make it retain its status as a high-performance blockchain, which Ethereum and BNB Chain have been threatening lately. However, implementation risks require careful management to preserve network stability, which is not yet guaranteed, based on the current state of the community discussion