How the Stacks 2.1 Transition Impacts Stacking

If you are unfamiliar with the 2.1 upgrade, start with this overview and then this developer guide for more context. Voting is currently live for 2.1 (vote here). Here is a rough timeline of 2.1:

• Voting ends: December 15th
• Release of 2.1: December 16th
• 2.1 Rule Activation (launch of PoX-2): January 17th

The 2.1 upgrade brings important changes to stacking. For more info on stacking, click here, but at a high level stacking allows users to lock up STX to support the network and earn BTC in the process. The upcoming upgrade brings a number of big stacking changes, including:

• Continuous stacking: currently, users can only opt in to stack for a set number of cycles, which means users are penalized by missing a reward cycle in a cooldown period. With 2.1, stackers can stack as much as they want, whenever they want.
• Increasing lock-ups: Users can “top off” their stacked STX with an arbitrarily small amount of STX.
• Support for Segwit and Taproot: 2.1 adds support for stacking to a native segwit or taproot address. This saves user Bitcoin transaction fees and enables more programmatic control over the accumulated Bitcoin by means of tapscripts. For example, this enables the creation of decentralized stacking pools that pay out BTC.
• PoX sunset removed: as part of Stacks 2.0, the proof of transfer (PoX) contract was set to expire after two years. 2.1 removes this "sunset" and allows PoX/Stacking to continue into the future.

Two important things to note:

• These changes are still dependent on being approved during the voting process, which is currently live. Vote here.
• Users who are stacking going into the 2.1 transition will be required to restack their STX if they wish to continue stacking after the transition.

Today, users stack via the PoX-1 contract (view the contract on the explorer here—note the original PoX contract <code-rich-text>.pox<code-rich-text> is referred to as PoX-1 in this article for clarity). With this upgrade, the PoX-1 contract will be retired (but the contract will still be accessible on the blockchain), and users will begin stacking via the upgraded PoX-2 contract. Upgrading the PoX contract is tricky, given all the moving pieces (e.g. ongoing Stacking / delegation operations). To ensure safety and accuracy, the transition process makes some choices to reduce the complexity of the change. These choices will end up impacting anyone participating in Stacking. What sort of impact? Let's find out.

Overview of Transition Periods

First, let’s walk through some quick context. This blog post names some variables and placeholders used throughout the Stacks ecosystem and SIP-015. The exact values are not yet decided and may change. The most important ones are listed below. See the period explanation for more information.

• <code-rich-text>v1_unlock_height<code-rich-text> == <code-rich-text>POX2_ACTIVATION<code-rich-text>: the block height, which will determine when Period 2a ends
• Cycle N: the last cycle using PoX-1 for its reward set. This is defined as the cycle. which <code-rich-text>POX2_ACTIVATION<code-rich-text> is in.‍
• Cycle N+1: the cycle after cycle N; The first cycle to use PoX-2 for its reward set

At a high level, there are a few key periods to be aware of with the 2.1 upgrade. Here’s some high-level information adapted from the official SIP-015.

What does “PoX-contract is active / in effect” mean?

The currently “active” PoX-contract will determine the reward set for the upcoming reward cycle. By that we mean, if PoX-1 is the “active” contract, the next reward cycle will read from the smart-contract state of PoX-1 to determine who is paid out to for Proof-of-Transfer consensus. There will be a time during this transition when PoX-2 is “active”, but the current reward set is still being read from PoX-1 state (i.e. during Period 2b).

What is a “PoX-2 reward cycle”?

This refers to a complete PoX-2 cycle, in which stackers stack to PoX-2 and PoX-2 state determines who is paid out for Proof-of-Transfer consensus.

Transition Periods — Timeline

Now let’s get visual and dive a bit deeper into the semantics of this transition…

Period 1:

• This is before the 2.1 fork, and the period we are in right now.
• We have to deal with the original limitations of PoX-1 (e.g. cooldown cycle after stacking).

Period 2a:

• This marks the start of the 2.1 fork.
• This period is intended to be very short and is needed for technical reasons to upgrade the PoX contract.
• PoX-1 is still technically the active PoX-contract. However, there is likely no reason to stack to PoX-1 anymore in practice. This is due to the fact that the next cycle will be using a reward set which is already established at this point in time.
• PoX-2 can already be used. Users can stack their own funds to PoX-2 for the upcoming cycle or delegate to pools of their choice.

Period 2b:

• Period 2b starts one block after <code-rich-text>v1_unlock_height<code-rich-text>.
• PoX-2 is now the active PoX-contract!
• Any funds locked via PoX-1 are now automatically unlocked and can be stacked/locked to PoX-2. Users will be required to restack after 2b if they wish to continue stacking.
• PoX-1 is deactivated; It’s still possible to read from its state, but any stacking operations will fail.
• The current reward cycle still uses PoX-1 to get its reward set.

Period 3:

• PoX-2 stays the active PoX-contract and will remain so moving forward.
• The first cycle of Period 3 (cycle N+1) is also the first cycle to use PoX-2 for its reward set.

Deep Dive into Stacking Behavior

How do these various periods impact stacking behavior? Let’s take a look at each PoX contract to show when users can stack STX to each contract.

PoX-1

The following rules relate to PoX-1 during the transition to the 2.1 fork:

• In Period 1, users can stack as they always did — there is no concept of a fork yet. It is perfectly fine if users have started stacking in Period 1 for enough cycles to reach Period 3 and beyond.
• Users can initiate stacking via periods 1 and 2a (though 2a is likely too short for an entire stacking cycle). Rewards will continue to be processed in the same way that they have been.
• Beginning with Period 2a, any new stacking commitments to PoX-1 where the stacking cycle ends in Period 2b or beyond will fail.
• In Period 2b, any STX locked up in the PoX-1 contract will be automatically unlocked (and those funds will become usable by their owners again).

PoX-2

The following rules relate to PoX-2 during the transition to the 2.1 fork:

• Users can start stacking to PoX-2 as soon as Period 2a starts (i.e. any time in the 2.1 fork).
• The first possible cycle to stack to PoX-2 AND receive stacking rewards via the PoX-2 contract is cycle N+1 (in Period 3).

Stacking Pools

There is some behavior pool operators should be aware of as well. Let’s take a look at a timeline for pools.

Pool operators will have to switch to PoX-2 during the transition of the 2.1 fork activation. Beginning in Period 3, PoX-2 will become the new active Proof-of-Transfer contract.

At the start of Period 2b, PoX-1 will become defunct and unusable. This means that previously collected delegations (to PoX-1) will become unusable with the start of Period 2b. In practice, PoX-1 is useless as soon as the 2.1 fork occurs (Period 2a), but cycle N will still use the last reward set from PoX-1.

Period 2b exists, in part, to make uninterrupted stacking possible. Assuming pools want to stack in as many cycles as possible, they will need to ask their users to delegate again (to PoX-2 this time) beginning as soon as Period 2a. In other words, pools will need to collect new delegations — anytime in the 2.1 fork:

• New users (without previous stacking/delegations) can delegate to PoX-2 anytime in the 2.1 fork (after the start of Period 2a). Pools can immediately stack for them (as they don’t currently have locked funds).
• Existing users (with their funds still locked in PoX-1) need to delegate again to their pools via PoX-2 anytime in the 2.1 fork. To maximize cycles during the transition, the pools can stack for their users as soon as Period 2a (if the respective user’s funds are NOT locked), or wait until Period 2b (for the funds to automatically unlock in PoX-1, enabling users to then lock them into PoX-2).

With the new methods available in PoX-2, managing cycle commitments is a lot easier. At any time in the reward phase of a cycle*, operators can increase their commitment — for example, if users added delegations or increased their delegation amount. Read about the exact changes to the contract in SIP-015.

*assuming other PoX constraints (e.g. the resulting block will be part of the canonical chain before the chosen PoX anchor block)

Conclusion

Big changes are on the way, and we’ve created this resource to try to minimize any disruptions to the stacking user experience. As a reminder, users who are stacking before the 2.1 transition will be required to restack their STX if they wish to continue stacking after the transition. Similarly, for users who delegate to a stacking pool, they will need to re-delegate their STX to the pool of their choice, via PoX-2. 

If you have any questions, reach out to us on Discord via the HIRO PUBLIC channels.