After 2+ years of development and ~8 months of testing, Stacks 2.0 mainnet is scheduled go live later this week! The high-level launch process is similar to what was first proposed back in November and we shared a more granular plan two weeks ago. I wanted to share some more details of what to expect in the coming days, and immediately post-launch.
- The activation threshold of 20+ names registered in the
.minernamespace was met at BTC block 665250 - January 12th (Tuesday): As outlined here, the legacy Stacks 1.0 chain will “freeze” (stop accepting any new transactions) at BTC block 665750. Depending on the exact block intervals, we anticipate this happening sometime between 10am and 4pm ET tomorrow, January 12th (Tuesday). Stacks 1.0 nodes will also generate an export of all Stacks 1.0 state (excluding transaction history) and all further transactions will be rejected.
- January 13th (Wednesday): A Github workflow will automatically generate a PR on the stacks-blockchain repo to embed this exported chainstate in Stacks 2.0 (here’s an example of what this PR would look like). The exported chainstate will also be validated for accuracy and integrity, including a comprehensive automated suite described here.
- After adequate testing and validation, a “mainnet-release” will be tagged with version 2.0.0 and made available on the releases page, likely by end of day on January 13th or early on January 14th.
-
January 14th (Thursday): The “mainnet-release” will also set the “first burn block” height to 666050 — this means that the
stacks-nodesoftware will only start processing Bitcoin blocks starting at block 666050. Depending on the exact block intervals, we anticipate this happening sometime between 6am and 8pm on January 14th. All of the Stacks 1.0 exported state will be automatically incorporated into the Stacks 2.0 genesis block.
While Stacks 2.0 code has undergone significant testing (public testnets running for ~8 months; multiple security audits; bug bounties), like any complex software (~200K lines of code!) and protocol, there can be latent or emergent bugs (remember the early days of Bitcoin and Ethereum).
Below is a proposal for dealing with any CRITICAL issues post-launch: critical meaning there’s active or imminent threat to the network security or assets. For everything else, follow the SIP process (outlined in SIP-000).
| Category | Expected Remediation | Communication Channel |
|---|---|---|
|
Critical but non-consensus-breaking updates e.g. a crash on the networking path |
The Stacks Foundation, working with Stacks core developers, will publish a new release on Github. Anyone running a Stacks 2.0 node SHOULD upgrade. This would be just a routine software update, no impact to chainstate. |
- New release on Github is authoritative source of truth. We’ll be using semver, so there should be no major version bump. - Announcement in #mining on Discord, as well as on Forum and Twitter. |
|
Critical, consensus-breaking updates e.g. an exploit is discovered in PoX or Clarity |
The Stacks Foundation, working with Stacks core developers, will publish a new release on Github. Anyone running a Stacks 2.0 node MUST upgrade. This will be a hard-fork of the chain. |
- New release on Github is authoritative source of truth. We’ll be using semver, so there will be a major version bump. - Announcement in #mining on Discord, as well as on Forum and Twitter. |
In the first month or two immediately post launch, miners should anticipate and be prepared to (frequently) upgrade their nodes to:
- Incorporate fixes for critical issues in the first category.
- Incorporate regular updates that are not-critical, but still useful: for instance, improvements in logging, configuration management, monitoring etc.
We strongly encourage anyone running Stacks 2.0 nodes to subscribe to the stacks-blockchain releases Github:
Thanks for your support, and we’ll see you on Stacks 2.0!
