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 https://github.com/stacksgov/sips/pull/152#issuecomment-2225700977

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]

Hi @andrerserrano, SIP-022 has already been used for a merged SIP in SIP Repo therefore cannot be available.

This SIP will be assigned to the next available number: SIP-028 Please can you update the text and content accordingly?

(SIP-025 used by #183 Iterating towards WSTS) (SIP-026 intended to be used by an ongoing discussion re: Clarity DeFi Vault) (SIP-027 intended to be used by #152 Non-seq Multi-sig)

[radicleart]

The header of the document declares this to be

SIP Number: 022

But it seems to be assigned to SIP-026 in github but also linked to 028 ?

[Hero-Gamer]

But it seems to be assigned to SIP-026 in github but also linked to 028 ?

Hi @andrerserrano there is SIP-026 discussion regarding DeFi already from some months ago, it is possible for this SIP to be named SIP-028 & the corresponding PR path?

[andrerserrano]

@Hero-Gamer @radicleart yes we've received the feedback and will update the SIP number to SIP-028 in the new version.

[andrerserrano]

Hi everyone - thanks for all the feedback. I have updated the SIP based on comments from the technical CAB and steering committee. Also thanks to @AshtonStephens and @wileyj for their help on the SIP edits. Any questions or concerns, let me know.

[jiga]

@andrerserrano folder name and file name still mention sip-026, should be renamed to sip-028

[wileyj]

@andrerserrano folder name and file name still mention sip-026, should be renamed to sip-028

was about to say the same - @andrerserrano i would wait until after any outstanding comments are resolved, else it gets messy and it's not a change that warrants re-review

[andrerserrano]

Thanks all for the comments. I have updated the SIP and amended the signer criteria to be more objective and falsifiable, among other changes. Please review and let me know any feedback.

[jcnelson]

Mostly nits at this point. Great job getting this together!

The only significant point of contention that makes this SIP very difficult to ratify is that this SIP still puts too much authority in the hands of the sBTC working group's ability to choose the signers. I can't support this as-is because it would mean that the sBTC working group -- a non-SIP-process body that is not accountable to SIP officers and the community they serve -- would end up with a lot of unrestrained power to decide what happens to peoples' BTC.

To avoid this, and to avoid the need to come up with (very complex) means of having the SC validate the signers themselves, I think the SIP authors should do the following prior to activation:

1. Obtain the list of signers from the sBTC working group, including the ones that were candidates but were not selected
2. Describe how each candidate met each criterion
3. If there were more than 15 candidates, describe why they were the best 15 candidates
4. Present this information as part of the Activation section, so the community can make its own decision on whether or not these signers are adequate (and whether or not the sBTC working group's rationale is good enough).

This not only holds the sBTC working group accountable, but also frees them from having to reproduce the vetting process with the SC (some of which can, understandably, be difficult).

Also, I think it needs to be explicitly stated that once this SIP activates, the signer set cannot be changed except through a subsequent SIP that supersedes this one. If we need to kick a signer out, or replace signers, then there needs to be an accountable process for doing so (EDIT: such as by having sBTC holders vote on new signing sets). SIPs like this don't need to take a long time to activate; all that's necessary for activation is that the relevant stakeholders have a means to accept or reject the decisions made by SIP officers and authors.

[jcnelson]

@andrerserrano @aldur I heard from @wileyj, who I understand spoke with you two, and we spoke about how to move this SIP forward. While I think all of the technical comments are readily addressable, it's currently my understanding that you are concerned about the speed at which you can choose a new signing set (should the need arise). And, that concern is the reason why this SIP proposes that the sBTC working group indefinitely retains the ability to unilaterally change signing sets with no community oversight -- something that I oppose on the strongest terms.

Community Oversight of the Signers

This SIP proposes a system that is intended to garner significant user and economic traction in the Stacks ecosystem. If ratified, there are three possible outcomes for sBTC:

1. sBTC drives substantial ecosystem growth -- both in terms of number of users and amount of BTC value locked in it
2. sBTC has little impact on ecosystem growth, but it does not slow or diminish it either
3. sBTC drives substantial ecosystem decline, such as by locking up and then losing a substantial amount of BTC

The first two outcomes are acceptable, and if I had to choose, I'd (obviously) chose the foremost. The third one, however, must be avoided at all costs.

What makes this SIP challenging in a way not faced by other SIPs like SIP-010 is that the integrity of sBTC relies on an honest signer set. Indeed, the success or failure of sBTC hinges on the behavior of its signers! It does not matter how perfect the sBTC code is if too many signers go offline or act maliciously -- we can hit outcome #3 solely through signer misbehavior.

As such, avoiding outcome #3 requires ensuring that the signer set is honest and online at all times, or as close to it as possible. This not only requires a means of choosing suitable candidates (a process described by this SIP), but also requires a means of identifying, adding, and removing the signers themselves as needed. Offline or malicious singers must be replaced with honest, online signers as quickly as possible to achieve an acceptable quality of service needed for outcome #1 above.

But, who decides which signer candidates are trustworthy? It can't be just the SIP authors -- we have no way of knowing who the ecosystem trusts, short of asking the ecosystem itself. But this SIP does not do this. Instead, it proposes delegating the decision-making of which signers are trustworthy to an unelected, unaccountable body that isn't even part of the SIP process.

Why should the ecosystem blindly and indefinitely trust the sBTC working group to decide who handles their BTC? Can't the ecosystem collectively decide this for itself?

Fast sBTC Signer Selection

The SIP process is a means for the ecosystem to decide for itself what services the Stacks blockchain should (and should not) provide for them. Since decision speed seems to be the driving concern for choosing sBTC signers, why not extend this SIP to provide a means for the ecosystem to decide the signing set after it it initially proposed? Then, the SIP's ratification would not only choose the initial signing set, but also provide an accountable means for rotating signers.

I can see a few ways to do this (this is non-exhaustive):

• sBTC signer smart contract. This SIP could propose a smart contract that contains a registry of all candidate signers, and provides a means for sBTC holders to rank them by trustworthiness. Every so often (e.g. once a reward cycle), the sBTC software inspects this smart contract to identify the 15 highest-ranked candidates to become the new signers in the next reward cycle. For example, a very simple ranking system could be that sBTC holders can vote to replace signer A with signer B, and if enough sBTC votes by the end of the reward cycle, then the new signer must replace the old signer in the next reward cycle. There doesn't have to be a programmatic way for the sBTC software to automatically eject the old signer and add the new signer (this can be a manual process); what matters is that the signer set reflects the wishes of the ecosystem.

• sBTC Consideration Advisory Board. This SIP could elevate the sBTC working group to a CAB, and specify a governance charter for them that not only requires CAB officers to stand for election by an ecosystem-wide vote, but also requires CAB officers to poll the ecosystem (such as via SIP-018 signed structured messages) every so often for their opinions on a signer set. This SIP would specify voting thresholds for CAB officer election and signer set activation. Importantly, signer set activation can be fast -- as fast as sBTC holders can clear the voting threshold. This would also pave the way for future SIPs that require the sBTC CAB's sign-off, which I think is something you're going to want anyway.

• Fast-Activating SIPs. Nothing about the SIP process has to be slow -- a SIP can be ratified as soon as it gets the right sign-offs. This SIP could describe a template for future SIPs that only change the sBTC signing set, and require a threshold of sBTC holder votes via SIP-018 signed structured messages. The difference between this and the above is that it doesn't require organizing the sBTC WG into a CAB.

• Withdraw the SIP. I'm in no way taking a position on whether or not the SIP should proceed or be withdrawn -- that's for the authors and ecosystem to decide, not me. I am merely pointing out that sBTC as described in this SIP is an application -- it does not make any consensus changes, nor does it mandate the use of (or even define) a novel API or procedure for interacting with it. So, it's entirely reasonable to build and ship this version of sBTC without going through the SIP process. Other prominent applications, including other wrapped BTC assets on Stacks, don't have SIPs either. If you take this route, it would mean that you would be free to designate the sBTC working group as the sole arbiter of who is in the signer set, since then it could be the purview of the sBTC application (or anyone the authors choose).

I'm sure there are other ways to do this, but my point is that signer set agility is feasible today without delegating unilateral authority to the sBTC WG.

[andrerserrano]

@andrerserrano @aldur I heard from @wileyj, who I understand spoke with you two, and we spoke about how to move this SIP forward. While I think all of the technical comments are readily addressable, it's currently my understanding that you are concerned about the speed at which you can choose a new signing set (should the need arise). And, that concern is the reason why this SIP proposes that the sBTC working group indefinitely retains the ability to unilaterally change signing sets with no community oversight -- something that I oppose on the strongest terms.

Community Oversight of the Signers

This SIP proposes a system that is intended to garner significant user and economic traction in the Stacks ecosystem. If ratified, there are three possible outcomes for sBTC:

1. sBTC drives substantial ecosystem growth -- both in terms of number of users and amount of BTC value locked in it
2. sBTC has little impact on ecosystem growth, but it does not slow or diminish it either
3. sBTC drives substantial ecosystem decline, such as by locking up and then losing a substantial amount of BTC

The first two outcomes are acceptable, and if I had to choose, I'd (obviously) chose the foremost. The third one, however, must be avoided at all costs.

What makes this SIP challenging in a way not faced by other SIPs like SIP-010 is that the integrity of sBTC relies on an honest signer set. Indeed, the success or failure of sBTC hinges on the behavior of its signers! It does not matter how perfect the sBTC code is if too many signers go offline or act maliciously -- we can hit outcome #3 solely through signer misbehavior.

As such, avoiding outcome #3 requires ensuring that the signer set is honest and online at all times, or as close to it as possible. This not only requires a means of choosing suitable candidates (a process described by this SIP), but also requires a means of identifying, adding, and removing the signers themselves as needed. Offline or malicious singers must be replaced with honest, online signers as quickly as possible to achieve an acceptable quality of service needed for outcome #1 above.

But, who decides which signer candidates are trustworthy? It can't be just the SIP authors -- we have no way of knowing who the ecosystem trusts, short of asking the ecosystem itself. But this SIP does not do this. Instead, it proposes delegating the decision-making of which signers are trustworthy to an unelected, unaccountable body that isn't even part of the SIP process.

Why should the ecosystem blindly and indefinitely trust the sBTC working group to decide who handles their BTC? Can't the ecosystem collectively decide this for itself?

Fast sBTC Signer Selection

The SIP process is a means for the ecosystem to decide for itself what services the Stacks blockchain should (and should not) provide for them. Since decision speed seems to be the driving concern for choosing sBTC signers, why not extend this SIP to provide a means for the ecosystem to decide the signing set after it it initially proposed? Then, the SIP's ratification would not only choose the initial signing set, but also provide an accountable means for rotating signers.

I can see a few ways to do this (this is non-exhaustive):

• sBTC signer smart contract. This SIP could propose a smart contract that contains a registry of all candidate signers, and provides a means for sBTC holders to rank them by trustworthiness. Every so often (e.g. once a reward cycle), the sBTC software inspects this smart contract to identify the 15 highest-ranked candidates to become the new signers in the next reward cycle. For example, a very simple ranking system could be that sBTC holders can vote to replace signer A with signer B, and if enough sBTC votes by the end of the reward cycle, then the new signer must replace the old signer in the next reward cycle. There doesn't have to be a programmatic way for the sBTC software to automatically eject the old signer and add the new signer (this can be a manual process); what matters is that the signer set reflects the wishes of the ecosystem.
• sBTC Consideration Advisory Board. This SIP could elevate the sBTC working group to a CAB, and specify a governance charter for them that not only requires CAB officers to stand for election by an ecosystem-wide vote, but also requires CAB officers to poll the ecosystem (such as via SIP-018 signed structured messages) every so often for their opinions on a signer set. This SIP would specify voting thresholds for CAB officer election and signer set activation. Importantly, signer set activation can be fast -- as fast as sBTC holders can clear the voting threshold. This would also pave the way for future SIPs that require the sBTC CAB's sign-off, which I think is something you're going to want anyway.
• Fast-Activating SIPs. Nothing about the SIP process has to be slow -- a SIP can be ratified as soon as it gets the right sign-offs. This SIP could describe a template for future SIPs that only change the sBTC signing set, and require a threshold of sBTC holder votes via SIP-018 signed structured messages. The difference between this and the above is that it doesn't require organizing the sBTC WG into a CAB.
• Withdraw the SIP. I'm in no way taking a position on whether or not the SIP should proceed or be withdrawn -- that's for the authors and ecosystem to decide, not me. I am merely pointing out that sBTC as described in this SIP is an application -- it does not make any consensus changes, nor does it mandate the use of (or even define) a novel API or procedure for interacting with it. So, it's entirely reasonable to build and ship this version of sBTC without going through the SIP process. Other prominent applications, including other wrapped BTC assets on Stacks, don't have SIPs either. If you take this route, it would mean that you would be free to designate the sBTC working group as the sole arbiter of who is in the signer set, since then it could be the purview of the sBTC application (or anyone the authors choose).

I'm sure there are other ways to do this, but my point is that signer set agility is feasible today without delegating unilateral authority to the sBTC WG.

Hi @jcnelson thanks for this response. I hear your concerns. I have updated the SIP to include a link to the sBTC repo where there is a discussion topic on the sBTC Signer Set. This will be updated with the list of signers once the nomination period ends. I have also included a section on Updating the sBTC Signer Set, which specifies an approach where the existing Signer Set may perform a threshold vote to update the Signer Set based on the criteria defined in this SIP. This should hopefully satisfy the approaches you have outlined here in Fast Signer Selection.

[radicleart]

@andrerserrano, in the longer term and if wider community engagement is needed, it would also be possible to setup the ecosystem dao to hold a community vote on signer public key sets and to record the new keys on-chain automatically in response to a yes vote.

[andrerserrano]

This is really shaping up well! Just a few miner comments in this pass. Thank you for addressing my earlier feedback.

Thanks Jude. I will work on updating the SIP with the latest round of feedback.

[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 https://github.com/stacksgov/sips/commit/5e3d0de8dcb1530ac7e047115e43485954c401d3

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.