Archived article · Original source date: 2024-08-23
This article is preserved from the previous Solana Bulls site as a historical archive. It reflects its original context; references to products, people, market conditions, eligibility, or rules may no longer be current.
Changing a live blockchain requires more than publishing an idea. A feature must be specified, implemented in relevant validator clients, tested for compatibility and performance, and activated in a way that preserves consensus.
Design and Solana Improvement Documents
Material protocol proposals can be documented in the public Solana Improvement Documents repository. A proposal's status matters: discussion or acceptance does not prove that code is implemented or active on mainnet.
Client implementation and review
Engineering teams implement changes in validator clients such as Agave and Firedancer. Consensus-critical behavior requires compatible implementations, code review, tests, benchmarks, and security analysis.
Test networks and feature activation
Changes may be exercised on local clusters, test environments, Devnet, and Testnet before mainnet. Many runtime changes use feature gates so activation can be coordinated after sufficient software adoption.
Validator operators decide which released client software to run. Stake-weighted adoption and operational coordination matter for consensus upgrades; holding SOL does not provide a universal direct vote over every code change.
Monitoring and incident response
- Monitor performance and correctness before and after activation.
- Publish release notes and operator requirements.
- Maintain rollback or mitigation plans where the change permits them.
- Distinguish proposed, implemented, activated, and fully adopted features.
For current status, inspect the proposal, relevant client repositories, release notes, feature activation evidence, and network announcements rather than relying on a static article alone.