In this article, you will learn about Stacks 2.05 to 2.1 migration and how the Hiro product changes reflect this upgrade.
What is Stacks 2.1?
Stacks 2.1 is a fork and protocol upgrade of the Stacks blockchain. Among other improvements, Stacks 2.1 includes an updated Proof-of-Transfer (PoX) contract (often informally referred to as "PoX-2") for Stacking. Stacking allows users to lock up STX to support the network and earn BTC. For more information on stacking changes, refer to How Stacks 2.1 Impacts Stacking.
What is PoX-2?
Proof-of-transfer (PoX) is a consensus mechanism in modern blockchains. In Stacks 2.05 or earlier versions, this consensus mechanism uses the
.pox (boot/pox.clar, aka PoX-1) boot smart contract. With the Stacks 2.1 upgrade, the new fork is updated to
.pox-2 (boot/pox-2.clar, aka PoX-2).
The PoX-2 fork evolves in the following periods. Hiro products adapt to these periods to align with the new network upgrade — SIP-015.
Period 1— Stacks 2.0 and PoX-1 consensus rules in effect.
Period 2— PoX-1 is still active. Stacking or delegating can start with PoX-2.
Period 2a— PoX-1 deactivates and PoX-2 is now active. Tokens locked in PoX-1 contract unlock.
Period 2b— In the 2.1 fork, after v1_unlock_height, but before the first PoX-2 reward cycle.
Period 3— PoX-2 is active. The first PoX-2 reward cycle starts.
PoX-2 is not immediately used for reward cycles after the 2.1 fork. Period 2 (2a and 2b) allows stackers to stack and delegate their funds using PoX-2.
The currently "active" PoX contract will determine the reward set for the upcoming reward cycle. 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. The transition when PoX-2 is "active," but the current reward set is still being read from PoX-1 state is Period 2b.
To understand more about PoX-2 activation, reward cycles, and phases, refer to the below diagram.
Now that you have a general understanding of Stacks 2.1 and the PoX changes and what to expect, let's dive into each product and understand the new features or improvements to the existing features for Stacks 2.1 upgrade.
This section explains the Stacks 2.1 upgrade for Clarinet.
In your project's
Clarinet.toml file, you can now specify the epoch during which a contract should be deployed, and the Clarity version it uses. Note that you may only select the Clarity version in epoch 2.1.
path = "contracts/cbtc-token.clar"
clarity_version = 2
epoch = "2.1"
Update Devnet settings
This section helps you update your Devnet settings to work with the Stacks 2.1 upgrade.
After installing the latest version of Clarinet, navigate to your project directory and then to
settings/Devnet.toml (hereafter referred to as devnet.toml).
Find the section [devnet] with the following settings.
disable_stacks_explorer = false
disable_stacks_api = false
Add a new setting,
enable_next_features = true, and keep the remaining settings as-is.
The updated Devnet.toml looks like this:
enable_next_features = true
disable_stacks_explorer = false
disable_stacks_api = false
Spin up a local Devnet network using the command:
New stacks-node will spin up. At Bitcoin block height 102, the chainstate will migrate to epoch 2.05, a network upgrade introduced earlier this year, reducing operations costs. At bitcoin block height 106, the chainstate will migrate to epoch 2.1.
As shown in the below screenshot, the epoch changes are indicated in the Transactions section
deployed: ST00000000000000002AMW42H.costs-3 (ok true).
If the contracts you're developing use Clarity 2, you must wait for this epoch to cross before deploying your contracts.
These block heights can be customized using the settings in the devnet.toml:
epoch_2_05 = 102
epoch_2_1 = 106
NOTE: If you have trouble or find issues, you can report them here.
Stacks Blockchain API
The following updates for the API endpoints are for the Stacks 2.1 upgrade.
Distinguish contract versions
This section explains the new property returned with the following existing endpoints.
/extended/v1/contract/<contract-id> now return a new property,
The sample response with the new property is shown below:
"clarity_version": 2, # <-- New
"source_code": ";; PoX testnet constants\n;; Min/max number of reward cycles uSTX can be locked for..."
A sample response for a regular (non-versioned) smart contract transaction with Clarity version null is shown below:
"clarity_version": null, # <-- New
"source_code": ";;;; Errors\n(define-constant ERR_PANIC 0)..."
The Stacks 2.1 upgrade supports alternate recipients for Coinbase transactions. The
alt_recipient value is passed in the blockchain transaction, and the API returns a new Coinbase
alt_recipient property on applicable requests; if you want to use the latest methods detailed above, you need to update
@stacks/stacking to version >=
alt_recipient value varies based on the standard vs. contract principal recipients.
Standard principal recipient sample:
"alt_recipient": "ST2X2FYCY01Y7YR2TGC2Y6661NFF3SMH0NGXPWTV5" <-- New
Contract principal recipient sample:
"alt_recipient": "ST2X2FYCY01Y7YR2TGC2Y6661NFF3SMH0NGXPWTV5.hello_world" <-- New
PoX-2 support for Rosetta API
- Address format changes: Adding support for segwit/taproot/bech32 addresses in PoX-2.
- Constructing stacking operations: Rosetta has built-in support for performing various "Stacking" operations, which perform PoX-1 contract calls under the hood. These need to be changed to PoX-2 contract calls.
- Parsing stacking operations: Adding support for performing various "Stacking" operations involving PoX-2 contract calls.
Stacks 2.1 upgrade for Stacks.js include methods now accepting
poxAddress in more BTC address formats (P2PKH, P2SH, P2WPKH, P2WSH, P2TR) and new Stacking and Helper methods.
New PoX interactive functions for Clarity
This section explains the new PoX interactive functions/methods for Clarity. The following are the new
@stacks/stacking methods that interact with the new PoX functions added in 2.1.
New helper methods
StackingClient.getAccountBalanceLocked()gets the locked balance of the address from a node (
StackingClient.getAccountExtendedBalances()gets more detailed balances of the address from an API (
/extendedendpoint); this includes STX, FTs, and NFTs
get-delegation-infoinformation of the address from a node (read-only contract call)
StackingClient.getPoxOperationInfo()gets information about the current period of transition to PoX-2
StackingClient.getStackingContract()gets the contract identifier (
address.name) of the PoX-contract to use. This will be PoX-1, unless PoX-2 is available (anytime after the 2.1 fork).
@stacks/stacking releases will automatically switch to the new PoX contract (in Period 2b).
However, if you want to use the new methods detailed above, you need to update to
@stacks/stacking to a version >=
6.0.0. The updated release will also always prefer PoX-2 if possible. Use the following command to update the version.
npm install @stacks/stacking@^6.0.0
There will be a short period of time (Period 2a), where old versions
6.0.0) will stack to PoX-1, even though PoX-2 is available.