SIP-1: Solana Improvement Proposal Process and Guidelines
What Is an SIP?
A Solana Improvement Proposal (SIP) is a formal design document that outlines a proposed change, feature, or process for the Solana blockchain or its ecosystem. Each SIP provides a concise technical specification of the proposal and the rationale behind it. SIPs serve as the primary mechanism for the Solana community to propose new features, modifications, or standards, to collect technical feedback, and to document the decision-making process.
An SIP author (also called a champion) is responsible for writing the proposal, rallying community consensus, and seeing the proposal through to resolution. All SIPs are archived in a public repository, allowing the community to review, discuss, and contribute.
SIPs are reserved for changes that have broad impact or require coordination across the ecosystem – for example, modifications to core consensus rules, changes to the network protocol or RPC API, or new standards that will be adopted by multiple programs or clients.
SIP Types
There are two primary types of Solana Improvement Proposals:
- Standards Track SIP: Proposes a change that affects multiple Solana implementations or impacts interoperability across the Solana ecosystem. This includes any proposal that alters the network protocol, consensus rules, client APIs/RPC interfaces, or on-chain program standards. We subdivide Standards Track SIPs into categories:
- Core: Changes to core protocol or consensus that may require a coordinated network upgrade. Core proposals typically must be discussed with Solana core engineers and may be subject to off-chain governance signaling before implementation.
- Networking: Improvements to Solana’s peer-to-peer network layer or gossip protocol.
- Interface: Proposals that affect external interfaces, such as client APIs, JSON-RPC endpoints, or SDK libraries used by applications and wallets.
- Solana Request for Comments (SRC): Application-level standards and conventions, including on-chain program and smart contract standards. Examples include token standards, NFT metadata formats, naming system protocols, or other contract interface specifications.
- Runtime (BPF/VM): Improvements to Solana’s runtime environment for executing programs. These include proposals to introduce new syscalls or instructions, adjust compute fee costs, enhance the capabilities of on-chain programs, or otherwise change the behavior of the runtime.
- Informational SIP: Offers general guidelines, definitions, or information to the Solana community without proposing a new feature to the Solana codebase. Informational SIPs can describe design principles, development processes, toolchain conventions, or other matters of community interest. They do not require consensus or network upgrades and are not binding. SIP-1 is itself an Informational SIP because it describes the SIP process and does not introduce a protocol change.
Note: Each SIP should focus on a single key proposal or idea. Minor changes that only affect a single implementation usually do not require a SIP; only changes with cross-implementation impact or those that aim to establish a new standard for the ecosystem should go through the SIP process.
Roles and Responsibilities
SIP Author (Champion)
The author is the proposal’s champion. Key responsibilities include:
- Drafting the Proposal: Writing a clear, detailed SIP document using the prescribed template.
- Soliciting Feedback: Presenting the idea to the community and incorporating feedback.
- Building Consensus: Working to gain support from various stakeholders.
- Revising and Updating: Continuously improving the SIP document as new insights are gained.
- Responding to Reviews: Engaging with formal reviews by SIP editors or core developers.
- Reference Implementation (if applicable): For Standards Track proposals, the author may be expected to provide a reference implementation or proof-of-concept.
SIP Editors
SIP Editors are experienced community members entrusted with administrating the SIP process. Their main duties include:
- Review for Format and Completeness: Ensuring proposals adhere to the required template and style.
- Assigning SIP Numbers: SIPs are numbered sequentially upon acceptance of the draft.
- Merging and Publishing Drafts: After number assignment, the editor merges the SIP into the official repository.
- Status Changes: Editors update an SIP’s status as it moves through the process.
- Ensuring Clarity and Consensus: Editors can delay progression if an SIP is unclear or if there’s obvious lack of consensus.
- Repository Maintenance: Editors maintain the SIP repository’s health.
- Neutrality: SIP Editors do not judge the technical merit of a proposal. The decision to accept or reject a proposal content-wise is driven by community and core developer consensus.
Solana Core Developers and Maintainers
For proposals in the Core category, the Solana core development team plays a crucial decision-making role. Their responsibilities include:
- Technical Evaluation: Core developers review Core and Runtime SIPs for feasibility, correctness, and impact on the network.
- Coordination and Discussion: Core proposals typically need to be discussed in dedicated forums with the core team and validator community.
- Signaling Acceptance: For a Core SIP to move forward, the core developers must come to an agreement to implement the change in a future release.
- Implementation and Network Upgrade: Once accepted, core developers are responsible for integrating the changes into the Solana core codebase.
- Governance and Finalization: Once the change is successfully implemented and activated on the network, the SIP can be moved to “Final” status.
For non-core proposals, community consensus is the primary factor. The ultimate test for non-core SIPs is adoption: whether many projects implement a new standard, or whether wallet providers accept a new Interface guideline.
SIP Workflow: Proposal Process
1. Idea Formation & Preliminary Discussion
Every SIP begins with an idea. Before investing time in writing a formal proposal, an author should gauge interest and gather early feedback from the community. This includes:
- Community Forum or Discussion Board: Start by posting the idea in an appropriate public forum.
- Solicit Feedback: Invite others to weigh in.
- Research and Due Diligence: Ensure the idea is original or acknowledge prior related proposals.
- Feasibility Consultation: Reach out to core team members to assess technical feasibility.
2. Drafting the SIP
Once the idea has been honed, the author proceeds to write a draft SIP document following the official SIP template. Key points:
- Use the SIP Markdown Template
- Provide a Clear Summary and Motivation
- Detailed Specification
- Backward Compatibility and Impact
- Reference Implementation or Tests (if available)
- Discussions-To Link
- Follow Style Guidelines
3. Submitting a Pull Request
The author submits the proposal to the SIP repository as a Pull Request (PR):
- One Proposal per PR
- PR Title: Should be descriptive
- Fill Metadata Placeholders
- Include a Link to Discussion in PR Description
- Address CI/Format Issues
4. Draft Review and Number Assignment
After submission, the draft SIP undergoes an initial review by SIP editors to verify:
- Correct Structure and Fields
- Clarity and Language
- Duplication and Scope
If the draft passes these checks, the SIP editor will assign an official SIP number and merge the PR. The SIP’s status is set to “Draft”.
5. Draft Phase and Iteration
The Draft status is an active state in which the SIP can evolve:
- Open Discussion Continues
- Revisions via Pull Requests
- Version Control
- Gathering Consensus
- Abandonment of Drafts: If an author stops engaging, the SIP may be moved to “Abandoned” status.
6. Last Call (Final Review)
When the SIP author believes the proposal is mature, they can request to transition to Last Call status:
- Author Request
- Editor Action – Status Update: The editor updates the status to Last Call and sets a review deadline (typically at least two weeks).
- Announcement of Last Call
- Minimal Changes: Only minor edits are allowed during Last Call.
- Handling Objections
7. Decision and Acceptance
After the Last Call period concludes:
- For Standards Track – Core (and possibly Runtime) SIPs: Final approval comes from the core maintainers. If approved, the SIP’s status is updated to “Accepted.” If declined, it’s marked “Rejected.”
- For Standards Track – Non-Core SIPs and Informational SIPs: These rely on community consensus. After Last Call, if there are no outstanding objections, an editor can move the SIP directly to “Final” status.
8. Final Status and Implementation
An SIP that reaches Final status is considered completed and normative:
- For non-core SIPs, Final means the proposal has been accepted by the community as a standard or reference.
- For core SIPs, Final usually is reached after the changes have actually been implemented in the Solana network.
9. Post-Final Maintenance
After an SIP has attained Final status, its content is intended to remain stable:
- No Substantive Changes
- Editorial Corrections: Minor non-normative edits are allowed to improve readability.
- Living Documents – Active Status: Some SIPs can be designated as Active to indicate they’re subject to change.
- Historical Reference
10. Other Outcome States
- Deferred: An SIP moved to Deferred when the idea is acknowledged but not currently actionable.
- Abandoned: An Abandoned SIP is one no longer being considered or worked on.
- Rejected: An SIP deemed unsuitable or if consensus is that it should not be implemented.
- Superseded: Used when a Final SIP is later replaced by a new proposal.
- Active: A special status for proposals that remain in use and might be continuously updated.
SIP Format and Structure
Each Solana Improvement Proposal follows a standard format with two main parts:
- The SIP Header – a block of metadata at the top of the document.
- The SIP Body – the detailed text of the proposal, divided into well-defined sections.
SIP Header
sip: <SIP number>
title: <Short Descriptive Title>
author: <Author Name or Username <email@domain.com>>
discussions-to: <URL of discussion thread or issue>
status: <Draft | Last Call | Accepted | Final | Active | Deferred | Rejected | Superseded | Abandoned>
type: <Standards Track | Informational>
category: <Core | Networking | Interface | SRC | VM> (required for Standards Track SIPs only)
created: <YYYY-MM-DD>
requires: <SIP number(s)> (optional)
replaces: <SIP number(s)> (optional)
Explanation of each field:
sip:Unique identification number assigned by SIP Editors.title:Short, descriptive title (ideally under 44 characters).author:Name(s) or handle(s) of the author(s) with contact info.discussions-to:URL pointing to the discussion venue.status:Current status of the SIP.type:Either Standards Track or Informational.category:Used only for Standards Track SIPs. One of: Core, Networking, Interface, SRC, VM.created:Date when the first draft was created (YYYY-MM-DD).requires:(Optional) Lists SIP numbers this proposal depends on.replaces:(Optional) Lists SIP numbers this proposal supersedes.
SIP Body
The body of the SIP contains the rich content structured into sections:
- Simple Summary: A few sentences in plain language summarizing the proposal.
- Abstract: A one-paragraph technical summary of the proposal.
- Motivation: Explains why the change is necessary or useful.
- Specification: The core technical section describing the details of the proposed change with precision.
- Rationale: Discusses why the specification is designed the way it is, particularly if there were alternative approaches considered.
- Backward Compatibility: Details how the proposal impacts backward compatibility.
- Test Cases: (Required for consensus changes) Provides examples or scenarios to illustrate how the system will behave.
- Implementation: Describes the current status or plans for implementation.
- Security Considerations: (Optional) Discusses any security implications of the proposal.
Additional sections as needed:
- Copyright
- References
Referencing Other SIPs and Assets
- Referencing another SIP: Use the format “SIP-N”.
- Images and Diagrams: Must be added to the SIP repository’s
assets/folder. - Relative Paths: Always use relative paths for linking to other files in the repository.
Managing SIP Changes and Versioning
Draft Updates
While an SIP is in Draft status, authors are free to update the content via new pull requests.
Changing Status
The status of an SIP is changed via Pull Request by editors, ensuring the required conditions are met.
Final SIP Updates
When an SIP reaches Final status, no normative changes are allowed. Only cosmetic or clarification fixes are permitted.
Superseding and Replacing
When drafting a new SIP that obsoletes an old one, include replaces: <old SIP number> in the header.
Dependencies (Requires)
The requires: field lists dependencies. An SIP cannot be finalized until the required SIPs are at least Accepted or Final.
Coordination with Software Versions
For proposals implemented in core Solana software, note the version/release in the Implementation section.
Conclusion
SIP-1 establishes the framework for an open and orderly evolution of the Solana protocol and ecosystem. By defining how Solana Improvement Proposals are created, discussed, and accepted, we aim to increase transparency, community participation, and technical rigor in Solana’s development process.
Under this SIP-1 process, anyone in the community has a clear path to propose changes or standards. The structured workflow ensures that proposals are thoroughly reviewed and that decisions are documented. The roles defined create accountability and support.
The Solana Foundation and core contributors are encouraged to adopt and support this SIP process. Once ratified, SIP-1 will become the cornerstone “Active” document guiding all future Solana improvements.