SIPs

Sila Improvement Proposals (SIPs) describe standards for the Sila platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the Sila Project Management repository.

Contributing

First review SIP-1. Then clone the repository and add your SIP to it. There is a template SIP here. Then submit a Pull Request to Sila's SIPs repository.

SIP status terms

• Idea - An idea that is pre-draft. This is not tracked within the SIP Repository.
• Draft - The first formally tracked stage of an SIP in development. An SIP is merged by an SIP Editor into the SIP repository when properly formatted.
• Review - An SIP Author marks an SIP as ready for and requesting Peer Review.
• Last Call - This is the final review window for an SIP before moving to FINAL. An SIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the SIP to Review.
• Final - This SIP represents the final standard. A Final SIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
• Stagnant - Any SIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An SIP may be resurrected from this state by Authors or SIP Editors through moving it back to Draft.
• Withdrawn - The SIP Author(s) have withdrawn the proposed SIP. This state has finality and can no longer be resurrected using this SIP number. If the idea is pursued at later date it is considered a new proposal.
• Living - A special status for SIPs that are designed to be continually updated and not reach a state of finality. This includes most notably SIP-1.

SIP Types

SIPs are separated into a number of types, and each has its own list of SIPs.

Standards Track (1138)

Describes any change that affects most or all Sila implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Sila. Furthermore Standard SIPs can be broken down into the following categories.

Core (437)

Improvements requiring a consensus fork (e.g. SIP-5, SIP-211), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in SIP-225).

Networking (28)

Includes improvements around devp2p (SIP-8) and Light Sila Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.

Interface (59)

Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (SIP-6) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an SIP is submitted to the SIPs repository.

SRC (614)

Application-level standards and conventions, including contract standards such as token standards (SIP-20), name registries (SIP-137), URI schemes (SIP-681), library/package formats (SIP-190), and account abstraction (SIP-4337).

Meta (43)

Describes a process surrounding Sila or proposes a change to (or an event in) a process. Process SIPs are like Standards Track SIPs but apply to areas other than the Sila protocol itself. They may propose an implementation, but not to Sila's codebase; they often require community consensus; unlike Informational SIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Sila development. Any meta-SIP is also considered a Process SIP.

Informational (23)

Describes a Sila design issue, or provides general guidelines or information to the Sila community, but does not propose a new feature. Informational SIPs do not necessarily represent Sila community consensus or a recommendation, so users and implementers are free to ignore Informational SIPs or follow their advice.