Scaling up the SIP process

Hi folks,

We are both encouraged and humbled by the recent flurry of proposals for making the Stacks blockchain better! As you may have read elsewhere, these proposals are the starting point for official Stacks Improvement Proposals (SIPs), and must pass through the SIP process. The SIP process is a formal procedure that Stacks ecosystem members follow in order to discuss, document, ratify, and amend the rules that govern how the blockchain and its ecosystem are organized and operated. The SIPs that come out of the SIP process describe how and why a particular facet of the ecosystem works the way it does. SIPs are not limited to technical specifications, either. Today, there are tracks for governance, economics, ethics, and diversity SIPs that describe how the people in the ecosystem are expected to work together.

No one is above the SIP process. Even the most senior developers must follow it for each network upgrade they write in order to make backwards-incompatible changes in an orderly fashion. Such SIPs require explicit community approval, as has been done for SIPs 001 through 008 and the more-recent SIP 012 upgrade. Given the recent high influx of inbound proposals for backwards-incompatible changes, we are aiming to clarify the process and create spaces for more conversations. To this end, we at the Stacks Foundation are taking the following steps:

  • Weekly SIPs Call. We will hold a public weekly call where SIP authors can give short presentations on their “pre-SIP” proposals and do Q&A with other community members and SIP committee members. Date and time to be announced soon.

  • SIP Resident. The Stacks Foundation will create a paid position for an individual who will spend up to a year supporting SIP authors through the SIP process as needed and desired, helping them to take their proposals from an idea to a fully-scoped SIP and corresponding implementation. They will use their learnings from the experience to further streamline the SIP process, and will communicate the status and updates of in-progress SIPs to the community.

  • Community pre-approval. To prioritize the growing volume of proposals, we propose the creation of a pre-approval process whereby the community helps determine which up-and-coming proposals will be considered for the next network upgrade. It will take a few iterations to figure out the best way to do this, so we would love your input on designing it. If this works out well, we’ll formalize it with a governance-track SIP submission (subject to community ratification, of course!).

  • Mentorship. In order for a SIP to advance to ratification, it needs to include both the detailed technical description of the proposed change, as well as a reference implementation. To help guide technical SIP authors through the process, authors of pre-approved SIPs will have access to mentorship from a current core developer. The mentoring developer will help the SIP author(s) set up a testnet deployment with their implementation, and help them get their code merged into the codebase. Over time, this mentorship program is expected to grow the number of contributors to core development, thereby increasing the number of person-hours available to work on future network upgrades.

If you want to read more about the SIP process, a good starting point is SIP 000, which describes the SIP ratification procedure in detail. All SIPs, including submitted works-in-progress, are stored in the SIPs repository on Github.

Thank you again for all of the discussion! Let’s keep this conversation going below.


Thanks, Jude! Great to see the effort here to make the process more streamlined. As the Stacks community grows, we’ll likely see more discussions/suggestions around SIPs and it’s important to start thinking about scaling the process now.

I think @diwaker was talking about a RFC like idea, basically something in-between a formal SIP and a brainstorming idea on the forum, where the author is expected to write up things in a specified format, lists open questions, gets help from community in closing the loop on the open questions etc.

So we’ll start going towards a situation where there are 100s of brainstorming ideas > 10s of RFCs > and a few SIPs that are considered for activation each network upgrade (say every 6 months). This can also allow core developers to focus their time/attention on RFCs as spending time on ideas at brainstorming stage can become not scalable quickly (there will always be some interaction for brainstorming but it’s optional and not critical). Let me know if that makes sense!

P.S: I love the ideas of a SIP resident and mentorship. Getting more contributors to Stacks core blockchain can be an amazing outcome!


This is awesome. Great work, Jude! :tada:


I think this is a great idea!

Thanks for sharing all of this, Jude! We’re planning to schedule the first SIP call for this coming week and would like to feature a lot of the recent discussion on miner centralization.

Would you and @shea256 be up for leading that? If so, we’d have our tokenomics resident, @MattySTX, moderate the discussion + Q&A with the community.