From 0733c3e1ed34c3d369b8a9fadaccae4f26c2a928 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 22:56:29 -0400 Subject: [PATCH 01/29] Create Replaced SIPs --- sips/sip-000/Replaced SIPs | 1 + 1 file changed, 1 insertion(+) create mode 100644 sips/sip-000/Replaced SIPs diff --git a/sips/sip-000/Replaced SIPs b/sips/sip-000/Replaced SIPs new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/sips/sip-000/Replaced SIPs @@ -0,0 +1 @@ + From fa7a8e648d6727f2db06a534b074fca62549a143 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 22:57:15 -0400 Subject: [PATCH 02/29] =?UTF-8?q?Rename=20sips/sip-000/Replaced=20SIPs=20t?= =?UTF-8?q?o=20sips/sip-000/=E2=80=9C/Replaced=20SIPs=E2=80=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sip-000/\342\200\234/Replaced SIPs\342\200\234" | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/sip-000/Replaced SIPs => "sips/sip-000/\342\200\234/Replaced SIPs\342\200\234" (100%) diff --git a/sips/sip-000/Replaced SIPs "b/sips/sip-000/\342\200\234/Replaced SIPs\342\200\234" similarity index 100% rename from sips/sip-000/Replaced SIPs rename to "sips/sip-000/\342\200\234/Replaced SIPs\342\200\234" From 4e43b9dab322157db72977a56f9eb4f73efd842d Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 22:59:18 -0400 Subject: [PATCH 03/29] =?UTF-8?q?Delete=20sips/sip-000/=E2=80=9C/Replaced?= =?UTF-8?q?=20SIPs=E2=80=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "sips/sip-000/\342\200\234/Replaced SIPs\342\200\234" | 1 - 1 file changed, 1 deletion(-) delete mode 100644 "sips/sip-000/\342\200\234/Replaced SIPs\342\200\234" diff --git "a/sips/sip-000/\342\200\234/Replaced SIPs\342\200\234" "b/sips/sip-000/\342\200\234/Replaced SIPs\342\200\234" deleted file mode 100644 index 8b1378917..000000000 --- "a/sips/sip-000/\342\200\234/Replaced SIPs\342\200\234" +++ /dev/null @@ -1 +0,0 @@ - From 42701a7e8c9539f39460ddc9d8da36e949ee490d Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 22:59:42 -0400 Subject: [PATCH 04/29] Create replaced SIPs --- sips/sip-000/replaced SIPs | 1 + 1 file changed, 1 insertion(+) create mode 100644 sips/sip-000/replaced SIPs diff --git a/sips/sip-000/replaced SIPs b/sips/sip-000/replaced SIPs new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/sips/sip-000/replaced SIPs @@ -0,0 +1 @@ + From 269585292446fd2593f74068dd35b7a2665a8787 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:00:28 -0400 Subject: [PATCH 05/29] Delete sips/sip-000/replaced SIPs --- sips/sip-000/replaced SIPs | 1 - 1 file changed, 1 deletion(-) delete mode 100644 sips/sip-000/replaced SIPs diff --git a/sips/sip-000/replaced SIPs b/sips/sip-000/replaced SIPs deleted file mode 100644 index 8b1378917..000000000 --- a/sips/sip-000/replaced SIPs +++ /dev/null @@ -1 +0,0 @@ - From 723643c63146362d872bc39ae706f980101bc724 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:02:32 -0400 Subject: [PATCH 06/29] Create readme.md --- sips/sip-000/replaced SIPs/readme.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 sips/sip-000/replaced SIPs/readme.md diff --git a/sips/sip-000/replaced SIPs/readme.md b/sips/sip-000/replaced SIPs/readme.md new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/sips/sip-000/replaced SIPs/readme.md @@ -0,0 +1 @@ + From cf08c7598873510602dd43677f203abaee86bed1 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:04:10 -0400 Subject: [PATCH 07/29] Rename sips/sip-000/sip-000-stacks-improvement-proposal-process.md to sips/sip-000/replaced SIPs/sip-000-stacks-improvement-proposal-process.md --- .../sip-000-stacks-improvement-proposal-process.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/sip-000/{ => replaced SIPs}/sip-000-stacks-improvement-proposal-process.md (100%) diff --git a/sips/sip-000/sip-000-stacks-improvement-proposal-process.md b/sips/sip-000/replaced SIPs/sip-000-stacks-improvement-proposal-process.md similarity index 100% rename from sips/sip-000/sip-000-stacks-improvement-proposal-process.md rename to sips/sip-000/replaced SIPs/sip-000-stacks-improvement-proposal-process.md From f1d16ea87b16a2113ee2264dea778400c99014b4 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:10:06 -0400 Subject: [PATCH 08/29] Rename sips/sip-000/replaced SIPs/readme.md to sips/sip-000/sip-000/replaced SIPs/readme.md --- sips/sip-000/{ => sip-000}/replaced SIPs/readme.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/sip-000/{ => sip-000}/replaced SIPs/readme.md (100%) diff --git a/sips/sip-000/replaced SIPs/readme.md b/sips/sip-000/sip-000/replaced SIPs/readme.md similarity index 100% rename from sips/sip-000/replaced SIPs/readme.md rename to sips/sip-000/sip-000/replaced SIPs/readme.md From 3e238b733683e565903ce32b791aea2c433cc631 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:10:53 -0400 Subject: [PATCH 09/29] Rename sips/sip-000/sip-000/replaced SIPs/readme.md to sips/sip-000/sip-000replaced SIP.readme.md --- .../replaced SIPs/readme.md => sip-000replaced SIP.readme.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/sip-000/{sip-000/replaced SIPs/readme.md => sip-000replaced SIP.readme.md} (100%) diff --git a/sips/sip-000/sip-000/replaced SIPs/readme.md b/sips/sip-000/sip-000replaced SIP.readme.md similarity index 100% rename from sips/sip-000/sip-000/replaced SIPs/readme.md rename to sips/sip-000/sip-000replaced SIP.readme.md From 43522bd17cc3713accc56f6c113a22dccfade003 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:12:44 -0400 Subject: [PATCH 10/29] Rename sip-000replaced SIP.readme.md to sip-replaced SIP.readme.md --- .../{sip-000replaced SIP.readme.md => sip-replaced SIP.readme.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/sip-000/{sip-000replaced SIP.readme.md => sip-replaced SIP.readme.md} (100%) diff --git a/sips/sip-000/sip-000replaced SIP.readme.md b/sips/sip-000/sip-replaced SIP.readme.md similarity index 100% rename from sips/sip-000/sip-000replaced SIP.readme.md rename to sips/sip-000/sip-replaced SIP.readme.md From 462962b3b8f832de05e16ac051b45a45e9c6db4d Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:15:42 -0400 Subject: [PATCH 11/29] sip-000-1.md --- sips/sip-000/sip-replaced SIP.readme.md | 850 ++++++++++++++++++++++++ 1 file changed, 850 insertions(+) diff --git a/sips/sip-000/sip-replaced SIP.readme.md b/sips/sip-000/sip-replaced SIP.readme.md index 8b1378917..a213fb07b 100644 --- a/sips/sip-000/sip-replaced SIP.readme.md +++ b/sips/sip-000/sip-replaced SIP.readme.md @@ -1 +1,851 @@ +# Preamble + +SIP Number: 000 + +Title: Stacks Improvement Proposal Process + +Author: Jude Nelson , Ken Liao + +Consideration: Governance + +Type: Meta + +Status: Ratified + +Created: 2020-06-23 + +License: BSD-2-Clause + +Sign-off: Jude Nelson , Technical Steering Committee Chair + +Discussions-To: https://github.com/stacksgov/sips + +# Abstract + +A Stacks Improvement Proposal (SIP) is a design document that provides +information to the greater Stacks ecosystem's participants concerning the design +of the Stacks blockchain and its ongoing operation. Each SIP shall provide a +clear and concise description of features, processes, and/or standards for the +Stacks blockchain and its operators to adopt, with sufficient details provided +such that a reasonable practitioner may use the document to create an +independent but compatible implementation of the proposed improvement. + +SIPs are the canonical medium by which new features are proposed and described, +and by which input from the Stacks ecosystem participants is collected. The SIP +Ratification Process is also described in this document, and provides the means +by which SIPs may be proposed, vetted, edited, accepted, rejected, implemented, +and finally incorporated into the Stacks blockchain's design, governance, and +operational procedures. The set of SIPs that have been ratified shall +sufficiently describe the design, governance, and operationalization of the +Stacks blockchain, as well as the means by which future changes to its official +design, implementation, operation, and governance may be incorporated. + +# License and Copyright + +This SIP is made available under the terms of the BSD-2-Clause license, +available at https://opensource.org/licenses/BSD-2-Clause. This SIP’s copyright +is held by the Stacks Open Internet Foundation. + +# Introduction + +Blockchains are unique among distributed systems in that they also +happen to encode a social contract. By running a blockchain node, a user +implicitly agrees to be bound to the social contract's terms embedded within the +blockchain's software. These social contracts are elaborate constructions that +contain not only technical terms (e.g. "a block may be at most 1MB"), but also +economic terms (e.g. "only 21 million tokens may exist") and social terms (e.g. +"no money can leave this account" or "this transaction type was supported +before, but will now be ignored by the system") which the user agrees to uphold +by running a blockchain node. + +It stands to reason that the Stacks blockchain is made of more than just +software; it is also made of the people who run it. As such, the act of +developing and managing the Stacks blockchain network includes the act of +helping its people coordinate and agree on what the blockchain is and what it +should do. To this end, this document proposes a process by which the Stacks +blockchain's users can conduct themselves to be the stewards of the blockchain +network in perpetuity. + +The goals of this process are to ensure that anyone may submit a SIP in good +faith, that each SIP will receive fair and speedy good-faith consideration by +other people with the relevant expertise, and that any discussions and +decision-making on each SIP's ratification shall happen in public. To achieve +these ends, this document proposes a standard way of presenting a Stacks +Improvement Proposal (SIP), and a standard way of ratifying one. + +Each SIP document contains all of the information needed to propose a +non-trivial change to the way in which the Stacks blockchain operates. This +includes both technical considerations, as well as operational and governance +considerations. This document proposes a formal document structure based on both +request-for-comments (RFC) practices in the Internet Engineering Task Force +(IETF), as well as existing blockchain networks. + +SIPs must be ratified in order to be incorporated into the definition of what +the Stacks blockchain is, what it does, and how it operates. This document +proposes a ratification process based on existing governance processes from +existing open source projects (including Python, Bitcoin, Ethereum, and Zcash), +and makes provisions for creating and staffing various roles that people must +take on to carry out ratification (e.g. committees, editors, working groups and +so on). + +This document uses the word “users” to refer specifically to people who +participate in the greater Stacks ecosystem. This includes, but is not limited +to, people who mine blocks, people who contribute code, people who run nodes, +people who develop applications that rely on the Stacks blockchain, people who +use such applications, people involved in the project governance, and people +involved in operating software deployments. + +# Specification + +Each SIP shall adhere to the same general formatting and shall be ratified +through the processes described by this document. + +## SIP Format + +All SIPs shall be formatted as markdown files. Each section shall be +annotated as a 2nd-level header (e.g. `##`). Subsections may be added with +lower-level headers. + +Each SIP shall contain the following sections, in the given order: + +- _Preamble_. This section shall provide fields useful for categorizing the SIP. + The required fields in all cases shall be: + - _SIP Number_. Each SIP receives a unique number once it has been accepted + for consideration for ratification (see below). This number is assigned to + a SIP; its author does not provide it. + - _Title_. A concise description of the SIP, no more than 20 words long. + - _Author_. A list of names and email addresses of the SIP's author(s). + - _Consideration_. What class of SIP this is (see below). + - _Type_. The SIP track for consideration (see below). + - _Status_. This SIP's point in the SIP workflow (see below). + - _Created_. The ISO 8601 date when this SIP was created. + - _License_. The content license for the SIP (see below for permitted + licenses). + - _Sign-off_. The list of relevant persons and their titles who have worked to + ratify the SIP. This field is not filled in entirely until ratification, + but is incrementally filled in as the SIP progresses through the ratification + process. +- Additional SIP fields, which are sometimes required, include: + - _Layer_. The logical layer of the Stacks blockchain affected. Must be one + - of the following: + - _Consensus (soft fork)_. For backwards-compatible proposals for + transaction-processing. + - _Consensus (hard fork)_. For backwards-incompatible proposals for + transaction-processing. + - _Peer Services_. For proposals to the peer-to-peer network protocol + stack. + - _API/RPC_. For proposals to the Stacks blockchain's official + programmatic interfaces. + - _Traits_. For proposals for new standardized Clarity trait definitions. + - _Applications_. For proposals for standardized application protocols + that interface with the Stacks blockchain. + - _Discussions-To_. A mailing list where ongoing discussion of the SIP takes + place. + - _Comments-Summary_. The comments summary tone. + - _Comments-URI_. A link to the Stacks blockchain wiki for comments. + - _License-Code_. Abbreviation for code under a different license than the SIP + proposal. + - _Post-History_. Dates of posting the SIP to the Stacks mailing list, or a + link to a thread with the mailing list. + - _Requires_. A list of SIPs that must be implemented prior to this SIP. + - _Replaces_. A list of SIPs that this SIP replaces. + - _Superceded-By_. A list of SIPs that replace this SIP. + +- _Abstract_. This section shall provide a high-level summary of the proposed + improvement. It shall not exceed 5000 words. +- _Copyright_. This section shall provide the copyright license that governs the + use of the SIP content. It must be one of the approved set of licenses (see +below). +- _Introduction_. This section shall provide a high-level summary of the + problem(s) that this SIP proposes to solve, as well as a high-level +description of how the proposal solves them. This section shall emphasize its +novel contributions, and briefly describe how they address the problem(s). Any +motivational arguments and example problems and solutions belong in this +section. +- _Specification_. This section shall provide the detailed technical + specification. It may include code snippets, diagrams, performance +evaluations, and other supplemental data to justify particular design decisions. +However, a copy of all external supplemental data (such as links to research +papers) must be included with the SIP, and must be made available under an +approved copyright license. +- _Related Work_. This section shall summarize alternative solutions that address + the same or similar problems, and briefly describe why they are not adequate +solutions. This section may reference alternative solutions in other blockchain +projects, in research papers from academia and industry, other open-source +projects, and so on. This section must be accompanied by a bibliography of +sufficient detail such that someone reading the SIP can find and evaluate the +related works. +- _Backwards Compatibility_. This section shall address any + backwards-incompatiblity concerns that may arise with the implementation of +this SIP, as well as describe (or reference) technical mitigations for breaking +changes. This section may be left blank for non-technical SIPs. +- _Activation_. This section shall describe the timeline, falsifiable criteria, + and process for activating the SIP once it is ratified. This applies to both +technical and non-technical SIPs. This section is used to unambiguously +determine whether or not the SIP has been accepted by the Stacks users once it +has been submitted for ratification (see below). +- _Reference Implementations_. This section shall include one or more references + to one or more production-quality implementations of the SIP, if applicable. +This section is only informative — the SIP ratification process is independent +of any engineering processes (or other processes) that would be followed to +produce implementations. If a particular implementation process is desired, +then a detailed description of the process must be included in the Activation +section. This section may be updated after a SIP is ratified in order to +include an up-to-date listing of any implementations or embodiments of the SIP. + +Additional sections may be included as appropriate. + +### Supplemental Materials + +A SIP may include any supplemental materials as +appropriate (within reason), but all materials must have an open format +unencumbered by legal restrictions. For example, an LibreOffice `.odp` +slide-deck file may be submitted as supplementary material, but not a Keynote +`.key` file. + +When submitting the SIP, supplementary materials must be present within the same +directory, and must be named as `SIP-XXXX-YYY.ext`, where: + +- `XXXX` is the SIP number, +- `YYY` is the serial number of the file, starting with 1, +- `.ext` is the file extension. + +## SIP Types + +The types of SIPs are as follows: + +- _Consensus_. This SIP type means that all Stacks blockchain implementations + would need to adopt this SIP to remain compatible with one another. If this is +the SIP type, then the SIP preamble must have the Layer field set to either +_Consensus (soft fork)_ or _Consensus (hard fork)_. +- _Standard_. This SIP type means that the proposed change affects one or more + implementations, but does not affect network consensus. If this is the SIP +type, then the SIP preamble must have the Layer field set to indicate which +aspect(s) of the Stacks blockchain are affected by the proposal. +- _Operation_. This SIP type means that the proposal concerns the operation of the + Stacks blockchain -- in particular, it concerns node operators and miners. +The difference between this SIP type and the Standard type is that this type +does not change any existing protocols. +- _Meta_. This SIP type means that the proposal concerns the SIP ratification + process. Such a SIP is a proposal to change the way SIPs are handled. +- _Informational_. This is a SIP type that provides useful information, but does + not require any action to be taken on the part of any user. + +New types of SIPs may be created with the ratification of a Meta-type SIP under +the governance consideration (see below). SIP types may not be removed. + +## SIP Considerations + +A SIP's consideration determines the particular steps needed to ratify the SIP +and incorporate it into the Stacks blockchain. Different SIP considerations have +different criteria for ratification. A SIP can have more than one consideration, +since a SIP may need to be vetted by different users with different domains of +expertise. + + +- _Technical_. The SIP is technical in nature, and must be vetted by users with + the relevant technical expertise. +- _Economic_. The SIP concerns the blockchain's token economics. This not only + includes the STX token, but also any on-chain tokens created within smart +contracts. SIPs that are concerned with fundraising methods, grants, bounties, +and so on also belong in this SIP track. +- _Governance_. The SIP concerns the governance of the Stacks blockchain, + including the SIP process. This includes amendments to the SIP Ratification +Process, as well as structural considerations such as the creation (or removal) +of various committees, editorial bodies, and formally recognized special +interest groups. In addition, governance SIPs may propose changes to the way by +which committee members are selected. +- _Ethics_. This SIP concerns the behaviors of office-holders in the SIP + Ratification Process that can affect its widespread adoption. Such SIPs +describe what behaviors shall be deemed acceptable, and which behaviors shall be +considered harmful to this end (including any remediation or loss of privileges +that misbehavior may entail). SIPs that propose formalizations of ethics like +codes of conduct, procedures for conflict resolution, criteria for involvement +in governance, and so on would belong in this SIP consideration. +- _Diversity_. This SIP concerns proposals to grow the set of users, with an + emphasis on including users who are traditionally not involved with +open-source software projects. SIPs that are concerned with evangelism, +advertising, outreach, and so on must have this consideration. + +Each SIP consideration shall have a dedicated Advisory Board that ultimately +vets SIPs under their consideration for possible ratification in a timely +fashion (see below). New considerations may be created via the ratification of +a Meta-type SIP under the governance consideration. + +## SIP Workflow + +As a SIP is considered for ratification, it passes through multiple statuses as +determined by one or more committees (see next section). A SIP may have exactly +one of the following statuses at any given time: + +- _Draft_. The SIP is still being prepared for formal submission. It does not yet + have a SIP number. +- _Accepted_. The SIP text is sufficiently complete that it constitutes a + well-formed SIP, and is of sufficient quality that it may be considered for +ratification. A SIP receives a SIP number when it is moved into the Accepted +state by SIP Editors. +- _Recommended_. The people responsible for vetting the SIPs under the + consideration(s) in which they have expertise have agreed that this SIP should +be implemented. A SIP must be Accepted before it can be Recommended. +- _Activation-In-Progress_. The SIP has been tentatively approved by the Steering + Committee for ratification. However, not all of the criteria for ratification +have been met according to the SIP’s Activation section. For example, the +Activation section might require miners to vote on activating the SIPs’ +implementations, which would occur after the SIP has been transferred into +Activation-In-Progress status but before it is transferred to Ratified status. +- _Ratified._ The SIP has been activated according to the procedures described in + its Activation section. Once ratified, a SIP remains ratified in perpetuity, +but a subsequent SIP may supersede it. If the SIP is a Consensus-type SIP, and +then all Stacks blockchain implementations must implement it. A SIP must be +Recommended before it can be Ratified. Moving a SIP into this state may be done +retroactively, once the SIP has been activated according to the terms in its +Activation section. +- _Rejected_. The SIP does not meet at least one of the criteria for ratification + in its current form. A SIP can become Rejected from any state, except +Ratified. If a SIP is moved to the Rejected state, then it may be re-submitted +as a Draft. +- _Obsolete_. The SIP is deprecated, but its candidacy for ratification has not + been officially withdrawn (e.g. it may warrant further discussion). An +Obsolete SIP may not be ratified, and will ultimately be Withdrawn. +- _Replaced_. The SIP has been superseded by a different SIP. Its preamble must + have a Superseded-By field. A Replaced SIP may not be ratified, nor may it be +re-submitted as a Draft-status SIP. It must be transitioned to a Withdrawn +state once the SIP(s) that replace it have been processed. +- _Withdrawn_. The SIP's authors have ceased working on the SIP. A Withdrawn SIP + may not be ratified, and may not be re-submitted as a Draft. It must be +re-assigned a SIP number if taken up again. + + +The act of ratifying a SIP is the act of transitioning it to the Ratified status +-- that is, moving it from Draft to Accepted, from Accepted to Recommended, and +Recommended to Activation-In-Progress, and from Activation-In-Progress to +Ratified, all without the SIP being transitioned to Rejected, Obsolete, +Replaced, or Withdrawn status. A SIP's current status is recorded in its Status +field in its preamble. + +## SIP Committees + +The act of deciding the status of a SIP is handled by a set of designated +committees. These committees are composed of users who dedicate their time and +expertise to curate the blockchain, ratifying SIPs on behalf of the rest of the +ecosystem’s users. + +There are three types of committee: + +- _Steering Committee (SC)_. The roles of the SC are to select Recommended-status + SIPs to be activated, to determine whether or not a SIP has been activated and +thus ratified, and to formally recognize Consideration Advisory Boards (see +below). +- _Consideration Advisory Boards_. The roles of the Consideration Advisory Boards + are to provide expert feedback on SIPs that have been moved to Accepted status +in a timely manner, and to transition SIPs to Recommended status if they meet +the Board's consideration criteria, and Rejected status otherwise. +- _SIP Editors_. The role of the SIP Editors is to identify SIPs in the Draft + status that can be transitioned to Accepted status. A SIP editor must be able +to vet a SIP to ensure that it is well-formed, that it follows the ratification +workflow faithfully, and that it does not overlap with any already-Accepted SIPs +or SIPs that have since become Recommended or Ratified. + +Any user may serve on a committee. However, all Stacks committee members must +abide by the SIP Code of Conduct and must have a history of adhering to it. +Failure to adhere to the Code of Conduct shall be grounds for immediate removal +from a committee, and a prohibition against serving on any future committees. + +### Compensation + +Compensation for carrying out committee duties is outside of the scope of this +document. This document does not create a provision for compensation for +committee participation, but it does not forbid it either. + +### Steering Committee Duties + +The Steering Committee's overarching duty is to oversee the evolution of the +Stacks blockchain’s design, operation, and governance, in a way that is +technically sound and feasible, according to the rules and procedures described +in this document. The SC shall be guided by and held accountable by the greater +community of users, and shall make all decisions with the advice of the relevant +Consideration Advisory Boards. + +The SC’s role is that of a steward. The SC shall select SIPs for ratification +based on how well they serve the greater good of the Stacks users. Given the +nature of blockchains, the SC's particular responsibilities pertaining to +upgrading the blockchain network are meant to ensure that upgrades happen in a +backwards-compatible fashion if at all possible. While this means that more +radical SIPs may be rejected or may spend a long amount of time in Recommended +status, it also minimizes the chances of an upgrade leading to widespread +disruption (the minimization of which itself serves the greater good). + +#### Membership + +The initial Steering Committee shall be comprised of at least three members: +two from the Stacks Open Internet Foundation, and one +from the greater Stacks blockchain community (independent of the Stacks +Foundation). + +A provisional Steering Committee will be appointed by the Stacks Open Internet Foundation Board +before the launch of the Stacks blockchain’s mainnet (see the "Activation" section). +Once this SIP activates, the Stacks Open Internet Foundation shall select its +representatives in a manner of their choosing within 90 days after activation. +The committee may be expanded later to include more seats. Once this SIP +activates, the provisional SC will consult with the community to +ratify a SIP that implements a voting procedure whereby +Stacks community members can select the individual who will serve on the +community SC seat. + +#### Qualifications + +Members of this committee must have deep domain expertise +pertinent to blockchain development, and must have excellent written +communication skills. It is highly recommended that members should have authored +at least one ratified technical-consideration SIP before joining this committee. + +#### Responsibilities + +The Steering Committee shall be responsible for the following +tasks. + +##### Recognizing Consideration Advisory Boards. + +The members of the Steering Committee +must bear in mind that they are not infallible, and that they do not know everything +there is to know about what is best for the broader user community. To the +greatest extent practical, the SC shall create and foster the development of +Consideration Advisory Boards in order make informed decisions on subjects that +in which they may not be experts. + +Any group of users can form an unofficial working group to help provide feedback +to SIPs, but the SC shall have the power to recognize such groups formally as a +Consideration Advisory Board via at least a two-thirds majority vote. The SC +shall simultaneously recognize one of it’s member to serve as the interim +chairperson while the Advisory Board forms. A SC member cannot normally serve on +a Consideration Advisory Board concurrently with serving on the SC, unless +granted a limited exception by a unanimous vote by the SC (e.g. in order to +address the Board’s business while a suitable chairperson is found). Formally +recognizing Consideration Advisory Boards shall occur in Public Meetings (see +below) no more than once per quarter. + +Once recognized, Consideration Advisory Boards may not be dissolved or +dismissed, unless there are no Accepted or Recommended SIPs that request their +consideration. If this is the case, then the SC may vote to rescind recognition +of a Consideration Advisory Board with a two-thirds majority at one of its +Public Meetings. + +In order to identify users who would form a Consideration Advisory Board, users +should organize into an unofficial working group and submit a SIP to petition +that SC recognize the working group as a Consideration Advisory Board. This +petition must take the form of a Meta-type SIP, and may be used to select the +initial chairperson and define the Board's domain(s) of expertise, bylaws, +membership, meeting procedures, communication channels, and so on, independent +of the SC. The SC would only be able to ratify or reject the SIP. + +The SC shall maintain a public index of all Consideration Advisory Boards that +are active, including contact information for the Board and a summary of what +kinds of expertise the Board can offer. This index is meant to be used by SIP +authors to help route their SIPs towards the appropriate reviewers before being +taken up by the SC. + +##### Voting on Technical SIPs + +The Steering Committee shall select Recommended SIPs +for ratification by moving them to Activation-In-Progress status. All +technical-consideration SIPs shall require an 80% vote. If it is a +Consensus-type SIP for a hard fork, then a unanimous vote shall be required. If +a SIP is voted on and is not moved to Activation-in-Progress, then it shall be +moved to Rejected status, and the SC shall provide a detailed explanation as to +why they made their decision (see below). + +##### Voting on Non-technical SIPs + +Not all SIPs are technical in nature. All +non-technical SIPs shall require only a two-thirds majority vote to transition +it to Activation-In-Progress status. The SC members must provide a public +explanation for the way it voted as supplementary materials with the ratified +non-technical SIP (see below). If the SC votes to move a non-technical SIP to +Activation-In-Progress status, but does not receive the requisite number of +votes, then the SIP shall be transferred to Rejected status, and the SC shall +provide a detailed explanation as to why they made their decision (see below). + +##### Overseeing SIP Activation and Ratification + +Once a SIP is in Activation-In-Progress status, +the SC shall be responsible for overseeing the procedures and criteria in the +SIP’s Activation section. The Activation section of a SIP can be thought of as +an “instruction manual” and/or “checklist” for the SC to follow to determine if +the SIP has been accepted by the Stacks users. The SC shall strictly adhere to +the process set forth in the Activation section. If the procedure and/or +criteria of the Activation section cannot be met, then the SC may transfer the +SIP to Rejected status and ask the authors to re-submit the SIP with an updated +Activation section. + +Once all criteria have been unambiguously meet and all activation procedures +have been followed, the SC shall transition the SIP to Ratified status. The SC +shall keep a log and provide a record of the steps they took in following a +SIP’s Activation section once the SIP is in Activation-In-Progress status, and +publish them alongside the Ratified SIP as supplemental material. + +Due to the hands-on nature of the Activation section, the SC may deem it +appropriate to reject a SIP solely on the quality of its Activation section. +Reasonable grounds for rejection include, but are not limited to, ambiguous +instructions, insufficiently-informative activation criteria, too much work on +the SC members’ parts, the lack of a prescribed activation timeout, and so on. + +Before the Stacks mainnet launches, the SC shall ratify a SIP that, when +activated according to the procedures outlined in its Activation section, will +allow Stacks blockchain miners to signal their preferences for the activation of +particular SIPs within the blocks that they mine. This will enable the greater +Stacks community of users to have the final say as to which SIPs activate and +become ratified. + +##### Feedback on Recommended SIPs + +The Steering Committee shall give a full, fair, +public, and timely evaluation to each SIP transitioned to Recommended status by +Consideration Advisory Boards. A SIP shall only be considered by the SC if the +Consideration Advisory Board chairpeople for each of the SIP's considerations +have signed-off on the SIP (by indicating as such on the SIP's preamble). + +The SC may transition a SIP to Rejected status if it disagrees with the +Consideration Advisory Boards' recommendation. The SC may transition a SIP to +Obsolete status if it finds that the SIP no longer addresses a relevant concern. +It may transition the SIP to a Replaced status if it considers a similar, +alternative SIP that is more likely to succeed. In all cases, the SC shall +ensure that a SIP does not remain in Recommended status for an unreasonable +amount of time. + +The SC shall maintain a public record of all feedbacks provided for each SIP it +reviews. + +If a SIP is moved to Rejected, Obsolete, or Replaced status, the SIP authors may +appeal the process by re-submitting it in Draft status once the feedback has +been addressed. The appealed SIP must cite the SC’s feedback as supplemental +material, so that SIP Editors and Consideration Advisory Boards are able to +verify that the feedback has, in fact, been addressed. + +##### Public Meetings + +The Steering Committee shall hold and record regular public +meetings at least once per month. The SC may decide the items of business for +these meetings at its sole discretion, but it shall prioritize business +pertaining to the ratification of SIPs, the recognition of Consideration +Advisory Boards, and the needs of all outstanding committees. That said, any +user may join these meetings as an observer, and the SC shall make a good-faith +effort to address public comments from observers as time permits. + +The SC shall appoint up to two dedicated moderators from the user community for +its engineering meetings, who shall vet questions and commentary from observers +in advance (possibly well before the meeting begins). If there is more than one +moderator, then the moderators may take turns. In addition, the SC shall appoint +a dedicated note-taker to record the minutes of the meetings. All of these +appointees shall be eligible to receive a fixed, regular bounty for their work. + +### Consideration Advisory Board Duties + +There is an Advisory Board for each SIP consideration, with a designated +chairperson responsible for maintaining copies of all discussion and feedback on +the SIPs under consideration. + +#### Membership + +All Consideration Advisory Boards begin their life as unofficial +working groups of users who wish to review inbound SIPs according to their +collective expertise. If they wish to be recognized as an official +Consideration Advisory Board, they shall submit a SIP to the Steering Committee +per the procedure described in the Steering Committee’s duties. Each +Consideration Advisory Board shall be formally created by the SC with a +designated member serving as its first interim chairperson. After this, the +Consideration Advisory Board may adopt its own bylaws for selecting members and +chairpeople. However, members should have domain expertise relevant to the +consideration. + +#### Members + +Members shall serve on their respective Consideration Advisory Boards so long as +they are in good standing with the SIP Code of Conduct and in accordance to the +individual Board’s bylaws. A user may serve on at most three Consideration +Advisory Boards concurrently. + +#### Qualifications + +Each Consideration Advisory Board member shall have sufficient +domain expertise to provide the Steering Committee with feedback pertaining to a +SIP's consideration. Members shall possess excellent written communication +skills. + +#### Responsibilities + +Each Consideration Advisory Board shall be responsible for the +following. + +##### Chairperson + +Each Consideration Advisory Board shall appoint a chairperson, who +shall serve as the point of contact between the rest of the Board and the +Steering Committee. If the chairperson becomes unresponsive, the SC may ask the +Board to appoint a new chairperson (alternatively, the Board may appoint a new +chairperson on its own and inform the SC). The chairperson shall be responsible +for maintaining the Board’s public list of members’ names and contact +information as a supplementary document to the SIP that the SC ratified to +recognize the Board. + +##### Consideration Track + +Each Consideration Advisory Board shall provide a clear and +concise description of what expertise it can offer, so that SIP authors may +solicit it with confidence that it will be helpful. The chairperson shall make +this description available to the Steering Committee and to the SIP Editors, so +that both committees can help SIP authors ensure that they receive the most +appropriate feedback. + +The description shall be provided and updated by the chairperson to the SC so +that the SC can provide a public index of all considerations a SIP may possess. + +##### Feedback + +Feedback to SIP Authors Each Consideration Advisory Board shall provide a full, +fair, public, and timely evaluation of any Accepted-status SIP that lists the +Board's consideration in its preamble. The Board may decide to move each SIP to +a Recommended status or a Rejected status based on whether or not the Board +believes that the SIP is feasible, practical, and beneficial to the greater +Stacks ecosystem. + +Any feedback created shall be made public. It is the responsibility of the Board +to store and publish all feedbacks for the SIPs it reviews. It shall forward +copies of this feedback to both the SIP authors. + +##### Consultation with the Steering Committee + +The Steering Committee may need to +follow up with the Consideration Advisory Board in order to clarify its position +or solicit its advice on a particular SIP. For example, the SC may determine +that a Recommended SIP needs to be considered by one or more additional Boards +that have not yet been consulted by the SIP authors. + +The Board shall respond to the SC's request for advice in a timely manner, and +shall prioritize feedback on SIPs that are under consideration for ratification. + +### SIP Editor Duties + +By far the largest committee in the SIP process is the SIP Editor Committee. +The SIP Editors are responsible for maintaining the "inbound funnel" for SIPs +from the greater Stacks community. SIP Editors ensure that all inbound SIPs are +well-formed, relevant, and do not duplicate prior work (including rejected +SIPs). + +#### Membership + +Anyone may become a SIP Editor by recommendation from an existing SIP +Editor, subject to the “Recruitment” section below. + +#### Qualifications + +A SIP Editor must demonstrate proficiency in the SIP process and +formatting requirements. A candidate SIP Editor must demonstrate to an existing +SIP Editor that they can independently vet SIPs. + +#### Responsibilities + +SIP Editors are concerned with shepherding SIPs from Draft +status to Accepted status, and for mentoring community members who want to get +involved with the SIP processes (as applicable). + +##### Getting Users Started + +SIP Editors should be open and welcoming towards +enthusiastic users who want to help improve the greater Stacks ecosystem. As +such, SIP Editors should encourage users to submit SIPs if they have good ideas +that may be worth implementing. + +In addition, SIP Editors should respond to public requests for help from +community members who want to submit a SIP. They may point them towards this +document, or towards other supplemental documents and tools to help them get +started. + +##### Feedback + +When a SIP is submitted in Draft status, a SIP Editor that takes the +SIP into consideration should provide fair and full feedback on how to make the +SIP ready for its transition to Accepted status. + +To do this, the SIP Editor should: + +- Verify that the SIP is well-formed according to the criteria in this document +- Verify that the SIP has not been proposed before +- Verify as best that they can that the SIP is original work +- Verify that the SIP is appropriate for its type and consideration +- Recommend additional Considerations if appropriate +- Ensure that the text is clear, concise, and grammatically-correct English +- Ensure that there are appropriate avenues for discussion of the SIP listed in + the preamble. + +The SIP Editor does not need to provide public feedback to the SIP authors, but +should add their name(s) to the Signed-off field in the SIP preamble once the +SIP is ready to be Accepted. + +##### Acceptance + +Once a SIP is moved to Accepted, the SIP Editor shall assign it the +smallest positive number not currently used to identify any other SIP. Once that +number is known, the SIP Editor shall set the SIP's status to Accepted, set the +number, and commit the SIP to the SIP repository in order to make it visible to +other SIP Editors and to the Consideration Advisory Boards. + +##### Recruitment + +Each SIP Editor must list their name and contact information in an +easy-to-find location in the SIP repository, as well list of each SIP Editor +they recommended. In so doing, the SIP Editors shall curate an “invite tree” +that shows which Editors recommended which other Editors. + +A SIP Editor may recommend another user to be a SIP Editor no more than once per +month, and only if they have faithfully moved at least one SIP to Accepted +status in the last quarter. If a SIP Editor does not participate in editing a +SIP for a full year and a day, then they may be removed from the SIP Editor +list. The SC may remove a SIP Editor (and some or all of the users he or she +recommended) if they find that the SIP Editor has violated the SIP Code of +Conduct. + +Newly-Accepted SIPs, new SIP Editor recruitment, and SIP Editor retirement shall +be submitted as pull requests by SIP Editors to the SIP repository. + +## SIP Workflow + +The lifecycle of a SIP is summarized in the flow-chart below: + +``` + ------------------ + | Draft | <-------------------------. Revise and resubmit + ------------------ | + | -------------------- + Submit to SIP Editor -------------> | Rejected | + | -------------------- + | ^ + V | + ------------------ | + | Accepted | -------------------------/ | /--------------------------------. + ------------------ | | + | -------------------- | + Review by Consideration ----------> | Rejected | | + Advisory Board(s) -------------------- | + | ^ | + V | | + ------------------------- | | + | Recommended | -----------------/ | /------------------------------->| + ------------------------- | | + | -------------------- | + Vote by the Steering -----------> | Rejected | | + Committee for activation -------------------- | + | ^ | + V | | + -------------------------- | | + | Activation-in-Progress | -----------------/ | /------------------------------->| + -------------------------- | | + | --------------------- | + All activation ------------------> | Rejected | | + criteria are met | --------------------- ------------------ | + | |----------------------------------> | Obsolete | | + V | --------------------- ------------------ | + ------------------ *---> | Replaced | --------------->|<-----------* + | Ratified | --------------------- | + ------------------ V + ------------------- + | Withdrawn | + ------------------- +``` + +When a SIP is transitioned to Rejected, it is not deleted, but is preserved in +the SIP repository so that it can be referenced as related or prior work by +other SIPs. Once a SIP is Rejected, it may be re-submitted as a Draft at a later +date. SIP Editors may decide how often to re-consider rejected SIPs as an +anti-spam measure, but the Steering Committee and Consideration Advisory Boards +may opt to independently re-consider rejected SIPs at their own discretion. + +Once a SIP has been moved to Ratified status, the only changes that may be made +to it are fixing errata and adding supplementary materials. Substantial changes +to the SIP's body should be done as a separate SIP. + +## Public Venues for Conducting Business + +The canonical set of SIPs in all state shall be recorded in the same medium that +the canonical copy of this SIP is. Right now, this is in the Github repository +`https://github.com/stacksgov/sips`, but may be changed before this SIP is +ratified. New SIPs, edits to SIPs, comments on SIPs, and so on shall be +conducted through Github's facilities for the time being. + +In addition, individual committees may set up and use public mailing lists for +conducting business. The Stacks Open Internet Foundation shall provide a means +for doing so. Any discussions on the mailing lists that lead to non-trivial +contributions to SIPs should be referenced by these SIPs as supplemental +material. + +### Github-specific Considerations + +All SIPs shall be submitted as pull requests, and all SIP edits (including status +updates) shall be submitted as pull requests. The SC, or one or more +individuals or entities appointed by the SC, shall be responsible for merging +pull requests to the main branch. + +## SIP Copyright & Licensing + +Each SIP must identify at least one acceptable license in its preamble. Source +code in the SIP can be licensed differently than the text. SIPs whose reference +implementation(s) touch existing reference implementation(s) must use the same +license as the existing implementation(s) in order to be considered. Below is a +list of recommended licenses. + +- BSD-2-Clause: OSI-approved BSD 2-clause license +- BSD-3-Clause: OSI-approved BSD 3-clause license +- CC0-1.0: Creative Commons CC0 1.0 Universal +- GNU-All-Permissive: GNU All-Permissive License +- GPL-2.0+: GNU General Public License (GPL), version 2 or newer +- LGPL-2.1+: GNU Lesser General Public License (LGPL), version 2.1 or newer + +# Related Work + +The governance process proposed in this SIP is inspired by the Python PEP +process [1], the Bitcoin BIP2 process [2], the Ethereum Improvement Proposal [3] +processes, the Zcash governance process [4], and the Debian GNU/Linux +distribution governance process [5]. This SIP describes a governance process +where top-level decision-making power is vested in a committee of elected +representatives, which distinguishes it from Debian (which has a single elected +project leader), Python (which has a benevolent dictator for life), and Bitcoin +and ZCash (which vest all decision ratification power solely in the blockchain +miners). The reason for a top-level steering committee is to ensure that +decision-making power is not vested in a single individual, but also to ensure +that the individuals responsible for decisions are accountable to the community +that elects them (as opposed to only those who have the means to participate +in mining). This SIP differs from Ethereum's governance +process in that the top-level decision-making body (the "Core Devs" in Ethereum, +and the Steering Committee in Stacks) is not only technically proficient to evaluate +SIPs, but also held accountable through an official governance +process. + +[1] https://www.python.org/dev/peps/pep-0001/ + +[2] https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki + +[3] https://eips.ethereum.org/ + +[4] https://www.zfnd.org/governance/ + +[5] https://debian-handbook.info/browse/stable/sect.debian-internals.html + +# Activation + +This SIP activates once following tasks have been carried out: + +- The provisional Steering Committee must be appointed by the Stacks Open Internet + Foundation Board. +- Mailing lists for the initial committees must be created. +- The initial Consideration Advisory Boards must be formed, if there is interest + in doing so before this SIP activates. +- A public, online SIP repository must be created to hold all non-Draft SIPs, their edit + histories, and their feedbacks. +- A directory of Consideration Advisory Boards must be established (e.g. within + the SIP repository). +- A SIP Code of Conduct should be added as a supplemental document +- The Stacks blockchain mainnet must launch. + +# Reference Implementation + +Not applicable. From ddbe6350de8c161b49c8c83592a7b19ea40a32a9 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:18:09 -0400 Subject: [PATCH 12/29] Update and rename sip-replaced SIP.readme.md to sip-000-01-stacks-improvement-proposal-process.md --- ... sip-000-01-stacks-improvement-proposal-process.md} | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) rename sips/sip-000/{sip-replaced SIP.readme.md => sip-000-01-stacks-improvement-proposal-process.md} (99%) diff --git a/sips/sip-000/sip-replaced SIP.readme.md b/sips/sip-000/sip-000-01-stacks-improvement-proposal-process.md similarity index 99% rename from sips/sip-000/sip-replaced SIP.readme.md rename to sips/sip-000/sip-000-01-stacks-improvement-proposal-process.md index a213fb07b..a4500e243 100644 --- a/sips/sip-000/sip-replaced SIP.readme.md +++ b/sips/sip-000/sip-000-01-stacks-improvement-proposal-process.md @@ -1,11 +1,15 @@ # Preamble -SIP Number: 000 +SIP Number: 000-1 Title: Stacks Improvement Proposal Process -Author: Jude Nelson , Ken Liao +Author: +- Jw +- Jude +- Brice +- HeroGamer Consideration: Governance @@ -17,7 +21,7 @@ Created: 2020-06-23 License: BSD-2-Clause -Sign-off: Jude Nelson , Technical Steering Committee Chair +Sign-off: tbc Discussions-To: https://github.com/stacksgov/sips From e98f3ec30b365108a726d5ef1870290ca88bd810 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:18:31 -0400 Subject: [PATCH 13/29] Rename sip-000-01-stacks-improvement-proposal-process.md to sip-000-01-stacks-improvement-proposal-process.md --- .../sip-000-01-stacks-improvement-proposal-process.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/{sip-000 => sip-000-1}/sip-000-01-stacks-improvement-proposal-process.md (100%) diff --git a/sips/sip-000/sip-000-01-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-01-stacks-improvement-proposal-process.md similarity index 100% rename from sips/sip-000/sip-000-01-stacks-improvement-proposal-process.md rename to sips/sip-000-1/sip-000-01-stacks-improvement-proposal-process.md From 148a902c623ecf4e14ae22c8691b1171af9142ce Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:19:26 -0400 Subject: [PATCH 14/29] Rename sip-000-stacks-improvement-proposal-process.md to sip-000-stacks-improvement-proposal-process.md --- .../replaced SIPs/sip-000-stacks-improvement-proposal-process.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/{sip-000 => sip-000-1}/replaced SIPs/sip-000-stacks-improvement-proposal-process.md (100%) diff --git a/sips/sip-000/replaced SIPs/sip-000-stacks-improvement-proposal-process.md b/sips/sip-000-1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md similarity index 100% rename from sips/sip-000/replaced SIPs/sip-000-stacks-improvement-proposal-process.md rename to sips/sip-000-1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md From d1d46a235e99dda7f0012b351950938b1f5ab860 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:22:43 -0400 Subject: [PATCH 15/29] Rename sip-000-01-stacks-improvement-proposal-process.md to sip-000-01-stacks-improvement-proposal-process.md --- .../sip-000-01-stacks-improvement-proposal-process.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/{sip-000-1 => sip-000_1}/sip-000-01-stacks-improvement-proposal-process.md (100%) diff --git a/sips/sip-000-1/sip-000-01-stacks-improvement-proposal-process.md b/sips/sip-000_1/sip-000-01-stacks-improvement-proposal-process.md similarity index 100% rename from sips/sip-000-1/sip-000-01-stacks-improvement-proposal-process.md rename to sips/sip-000_1/sip-000-01-stacks-improvement-proposal-process.md From ae692b6dc48dd1f5dfaebc9bdf8c8f6dadbe4631 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:23:36 -0400 Subject: [PATCH 16/29] Rename sip-000-stacks-improvement-proposal-process.md to sip-000-stacks-improvement-proposal-process.md --- .../replaced SIPs/sip-000-stacks-improvement-proposal-process.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/{sip-000-1 => sip-000_1}/replaced SIPs/sip-000-stacks-improvement-proposal-process.md (100%) diff --git a/sips/sip-000-1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md b/sips/sip-000_1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md similarity index 100% rename from sips/sip-000-1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md rename to sips/sip-000_1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md From 1bf0f436ef437dfb102d2f2c8854676bd069d64c Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:24:33 -0400 Subject: [PATCH 17/29] Rename sip-000-01-stacks-improvement-proposal-process.md to sip-000_1-stacks-improvement-proposal-process.md --- ...rocess.md => sip-000_1-stacks-improvement-proposal-process.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/sip-000_1/{sip-000-01-stacks-improvement-proposal-process.md => sip-000_1-stacks-improvement-proposal-process.md} (100%) diff --git a/sips/sip-000_1/sip-000-01-stacks-improvement-proposal-process.md b/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md similarity index 100% rename from sips/sip-000_1/sip-000-01-stacks-improvement-proposal-process.md rename to sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md From b0d2d0b790aca67491c7480b9fd504d111aa9ac6 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:25:00 -0400 Subject: [PATCH 18/29] Update sip-000_1-stacks-improvement-proposal-process.md --- sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md b/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md index a4500e243..ab53e9a73 100644 --- a/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md +++ b/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md @@ -1,7 +1,7 @@ # Preamble -SIP Number: 000-1 +SIP Number: 000_1 Title: Stacks Improvement Proposal Process From 69fe7be629621c7da55b734fff3a9ccd70f27ab4 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Tue, 21 Oct 2025 23:30:45 -0400 Subject: [PATCH 19/29] Update sip-000_1-stacks-improvement-proposal-process.md --- sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md b/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md index ab53e9a73..1017b348e 100644 --- a/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md +++ b/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md @@ -25,6 +25,8 @@ Sign-off: tbc Discussions-To: https://github.com/stacksgov/sips +Replaces: SIP-000 + # Abstract A Stacks Improvement Proposal (SIP) is a design document that provides From 682f6c4a53db171de7d93d6beb6772ceae3bad79 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Wed, 22 Oct 2025 01:17:46 -0400 Subject: [PATCH 20/29] Update and rename sip-000_1-stacks-improvement-proposal-process.md to sip-000-1-stacks-improvement-proposal-process.md --- .../sip-000-1-stacks-improvement-proposal-process.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename sips/{sip-000_1/sip-000_1-stacks-improvement-proposal-process.md => sip-000-1/sip-000-1-stacks-improvement-proposal-process.md} (99%) diff --git a/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md similarity index 99% rename from sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md rename to sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md index 1017b348e..9d0ef63f0 100644 --- a/sips/sip-000_1/sip-000_1-stacks-improvement-proposal-process.md +++ b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md @@ -1,7 +1,7 @@ # Preamble -SIP Number: 000_1 +SIP Number: 000-1 Title: Stacks Improvement Proposal Process From 22fe055242615255f963dfcecca3cc67a8f8dbed Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Wed, 22 Oct 2025 01:18:17 -0400 Subject: [PATCH 21/29] Update sip-000-1-stacks-improvement-proposal-process.md From c00be9a83614bb3363295427006fccfab1458aab Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Wed, 22 Oct 2025 01:18:48 -0400 Subject: [PATCH 22/29] Rename sip-000-stacks-improvement-proposal-process.md to sip-000-stacks-improvement-proposal-process.md --- .../replaced SIPs/sip-000-stacks-improvement-proposal-process.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/{sip-000_1 => sip-000-1}/replaced SIPs/sip-000-stacks-improvement-proposal-process.md (100%) diff --git a/sips/sip-000_1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md b/sips/sip-000-1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md similarity index 100% rename from sips/sip-000_1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md rename to sips/sip-000-1/replaced SIPs/sip-000-stacks-improvement-proposal-process.md From d0ea72d4e386e62ffc3d35c5bdc5d7c5b812b65d Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Wed, 22 Oct 2025 01:30:47 -0400 Subject: [PATCH 23/29] Update sip-000-1-stacks-improvement-proposal-process.md --- ...ip-000-1-stacks-improvement-proposal-process.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md index 9d0ef63f0..a752c15f9 100644 --- a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md +++ b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md @@ -5,25 +5,27 @@ SIP Number: 000-1 Title: Stacks Improvement Proposal Process -Author: +Author(s): - Jw - Jude - Brice - HeroGamer +Status: Draft + Consideration: Governance Type: Meta -Status: Ratified +Layer: NA -Created: 2020-06-23 +Created: 2025-10-22 License: BSD-2-Clause Sign-off: tbc -Discussions-To: https://github.com/stacksgov/sips +Discussions-To: https://github.com/stacksgov/sips/issues/228 Replaces: SIP-000 @@ -47,6 +49,10 @@ sufficiently describe the design, governance, and operationalization of the Stacks blockchain, as well as the means by which future changes to its official design, implementation, operation, and governance may be incorporated. +This SIP-000-1 replaces SIP-000 to update and clarify the governance and operational framework of the Stacks Improvement Proposal (SIP) process. After several years of firsthand operation and feedback from SIP authors, Editors, CAB members, and the Steering Committee, this revision incorporates procedural refinements to improve transparency, consistency, and accountability across the SIP lifecycle. + +Key updates include clearer authoring and submission rules, standardized CAB engagement requirements, defined voting procedures and minimum timelines, explicit handling of hard fork SIPs, and strengthened maintenance responsibilities for the Steering Committee and Editors. These changes aim to make the SIP process more predictable, auditable, and efficient while preserving its community-driven and open-governance foundation. + # License and Copyright This SIP is made available under the terms of the BSD-2-Clause license, From d3e2107e00bbcc2b096d161e3e7d945d1968a571 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Wed, 22 Oct 2025 08:49:55 -0400 Subject: [PATCH 24/29] Update sip-000-1-stacks-improvement-proposal-process.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1. Update Abstract to mention this replaces SIP-000 and the rationale 2. Added “## Backwards Compatibility” but it is NA 3. Moved 2 ## SIP Flow subsections together, renamed the first to SIP Status 4. Moved “## SIP Types” to logical order, after “## Layer” 5. New subsection “## SIP Layers” created by moving the explanations from Preambles 6. Preambles’ spec’s ordering of fields reordered to match the SIP_TEMPLATE 7. Added “### SIP Authoring Rules” 8. Added “### Expectation of Minimum Timelines And Rules” 9. Added “### SIP Versioning and Replacement Update Policy” 10. Added “### Documentation, Repo Maintancne, Merging into Main”

 Unanswered questions requiring agreeing upon: ### Hard Fork SIPs - Define process for code freeze and creation of dedicated release branches. - Only milestone changes for that release may be merged into the fork branch. --- ...0-1-stacks-improvement-proposal-process.md | 341 +++++++++++------- 1 file changed, 201 insertions(+), 140 deletions(-) diff --git a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md index a752c15f9..bfb8037e2 100644 --- a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md +++ b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md @@ -6,10 +6,10 @@ SIP Number: 000-1 Title: Stacks Improvement Proposal Process Author(s): -- Jw -- Jude -- Brice -- HeroGamer +* Brice +* HeroGamer +* Jw +* Jude Status: Draft @@ -49,7 +49,7 @@ sufficiently describe the design, governance, and operationalization of the Stacks blockchain, as well as the means by which future changes to its official design, implementation, operation, and governance may be incorporated. -This SIP-000-1 replaces SIP-000 to update and clarify the governance and operational framework of the Stacks Improvement Proposal (SIP) process. After several years of firsthand operation and feedback from SIP authors, Editors, CAB members, and the Steering Committee, this revision incorporates procedural refinements to improve transparency, consistency, and accountability across the SIP lifecycle. +This SIP-000-1 replaces SIP-000 to update and clarify the governance and operational framework of the SIP process. After several years of firsthand operation and feedback from SIP authors, Editors, CAB members, and the Steering Committee, this revision incorporates procedural refinements to improve transparency, consistency, and accountability across the SIP lifecycle. Key updates include clearer authoring and submission rules, standardized CAB engagement requirements, defined voting procedures and minimum timelines, explicit handling of hard fork SIPs, and strengthened maintenance responsibilities for the Steering Committee and Editors. These changes aim to make the SIP process more predictable, auditable, and efficient while preserving its community-driven and open-governance foundation. @@ -128,9 +128,10 @@ Each SIP shall contain the following sections, in the given order: a SIP; its author does not provide it. - _Title_. A concise description of the SIP, no more than 20 words long. - _Author_. A list of names and email addresses of the SIP's author(s). + - _Status_. This SIP's point in the SIP workflow (see below). - _Consideration_. What class of SIP this is (see below). - _Type_. The SIP track for consideration (see below). - - _Status_. This SIP's point in the SIP workflow (see below). + - _Layer_. The logical layer of the Stacks blockchain affected (see below). - _Created_. The ISO 8601 date when this SIP was created. - _License_. The content license for the SIP (see below for permitted licenses). @@ -138,22 +139,11 @@ Each SIP shall contain the following sections, in the given order: ratify the SIP. This field is not filled in entirely until ratification, but is incrementally filled in as the SIP progresses through the ratification process. -- Additional SIP fields, which are sometimes required, include: - - _Layer_. The logical layer of the Stacks blockchain affected. Must be one - - of the following: - - _Consensus (soft fork)_. For backwards-compatible proposals for - transaction-processing. - - _Consensus (hard fork)_. For backwards-incompatible proposals for - transaction-processing. - - _Peer Services_. For proposals to the peer-to-peer network protocol - stack. - - _API/RPC_. For proposals to the Stacks blockchain's official - programmatic interfaces. - - _Traits_. For proposals for new standardized Clarity trait definitions. - - _Applications_. For proposals for standardized application protocols - that interface with the Stacks blockchain. - _Discussions-To_. A mailing list where ongoing discussion of the SIP takes place. + +- Additional SIP fields, which are sometimes required, include: + - _Comments-Summary_. The comments summary tone. - _Comments-URI_. A link to the Stacks blockchain wiki for comments. - _License-Code_. Abbreviation for code under a different license than the SIP @@ -164,6 +154,7 @@ Each SIP shall contain the following sections, in the given order: - _Replaces_. A list of SIPs that this SIP replaces. - _Superceded-By_. A list of SIPs that replace this SIP. + - _Abstract_. This section shall provide a high-level summary of the proposed improvement. It shall not exceed 5000 words. - _Copyright_. This section shall provide the copyright license that governs the @@ -223,69 +214,7 @@ directory, and must be named as `SIP-XXXX-YYY.ext`, where: - `YYY` is the serial number of the file, starting with 1, - `.ext` is the file extension. -## SIP Types - -The types of SIPs are as follows: - -- _Consensus_. This SIP type means that all Stacks blockchain implementations - would need to adopt this SIP to remain compatible with one another. If this is -the SIP type, then the SIP preamble must have the Layer field set to either -_Consensus (soft fork)_ or _Consensus (hard fork)_. -- _Standard_. This SIP type means that the proposed change affects one or more - implementations, but does not affect network consensus. If this is the SIP -type, then the SIP preamble must have the Layer field set to indicate which -aspect(s) of the Stacks blockchain are affected by the proposal. -- _Operation_. This SIP type means that the proposal concerns the operation of the - Stacks blockchain -- in particular, it concerns node operators and miners. -The difference between this SIP type and the Standard type is that this type -does not change any existing protocols. -- _Meta_. This SIP type means that the proposal concerns the SIP ratification - process. Such a SIP is a proposal to change the way SIPs are handled. -- _Informational_. This is a SIP type that provides useful information, but does - not require any action to be taken on the part of any user. - -New types of SIPs may be created with the ratification of a Meta-type SIP under -the governance consideration (see below). SIP types may not be removed. - -## SIP Considerations - -A SIP's consideration determines the particular steps needed to ratify the SIP -and incorporate it into the Stacks blockchain. Different SIP considerations have -different criteria for ratification. A SIP can have more than one consideration, -since a SIP may need to be vetted by different users with different domains of -expertise. - - -- _Technical_. The SIP is technical in nature, and must be vetted by users with - the relevant technical expertise. -- _Economic_. The SIP concerns the blockchain's token economics. This not only - includes the STX token, but also any on-chain tokens created within smart -contracts. SIPs that are concerned with fundraising methods, grants, bounties, -and so on also belong in this SIP track. -- _Governance_. The SIP concerns the governance of the Stacks blockchain, - including the SIP process. This includes amendments to the SIP Ratification -Process, as well as structural considerations such as the creation (or removal) -of various committees, editorial bodies, and formally recognized special -interest groups. In addition, governance SIPs may propose changes to the way by -which committee members are selected. -- _Ethics_. This SIP concerns the behaviors of office-holders in the SIP - Ratification Process that can affect its widespread adoption. Such SIPs -describe what behaviors shall be deemed acceptable, and which behaviors shall be -considered harmful to this end (including any remediation or loss of privileges -that misbehavior may entail). SIPs that propose formalizations of ethics like -codes of conduct, procedures for conflict resolution, criteria for involvement -in governance, and so on would belong in this SIP consideration. -- _Diversity_. This SIP concerns proposals to grow the set of users, with an - emphasis on including users who are traditionally not involved with -open-source software projects. SIPs that are concerned with evangelism, -advertising, outreach, and so on must have this consideration. - -Each SIP consideration shall have a dedicated Advisory Board that ultimately -vets SIPs under their consideration for possible ratification in a timely -fashion (see below). New considerations may be created via the ratification of -a Meta-type SIP under the governance consideration. - -## SIP Workflow +## SIP Status As a SIP is considered for ratification, it passes through multiple statuses as determined by one or more committees (see next section). A SIP may have exactly @@ -328,7 +257,6 @@ state once the SIP(s) that replace it have been processed. may not be ratified, and may not be re-submitted as a Draft. It must be re-assigned a SIP number if taken up again. - The act of ratifying a SIP is the act of transitioning it to the Ratified status -- that is, moving it from Draft to Accepted, from Accepted to Recommended, and Recommended to Activation-In-Progress, and from Activation-In-Progress to @@ -336,6 +264,191 @@ Ratified, all without the SIP being transitioned to Rejected, Obsolete, Replaced, or Withdrawn status. A SIP's current status is recorded in its Status field in its preamble. +## SIP Considerations + +A SIP's consideration determines the particular steps needed to ratify the SIP +and incorporate it into the Stacks blockchain. Different SIP considerations have +different criteria for ratification. A SIP can have more than one consideration, +since a SIP may need to be vetted by different users with different domains of +expertise. + + +- _Technical_. The SIP is technical in nature, and must be vetted by users with + the relevant technical expertise. +- _Economic_. The SIP concerns the blockchain's token economics. This not only + includes the STX token, but also any on-chain tokens created within smart +contracts. SIPs that are concerned with fundraising methods, grants, bounties, +and so on also belong in this SIP track. +- _Governance_. The SIP concerns the governance of the Stacks blockchain, + including the SIP process. This includes amendments to the SIP Ratification +Process, as well as structural considerations such as the creation (or removal) +of various committees, editorial bodies, and formally recognized special +interest groups. In addition, governance SIPs may propose changes to the way by +which committee members are selected. +- _Ethics_. This SIP concerns the behaviors of office-holders in the SIP + Ratification Process that can affect its widespread adoption. Such SIPs +describe what behaviors shall be deemed acceptable, and which behaviors shall be +considered harmful to this end (including any remediation or loss of privileges +that misbehavior may entail). SIPs that propose formalizations of ethics like +codes of conduct, procedures for conflict resolution, criteria for involvement +in governance, and so on would belong in this SIP consideration. +- _Diversity_. This SIP concerns proposals to grow the set of users, with an + emphasis on including users who are traditionally not involved with +open-source software projects. SIPs that are concerned with evangelism, +advertising, outreach, and so on must have this consideration. + +Each SIP consideration shall have a dedicated Advisory Board that ultimately +vets SIPs under their consideration for possible ratification in a timely +fashion (see below). New considerations may be created via the ratification of +a Meta-type SIP under the governance consideration. + +## SIP Types + +The types of SIPs are as follows: + +- _Consensus_. This SIP type means that all Stacks blockchain implementations + would need to adopt this SIP to remain compatible with one another. If this is +the SIP type, then the SIP preamble must have the Layer field set to either +_Consensus (soft fork)_ or _Consensus (hard fork)_. +- _Standard_. This SIP type means that the proposed change affects one or more + implementations, but does not affect network consensus. If this is the SIP +type, then the SIP preamble must have the Layer field set to indicate which +aspect(s) of the Stacks blockchain are affected by the proposal. +- _Operation_. This SIP type means that the proposal concerns the operation of the + Stacks blockchain -- in particular, it concerns node operators and miners. +The difference between this SIP type and the Standard type is that this type +does not change any existing protocols. +- _Meta_. This SIP type means that the proposal concerns the SIP ratification + process. Such a SIP is a proposal to change the way SIPs are handled. +- _Informational_. This is a SIP type that provides useful information, but does + not require any action to be taken on the part of any user. + +New types of SIPs may be created with the ratification of a Meta-type SIP under +the governance consideration (see below). SIP types may not be removed. + +## SIP Layers + +The layers of SIPs are as follows: + +- _Consensus (soft fork)_. For backwards-compatible proposals for + transaction-processing. +- _Consensus (hard fork)_. For backwards-incompatible proposals for + transaction-processing. +- _Peer Services_. For proposals to the peer-to-peer network protocol + stack. +- _API/RPC_. For proposals to the Stacks blockchain's official + programmatic interfaces. +- _Traits_. For proposals for new standardized Clarity trait definitions. +- _Applications_. For proposals for standardized application protocols + that interface with the Stacks blockchain. + +## SIP lifecycle + +The lifecycle of a SIP is summarized in the flow-chart below: + +``` + ------------------ + | Draft | <-------------------------. Revise and resubmit + ------------------ | + | -------------------- + Submit to SIP Editor -------------> | Rejected | + | -------------------- + | ^ + V | + ------------------ | + | Accepted | -------------------------/ | /--------------------------------. + ------------------ | | + | -------------------- | + Review by Consideration ----------> | Rejected | | + Advisory Board(s) -------------------- | + | ^ | + V | | + ------------------------- | | + | Recommended | -----------------/ | /------------------------------->| + ------------------------- | | + | -------------------- | + Vote by the Steering -----------> | Rejected | | + Committee for activation -------------------- | + | ^ | + V | | + -------------------------- | | + | Activation-in-Progress | -----------------/ | /------------------------------->| + -------------------------- | | + | --------------------- | + All activation ------------------> | Rejected | | + criteria are met | --------------------- ------------------ | + | |----------------------------------> | Obsolete | | + V | --------------------- ------------------ | + ------------------ *---> | Replaced | --------------->|<-----------* + | Ratified | --------------------- | + ------------------ V + ------------------- + | Withdrawn | + ------------------- +``` + +When a SIP is transitioned to Rejected, it is not deleted, but is preserved in +the SIP repository so that it can be referenced as related or prior work by +other SIPs. Once a SIP is Rejected, it may be re-submitted as a Draft at a later +date. SIP Editors may decide how often to re-consider rejected SIPs as an +anti-spam measure, but the Steering Committee and Consideration Advisory Boards +may opt to independently re-consider rejected SIPs at their own discretion. + +Once a SIP has been moved to Ratified status, the only changes that may be made +to it are fixing errata and adding supplementary materials. Substantial changes +to the SIP's body should be done as a separate SIP. + +### SIP Authoring Rules + +- SIP pull requests **must be submitted from a fork** of the SIPs repository. Direct branches in the main SIP repository are prohibited, except for a small group of maintainers explicitly granted override privileges. + +- SIP authors may not resolve review comments on their own submissions unless a substantive change or clear justification is provided. Resolution of comments should be observable to reviewers and CABs. + +### Expectation of Minimum Timelines And Rules + +- Define explicit minimum periods: + - Draft open in SIP Repo as PR for comments and SIP Editors editing: 2 weeks + - CAB review: 2 week + - Final CAB comments resolution: 2 weeks + +- A public vote cannot begin until: + - All comments are addressed + - The SIP is approved by relevant CAB(s) and SIP Editor, CAB chairs and Editor to add that sign-off themselves in the SIP as comment suggestion + +This establishes a minimum of **Minimum 6 weeks** from draft being opened to the earliest possible public vote. Longer timelines are encouraged for complex proposals. + +- Minimum wait time before public vote to allow for comprehensive discussion and resolution of comments. If all comments have been addressed after CAB review, it could be agreed to host public vote earlier, however it should be expected, it all depends on the comments resolution. Therefore it is critical for the SIP author(s) to be proactive during the review period. + +- Emergency SIPs may bypass wait times under exceptional circumstances. + +### Documentation, Repo Maintancne, Merging into Main + +- SIPs must conform to the template and formatting rules defined in SIP-000. SIP template.md can be found https://github.com/stacksgov/sips/tree/main/sips +- SIPs must be written in plain language. Marketing claims or promotional material are not permitted in the main SIP text. Such material may be provided in supplementary reference documents. +- SIPs can only be merged into Main when: + - the SIP has received all relevant CABs sign-offs + - relevant CABs Minutes submitted and merged + - Sign-off from a Steering Committee member + - For SIPs that have public vote, typically Consensus breaking SIPs, "Activation Status" (Voting Results) must be added to SIP text which the numbers must have been verified, any verification script attached + +### Hard Fork SIPs + +For SIPs that involve consensus changes or hard forks: + +- A **dedicated release branch** must be created for the hard fork. +- Only milestone changes relevant to that release may be merged. +- Changes unrelated to the hard fork must not be introduced via this branch. + +### SIP Versioning and Replacement Update Policy + +- All SIPs except for SIP-000 to adopt Replacement Model. SIP-000 will be an outlier, since it defines the process by which all over sips must adhere. + +- The SIP that is replaced by must add the field to Preamble "Superceded-By: SIP-XYZ", and the new SIP that is replacing old SIP must the field in Preamable "Replaces: SIP-XYZ" + +- SIP-000 to take the approach of adding -1 increment such as SIP-000-1, SIP-000-2 for updating the SIP process. + +- Replacing SIP-XYZ with another SIP-XYZ or SIP-XYZ-1, must contain the complete, definitive text, it can't just be a list of changes with back-pointers to the old SIP-000. + ## SIP Committees The act of deciding the status of a SIP is handled by a set of designated @@ -720,62 +833,6 @@ Conduct. Newly-Accepted SIPs, new SIP Editor recruitment, and SIP Editor retirement shall be submitted as pull requests by SIP Editors to the SIP repository. -## SIP Workflow - -The lifecycle of a SIP is summarized in the flow-chart below: - -``` - ------------------ - | Draft | <-------------------------. Revise and resubmit - ------------------ | - | -------------------- - Submit to SIP Editor -------------> | Rejected | - | -------------------- - | ^ - V | - ------------------ | - | Accepted | -------------------------/ | /--------------------------------. - ------------------ | | - | -------------------- | - Review by Consideration ----------> | Rejected | | - Advisory Board(s) -------------------- | - | ^ | - V | | - ------------------------- | | - | Recommended | -----------------/ | /------------------------------->| - ------------------------- | | - | -------------------- | - Vote by the Steering -----------> | Rejected | | - Committee for activation -------------------- | - | ^ | - V | | - -------------------------- | | - | Activation-in-Progress | -----------------/ | /------------------------------->| - -------------------------- | | - | --------------------- | - All activation ------------------> | Rejected | | - criteria are met | --------------------- ------------------ | - | |----------------------------------> | Obsolete | | - V | --------------------- ------------------ | - ------------------ *---> | Replaced | --------------->|<-----------* - | Ratified | --------------------- | - ------------------ V - ------------------- - | Withdrawn | - ------------------- -``` - -When a SIP is transitioned to Rejected, it is not deleted, but is preserved in -the SIP repository so that it can be referenced as related or prior work by -other SIPs. Once a SIP is Rejected, it may be re-submitted as a Draft at a later -date. SIP Editors may decide how often to re-consider rejected SIPs as an -anti-spam measure, but the Steering Committee and Consideration Advisory Boards -may opt to independently re-consider rejected SIPs at their own discretion. - -Once a SIP has been moved to Ratified status, the only changes that may be made -to it are fixing errata and adding supplementary materials. Substantial changes -to the SIP's body should be done as a separate SIP. - ## Public Venues for Conducting Business The canonical set of SIPs in all state shall be recorded in the same medium that @@ -842,6 +899,10 @@ process. [5] https://debian-handbook.info/browse/stable/sect.debian-internals.html +# Backwards Compatibility + +NA + # Activation This SIP activates once following tasks have been carried out: From 1fc43efc91eb813b1364745affb861dfd0bc12b5 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Wed, 22 Oct 2025 08:51:42 -0400 Subject: [PATCH 25/29] Update sip-000-1-stacks-improvement-proposal-process.md --- .../sip-000-1-stacks-improvement-proposal-process.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md index bfb8037e2..cd85311c5 100644 --- a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md +++ b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md @@ -6,10 +6,10 @@ SIP Number: 000-1 Title: Stacks Improvement Proposal Process Author(s): -* Brice +* Brice Dobry * HeroGamer -* Jw -* Jude +* Jesse Wiley +* Jude Nelson Status: Draft From 54c661d84ecc2a94a6d152a3472a7bf4f632898f Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Fri, 24 Oct 2025 10:30:46 -0400 Subject: [PATCH 26/29] Adding ### Post-CAB Vote Updates rules --- .../sip-000-1-stacks-improvement-proposal-process.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md index cd85311c5..7402bf8a2 100644 --- a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md +++ b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md @@ -404,6 +404,17 @@ to the SIP's body should be done as a separate SIP. - SIP authors may not resolve review comments on their own submissions unless a substantive change or clear justification is provided. Resolution of comments should be observable to reviewers and CABs. +### Post-CAB Vote Updates + +- Once a CAB vote concludes, the SIP is considered approved in its voted form. + +- However, minor updates may still be made after the CAB vote and before merge under the following conditions: + - The changes are editorial or implementation-detail only — i.e. they do not alter the SIP’s intent, semantics, or functional behavior as approved. + - Any such change must be shared in the relevant CAB communication channel(s), and the diff must be visible in the PR for auditability. + +- If any CAB member believes the change alters meaning, a CAB re-vote must be called. +- The CAB Chair should note such updates in the meeting Minutes and/or SIP PR discussion for record-keeping. + ### Expectation of Minimum Timelines And Rules - Define explicit minimum periods: From 941c81d6a6f29dad60c750656348112349367191 Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Fri, 24 Oct 2025 11:49:02 -0400 Subject: [PATCH 27/29] minor spelling error update --- .../sip-000-1-stacks-improvement-proposal-process.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md index 7402bf8a2..6b0ac47d5 100644 --- a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md +++ b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md @@ -432,7 +432,7 @@ This establishes a minimum of **Minimum 6 weeks** from draft being opened to the - Emergency SIPs may bypass wait times under exceptional circumstances. -### Documentation, Repo Maintancne, Merging into Main +### Documentation, Repo Maintenance, Merging into Main - SIPs must conform to the template and formatting rules defined in SIP-000. SIP template.md can be found https://github.com/stacksgov/sips/tree/main/sips - SIPs must be written in plain language. Marketing claims or promotional material are not permitted in the main SIP text. Such material may be provided in supplementary reference documents. @@ -454,7 +454,7 @@ For SIPs that involve consensus changes or hard forks: - All SIPs except for SIP-000 to adopt Replacement Model. SIP-000 will be an outlier, since it defines the process by which all over sips must adhere. -- The SIP that is replaced by must add the field to Preamble "Superceded-By: SIP-XYZ", and the new SIP that is replacing old SIP must the field in Preamable "Replaces: SIP-XYZ" +- The SIP that is replaced by must add the field to Preamble "Superceded-By: SIP-XYZ", and the new SIP that is replacing old SIP must the field in Preamble "Replaces: SIP-XYZ" - SIP-000 to take the approach of adding -1 increment such as SIP-000-1, SIP-000-2 for updating the SIP process. From 3327dc7f2c7f71dc81eb8b6d5707ba132d2cb152 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Fri, 24 Oct 2025 10:08:52 -0700 Subject: [PATCH 28/29] Apply suggestion from @wileyj --- sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md index 6b0ac47d5..f5bca6616 100644 --- a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md +++ b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md @@ -8,7 +8,7 @@ Title: Stacks Improvement Proposal Process Author(s): * Brice Dobry * HeroGamer -* Jesse Wiley +* Jesse Wiley (jesse@stacks.org) * Jude Nelson Status: Draft From d5778cffe25780bfb60dfdcdd61a9993b8bdcf9a Mon Sep 17 00:00:00 2001 From: herogamer <92864860+Hero-Gamer@users.noreply.github.com> Date: Fri, 7 Nov 2025 10:43:11 -0500 Subject: [PATCH 29/29] minor wording update --- sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md index f5bca6616..8f085f880 100644 --- a/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md +++ b/sips/sip-000-1/sip-000-1-stacks-improvement-proposal-process.md @@ -428,7 +428,7 @@ to the SIP's body should be done as a separate SIP. This establishes a minimum of **Minimum 6 weeks** from draft being opened to the earliest possible public vote. Longer timelines are encouraged for complex proposals. -- Minimum wait time before public vote to allow for comprehensive discussion and resolution of comments. If all comments have been addressed after CAB review, it could be agreed to host public vote earlier, however it should be expected, it all depends on the comments resolution. Therefore it is critical for the SIP author(s) to be proactive during the review period. +- Minimum wait time before public vote to allow for comprehensive discussion and resolution of comments. If all comments have been addressed after CAB review, it could be agreed to host public vote earlier, however it should not be expected, it all depends on the comments resolution. Therefore it is critical for the SIP author(s) to be proactive during the review period. - Emergency SIPs may bypass wait times under exceptional circumstances.