Solana developers are considering a major change to prevent disagreements between the software programs securing its crypto network. On October 30, 2026, Anza CEO Brennan Watt proposed creati
Solana developers are considering a major change to prevent disagreements between the software programs securing its crypto network. On October 30, 2026, Anza CEO Brennan Watt proposed creating a single official specification covering the blockchain’s operating rules. The draft already contains 18 technical sections, including transactions, consensus and validator rewards. The proposal aims to reduce the risk of conflicting interpretations that could disrupt the network.
Solana’s developers want to address a problem that could become more serious as its infrastructure expands. Although Fidelity recently highlighted Solana’s improved reliability while identifying three remaining weaknesses, the blockchain still faces challenges related to its validator software.
Validators are computers responsible for checking transactions, processing blocks and participating in the network’s consensus mechanism. They must follow identical rules to agree on which transactions are valid.
Solana currently supports several validator implementations. Agave, developed by Anza, remains one of the main clients. Firedancer, built by Jump Crypto, uses an independent software architecture.
Having different clients reduces dependence on a single codebase. A serious bug in one implementation does not necessarily affect the others.
However, independent software also introduces another risk. Two clients could interpret the same blockchain rule differently and produce conflicting results when processing identical transactions.
Such disagreements could disrupt consensus or, in severe cases, create temporary divisions in the network. No new incident of this kind has been reported in connection with Watt’s proposal.
The Anza executive believes the current documentation system makes this problem harder to manage.
Solana’s technical rules are spread across validator code and numerous Solana Improvement Documents, known as SIMDs. These documents describe individual upgrades but do not provide a complete reference for the entire protocol.
Developers sometimes need to examine previous proposals or study existing software to determine which rules are active. For teams building independent clients, this creates additional work and opportunities for inconsistencies.
Your 1st cryptos with BitgetThis link uses an affiliate program.Watt proposes replacing this fragmented approach with a shared technical specification. The initial draft already contains 18 sections covering major parts of Solana’s infrastructure. These include transaction processing, accounts, consensus, network communications, fees and validator rewards.
The document would serve as an authoritative reference for developers building validator software. Under the proposal, changes to the crypto protocol would still begin with technical discussions. However, developers would submit formal modifications directly to the common specification instead of maintaining separate descriptions of individual upgrades.
Each proposed change would need to identify the relevant rules and explain how the modification affects other parts of the network. Technical reviews and applicable governance procedures would remain in place. An amendment would become part of the official specification only after the corresponding change had been activated on Solana’s mainnet.
The timing matters because Solana recently introduced a major consensus upgrade. On October 21, the blockchain activated Alpenglow, replacing TowerBFT and targeting much faster transaction finality.
Alpenglow aims to reduce finality from approximately 12.8 seconds to around 150 milliseconds. Some components of the broader upgrade still require further deployment. As Solana changes its consensus and validator infrastructure, maintaining consistent technical documentation becomes increasingly important.
Firedancer developers would also benefit from a common specification. They could implement blockchain rules without relying primarily on Agave’s source code to determine the expected behavior. The proposal does not require Solana to abandon its existing validator clients or immediately change how users transfer SOL.
The proposed overhaul has not been approved. Developers have started discussing how the new specification should be maintained and how future protocol changes would enter the official document.
Jacob Creech, a contributor associated with the Solana Foundation, has raised questions about the numbering of improvement proposals and the procedure for reviewing amendments.
Other contributors have questioned how dependencies between different protocol sections should be documented. These issues matter because the official rulebook would need to remain accurate as the network continues to evolve.
One possible next step involves updating SIMD-0001, which currently defines Solana’s technical proposal process. No implementation date has been announced. The changes would primarily affect developers, validators and governance procedures rather than everyday crypto transactions.
A shared specification would not eliminate every software bug. Different programs can still contain independent coding mistakes even when their developers follow the same documentation.
Solana also faces other decentralization concerns. Fidelity’s October assessment found that approximately 18 validators controlled more than one-third of the staked SOL, while different validator configurations continued to share important parts of the same codebase. These issues are separate from the documentation problem Watt wants to address.
For the crypto industry, Solana’s proposal reflects the challenges of supporting several independent validator clients. Cointribune previously reported that Solana had lost 68% of its validators over three years, raising additional questions about the network’s structure. The new specification could improve coordination between development teams, but its effectiveness will depend on the quality of the rules and how consistently they are implemented.
