sBTC Rollout: Bootstrapping To Programmable Bitcoin

sBTC Rollout: Overview

sBTC enables secure movement of BTC onto the Stacks L2 in order to benefit from more scalable and expressive smart contracts. Today, the sBTC working group has released an update on the sBTC rollout plan that comes following an extensive scoping exercise.

TL;DR

The sBTC Release Candidate will be ready at the end of August. From there, core developers want to observe 3-4 weeks of stable Nakamoto behavior on mainnet, and then the release of sBTC can begin. Given the extra time between now and Nakamoto Activation that was added for Signer resiliency features, sBTC can now follow Nakamoto by roughly a month instead of two.

Bootstrapping Phase

Since the introduction of the initial sBTC design last year, the Working Group has been gathering extensive feedback from builders and experts inside and outside the ecosystem. This process has identified a path for rollout that includes two key phases:

1. Bootstrapping: In this phase, an initial group of Signers selected by a community vote will be responsible for Signing sBTC transactions on the network.

2. Signer Rotation: In this phase, the full design of the sBTC system with an open and decentralized Signer set is reached, increasing decentralization after the system is further tested in the bootstrapping phase.

Rollout Plan

The benefit of this initial bootstrapping phase is that sBTC can launch quickly and securely. This version does not require a hard fork to launch, which will help accelerate the timeline. This approach will allow builders to start gathering users and TVL, while also allowing as much time as needed to safely increase Signer decentralization.

The sBTC working group has projected the following launch milestones:

• October 2024: Nakamoto Activation (sBTC follows +4 weeks)

• November 2024: sBTC code complete and testnet release

• December 2024: sBTC mainnet release candidate ready

• Q2 2025: sBTC Signer Rotation begins

Rollout Rationale

The rollout plan for sBTC takes over a year of research and learnings into account, with the key points being:

1. sBTC must be safe at launch. Given the fact that Bitcoin is a pristine asset, there is no room for launching a production system that is experimental in nature. For sBTC, a controlled release that is more centralized initially is an industry best practice that will allow more time with the benefit of real-world usage and mainnet activity in hand to ensure the system is robust before further decentralizing the Signer set.

2. Builders need sBTC ASAP to power Bitcoin applications. The sBTC Working Groups has received consistent feedback that builders would prefer a version of sBTC that can be released sooner rather than later. Starting with the bootstrapping phase allows sBTC to be released more quickly but still safely, allowing builders to begin using it, acquiring TVL, and building their user base while further upgrades and progressive decentralization of the Signer set can happen in the background.

Deep Dive: Bootstrapping Phase

The bootstrapping phase brings sBTC to the Stacks mainnet with a limited group of Signers. From a user and developer perspective, sBTC during this phase will not be vastly different from sBTC as articulated in the white paper.

There are, however, important difference and tradeoffs during this phase. Let’s first take a look at the high-level features.

Features:

1. sBTC will be a SIP-10 token backed 1-1 by BTC in a peg wallet

2. The sBTC wallet will be maintained and managed by a limited sBTC signer set that will persist throughout the bootstrapping phase

3. BTC can be converted into sBTC within 3 Bitcoin blocks; and sBTC can be converted into BTC within 6 Bitcoin blocks

4. The SIP-10 token contract stays the same, meaning no adjustment from builders will be needed as the system gets more decentralized in the Signer Rotation phase.

Differences in the Bootstrapping Phase:

Several changes are being implemented to enable sBTC to be launched earlier and with less risk:

• sBTC Signers will be selected through a community voting process. The sBTC design implements a dynamically rotating signer set each Proof of Transfer cycle. However, in the bootstrapping phase, sBTC signers will be selected through a community voting process that will take into account Signer features and availability.

• sBTC Signers are separate from Stacks Signers. In the final sBTC design, Stacks signers are required to become sBTC signers to fulfill sBTC deposit and withdrawal actions. The bootstrapping period uses a separate subset of Stacks signers to secure the BTC wallet and Signer operations are not explicitly linked with slashing of rewards.

• sBTC deposits will be triggered via an API call. During the bootstrap phase sBTC deposits must be initiated via an API call to alert the signers to the presence of a Deposit. After the bootstrapping phase users will have the option to alert the Signers of a deposit via a Stacks contract call, but the API will remain as a fee-less option to communicate with the Signers.

Next steps

Since the sBTC whitepaper was released, we’ve set out to build a more decentralized and permissionless Bitcoin asset aligned with the ethos of the Bitcoin ecosystem. In addition, we want to ensure a safe launch with minimized downside, ensuring we treat Bitcoin as the premier asset it is. The bootstrapping phase outlined above enables all of this while accelerating the speed to market, helping Bitcoin builders in the process. The ecosystem and sBTC Working Group are committed to continued increases in decentralization as the system matures and invite you to follow progress on Github or by subscribing to this newsletter.

Bitcoin is more than people think and sBTC will soon prove that to the world!