Anza's Brennan Watt has proposed changing how Solana SOL$95.50-2.2% protocol changes are written down. In a GitHub discussion opened on 30 October 2026, titled "Move to Protocol Spec", Watt (GitHub handle bw-solana) suggests that a protocol change should no longer be a standalone Solana Improvement Document (SIMD). Each change would instead be a pull request against one living Solana protocol specification, merged only when the change goes live on Mainnet. It is a proposal for feedback. Nothing has been adopted, and no decision or schedule has been announced.
Watt has already written the starting point. His post links a draft of a full Solana Protocol Specification with 18 chapters, from account state and transactions through Proof of History, shreds, consensus and voting, to fees and rewards. The draft gives its Mainnet reference epoch as 1072, which is the live one. According to Solana Compass epoch data, epoch 1072 was about 77% complete at 21:23 UTC on 30 October, and recent epochs have lasted a little over a day. In that epoch 691 validators held active stake, each running client software that has to follow the same rules.
Why Solana has no single protocol specification today
Solana's rules are spread across years of SIMDs and the code of its validator clients. Under the current process, defined in SIMD-0001, each proposal is a self-contained document that moves through statuses such as Draft, Review, Accepted, Implemented and Activated. Once activated, it stays a separate document. Nothing gathers the active rules into one place.
Watt's post lists four problems that follow. Proposals that change existing behaviour often have no way to reference it except by linking to a client's code or redefining it inline, so the same behaviour gets defined repeatedly, "sometimes in slightly different ways." Reviewers struggle to tell whether a proposal has covered every part of the protocol it touches. Standalone SIMDs share no common structure. And newcomers have to reverse-engineer how the protocol is meant to work from client implementations.
The problem is sharper now that Solana runs more than one validator client. Anza builds Agave, and Jump Crypto's Firedancer is a separately written client, so the two codebases have to agree on every rule. Jump Crypto's Michael McGee has talked through that conformance problem before. Under the proposal, each spec pull request would describe "the complete normative change, including byte layouts, state transitions, error behavior, limits, feature interactions," and anything else "needed for independent implementations to agree."
How the spec pull request process would replace standalone SIMDs
Ideas would still start in SIMD Discussions, the open GitHub forum where the sol_math syscall debate began this week and where Watt floated his block compute limit increase earlier in October. There an idea gets an initial concept ACK, an acknowledgement that it is worth specifying in detail. A proposal ready for detail would become a pull request that edits the specification itself. Each change keeps a stable SIMD number from discussion to activation, and the same technical review, contributor ACKs and governance approval would still apply.
The specification is organised by protocol domain: transactions, runtime, consensus, networking, ledger format, programs and so on. A proposal has to edit every domain it affects, which Watt argues makes omissions visible in review: if a change touches transaction validation, runtime execution, fees and consensus, reviewers can see whether all four sections changed. Large features that cut across domains can also get their own entry in a "Features" section.
The merge rule is the sharpest change. "A specification pull request does not merge just because the design has been accepted, implemented, or activated on another cluster," Watt wrote. A change merges when it becomes active on Mainnet, and the spec is versioned by Mainnet epoch, so the merged text always describes the live network. Corrections that make the spec match behaviour already on Mainnet can merge without a feature activation. Proposals that depend on each other would be stacked like code branches, and meta proposals about governance or process would stay standalone documents.
The model resembles a consolidated statute book. Bills are debated separately, but the book is amended only when a law takes effect, so anyone can read the rules as they stand today.
Migrating existing SIMDs to spec pull requests, and next steps for SIMD-0001
Watt proposes cataloguing every SIMD in Draft, Review, Accepted or Implemented status that is not yet active on Mainnet, then turning each into a spec pull request that keeps its SIMD number and links back to the original document and implementation work. Those pull requests would stay open until Mainnet activation. SIMDs already active would be covered by the baseline specification, with any gaps handled as errata.
For the stage between approval and activation, Watt suggests keeping the pull request open with an "accepted for implementation" label and a maintainer comment pinning the approved commit, so client teams can build against fixed text. If there is broad agreement, his listed next steps are a rewrite of SIMD-0001 covering repository ownership, review authority, labels and identifier assignment, and agreement on which baseline spec to cut over to and where to host it.
Early feedback on discussion #716 from Jacob Creech and alnoki
Two replies had arrived by the evening of 30 October. Jacob Creech of the Solana Foundation, a maintainer of the SIMD repository and a co-author of SIMD-0001, argued that a SIMD number should be assigned only when an idea graduates from discussion to a pull request, rather than at the discussion stage. He also asked whether a spec change found during testing would send a proposal from "Accepted for implementation" back to "Proposal review", and said the specification should live in the existing SIMD repository.
Developer alnoki said spec-driven development is "overall the right option" but asked how the process would catch dependencies inside the protocol that client code currently surfaces, suggesting "some kind of specification dependency chart."
Ethereum offers one comparison. It keeps execution-specs, "an executable Python reference implementation of Ethereum's execution layer, along with the test cases that verify it." Watt's draft is a written specification and his post does not propose executable tests. The open question is whether Solana's maintainers and client teams agree to make it the record they build against.
