Stacks 2.1: Strengthening The Connection to Bitcoin
Updated on February 22, 2023 by Claire Topalian
As a community, we see the incredible potential of Bitcoin and are committed to building the best tools to make it more useful. Stacks is the top Web3 project on Bitcoin today, and this is just the beginning. We’re excited to highlight the updates proposed for the network in Stacks 2.1 — an upgrade that will strengthen the connection between Stacks and Bitcoin.

Among other upgrades, Stacks 2.1 can enable more efficient Bitcoin yield via Stacking, make bridges to other networks more robust, simplify the ways developers can link and trigger interactions between Stacks and Bitcoin, and lay some helpful groundwork for Subnets which can bring additional speed and scalability to the network when launched.

Stacks Blockchain Release 2.1.0.0.0

After many months of hard work, the official release of Stacks 2.1 is finally upon us! This release is a culmination of a lot of work between many users, developers, exchanges, and companies building on Stacks, and adds many improvements.

Since this is a hard fork upgrade, attempting to upgrade an existing chain-state will fail. The main requirement for this release is that a full genesis sync must be performed since the 2.1 chain-state is incompatible with previous Stacks blockchain versions. For anyone using the Hiro API - any existing database data will also be incompatible with the 2.1 chain-state.

The expected cutover date for when Stacks 2.1 is activated should happen around March 20, 2023 (Bitcoin block 781,551), and the upgrade path is similar to previous minor updates - with the only requirement being a full chain-state sync from genesis. Read more here.

Releases
Stacks Blockchain
Hiro API

Changelogs
Stacks Blockchain
Hiro API

Stacks 2.1 Launch Timeline

Note: The dates provided are estimates and are subject to change as testing and other implementation efforts begin. This post will remain updated as we collect new information from core developers.
Voting Begins: November ~10th
Voting will take place during reward cycles 46 and 47. This window is estimated to begin starting November 10, 2022 and ending December 8, 2022. At the Stacks Foundation, we will be hosting weekly Twitter Spaces or Discord sessions to explain what the vote is about and help people navigate the voting process.
Code Complete: November ~15th
Stacks core developers are hard at work putting the finishing touches on code for Stacks 2.1. We anticipate they will be done by November 15th and move into testing.
Testnet Launch: +7 days
Following code completion, core devs will launch a public testnet. This will give the community and researchers a chance to catch any potential bugs as new features are tested. We expect a testnet launch roughly 7 days after code complete.

Key Stacks 2.1 upgrade areas:

Click to jump to a section
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.

  • PoX Sunset Removed. As part of Stacks 2.0, The PoX contract was set to expire after 2 years. Stacks 2.1 removes this 'sunset' and allows PoX/Stacking to continue until the network wishes to renegotiate it.

  • 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. Previously, in order to stack, you would need $stx_liquid_supply / 20,000 STX, which works out to be 66,382.372261 STX at the time of this writing (it increases slightly every block, since $stx_liquid_supply increases every block). You could stack multiple times with the same BTC address, but each time you would need this amount of STX (or more). One of the changes in 2.1 is that this limit is removed. You can “top off” your stacked STX with an arbitrarily small amount of STX. This is helpful when you want to put in additional STX into Stacking or perhaps to adjust to a rising dynamic minimum.

  • Support for Segwit and Taproot. Stacks 2.1 adds support for Stacking to a native segwit or taproot address. This not only saves users Bitcoin transaction fees, but also enables a greater degree of programmatic control over the accumulated Bitcoin by means of tapscripts. For example, it would now be possible to build a decentralized Stacking pool that pays BTC by crafting a tapscript to ensure that each participant receives only their fair share of the reward.
New Clarity Functions for Parsing and Validating Data
Clarity has been upgraded with a plethora of new keywords that, among other things, make the following two developer asks possible or more straightforward than they had been before:

  • Make it easy to write Clarity contracts that react to Bitcoin transactions
  • Make it easy to write Clarity contracts that ingest off-chain data

In the service of these two asks, Stacks 2.1 ships with many new Clarity keywords that make the following tasks easier for developers:

  • Decoding Bitcoin transactions
  • Verifying SPV proofs for Bitcoin transactions
  • Converting Bitcoin public keys and signatures to Stacks addresses
  • Encoding and decoding Clarity values to and from Clarity types (such as Clarity data stored within a Bitcoin transaction)

While it is possible to do these things today, they are tedious and expensive, and impose a poor user experience on certain types of applications — namely, bridges, decentralized mining, and Bitcoin-native asset creation. These are all fixed by Stacks 2.1.
Better Bridges
While bridges on Stacks can work today, it is difficult for developers to make them work because three tasks in Clarity are currently somewhat difficult:

  • Converting a public key or signature to a Stacks address
  • Converting raw data to and from Stacks addresses
  • Decoding binary data into a Clarity data structure

The Stacks 2.1 upgrade adds and fixes Clarity keywords that turn these tasks into one-liners. This, in turn, is expected to unlock full support for bridges, oracles, and other services that need to relay data to the Stacks chain.
Decentralized Mining Pools
Stacks is an open-membership system — anyone can mine if they have BTC. But mining is a capital-intensive process. The 2.1 upgrade lowers the barrier to entry for mining by supplying the two key building blocks for decentralized mining pools.
Pay-to-Anyone Coinbase
The block’s coinbase transaction format has been upgraded so that the Stacks miner can pay the block reward to any address of their choosing. This includes a cold wallet address, as well as a contract address. (Currently, the reward can only go to the key that signed the coinbase transaction).

In the latter case, the ability to pay newly-minted STX to a contract address is a building block for decentralized pooled mining. The contract would receive the STX from the pool, and then permit the participants to withdraw a pro-rata share of the STX they earned proportional to the Bitcoin they contributed.
Mining with Segwit and Taproot
The 2.1 upgrade adds the ability for miners to mine using a native segwit or taproot UTXO. Not only does this reduce the Bitcoin transaction fee by around 25%, but also this is a major building block for decentralized mining pools. A taproot key representing many individual contributors’ BTC could be used to mine Stacks blocks. When this taproot key is linked to each participant’s contributions (such as by having the participant prove the existence of their funding transaction), it becomes possible to build a decentralized mining pool smart contract that accumulates the pool’s STX and authenticates contributors’ withdrawals by their funding key.
Bitcoin-native Assets and Smart Contract Control
One of the more radical features Stacks 2.1 unlocks is the ability to directly send Stacks assets to Bitcoin addresses. Then, only the owner of the Bitcoin address can manipulate the asset on the Stacks chain via a specially-crafted smart contract that can recognize their Bitcoin transactions as contract-calls. While this could be achieved today if the Bitcoin address owner is willing to create a Stacks address first, Stacks 2.1 removes this requirement. Now, use-cases such as air-dropping NFTs to Bitcoin wallets will be supported. This simplifies the application onboarding experience for users and developers alike: users can get started with Stacks applications with only a Bitcoin wallet.

Drop in your email to stay in the loop on Stacks Foundation news