stacksgov
SIP-028: sBTC Signer Criteria
SIP-028: sBTC Signer Criteria
SIP Number: 028
Title: Signer Criteria for sBTC, A Decentralized and Programmable Asset Backed 1:1 with BTC
Consideration: Technical, Economics
Type: Standard
Status: Draft
Authors:
- Andre Serrano ([email protected])
- Ashton Stephens ([email protected])
- Joey Yandle ([email protected])
- Mårten Blankfors ([email protected])
- Jesus Najera ([email protected])
- Jude Nelson ([email protected])
- Friedger Müffke ([email protected])
- Tycho Onnasch ([email protected])
- Daniel Jordon ([email protected])
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.
Introduction
Glossary
| Term | Definition |
|---|---|
| SIP-10 Token | A token on the Stacks blockchain that adheres to the fungible token standards outlined in SIP-10. |
| sBTC | A SIP-10 token on the Stacks Blockchain that can be turned back into BTC on the Bitcoin Blockchain. 1 sBTC is equivalent to 1 BTC on the Bitcoin Blockchain. |
| sBTC operation | An operation that initiates some action from the sBTC protocol. |
| .sbtc contract | A smart contract (or a collection of contracts) defining the sBTC token and functions related to it. |
| sBTC Peg Wallet | The single UTXO holding the entire BTC balance that’s pegged into sBTC. This peg wallet is managed and maintained by the sBTC Signers. |
| Stacks Signer | An entity that receives PoX payouts for stacking their STX tokens and actively participating in the Stacks protocol by signing mined blocks. |
| sBTC Signer | An entity that will sign sBTC operations and communicate with contracts on the chain to make that feasible. This entity has partial access to spending the sBTC UTXO. |
| sBTC Signer Set | The set of all sBTC signers. Each is registered with the .sbtc contract and the transfer. These entities as a group have full democratic access to the sBTC UTXO. |
| sBTC Signer API | An API exposed by the sBTC Signer that handles basic low-level commands. |
| Deposit API | A third party API that communicates with the sBTC Signers via the sBTC Signer API. |
Problem Statement
Bitcoin Script's computational expressiveness is limited, such that developers who want to build non-trivial decentralized applications must first build and maintain non-trivial off-chain services to make up the difference. Namely, because Bitcoin Script programs can neither store nor read arbitrary chain state (up to VM-imposed size limits), applications that maintain state across Bitcoin transactions must not only provide the means of storing it themselves but also somehow make it available to subsequent Bitcoin transactions.
Doing this in an open-membership peer-to-peer setting has been shown to be a difficult task (given the size and complexity of systems like Lightning, Taro, Bisq, and BitVM), which imposes a high barrier to entry for building decentralized applications on Bitcoin. Our key insight is that existing applications built on Bitcoin have built up most of the workings of an L2 blockchain like Stacks, but have done so implicitly within their interior components. This SIP makes this design choice explicit: the act of building non-trivial applications on Bitcoin is the act of building on a Bitcoin L2, and therefore the act of providing a rich programming environment for BTC is the act of implementing a wrapped BTC asset (sBTC) on a Bitcoin L2 with smart contracts. Indeed, this has been realized already with systems like Rootstock's RBTC.
Proposed Solution
sBTC aims to mitigate Bitcoin’s limitations by combining the capability of the Stacks Blockchain with the reliability and security of Bitcoin. By enabling the secure movement of BTC in and out of the Stacks Blockchain via the sBTC protocol, users can interact with their BTC on Stacks using Clarity smart contracts and fast block times. The protocol is “secure” in that it is operated by a decentralized signer network, removing the risk of a single point of failure and trust in a single custodian. Users can deposit BTC into the protocol, seamlessly transact using sBTC on the Stacks blockchain, and have the freedom to redeem sBTC tokens for the underlying BTC at any time.
Programmability
Clarity is the smart contract language on Stacks, which allows developers to encode essential business logic on a blockchain. Using smart contracts, developers can build more expressive decentralized applications that interact with sBTC, such as DeFi protocols, stablecoins, payments, and many others.
Fast Blocks
The Stacks Nakamoto Upgrade, proposed in SIP-021, enables fast blocks where user-submitted transactions will now take on the order of seconds, instead of tens of minutes. Thus, sBTC on Stacks Nakamoto will offer an improvement to Bitcoin’s current transaction times.
The sBTC protocol not only addresses the limitations of the Bitcoin scripting system but also provides a secure and decentralized solution for utilizing Bitcoin in various applications.
Design
While the first sBTC implementation is under development, the wrapped nature of the sBTC token means that any such system would have the following properties:
- sBTC is a SIP-10 token backed 1:1 by BTC.
- The sBTC peg wallet is maintained by the set of sBTC signers. These signers are responsible for the security and maintenance of the wallet, ensuring that sBTC is redeemable for BTC.
- Bitcoin can be converted into sBTC within 3 Bitcoin blocks; and sBTC can be converted into Bitcoin within 6 Bitcoin blocks. sBTC relies on the forking behavior guaranteed by SIP-021 in order to maintain the peg wallet correctly across forks.
Specification
Management of the sBTC peg wallet on the Bitcoin blockchain is decentralized, involving the sBTC Signer Set rather than a single custodian. At launch, the sBTC protocol will be maintained by 15 independent entities that make up the sBTC Signer Set. The eligibility criteria to become an sBTC Signer is determined through the community governance process of ratifying this SIP.
sBTC Signers are responsible for accepting or rejecting all sBTC deposit and withdrawal operations submitted to the network. For a transaction to be fulfilled, at least 70% of the signers need to approve the transaction. This means that the liveness and reliability of the signers is crucial to the success of the protocol. The system is live ("resilient") if at least 70% of the sBTC Signer voting power are online and honest. Then (and only then), deposits and withdrawals happen in a timely manner. The system is safe ("trustworthy") if at least 30% of the sBTC Signer voting power is honest. Then, no theft of funds can occur.
Throughout this release, sBTC will have an unchangeable and distinct signer set that will not explicitly be part of Stacks consensus. As a result, this release can activate without a hard fork. Each unique signer receives exactly one vote. Given there are 15 unique signers that comprise the system, it would require at least 11 out of 15 signatures for an sBTC operation to be fulfilled.
While up to 30% of the signers can be offline without a user impact on the functioning of the protocol, it becomes more critical for the rest of the signers to approve sBTC operations because operations necessarily still need to meet 70% of the original signing power. If more than 30% of signers become unavailable, no sBTC operations will be approved because it will be impossible to get 70% approval when less than 70% are online. An operation that isn’t approved will become spendable by the user after a predetermined timeout has elapsed, measured in Bitcoin blocks.
sBTC Signer Responsibilities
Overview of tasks the sBTC signers carry out: - They react to requests to deposit BTC. - They react to requests to withdraw BTC. - They stay online often enough that deposits and withdrawals happen in a timely manner. - They have to keep their signer hosts secure, so their keys don't get stolen. - They have to proactively re-key every so often, which means moving the BTC to a new UTXO.
- Signers must consolidate BTC as it is deposited.
- The process for UTXO consolidation of the BTC peg wallet is described in this issue.
- Signers must deduct transaction fees from users in order to fund BTC withdrawal transactions.
- They must ensure that the transaction fee is paid for (e.g., they deduct it from the user, and they set a minimum sBTC withdrawal amount).
- The process for handling transaction fee estimates is described in this issue.
- Signers must coordinate to set and advertise the fee parameters of the system.
- They must decide a minimum sBTC peg-out.
- They must decide an STX transaction fee for minting the sBTC. This fee is paid by the user and can be sponsored by a 3rd party, which is described in the “Auxiliary Features” section of this document.
sBTC Signer Eligibility Criteria
Signers will run the sBTC binary in addition to the core Stacks signer software and must meet certain criteria in order to facilitate the reliable functioning of the sBTC protocol at all times.
The following eligibility criteria will be used to identify the sBTC Signers:
- Company Standing:
Does the company have an operating history to demonstrate their experience and reliability? - Stacks Participation:
Has the Signer participated in running a signer node on Stacks 2.5 testnet or mainnet? - Network Uptime:
Does the Signer agree to use reasonable efforts to maintain >99% uptime on the sBTC Signer?
Note: This metric will be self-affirmed by the company. - Communication & Availability:
Does the signer have a direct communication channel set up with sBTC core engineers to be able to respond to urgent updates within 24 hours? (e.g., Slack, Telegram, Signal) - Ecosystem Alignment:
Has the signer made contributions to Bitcoin or the Stacks network over the past year that demonstrate their commitment to the growth and success of the network? Examples include, but are not limited to: publishing independent research, marketing, co-authoring a SIP, submitting a Stacks pull request, providing feedback on Stacks core development, or contributing to a Stacks working group.
The criteria described above will be used to identify sBTC Signers that are able to meet some or all of the responsibilities described in the previous section.
Selection Process
The sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria, by the sBTC working group. This process is to ensure that the sBTC Working Group can adjust to any changes in the sBTC Signer Set quickly and without the overhead of an additional community vote. For example, if an sBTC Signer is no longer available to complete their responsibilities, it is imperative for the liveness of the system that the sBTC Working Group is able to implement a suitable replacement based on the above criteria.
Related Work
WBTC
WBTC is a closed membership system. It is made up of 50+ merchants and custodians with keys to the WBTC multisig contract on Ethereum. WBTC deposits and withdrawals can only be performed by the authorized merchants, and end users purchase WBTC directly from the merchants. Although the merchants manage issuance and redemption, all BTC backing WBTC is held by a single custodian.
tBTC v2
tBTC is an open membership system, where the BTC is managed by a rotating set of randomly selected nodes which manage a threshold wallet. The system requires that 51-of-100 randomly selected wallet signers must collaborate to produce a proper signature.
RBTC
rBTC, Rootstock’s (RSK) 2-way peg protocol, called “the Powpeg,” is a closed membership system. Peg operations settle to Bitcoin via merge mining on the RSK side-chain. Instead of collateralizing the system with a new token, peg operators are incentivized by earning a portion of transaction fees. PowPeg operators keep specialized hardware called PowHSMs active and connected to special types of Rootstock full nodes. Since the Bitcoin blockchain and the Rootstock sidechain are not entangled in a single blockchain or in a parent-child relation, peg-in and peg-out transactions require a high number of block confirmations. Peg-ins require 100 Bitcoin blocks, and peg-outs require 4000 Rootstock blocks.
Activation
sBTC is designed to activate on Stacks Nakamoto as defined in SIP-021. Therefore, this SIP is only meaningful when SIP-021 activates. The sBTC Working Group plans to observe at least 2-4 weeks of network behavior on Stacks Nakamoto to ensure a stable release. After this period, sBTC can be activated on the Stacks network without requiring a separate hard fork.
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 80 million Stacked STX must vote at all to activate this SIP.
- Of the Stacked STX that vote, at least 66% 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 stacks dust 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 user’s balance, less any STX they have locked in the 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, 66% of all liquid STX committed by voting must be in favor of the proposal. This precedent was set by SIP-015.
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.
Appendix
Specification
Deposits
The main steps of the sBTC Deposit flow will be as follows:
- Deposit request: A bitcoin holder creates a transaction on Bitcoin.
- The deposit transaction contains a UTXO (deposit UTXO) spendable by sBTC Signers, with an OP_DROP payload.
- The payload contains the recipient address of the sBTC among other relevant info for the deposit.
- The relevant info could contain a fee suggestion or max_fee.
- Proof of deposit: The bitcoin holder submits a proof of deposit on Stacks by invoking the Signer binary API.
- Deposit accept:
- Deposit redeem: The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO.
- Mint: The sBTC Signers finalize the deposit acceptance making a Clarity contract call that mints the sBTC on the Stacks Layer.
Withdrawals (Redeeming sBTC)
The main steps of the sBTC withdrawal flow are as follows:
- Withdrawal request: An sBTC holder calls the
withdraw-requestfunction in the.sbtccontract.- This transfers the requested amount of sBTC to the
.sbtccontract & mints the user a non-transferable locked-sBTC as a placeholder.
- This transfers the requested amount of sBTC to the
- Withdrawal accept: If accepted, the following happens:
- The signers create a transaction on Bitcoin which returns the requested amount to the designated address.
- Once the Bitcoin transaction is confirmed, the signers make a smart contract call to one of the
.sbtccontracts to mark the transaction as fulfilled. - If successful, the resulting Stacks transaction will record the withdrawal request as complete & will accordingly burn the user’s locked-sBTC.
- Withdrawal reject: If instead the request is rejected, the sBTC signers will call the
withdraw-rejectfunction in the.sbtcsmart contract. This function does the following:- Returns the sBTC to the holder.
- Records the signer votes.
Auxiliary Features
Auxiliary features of the sBTC protocol are described below.
Stacks Transaction Fee Sponsorship
sBTC will include the option to have sBTC transactions on Stacks be sponsored in return for some sBTC. Using the approach suggested in this issue, sBTC users will be able to pay for their transaction fees in sBTC with support from an existing STX holder, provided the wallet supports it. The proposed solution introduces atomic transaction bundles on Stacks, which enable sBTC payments to sponsors for covering STX transaction fees. STX is maintained as the sole gas token, but the user only has to interact with sBTC.
Signer Key Rotation
Mechanisms are provided for the scenario where a signer wants to rotate their key. For this to happen, signers must coordinate offline and vote on-chain on the new signer set (aka set of keys). Once the new signer set is determined, the signers conduct a wallet handoff and re-execute the key generation event.
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.
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%!
How does this sip go with #156 ?
#156 is now outdated. This SIP supersedes that issues.
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.
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.
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 ?
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?
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.
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 ?
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?)
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)
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 ?
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?
@Hero-Gamer @radicleart yes we've received the feedback and will update the SIP number to SIP-028 in the new version.
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.
@andrerserrano folder name and file name still mention sip-026, should be renamed to sip-028
@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
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.
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:
- Obtain the list of signers from the sBTC working group, including the ones that were candidates but were not selected
- Describe how each candidate met each criterion
- If there were more than 15 candidates, describe why they were the best 15 candidates
- Present this information as part of the
Activationsection, 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.
@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:
- sBTC drives substantial ecosystem growth -- both in terms of number of users and amount of BTC value locked in it
- sBTC has little impact on ecosystem growth, but it does not slow or diminish it either
- 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 @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:
- sBTC drives substantial ecosystem growth -- both in terms of number of users and amount of BTC value locked in it
- sBTC has little impact on ecosystem growth, but it does not slow or diminish it either
- 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.
@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.
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.
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.
