Solana developers are considering a new protocol rulebook designed to make independently developed validator software more reliable and easier to maintain.
The proposal, published Oct. 30, comes from Brennan Watt, CEO of Anza, the blockchain engineering company behind Agave, one of the main software programs used to operate the Solana network.
Watt wants Solana to establish a single, authoritative specification defining how its blockchain processes transactions, validates blocks and reaches consensus, rather than relying on rules scattered across existing software and separate technical proposals.
The change could address a growing challenge as Solana expands beyond its original validator software to include independently developed alternatives such as Firedancer, built by trading firm Jump Crypto.
Validators are computers that verify transactions and help secure the blockchain. Although different developers can create the software running these computers, every implementation must follow the same underlying rules to maintain agreement across the network.
Disagreements over those rules could cause validators to process identical transactions differently, potentially creating conflicting views of the blockchain and threatening network reliability.
Watt argues that Solana's existing development process makes it unnecessarily difficult for independent teams to determine exactly how the network is supposed to behave.
Under the current system, protocol changes are proposed through Solana Improvement Documents, known as SIMDs. These documents describe individual upgrades, but the network's complete operating rules are not consolidated into one authoritative reference.
As a result, developers sometimes have to examine existing validator code or reconstruct previous upgrade decisions to understand which rules are active.
Watt said this approach can produce repeated or inconsistent descriptions of existing behavior while making it harder to identify every part of the protocol affected by a proposed upgrade.
New rulebook could reshape Solana's upgrade process
Under the proposal, developers would continue discussing potential upgrades through the existing SIMD process, but formal technical changes would be submitted as edits to a shared protocol specification.
Each amendment would describe precisely how the upgrade affects transactions, network communications, consensus and other relevant functions.
The changes would undergo technical review and any required governance approvals before becoming part of the official specification when activated on Solana's Mainnet.
This would allow teams developing Agave, Firedancer and future validator software to work from the same documented requirements rather than relying on another implementation's code as their primary reference.
Where does the client start?
Child-bank construction applies the epoch-E boundary transition once before its transactions.
A common rulebook makes the target explicit. Starting-state trust and the next epoch remain separate requirements.
This is a draft specification, not an adopted protocol change. It does not establish starting-state correctness, historical replay or continuous operation into E+1. No client reliability gain is quantified.
It could also make software testing more effective. When independent validators produce different results, developers would have a common standard against which to examine the disagreement and identify which implementation needs correction.
Watt has already published a draft specification covering 18 areas of Solana's operations, including transaction processing, network communications, consensus, fees, and validator rewards.
However, the draft remains limited to a defined period of Solana's blockchain history and assumes developers begin from an already trusted network state. Further work would be needed to cover subsequent upgrades and establish that implementations remain compatible over time.