The Stacks blockchain has some major proposed upgrades. The path forward goes through you, the community stakeholders.

Stacks 2.1 is a proposed network upgrade to the current Stacks 2.0 mainnet released in January. The upgrade will not happen automatically, so we’ve compiled information about the origin, status, voting plans, and included upgrades to help educate ecosystem stakeholders on what comes next and how to get involved.

Serendipity has occurred. At the launch of Stacks 2.0, the intent was for 2.1 to automatically go live at Bitcoin block 700,000. However, due to a bug this is not going to happen — the Stacks 2.0 chain will continue indefinitely (see#2507). But, we see this as blessing in disguise. We are strong believers in multi-stakeholder blockchain governance, and we believe that Stackers and miners should also have a say in when and how breaking changes occur — it shouldn’t be just the decision of developers. Therefore, we are going to take this opportunity to make sure that when the 2.1 upgrade is ready, it will only activate with the consent of the network.

To facilitate the upgrade to 2.1, the core developers are working on an on-chain smart contract that, once ready, will allow Stackers and miners to vote on when (or if) the 2.1 upgrade should take place. When it is ready, a 2.0 point-release will be made that rigs the 2.0 node to cease processing Bitcoin blocks at a block height determined by this smart contract. In doing so, the Stacks 2.0 network will stall out once there is enough support for 2.1 and the 2.1 network will resume processing blocks from when the 2.0 network left off. Note that the Stacks 2.1 upgrade follows the standard SIPs process; this vote will essentially be to either accept or reject that SIP.

The specific process by which the community can vote on this and future upgrades is being discussed here. The goal has always been to enter a state where the community can more easily determine the content and timing of major upgrades such as this, so this process prioritizes the work to enable that type of voting before the Stacks 2.1 upgrade as opposed to after it.

You can sign up below to get an email when more details about voting are available or you can track the Github issue here until a Stacks 2.1 SIP emerges.

The precise feature set for Stacks 2.1 was previously determined and likely won’t change much at this point; the proposals for inclusion in this upgrade are as follows:

Stacking Improvements
Stacks 2.1 will introduce several improvements to Stacking that will eliminate inefficient or confusing aspects of Stacking, the PoX reward and security mechanism.

• Continuous Stacking. Currently, Stackers that opt-in for 1-cycle intervals are penalized in the cooldown cycle because they miss the next immediate delegation period for the next reward cycle. Continuous Stacking allows for Stackers to avoid missing a reward cycle in between Stacking their STX, allowing them to Stack however much they want, whenever they want, without missing out due to the cooldown period.
• Increasing lock-ups or ‘topping off’. Once you Stack your tokens for an upcoming reward cycle, you should be able to increase the amount of STX you have Stacked. This is helpful when you want to put in additional STX into Stacking or perhaps to adjust to a rising dynamic minimum. Right now 50,000 STX is the minimum required increment by which you can increase your lock up; this could be much lower, allowing a user to increase their total Stacked amount by much smaller increments.
• Unlock unused STX automatically. For STX that get committed, only the STX that clinches a reward address slot will be locked and eligible for Stacking and any unused STX will be unlocked, allowing Stackers to only lock up what is necessary.

Clarity Improvements
Clarity has native access to Bitcoin state, but its current APIs for reading are rudimentary. There's a lot of room for improvement here(most of which could be written in Clarity itself!), but there are a few things that would need to be done through a network upgrade. These include:

• Better Parsing and Type Conversion Primitives. These include things like converting integers to and from buffers and strings, parsing principals to and from buffers, serializing and deserializing buffers to structured Clarity types and back, and taking slices of buffers. This will facilitate manipulating data on-chain, including Bitcoin transactions.
• Expose PoX reward set info. The PoX contract could represent each reward cycle's list of Bitcoin reward addresses, and keep track of whether or not the Bitcoin address has been up for payment by miners(and how much BTC has been received). This might enable Clarity developers to write much more interesting and complex financial derivatives built on top of Stacking.
• More Clarity Built-ins. There's a growing list of new things to add to Clarity to make it better. For example, there will be a 'tx-sponsor' keyword to indicate the principle who sponsored the transaction; this is not always 'tx-sender'. Also, there will be a 'stx-transfer-memo?' function for transferring STX with a memob(which improves exchange integration), and there will be a 'get-burn-block-info?' function for querying Bitcoin state at any point in the sortition history.

Better In-Band Blockchain Upgrades
By design, there are numerous ways to soft-fork the Stacks blockchain. However, there are a few areas where it could be improved:

• Voting to stop the network. Stacks 2.1 won’t be the last time users will want to make backwards-incompatible changes to the network. This means we need a way for miners and STX holders to vote on a "stop date" for the current version of the blockchain, such that developers have ample time to release an upgraded version of the blockchain with the new changes. Assuming at some point there is a Stacks 2.2 release, it would only happen if STX holders and miners vote for it. This differs from voting for a hard fork because if the vote passes, the current chain will die at a pre-determined block height(so there is no risk of an unforced chain split). Any new chain will simply pick up where the old chain left off.
• Voting to extend the PoX sunset date. PoX isn't currently scheduled to last forever and while Stackers can vote to disable PoX in order to keep the chain alive, there is no mechanism to vote to extend PoX. It may be worthwhile to make it so STX holders can vote to continue PoX past its targeted sunset date.

Reliability Improvements
There are a couple of things that could make mining and Stacking more reliable, but would require a network upgrade to achieve. These include:

• Fix mean-of-min-and-median sortition logic. The sortition weight a miner gets when mining STX is a function of how continuously they mine. This is intentional because it raises the barrier to entry for discount-mining -- a behavior whereby a miner Stacks their STX in order to reduce the amount of BTC they need to spend to mine. Making it so a miner's sortition weight is a function of many block-commits increases the number of STX they must Stack in order to do this reliably. Right now, there is a bug in the way the mean-of-min-and-median is calculated, which causes a missed sortition to over-penalize a miner by reducing their commitment weight to the minimum amount. This should be fixed in 2.1.
• Better tolerance for flash blocks. A Bitcoin behavior we did not fully anticipate the effects of are flash blocks-- two or more Bitcoin blocks that arrive so quickly that Stacks miners don't have a chance to mine in them. If enough of these happen in the PoX prepare phase, PoX is disabled for the subsequent reward cycle (see SIP-007 for details). We can make it far less likely that a flurry of Bitcoin mining activity shuts down PoX.
• Order-independent multisig signing and verification. Right now, the Stacks transaction wire format implicitly requires signers to sign in the given public key order. This could be fixed so that the signing order does not matter, but it would be a breaking change.
• Adjusted runtime costs. Right now, the built-in runtime costs are very pessimistic, which makes it tricky to implement smart contracts that deal with lots of iteration over lists and buffers. In general, runtime costs for "fast" computations should be brought down, but we will need to study the relative performance of each Clarity built-in to get a better sense of what the cost functions should be.

Stacks 2.1 isn’t the only effort community and core developers are pushing forward. Beyond 2.1, scalability is now a top priority. As you may have a seen a few days ago, congestion issues were reported in the Stacks network. While this is certainly frustrating, it should also be celebrated that we’re seeing more full blocks from the increased activity! The blockchain reached these congestion limits sooner than originally expected, but the core devs and community members are already working on speed and scalability improvements. Yesterday, a major release already started tackling these issues. More releases can be implemented in the coming weeks and beyond.

A great place to better understand the congestion issues and various ways the community is addressing them can be found in these two forum posts:

• Mempool congestion on Stacks: observations and next steps → Read more
• Framework for Stacks Scalability Muneeb Ali, Stacks Founder) → Read more

Beyond our support of the work outlined in the forum posts above, the Stacks Foundation is engaged in a number of efforts to increase the engineering capacity of the ecosystem, the robustness of the network and its key services, and the pace at which the Stacks chain can improve. Examples include:

• Hiring a DevOps, Blockchain, and Full-Stack Engineers: https://stacks.org/contribute
• Identifying and onboarding expert Stacks Residents to support key blockchain-related tooling, documentation, and more.
• Training over 100 new Clarity devs in its first cohort of Clarity Universe, all of which will be primed to contribute via teams, grants, or top the codebase directly
• Researching App Chains and subnets as scalability options
• Working toward hosting our own instances of the Stacks Explorer and incentivizing regional/translated versions of this and other key blockchain adjacent tools
• Providing grants to developers, blockchain contributors, and governance builders to improve upon these functions

To learn more about the 2.1 upgrade, join us for a community call next Wednesday, September 15th at 2:00pm UTC / 10:00am EST. We’ll be discussing the upgrade and what it means for the network with core developers from across the ecosystem.