Solana weighs one shared rulebook to stop its clients clashing

Solana's rulebook is scattered, and Anza CEO Brennan Watt wants to fix that. On October 30 he pitched a single official specification spelling out how the blockchain actually operates, according to Cointribune. The draft already runs 18 sections deep, covering transactions, accounts, consensus, network communications, fees and validator rewards.

The problem Watt is chasing: Solana runs on multiple validator clients, and they all have to agree. Agave, built by Anza, is one of the main ones; Firedancer, from Jump Crypto, was written on an independent architecture. Different codebases mean one nasty bug doesn't take down the whole network — but they also mean two clients can read the same rule two ways and spit out conflicting results, which could scramble consensus or briefly split the chain.

Today those rules live inside validator code and a pile of Solana Improvement Documents, or SIMDs. Each SIMD describes one upgrade, not the whole protocol, so developers hunting for the active rules have to dig through old proposals or reverse-engineer existing software. Watt's answer is one shared reference: protocol changes would still start as technical discussions, but formal edits would land in the common spec, flag the rules they touch and note the knock-on effects. An amendment only joins the official document after it's live on mainnet.

Timing isn't a coincidence. Solana switched on Alpenglow on October 21, swapping out TowerBFT and aiming to cut finality from roughly 12.8 seconds to about 150 milliseconds — with some pieces of the broader upgrade still pending. Firedancer's team would also get a rulebook that doesn't require leaning on Agave's source code to guess expected behavior. Nothing here forces Solana to drop a client, and it doesn't change how ordinary users move SOL.

It's not a done deal. Developers are still arguing over how the spec gets maintained and how future changes enter it. Jacob Creech, a contributor tied to the Solana Foundation, questioned how improvement proposals get numbered and how amendments get reviewed, while others pushed on how dependencies between protocol sections should be documented. One candidate next step: updating SIMD-0001, which defines the proposal process itself. No implementation date has been set.

A shared spec won't kill every bug — separate programs can still carry separate coding mistakes under identical documentation. Solana has other structural headaches too: Fidelity's October assessment found about 18 validators controlling more than a third of staked SOL, with different configurations still sharing chunks of the same codebase. Cointribune has also reported the network shed 68% of its validators over three years. Better documentation could tighten coordination between dev teams, but only if the rules are good and everyone actually follows them.