Solana developers propose major overhaul to address hidden risk that could disrupt its network

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.

Sources and evidence

Sources

1. Scope and conformance
2. Draft reference epoch

Supporting facts

• The draft landing page identifies its Mainnet reference epoch as E=1072; the scope starts an implementation from a trusted snapshot for that epoch or other state authenticated to an epoch-1072 root. [2] [1]
• The draft requires forward conformance within its reference epoch and does not require reproducing encodings or rule branches that stopped being accepted before that epoch. [1]
• The draft applies only to banks in reference epoch E and explicitly does not define the first bank of E+1, so conformance to this version alone does not establish continuous operation across that boundary. [1]
• Under the draft, an implementation starting at the last bank before E applies the epoch boundary transition once; a starting state already inside E must not apply it again. [1]
• Forward conformance leaves the starting snapshot or authenticated root as a trust input: the draft begins after that input has been accepted rather than requiring a new client to prove the entire earlier chain by replay. [1]

Method

Schematic based on the draft landing page and scope chapter captured November 4, 2026. Two selectable initialization states reproduce the draft’s boundary rule; geometry is qualitative, with no duration or performance scale.

Scope

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.

Infographic by CryptoSlate

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.