SIP-028: sBTC Signer Criteria

[andrerserrano]

Signer Criteria for sBTC, A Decentralized and Programmable Asset Backed 1:1 with BTC

Abstract

This SIP takes the position that Stacks can play a key role in offering a rich programming environment for Bitcoin with low-latency transactions. This would be achieved with a new wrapped Bitcoin asset, called sBTC, which would be implemented on Stacks 3.0 and later as a SIP-010 token. Stacks today offers a smart contract runtime for Stacks-hosted assets, and the forthcoming Stacks 3.0 release provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on threshold signatures, users would be able to lock their real BTC on the Bitcoin chain, instantiate an equal amount of sBTC tokens on Stacks, use these sBTC tokens on Stacks, and eventually redeem them for real BTC at 1:1 parity, minus the cost of the relevant blockchain transaction fees.

This is the first of several SIPs that describe such a system. This SIP describes the threshold signature mechanism and solicits from the ecosystem both a list of signers and the criteria for vetting them. These sBTC signers would be responsible for collectively holding all locked BTC and redeeming sBTC for BTC upon request. Given the high-stakes nature of their work, the authors of this SIP believe that such a wrapped asset can only be made to work in practice if the Stacks ecosystem members can reach broad consensus on how these signers are chosen. Thus, the first sBTC SIP put forth for activation concerns the selection of sBTC signers.

This SIP outlines but does not describe in technical detail the workings of the first sBTC system. A separate SIP will be written to do so if this SIP successfully activates.

[radicleart]

Hi Please update the activation criteria to include the voting address as below.

Activation
Since this SIP requires a change to the stacks consensus rules a community vote is additionally required.

Process of Activation

Users can vote to approve this SIP with either their locked/stacked STX or with unlocked/liquid STX, or both. The criteria for the stacker and non-stacker voting is as follows.

For Stackers:

In order for this SIP to activate, the following criteria must be met by the set of Stacked STX:

At least double the amount of Stacked STX locked by the largest Stacker in the cycle preceding the vote must vote at all to activate this SIP.
Of the Stacked STX that vote, at least 70% of them must vote "yes."
The voting addresses will be;

Bitcoin Yes Address: 3Jq9UT81fnT2t24XjNVY7wijpsSmNSivbK

Bitcoin No Address: 3QGZ1fDa97yZCXpAnXQd6JHF4CBC6bk1r4

Stacks Yes Address: SP36GHEPEZPGD53G2F29P5NEY884DXQR7TX90QE3T

Stacks No Address: SP3YAKFMGWSSATYNCKXKJHE2Z5JJ6DH88E4T8XJPK

which encode the hashes of the following phrases into bitcoin / stacks addresses:

Yes to A Decentralized Two-Way Bitcoin Peg
No to A Decentralized Two-Way Bitcoin Peg

Stackers (pool and solo) vote by sending a dust stacks to the corresponding stacks address from the account where their stacks are locked.

Solo stackers only, can also vote by sending a bitcoin dust transaction (6000 sats) to the corresponding bitcoin address.

For Non-Stackers:

Users with liquid STX can vote on proposals using the Ecosystem DAO. Liquid STX is the users balance, less any STX they have locked in PoX stacking protocol, at the block height at which the voting started (preventing the same STX from being transferred between accounts and used to effectively double vote). This is referred to generally as "snapshot" voting.

For this SIP to pass, 70% of all liquid STX committed by voting must be in favour of the proposal.

The act of not voting is the act of siding with the outcome, whatever it may be. We believe that these thresholds are sufficient to demonstrate interest from Stackers -- Stacks users who have a long-term interest in the Stacks blockchain's successful operation -- in performing this upgrade.

[Hero-Gamer]

If this sBTC V1 SIP were to go up for community vote.

I'd take a look at Multi-sig SIP's voting criteria comment for consistency #152 (comment)

Essentially my two suggestions below:

For Stackers:

In order for this SIP to activate, the following criteria must be met by the set of Stacked STX:

At least double the amount of Stacked STX locked by the largest Stacker in the cycle preceding the vote must vote at all to activate this SIP. Of the Stacked STX that vote, at least 70% of them must vote "yes."

My suggestion would be to change to:
In order for this SIP to activate, the following criteria must be met by the set of Stacked STX:

• At least 80 million Stacked STX must vote at all to activate this SIP.

• Of the Stacked STX that vote, at least 80% of them must vote "yes."

Historically that's what we've done. E.g. in SIP-015 (Stacks 2.1 Upgrade)

For Non-Stackers:

For this SIP to pass, 70% of all liquid STX committed by voting must be in favour of the proposal.

Commented in the multi-sig SIP, historically been 66% for context, but I actually think it's great to trial 70% threshold. Recommendation: keep 70%!

[friedger]

How does this sip go with #156 ?

[andrerserrano]

How does this sip go with #156 ?

#156 is now outdated. This SIP supersedes that issues.

[Hero-Gamer]

I few nuances to clarify for the public will be great.
1. Community governance process is voting on eligibility criteria

• sBTC Signers will be selected through an open community governance process - this wording indicates community governance process has some roles in selecting the sBTC Signers, but my understanding is the community vote is only voting on the "eligibility criteria" laid out in this SIP.
• sBTC Signers that meet the criteria are selected by a separate group of people (sBTC Working Group?).
• Therefore I'd personally phrase it as: eligibility criteria is confirmed through this community governance vote

2. Number of Signer set

• I'm not seeing the number of Signer set specified in this SIP. Could be 3, could be 15. Could be 30. I did hear on the call it is 15. So it would be good for the public information to know a range being targeted perhaps on the SIP itself, of if it's been decided it's going to be 15, just to allow people to get a sense what we are opting into/voting on.

3. Signers voting structure.

• For the pegging in and pegging out, more important for the pegging out part, what's the consensus mechanism, is it 1 signer 1 vote (if 15 signers, would need to reach 11 votes, is it 70/60/50% the quorum?), or is it via number of STX they held and reaching 70% of STX quorum consensus. From the SIP call my understanding is 1 signer 1 vote. Would be great to lay it out for the people using the V1 bridge understand the risk assessment.

[andrerserrano]

I few nuances to clarify for the public will be great. 1. Community governance process is voting on eligibility criteria

• sBTC Signers will be selected through an open community governance process - this wording indicates community governance process has some roles in selecting the sBTC Signers, but my understanding is the community vote is only voting on the "eligibility criteria" laid out in this SIP.
• sBTC Signers that meet the criteria are selected by a separate group of people (sBTC Working Group?).
• Therefore I'd personally phrase it as: eligibility criteria is confirmed through this community governance vote

2. Number of Signer set

• I'm not seeing the number of Signer set specified in this SIP. Could be 3, could be 15. Could be 30. I did hear on the call it is 15. So it would be good for the public information to know a range being targeted perhaps on the SIP itself, of if it's been decided it's going to be 15, just to allow people to get a sense what we are opting into/voting on.

3. Signers voting structure.

• For the pegging in and pegging out, more important for the pegging out part, what's the consensus mechanism, is it 1 signer 1 vote (if 15 signers, would need to reach 11 votes, is it 70/60/50% the quorum?), or is it via number of STX they held and reaching 70% of STX quorum consensus. From the SIP call my understanding is 1 signer 1 vote. Would be great to lay it out for the people using the V1 bridge understand the risk assessment.

Thanks, @Hero-Gamer I have incorporated all of these suggestions into the SIP.

[wileyj]

The formatting of this sip is off. I see a sip number referenced, but the PR is adding a single (text) file to the root of the repo. Please create a new file in the format, ex: ./sips/sip-025/sip-025-sbtc.md ref: https://github.com/stacksgov/sips/pull/156/files

Secondly - the sip number is already occupied by the emergency SIP process: https://github.com/stacksgov/sips/blob/main/sips/sip-022/sip-022-emergency-pox-fix.md

Third - the PR contains a lot of graphics and other data that isn't present in the file being PR'ed. is that by design?
ref: https://github.com/stacksgov/sips/pull/156/files for how to include graphics and other data in a proposed SIP (essentially, all additional data should be included in the sip folder i mentioned above).

If this sip is meant to supersede #156 - can you explain what the differences are, and if that PR is meant to be closed?
Alternatively, should the changes be PR'ed to the branch in #156 ?

[jiga]

hi @andrerserrano please see my comments below

Preamble: The preamble is missing several required fields such as 'Author', 'Created', 'License', 'Sign-off', 'Layer', 'Discussions-To', 'Comments-Summary', 'Comments-URI', 'License-Code', 'Post-History', 'Requires', 'Replaces', and 'Superseded-By'.

Abstract: The abstract exceeds the 5000-word limit.

Introduction: The introduction section is missing.

Specification: The specification section lacks detailed technical specifications, code snippets, payload formats and performance evaluations. Need more details on Deposit Accept step.

Related Work: This section is missing.

Backwards Compatibility: This section is missing.

Reference Implementations: This section is missing. Are there any issues/checkins to refer to?

[andrerserrano]

Secondly - the sip number is already occupied by the emergency SIP process: https://github.com/stacksgov/sips/blob/main/sips/sip-022/sip-022-emergency-pox-fix.md

@wileyj what is the correct SIP number for this?

Abstract: The abstract exceeds the 5000-word limit.

There are only 200 words in the abstract

Introduction: The introduction section is missing.

The introduction section is formatted similar to SIP 21 with a glossary and problem statement.

Going through the rest of the feedback now and will update accordingly. Thanks.

[jiga]

How does this sip go with #156 ?

#156 is now outdated. This SIP supersedes that issues.

does this SIP really supersedes #156 or does #156 requires this SIP as prerequisite ?

[jiga]

about Bootstrap Signer Eligibility

Communication & Availability: towards this, should Signers also have to be public entities ?

Ecosystem Alignment: How is this measured or ensured?

Are there any security requirements that must be followed by Signers (e.g. hardened deployments, following private key handling best practices? auditable?)

[Hero-Gamer]

Some comments

[314159265359879]

This looks good: overall it is well-structured. I have some minor comments and suggestions that could improve readability.

[314159265359879]

This is accepted by SIP editors. Lets move to voting.

The changes requested by Jude have been added in, lets make sure it is included in the merged version 5e3d0de

The suggestions I made can be considered for the final version that gets merged into the repo. I will leave that to the discretion of the authors.

[jcnelson]

This looks great. Thank you for working so hard to get this SIP into this form! Onwards to activation 🚀

[AshtonStephens]

LGTM.

[AshtonStephens]

Actually, revoking my approval until I've properly checked that this has gone through the governance channels.

[AshtonStephens]

Verified it was approved by:

• CABs
• Steering committee
• Vote