From c0b809e1124bb54ea5682c274087f190d5eb6aec Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Fri, 21 Jun 2024 10:45:24 -0400 Subject: [PATCH 01/66] Create sBTC SIP --- sBTC SIP | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 sBTC SIP diff --git a/sBTC SIP b/sBTC SIP new file mode 100644 index 00000000..fffbf735 --- /dev/null +++ b/sBTC SIP @@ -0,0 +1,146 @@ +# sBTC SIP + +## SIP Number: 022 +**Title:** A Decentralized Two-Way Bitcoin Peg +**Type:** Standard +**Status:** Draft + +## Abstract +sBTC is a novel digital asset that lets you move Bitcoin in and out of the Stacks blockchain. With sBTC, users can interact with Clarity smart contracts, which enable Bitcoin applications such as payments, decentralized lending, decentralized exchanges, and BTC-backed stablecoins. + +sBTC is a SIP-010 token on the Stacks blockchain, backed 1:1 against BTC, and operated by a decentralized set of signers. When BTC is locked on the Bitcoin L1, an equivalent amount of sBTC is issued on the Stacks layer, ensuring a consistent 1:1 ratio of sBTC:BTC. Users can redeem their sBTC at any time by submitting a withdrawal request. Once the request is processed by sBTC signers, BTC is returned to the user’s specified address on the Bitcoin L1. + +sBTC will have a crucial role in scaling Bitcoin, as well as introducing new and innovative functionalities to users, growing the size of the overall Bitcoin ecosystem. This SIP aims to describe the sBTC system, the process for signer selection, and the features available in the initial release compared to subsequent versions of sBTC. It does not attempt to describe the low-level technical details of any subsequent release, which will be provided in a future SIP. + +## 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. | +| Bitcoin holder | A person or system holding BTC, interested in acquiring sBTC. | +| sBTC holder | A person or system holding sBTC, interested in turning it back into BTC. | +| .sbtc contract | A smart contract (or a collection of contracts) defining the sBTC token and functions related to it. | +| sBTC UTxO | The single UTxO holding the entire BTC balance that’s pegged into sBTC. This UTxO is managed and maintained by the sBTC Signers. | +| Stacks Signer | The standard Stacks Signer introduced in Nakamoto. | +| sBTC Bootstrap Signer | A completely separate signer from the Stacks signer that will sign sBTC operations and communicate with contracts on the chain to make that feasible. This entity is registered as an sBTC signer and has partial access to spending the sBTC UTxO. This only exists in sBTC-v1. In subsequent sBTC releases this functionality will be native in the Stacks Signer. | +| sBTC Signer | sBTC Signer is a more general term for the entity that signs sBTC transactions under any version of sBTC. Under sBTC-v1 the sBTC signer is the sBTC Bootstrap Signer which is wholly separate from the Stacks Signer, but in subsequent releases of sBTC the Stacks Signer will also be responsible for signing sBTC operations, so it would be the sBTC Signer. | +| sBTC Bootstrap 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 | API exposed by the sBTC Signer binary that handles basic low level commands. Remains private except to the Deposit API. | +| Deposit API | A third party API that communicates with the sBTC Bootstrap Signers via the sBTC Signer API. | + +## Problem Statement +Bitcoin is limited in its programmability and scalability. While its security and censorship-resistance make it an ideal platform to build decentralized applications, it is not able to scale to meet the modern needs of users and developers. These challenges have been largely driven by the ethos of the Bitcoin ecosystem to prioritize simplicity and decentralization at the base layer. + +**Limitations with Bitcoin’s Scripting Language:** Bitcoin’s script has limited programmability, making it unsuitable for most decentralized applications. This leaves users with very few options to use financial applications, like lending and trading, without entrusting their Bitcoin to centralized entities. This also exposes users to counterparty risk, which has the potential to result in lost funds. This centralization contradicts the fundamental principles of Bitcoin and dampens the potential to unlock new functionality and scalability for users. These limitations in Bitcoin's script have made it challenging for developers to build applications directly on Bitcoin and led developers to seek alternative ecosystems that provide them with greater flexibility and tooling. + +**Limitations with Bitcoin’s Scalability:** Bitcoin is limited in its ability to process large amounts of data quickly and efficiently. Today, Bitcoin creates new blocks every 10 minutes on average, an interval which is longer than current state of the art blockchains like Ethereum (approximately 12 seconds) and Solana (about 400 milliseconds). This prohibits many types of applications that require faster confirmation times and creates challenges to provide good user experience. Additionally, during periods of high network congestion, this causes network transaction fees to increase, making it more expensive to transaction on the Bitcoin Layer 1 network. + +sBTC aims to solve these problems by enabling secure movement of BTC in and out of the Stacks network, providing fully decentralized and scalable Bitcoin applications. The goal is to implement a protocol that allows BTC holders to participate in smart contracts without relying on trusted third parties. By addressing these challenges, sBTC seeks to create new opportunities for Bitcoin, enhancing its utility and accessibility while preserving the core principles of decentralization and self-sovereignty. + +## Proposed Solution +The sBTC protocol enables a secure transfer of Bitcoin to and from the Stacks blockchain, providing users with a digital asset backed 1:1 with BTC that can utilize the scalability and programmability of Stacks. Users can deposit BTC into the protocol and seamlessly transact using smart contracts on the Stacks blockchain, and have the freedom to redeem sBTC tokens for the underlying BTC at any time. + +The Stacks blockchain allows for onchain verification of the BTC held in the protocol, enhancing transparency compared to custodial approaches like WBTC. Additionally, the management of the Bitcoin script/wallet on the Bitcoin blockchain is decentralized, involving multiple participants rather than a single entity. This ensures a more resilient and trustworthy system, where signers are economically incentivized to execute peg-out transactions efficiently. + +Overall, 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 +To achieve these goals, this proposal implements the following features for sBTC: +- 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. sBTC can be converted into Bitcoin within 6 Bitcoin blocks. This ensures sBTC on and off ramps are faster than other BTC assets on the market. +- SIP-10 token contact remains consistent across sBTC releases. This provides reliability for users and developers, meaning no adjustment from builders will be needed as the system evolves through subsequent releases. + +### Iterating Toward an Open Signer Network +This SIP describes an iterative approach to sBTC development via a release plan that is simpler to implement and helps accelerate the sBTC release timeline, but does not include the complete feature set described in the original sBTC design documents. + +Thus, the rollout for sBTC will include two key phases: + +**Bootstrap:** In this phase an initial group of Signers selected through an open community governance process will be responsible for Signing sBTC transactions on the network. The initial group of Signers will be unchanged throughout the Bootstrap phase of the release schedule. During this phase, sBTC will have a distinct signer set (known as the “sBTC Bootstrap Signer”). And sBTC will not explicitly be integrated into the Stacks Proof of Transfer consensus. As a result, this release can activate without a hard fork. + +**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 bootstrap phase. At this point, sBTC is integrated into the Proof of Transfer consensus and Signers receive rewards for fulfilling sBTC operations. This release does require a hard fork. + +#### Differences in the sBTC Bootstrap Phase: +- sBTC Signers will be selected through an open community governance process. The eligibility criteria to become an sBTC signer is described below and will take into account Signer performance and availability. A subsequent release will implement an open and dynamically rotating signer set for each Proof of Transfer cycle, as described in the original sBTC design documents. +- sBTC Bootstrap Signers are separate from Stacks Signers. In a subsequent sBTC release, and accompanying Stacks network hard fork, Stacks signers will be required to become sBTC signers. The bootstrapping period uses a separate subset of Stacks signers to secure the sBTC protocol 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. + +These changes enable sBTC to be launched earlier and with less risk than the long term decentralized approach. The sBTC release with an open and dynamic signer set is expected to be released early 2025, which would enshrine the sBTC protocol into Stacks consensus. + +## Specification + +### Deposits (Minting sBTC) +An API call referencing a Bitcoin transaction initiates the deposit process that can be completed within a single Bitcoin block. The API is separate from the sBTC Bootstrap Signers but will need access to the sBTC Bootstrap Signers to let them know which transactions to pick up. + +**API:** The API relays deposit information to the sBTC Bootstrap Signers. The API reduces the cost for deposit on rejection, reduces the scope of sBTC, and makes the sBTC system easier to service. + +**Bitcoin Deposit Information:** The deposit will need to pay to taproot and be spendable by a consensus threshold of the signers. The API will need to know all of the taproot spend paths and the spend paths will need to fit a specific format that cannot be clawed back in the short term in order for the Signers to consider approving it. + +#### Deposit Flow +The main steps of the sBTC Deposit flow are as follows: +1. **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 fee suggestion or max_fee. +2. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Signer API. +3. **Deposit accept:** +4. **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. +5. **Mint:** The sBTC Signers finalize the deposit acceptance by calling the mint function in .sbtc to mint the sBTC. + +### Withdrawals (Redeeming sBTC) +A clarity call initiates the withdrawal process that successfully completed after 6 sortitions paying to the specified Bitcoin address. Failure cases can be resolved earlier than 6 sortitions, but some will only fail after the sBTC Bootstrap Signer attempts to create the withdrawal transaction. + +**Six Sortitions for Withdrawal:** The sBTC Bootstrap signers will only trigger the withdrawal on Bitcoin after the Stacks withdrawal has been confirmed by 6 sortitions. Bitcoin transactions cannot be constructed such that they’re valid for only a specific Bitcoin fork, nor can they be forcefully taken back after they’re created, and a Bitcoin fork can cause a Stacks reorg such that the initial withdrawal request becomes invalid. The sBTC Bootstrap Signers will need to wait for the withdrawals to be sufficiently final in order to make the withdrawal on Bitcoin without risk of allowing a double withdrawal from the Stacks Blockchain. The withdrawal procedure will need to track the number of valid sortitions after the withdrawal to verify that the Stacks transaction is final, and 6 is the standard choice for Bitcoin finality. + +#### Withdrawal Flow +The main steps of the sBTC withdrawal flow are as follows: +1. **Withdrawal request:** An sBTC holder calls the withdraw-request function in the .sbtc contract. + - This transfers the requested amount of sBTC to the .sbtc contract & mints the user a non-transferable locked-sBTC as a placeholder. +2. **Withdrawal accept:** If accepted, the following happens: + - The signers create a "Withdrawal accept" transaction on Bitcoin which returns the requested amount to the designated address. + - Once the Bitcoin transaction is confirmed, the signers must then call into the sBTC protocol to mark it as complete - this is done through a Stacks transaction. + - If successful, the resulting Stacks transaction will record the withdrawal request as complete & will accordingly burn the user’s locked-sBTC. +3. **Withdrawal reject:** If instead the request is rejected, the sBTC signers will call the withdraw-reject function in the .sbtc smart contract. This function does the following: + - Returns the sBTC to the holder. + - Records the signer votes. + +## Auxiliary Features +Auxiliary features of the sBTC Bootstrap 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 nearly spend sBTC as gas by getting support from an existing STX holder. +- **Signer Wallet 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 DKG. + +### sBTC Bootstrap Signer Eligibility +The Stacks 2.5 epoch activated the Stacks Signer network, whereby Stackers (users who lock STX in consensus in order to earn BTC rewards) are able to participate in Stacks consensus. Stackers vote to append blocks to the Stacks blockchain by producing a signature over the block. Each Stacker's share of the signature (its weight) is proportional to the fraction of locked STX it owns. This essential function ensures the security and liveness of the Stacks network. + +The sBTC Bootstrap Signers will be a separate subset of Stacks Signers. For the sBTC Bootstrap release, Signers will run a binary in addition to the core Stacks software. In a subsequent release and hard fork, sBTC will be enshrined in Stacks consensus and Signers will only need to maintain a single binary. + +The following eligibility criteria has been used to identify the sBTC Bootstrap Signers: +- **Stacks 2.5 Participation:** Active participation running a signer on Stacks 2.5 testnet or mainnet for at least two previous cycles. +- **Technical Performance and Uptime:** Consistency in operational status and network stability. Signers should demonstrate a target uptime of at least 99%. +- **Communication & Availability:** Running an sBTC Signer is a pivotal role in the Stacks ecosystem, which requires a high degree of availability and communication with Stacks core developers. Signers must be able to respond to updates within 24 hours. +- **Ecosystem Alignment:** Commitment to the growth and principles of the Stacks and Bitcoin ecosystems with contributions to advance the network. + +By implementing a whitelisted signer set for the sBTC Bootstrap release, this helps to reduce time to market to launch sBTC sooner, remove complexity from the initial protocol design, and ensure the sBTC protocol is secure at launch. + +### Activation +sBTC Bootstrap 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 Bootstrap can be activated on the Stacks network without requiring a separate hard fork. + +#### Process of Activation +There are different rules for activating this SIP based on whether or not the user has stacked their STX, and how they have done so. + +**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 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. + +**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 sBTC Bootstrap to pass, 70% of all liquid STX committed by voting must be in favor of the proposal. From c78d463291590705481606017659f1b6413b8556 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 16 Jul 2024 13:12:24 -0400 Subject: [PATCH 02/66] Update sBTC SIP Updated activation criteria, clarified number of signer set, added detail to the signer voting structure, and cleaned up the language. --- sBTC SIP | 36 ++++++++++++++++++++++++++++-------- 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/sBTC SIP b/sBTC SIP index fffbf735..12d3f73b 100644 --- a/sBTC SIP +++ b/sBTC SIP @@ -52,6 +52,7 @@ Overall, the sBTC protocol not only addresses the limitations of the Bitcoin scr To achieve these goals, this proposal implements the following features for sBTC: - 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. +- To support deposits and withdrawals in sBTC, Signers must collectively make smart contract calls on Stacks. We require each signer to individually sign any contract call and ensure at least 70% of the signer signatures are present for each contract call to be valid. - Bitcoin can be converted into sBTC within 3 Bitcoin blocks. sBTC can be converted into Bitcoin within 6 Bitcoin blocks. This ensures sBTC on and off ramps are faster than other BTC assets on the market. - SIP-10 token contact remains consistent across sBTC releases. This provides reliability for users and developers, meaning no adjustment from builders will be needed as the system evolves through subsequent releases. @@ -65,7 +66,7 @@ Thus, the rollout for sBTC will include two key phases: **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 bootstrap phase. At this point, sBTC is integrated into the Proof of Transfer consensus and Signers receive rewards for fulfilling sBTC operations. This release does require a hard fork. #### Differences in the sBTC Bootstrap Phase: -- sBTC Signers will be selected through an open community governance process. The eligibility criteria to become an sBTC signer is described below and will take into account Signer performance and availability. A subsequent release will implement an open and dynamically rotating signer set for each Proof of Transfer cycle, as described in the original sBTC design documents. +- sBTC Signer eligibility criteria will be confirmed through community governance vote. The eligibility criteria to become an sBTC signer is described below and will take into account Signer performance and availability. sBTC Signers that meet the criteria are confirmed by the sBTC Working Group. A subsequent release will implement an open and dynamically rotating signer set for each Proof of Transfer cycle, as described in the original sBTC design documents. - sBTC Bootstrap Signers are separate from Stacks Signers. In a subsequent sBTC release, and accompanying Stacks network hard fork, Stacks signers will be required to become sBTC signers. The bootstrapping period uses a separate subset of Stacks signers to secure the sBTC protocol 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. @@ -108,6 +109,8 @@ The main steps of the sBTC withdrawal flow are as follows: - Returns the sBTC to the holder. - Records the signer votes. +To support deposits and withdrawals in sBTC, Signers must collectively make smart contract calls on Stacks. We require each signer to individually sign any contract call and ensure at least 70% of the signer signatures are present for each contract call to be valid. + ## Auxiliary Features Auxiliary features of the sBTC Bootstrap protocol are described below. @@ -117,7 +120,7 @@ Auxiliary features of the sBTC Bootstrap protocol are described below. ### sBTC Bootstrap Signer Eligibility The Stacks 2.5 epoch activated the Stacks Signer network, whereby Stackers (users who lock STX in consensus in order to earn BTC rewards) are able to participate in Stacks consensus. Stackers vote to append blocks to the Stacks blockchain by producing a signature over the block. Each Stacker's share of the signature (its weight) is proportional to the fraction of locked STX it owns. This essential function ensures the security and liveness of the Stacks network. -The sBTC Bootstrap Signers will be a separate subset of Stacks Signers. For the sBTC Bootstrap release, Signers will run a binary in addition to the core Stacks software. In a subsequent release and hard fork, sBTC will be enshrined in Stacks consensus and Signers will only need to maintain a single binary. +The sBTC Bootstrap Signers will be a separate subset of Stacks Signers. For the sBTC Bootstrap release, Signers will run a binary in addition to the core Stacks software. There will be 15 signers participating in the sBTC bootstrap release. In a subsequent release and hard fork, sBTC will be enshrined in Stacks consensus and Signers will only need to maintain a single binary. The following eligibility criteria has been used to identify the sBTC Bootstrap Signers: - **Stacks 2.5 Participation:** Active participation running a signer on Stacks 2.5 testnet or mainnet for at least two previous cycles. @@ -130,17 +133,34 @@ By implementing a whitelisted signer set for the sBTC Bootstrap release, this he ### Activation sBTC Bootstrap 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 Bootstrap can be activated on the Stacks network without requiring a separate hard fork. -#### Process of Activation -There are different rules for activating this SIP based on whether or not the user has stacked their STX, and how they have done so. +**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 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. +- 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." + +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 sBTC Bootstrap to pass, 70% of all liquid STX committed by voting must be in favor of the proposal. +For this SIP to pass, 70% of all liquid STX committed by voting must be in favor 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. From c741643a5e3ba6e78b6f454b8a9a02b7d48a63e5 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 16 Jul 2024 15:01:33 -0400 Subject: [PATCH 03/66] Reformatting Renaming to SIP-026 --- sips/sip-026/Withdrawal flow.png | Bin 0 -> 20293 bytes sips/sip-026/deposit flow.png | Bin 0 -> 19060 bytes sBTC SIP => sips/sip-026/sip-026-sbtc_peg.md | 0 3 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 sips/sip-026/Withdrawal flow.png create mode 100644 sips/sip-026/deposit flow.png rename sBTC SIP => sips/sip-026/sip-026-sbtc_peg.md (100%) diff --git a/sips/sip-026/Withdrawal flow.png b/sips/sip-026/Withdrawal flow.png new file mode 100644 index 0000000000000000000000000000000000000000..fe5fe4d48f3b29196743b67da8bcef011be03ae0 GIT binary patch literal 20293 zcmd43Ra6~K&^C&@ySoN=cXtWyo(%*I?(XgmI|O&wNYKE>31Q;|_u%e&c)$Pq*E%=n z{>;rxclDa7)m`2F)Kk?HtEsMljzWS01qFq!q$sNm1qBU)f`WlUg8isjGqjKUxWRst zR?u=x7=`ce11@&3M9`TlXOmEW(vySjPR)Yda| zOP-#dO?R&rmz460iTCyOXJzNTZ&w=_S&WQ~|NC<_+zh$8x=xMA$E9Xk=uEP)aXy=S z3JMCZE9~f~06#32t_>gfxP+@}>PsnT@JlHDnSvxFrNsD{cl_*(2uZ|d7Vi8J3XQ>0 zoK|%*S#WT0xU#Ya1w*#GyXWR$G13s*)ZCgGti6cv<`tdx#V!AT*qb+vGN6nq$-tSeIZI2{ZImEhFk+k3F5 zzNEvNpMl&s!;Hl5W;UfeW$lpGGi^BxYfM%?Fx(d z7r->}fHYPUkfLff9t9=X86^ozER`b{GtMp^!^oj+%%O3sp{6Mrchm{t3WEB58uu*cEu7A$;57Z;p+s{T-pS5JN{0X zM{&2BNnTIyuBA4#7G%w2P$(J3SwD#D&RO$cIR3!Kx(Uk`ikNMXT#;Re2Xf^*WUhvq zsrJUM;*Abp^7g>dCvAx&B%WlCjk%$}u@5o4lpRz{R~R$SL#v%p@ezltSn~G(er_Eg z%gvJU9DgG1C?@R`C1q+ki7<7K&(&t-yup*B-2fpnNGP(GPHm=rrO_<~|ELP2i*p#!{A0d;_f>~^1tuTMvS8L+t z<=zhNCG_{(@hFO&scKbHNajxqzhD~b&h}Z1^IUyVO+U%rJ=S1Hal(QRS}nzZWPOhR zTA(J@fi>(6m zWMUMe{6#*MdT3EIJr*b*Sb?A3WTgEb9%CU)@0?lfn8< z@zNHt?m^-)D?0_@HzQL`yfTor-Nx}Z5r}zZ_L+g@ttTNZpooB3dgjgfZS`YubK4*7 z&hav%AReP!4Gho|BBuXt5QQ7(7M(}^TMOnTv?eEHO`%Dvx3(-ZJSJ58>%c7yQ0M4T z{wWa?5|$H`tH+?^5L)4?%0|GCi^}$sp1YHjB}ycWRUK0%4orhL#)Oq^O8z`9KWJOe z=r=Au8U&qN<`%vLIW(x9?pfL%r_tjVwEG3^B}AgkPS0Q2wAGgcl|v#FT(t`gBI!^R z;%5LMdVS}mF6Mld>xr-%RFRLB`2(Zzd#h6A(bbllL{y429$G*KmiSPZJ0~|8gD_bx zygu$N0XMJbk}3u&kLVVU;l|Mqvq0j4S;4FkD9ojMC9;F_(#?*d7G1mm7Y5VOBtC4m z`uB%3bvQv!sC?R{!GU|HM5NdR!+rw8YN`?$Czfu;@F2~W|2Hz6tzOQ#uWi_y6nCRj zZ6wBri$}vn^cL7?`AMO(bds(WUs`gZ4W;{)ldI;+?enncYAwv|4*9sSq@;Ml_pyoG zRaw!4h+3*r2)=1R#(OIvrqf?C?343j#RYP$A}LfIH6Vf-t7wqgxC34#gv39pxm@Mx z+(myz8AAvjca?`*npQ!Z_hN_Yh`rndj%fPp30wJG*=)1b+j#JNg~xohJtk+vG_gGx z5aHQH$TkHXPz(grHb*>5yrh9A(}LP)=P#r&2@FFBuFOl;j1=VAKHMxS^Uh3SaU&yj zH6V#e5F6C$386a~h$fQTiozX40{Y}3#9Jd7`|V~A&gJ#|wc`;nTFxjaMQJyt#?V)A zDVYqjh|~N$=czG=hy~Wk&t!&^gt>;R!)Bol!_83svFaDLAB&rWT;b6PkA`2ur&Ogi zd9N*<8;QWuk88PQ;xN$&`Xswl|oGB+B1OvLzuL=B7^* z;ek>CZ(aiNlD6WQ%k-pLPW)+cLeR_ma|V9VOp5fh(zRD<{^{Mo1?|ld9ZNr<=IX*< z09rc+HPO-;W*yzx;y27P?BPhbppoAE3~wG_j0mo>UjeFGDd-uBarl#)9`eN8f$Xyu zDlx!-xQIWX7aXG$>CfZq9tDO*v1CBnCY1Fdn3hbjMgj9AhE7CtwV$A}Ne2r!`U~RC z0VdN5Ij$a0Vvr$L_PF1?NCcdPeTofCpT}?+^2jXqt8rJ0hi>U zjvCzlNF8FMdTBBVd@BC!VXa2X43bwg^aQPp&}1T_IcOtZi=q-P`EO&YFMwazGLb35 z2U(Gdn;xMV-`1Aysp$ZE#7ka=fX-w;%gHJ&YB`5T`fFwkmP!RVhITG88U z)db}*W2Q0I;O=(&H?g!Q{x#HW8+`t<{$t!`1--cR|D4$b4evi&2%-_L&? zT?`qr%S88>l9hzhNKKIB*n^;i5`^raR&pE~_=zQtPLLk{pcJU?1KimaQS_@PTIpBo zXHI-ZdaK@7X$HD|1ACHvuOCh0G>rH#6z+THDlg9C9}M!fkkNzL``Xhs|a{K{A? z9z44l1~(!0=gtG^&!Kun2t>OYPsH+D*QO%PVS)5gMaT9h{BZ}L}DmljZ2j1?d3TtD)IfR2s;i1m?yeL+ottwIOMW$q4WfpZ99)jdmLJ{|y1>2umij%4)RlYcuT}E*3Zb zwN{%SREr@e5>u`IWFS7c{TwfWYl>Z0lNKBx{13M3g@xD7m>iA@&OA5?lgS6?7;Xd>I#1!` zCS|ea=C8c?Ar_#UK)m=|ND1RKV%>=3c*zJL)SU}RiiU5YzN~ig;GM;n1=|)v9Bme; zf2ml(7DthG%3DafPaXj_wa81iEEb&sW#-iqqK3afd?xQ@W>wL^ zL5FJJR75g|`~lzT=@t35>_~w%ek2>5Cg@7=Us!UDb~`LH)-C((Og97`pIw7T~o#gMbVRN4MYCL zVdP|iHXKtAk;>-|6$1b=TkT&$y%7>4zv}*Is*NzqF>lZMr{uy+QJ ze3vW9h4HO-$>;yB81)zOb!D}B2ATwphP7=?a=ZV$pW&kT(^3JV-HMLWiuxw}OIgfN zHUx=deXTb}(fz-UsDL=Y6kO}QjqZ+ALw}rtDw-u5UYNcy&?iOuRah0x@&S;#Hv`l@bjEl6e}tPduuc&mukE9 zU)E59lmo8FyIl%slK7L?-cZ#A=NLQcMw|r#RDXfydqjY|_4~TmewNp#_;zZEV~Y?3 z+dRvbwttdT-~D27d0~`paTgP*l##gsBn}s~h(T&`COGC~tF-x4UD%RTG&m|eywrH7 zVW3mIhd%@+Z0=;G;cK-;!y?8bpnN5qp090x*iLl_8cK58234?vz>fV3R3|Pu$dbr1 zW1!Qpg%pD-%O%50a1HWtjiB&! zOHlaze$3gqMmD_D-4p(AGVIp9WG@6tPyDBwJ`&r1RVLJ+nr6_+gZ?#H(fHNikC;B# zQzD%l%DdRtmeK@?^7o^I`rxvzf-){;VU*M$A%fJSwA`#J59E4cvEf7V^16R;I~Rix zxw8AiGxN~><=Ap5coK)Ha~IZz*ms*W8!;hb_jw19ZY%1CEEmozDU#O z9mDG?KZDIccoc}F7l{ZeX2>Ax#4VrA_-t#_5Jn*}mw?!7TEO0n`%h8z@r~QzbPn_+ zQFt~QM-CfECD;MOB$i0Ovoh`sQ?L*SiO`aL0NO;mlDeVw5pBbcG001FZ;fBbGy1+j z^R8dsy_lhzgxE2J*<3L!nF<$3elvto%T!hRj2T^J^h9u1jT{mM`Xo84Iu?1aJ}x)I zE7&V(HX}1bxENXBGdjxFJs+LbCRId56zx{@lu$aYuX>6HlBE6%#rsKC{8L%%#NnK= zO8oY)B4w#N$H06&6Jn);8!2^?OrPkrUyPk=NGZDl!5U8pPa+XL|A%Y$1!6Gi{g*RU zw6C<2T!vG}tj3~ryU}PU<0UD??FiO)tQ}5cdopT~%QZX`jTOl_TLFE8naFGeRZYB~ zfNaVOZGv;At%j{&29FO>99bT*kJRT8Smvae31m{wPILu(Msg)q*6Z)@QV<%!5~CEl z2JDtfOeuJyx;GcHJ#H>>U;<-psc{7p3A=FIY3OVd=9_oMinvv z8b`ZemU1KX!Bww6+zPSGyV;OLEuibiz=Rl7^tZ@^cSRDzigO}mS+M}4>^Xk{IO0wB zKQxR`K|OeUOIVUi7WPOr-KSmt_>R^8P7GH(X}!%G*KTq!CR9e@0NUWyJ_nY!-!si} zxR9BFf-pNMH7RTMK{EM{PN`OkJaR3n^Nt0u(mfJWCtRK+3U`B_U<|220rW~X97&{N zuDo6j87G{hE^G1_x2)^KkGRUe8ToU5C|~;fpX~NC-w^Va0K5rNC=f;cZ$Rc$oN;>k z%=kIHyzy>9q>gbw<`Dm~MQM0E-rT<=w^rB4zDmr$jQrjFIoV&4|YyTdqj5s(P7Z z{wzH`VaX+vqs_E{VO0Q7TU@%dqp07~ZFp?5ABVgmc)B8#NRB}44TiU{1|dV&*43!Z z*3z8tGn4|dXL3*&LBCh`Ts|(6EEGxZt~~*255-B+%}mHyX49WJs~UpQ;C%{T{1rsN z5jF`C9G*U0US$~H4I1GBy;e*YcQNF&@N%W^~IJ2C{>?j0+ zQ5==)?jND+($=JA4|-zIV{7%&x?1St8D9V}lGlRu{Fy3c^_gX@Gt34<<%`Eb&?K-! z`k6e+%$XiFNnKjG`S4KZ_`EJk7VgRjiA`vQ$7y@R%3HF8j5+x!d(>eP&AiEbkAWk~ zz)&$hKFR%R4pz2s`I$~Dm@}?jC)jO#SXMUbB96%6v|a(PsjG{{wdGyiWjpctwjU_S zkCRbSt2_QGxYhIh`R}`PDMTANTl);*2m-P42!u~`(iJ1&f2mYD6OdY%2&!8+Bwe zj8G;MBO(|fX&A)2djVyt`L^o~bSQBawh$&Da|D8ZxW82ITlOIy^4C~d$OaM?@6e?P5`X8OhYXqfnmqj;X?v` zY2j*&ZjJMYb4eMSpYkI%Y@5ySDDu13xCx&sB`tsOsoB>MVAzu6$543D!lJNKhTB(} zeOCScTWo;86i0d$8<_~LiP}q)y5@T>In#&_X})$yyU|R5wF70AeRO7XF0pJ%r#O&_ z$+Qw3zW-gY@W8Fxci^+U{4G{SfdjS@=68OZwJPLSUP~J%8JoZ!CdceM0h!%KWXQh)EuLDZ-7mr~g4GM!WKKhd&wHmY;&U5NSt z9545HsyAGghcgatsB-Suxo_LHT{u3bXDt|@xUTBx@wZZ8;qYXvM80|Pw^zE(Go29E zH>Ll!-v_e1zlRYFp~E8NSG71SfWoL1H?VRAcBkh2nT_2JQrPgd1DI2ofrI{nYm5HG zFfwYk$uN-&wTc(Ga}j&ri}OT?l&a3>0s(|6GI_yCI+FazKqW!}mwA|0@$pfwF z)5;>9O$$O6FBt*INx?nEh97Q`muAJYz0Fa9E|c~#cE!H3Smu8=^WwG`0APxc7q=w0 zx~g;37Cn5AUdt0UyH)OuGi!u*<{#o(-C(oP=Xsh~HV+*B!^U##Fmtu!OrK>N=Uv(#wv~aRQwncRc12k@A~Th?RK5hj_Emm<(k`G<-;ZIjR2hQ;bf z%v(1@g`0knloKJ3bdsMaJ7=(>;j_cz_^jyiJMQ+ z2Z@<#TmuTPfj$MZ zS|(yYzGCGuJ3OVhm_5KxHkG5>CoAQjgvM4SPFtP z;C~40#T(GKAeH`KC)PLO^8PO<`(GJSH9{VN^*$svjQ zn!ff21cM11=$j$|yLUa=axUFdcD&3t zz&|a4q%J}cLyS{aD~InyW+z{TKrNLC;ZUak=ZO@t|HdlP=tGS2NeZj5PVOed9q=!O zLP3kZ?N2AvJ>xjAP-bV(f(or#2xOcdkQJ55!5r_q2E6=VG6~ zx_5u!uU?7fr(VO;jmP=2`fF1(j}(moL31V%Sz#Iv?%mym z8{yv93i=1>%&E+d!{-Soy?J{M-VS7pPdw_wm5B5Op;-kd^WB$%2ZpVyGjHKRb*iLO zb~e=2hPlM)x><_kPO4c4K)Z|V+|XRNy~+Kc?G*ozyS|DKI^|QeSNJ$^t;8A2=%*I| zz&e{gCeJugjn$v;E?}(sxxv$%oa?OTk<4okRovIzYmExjf0=5OTPsHRmEn-YL(!7; zf#t_>j-GNu(o)L&pjn`v@P~o>ABhBIea{CGo6R zoDo%8>C11`QZcB)UI01ti*?F-Z~u&ar+)h!FlgBL`VH65T`B z=ptU2x(I0rh^G`U#D>2P153?N4Orzm45EcHBi?W>UOAPj`OYOtJ5`jW$s;d*nF+Uy zKt7_(V;fxMPw$-2Y06t#y_UX(5hwkn9>~`=;_7_Xo}?yc0{{Ne%NYjz*f! zYsAKFwi$Z5REpJUmDO$j5YN-&kF@x5$X_jr1zWuE*GMGG5IvqN?o(7@{Trk`93E1L z@Z2oGPn#j}KHbA2xwq=ij30?i_L$Y#E-c^Yam{oV8LK#A7VBmZL)~nr+0U)GWpwG9 zH;-PLFyC0`MTj$Y9y_KwW2YoVa0O{Z*0DIy^BmBw_=;#W5mN#dTQI}ysJ?Pw>_!4lC&HQ@1 z=v#AfgH$zpT%m?;)WiJJ#Pn2HnL7ETfJ3`88&R?*-O#`md3mouYMv z1GRjSKs%#MUOJ@vm{dX;xokGJx4f+4jjz1j>U6xSM!YBG7$0M#s?g3%woS?X*Q;N^N)u5UNt>3%%b0>PI?sW2xvqnig ziTHe0ETjxx3VL{V)!f?q^0rB@bOb|MWb^J1nTZ`Aj;mkfU+tKyQTJPwUBB_$d?%s@ zW#P3~O<&2I8v)Zor)vgEP$2y73Jirg>Dr0=L_QNbBJ}VjnJV&Z$7?1Cg1eQW7O!AF zbI8oYAg6DUCta379xj9PK{YxvHW_XRgFMY;fJ}>%UJIPDn(tCuR*oHw2QTL=!c-S} zDK++cUIe>~zN=MG(6BiORFaR;NbJu`Z&9{yT`z*4q0PIW)x^!^usST@x0A*Rbkj2< zmT&)Om_Ttq+-fnv+`Ed7Pylr0YcRUvEVZ`e9+iL21}`U|irH=kFTwhceRM=SAATcr zo{fuu(~4x;@s8{@uHKc5fPH7}Kjgfw`BhCtARo-HFP3A-Cq3kiX9SY|?B@?{xI%U| zUBPztosr!nOPa*9Er$s^NW9Gj@Y;fyNkj@QTvV136jX|+mE3<Vb-i_onHA@Ne3ozXpF)> z0%@jp4`=a~N{l=}@P1V8*q-%x8OHsuy!HjTtC#WE;3lpU5DUR|X!6gx#;-?YMaXZ^ zL9@)vGg{Y6IWj~TdNqm3BXFC>_l^$qFqlAcp#^DQ6C;GTDBDbuhfZylZlN7I z`fxc@9fge=k|OVQ3703e-boA^um|*gu_skM+c!9&ShK!>OS~S#woa0??!0Kr>g?tU z(-A9X_H|XVjyuG70Zi;mh1tGus ziueP2rZ{ewH^aNGTwDI*`rdfl8Ynr z$zb1PC;uWf0X05kwrcu4`HSE)(Q?i~m9m!KXUB&Q2X|qt={DdGzBU{c80-u>>CfD; zLx1I^Zhy^LXbkOB=fY}P`N_ig<|W3_O4V9D*M34tBUhAM@k$wvGI*{zNCkG1s}jV` zsqj<+77ys7h>BO?tthja==?{=C1Jsu&5lHj!|pVnS5=3R-3sEcX7FGSJ^!XK(#P1_ zfRF6%v(g;VT6y32xMoLe^BDQ_)s6vqE+vPpm@;`BI`w4;!{~%ZW1EY-6K=5WlG_23 zQKQYFq?)Jd7MSM-R@>!g*mqETD+iLqh!B*NPt*(tNFS`3!;b9ed%jchRG*15^vHb~ zFy?oc0A;{an0Om6rG_0!u1U~m`XS3~-lS9-ZT(JRT7hhh_AuZ5`%F95BHKq$*l(3T zLFYtRN)$&Ejq$VQyUPz4dZdjD; zf;zP2LY@j4-C;K_99IWNEP{Iv#DJfkTgSG*?M9Eji&(Xrq;-Y?IIq!d4XCYGE*TT* zSXY>UOtZ;ozipkIEtKfMKUa)mKPGy`4YLl%uknu*3#@*stOqqXM(OkYGoBnyyL*NH z?Y&$)JjeP3>l?%tF)F7}M2(cNb=YBrGz?d9ZNX&q$PApJo3)m;5}fW^DfXKA*`xN> zbMkqOk+(ie&vauHtl8R_CmiiJ=cCH1#(8s@P(?gvP~=%*{gS~;RV_=S_u&rQsI#3? zo@otYt((z$W_>~od;gm?1QAq77F9Xc^EC?iVa_GbU_wD0T@ zQDZ9rlt{nkLAmb=59z&FwR@;H%y|+mc_A{2^$=xpCqBZ^{PqjFpi9SAu{FFlU0uJp zBs0~8t%Z?YBFZi*(|X$0!QLN1_HbG1Vj=VEDdl8uH~G>z5?`1%J+-5cL&f)?kT(=o zwf6zokQQ$z-K&bqz8M;t(qN6l9~@ssD2JjUn{APiwJ+PIbE`CSysEfBr}S=bLj_r5 zj|7@x@cYS-{N2Pa@j&!ckELfF7K@%y56!F8o;Pk@rj@D_zE}L@Sq(h3C@f7}2iOK3 zzC4?3&9k)Fid*E&z@h`Vd3ov`OuL<%%CD#J&2X@6pNbc#dZC;QpR`4vxp-wFmRqXr zKiN|f=**(G^K&Sr5%w2LhoMc*UGTS3=!X4Zhl_0lM=tZa$Y@gx$j5>xuFK)(ucVRe zbsN^KyKz{horaCKiIrl4*2L>%!YYJ53(S7v!%bU2}u+F3(t z={|lea=`^K$HFBH4jTJ3Y?rHa@;c#6rt7h1HBcwsyO!cu3PhHpd?zA?n(q%~?0_@s zkD+rd42=mj|H2a03!tdI`kpnM(ux@dt)TIxAZ%P$bVoVHBiGF|n1=w&Ex9#g#+{;7 z+L5MTzGHUu$V8hb)r?$0s={9DCKkHIQ2AR8an;ADOuaVZvI~8`q7x%2$kscm9(DC%1kC|PKr8oVM(}_g#_nih0$0= zSvG`$ukOBS)Fs6RyIyFT9mRcfR#VrcBmyC8=+z) z(+#{=n1A(uTCeW5r%F%xROvvC$F)fp!Z+EFGpuKgIyf^o`b-t_Vyl8HLSNbGMRLeU z>lDaJY5+BDJ!8&)If4k_X-1>K*8rSr8X&{Ybjhb>#rVr2_^#+S7aie3f>vfmIVslh zU!1UD5W%{-_VM$yyo>kRfPGRx(L@bX!k!{vNpn|S8`pGHxzy0k{z*k8KeUY84%0@lxh%z2w!{{d#Ce;` zkVZpdiz2xF9|`Lub$=1FubPtD1SnAQ2#OgL_V=%_e~}t)Ke;@4)+rW%sFo$XoJ7$! zwv67`zd<;On7b+ z<2^Tv#43uYuusR^IMSxsVy{SSrWmkcvdZVoaCs+*Rm3@lI^X%l)zt8hTC^JbzS?6v zaLn`IPhx5zt?(=|Lhi>a-G{(bD80Z~#rhZ#;mn&8Ld!(;-tubCSr+ zv%i%$t9u*%1|bIFh2gzv<;q8j^LIA=9v#h*z9FI^leD2$jqHGXYh?7RoY2b3xpQ>> z#ih!K<^K^{V<>NxMHsffsYF%GVJEH^xedc|Fq~Z`!gz}g>QYrHRY0z`S&4}BGZIcz zH!6Q*iYE$O+Oxg2U3dPDfh-GybgV{)rzi`Eaz#2E2rV4dMkS|f;)lw#;2}e_rBDv5 z8!M0eXUlflSj}D#I_5B_q;TC4IqNW}qY>$CQajHSVca zcQ-ql^kmkL#8KI%pvobv*^6mi2h-HH{D=5_ks5v&I+gOcAijfT1WS#w-LkJ<$PDUT zmA$a*&w6F~oOHs`Io`pE#aZ!L)`ue+A622ZvxwI|F%lIA{+X5g>0WT5SkvPN+Iiof zZ0fuqWTPnt@V_1r1)ClOdYk<;r(Bwqdf&5;cNxEdw6==9ZL?P2U(+2#_a*eXaK7QM zp@Wh=;Ok!czP~6za69Gyb2}jT(p|;er!s4dpb!2iu+A|eEBnK1N&Js21+x5CsOVk5 z|1bXc;i$+1d~>~|Km3$-5blT9lHl29|E~c%kG81uC>?TfTQ{WRT;z1QCv~AE^IYr@ z{FGE2QC@PE$>u+NqmD-X7&X3f;hXWMTUi23ml&Hxg_}>&CoxI2p)8!XW&x};HYmXe z_qDN-n$#E47_X5I;s#vjY=m}lv<(lnNi{lX9i-`z2IJWVA8R0xjyAfM zvhf)9c-X0Jn|Ok1)z6hAe5Qgf^p6^R@vNzeGQRpY z%a4eC5Tx?>Y*lf(w>I^=rsMf0vSp~kNgLtAKXC7PJaY5Vp)hq%waHqTr_u0TI(gG4 zPkkjiF##^OqIE|@C?_gM;y|(3pQQ%xhTa&b`jmn%JZoYg|2a0P6`c(adJO~)yS+DW z0Uq7SESTz`-A^OoD~`s!^Z>4)7T_mM6MjT-Tj2P}hHN(RCoU->GaCN72`E>HPYqLTQI;hm~ge`QtFofq;dCo-u{L-JqzJBu9WPbFs)Nd$g9 z=``9+vYVDUAe{-fDlw+!KN8u#+P5nU)!n zoY`_lnTrE}#vg4FcLE0Qo4cJo@rOrJ+^1s*o77J4-RQ54e~&Aj%m8!3TU5+$ljIM+PHI%5-MM1GD?i{+kSFC)a-^sk^6o??0=LvAL-(L8+D zXnE`D5Trc5P5v@pG?iXa4Ucp453lX5?TQ$V^*$v($ID|K_P*&p6Zt^nPes-v{*mQ7 z`K0%k5Ow+oF@X8ReYlPg=rgjJ49mh+@DeA{~_Bhqb{KtR-Md%inhBV3P6u13$1oMT2! z?t2BH757Lo=7?If&Y?=r!^Njd?B#%71GLg0F*%T*>TLJund|Qfb9IbUoiKe!6!yxFPEFq+`LMHH6mt_%Y02*10KcaU0OF zOb)E0jK8&n1clIYMWGBkcSKpQfZsad8HvSNqq=VW^nU}z4*els)10ljPY$|YhhF(G zj81C&odc z2cafAHR%Q$w0m7vzI6-?ZM|5MCmzuTYyAe2->#+ftr=OnAbPipnG?p-h7hpES$HP1 z^lg|we%nNded>4cZd9WTpAERUsNP6kko(X-9x5c=E3vfflmIL=Nczh6LU1I4Hb!}b zN?C9~6GR2scWT_R#5h&j0P)6f9XYuIh(Xa>ApbCg%favS)%Vo(tZjrff~e0WH%BA! zh97biakzhWrJ4gHfg;UKCMkdIh{>=db#Fm0$8?P7 z)!?_sE8OSE_?Mo;)5QDqkk$=t(ZbPyEjn@(>e_OoYh;`(<_78%LiE1+cHL=`+1f4x z;9?2;JH_CVvyF@{AYs*DQQ@eUx&^DVM8({;qVu>wv_UV6{4PFOP7R3r{X?xwmVKRW z$TQX%=Avd*UV~9k&6*2-ya?KRi4JVgF*P0OpRJ-Vwwue>N@^Bd_xcuonilxRfr3G2 zQYXa=s|%X#XP7`LW0^e?t3P)n=>hUAE*QWgt6Qjlet-reArNC=JMl3v5P-p&WQ3XA z^Re7Kkc7zErNhJ!{1t|ohLR4G}ay*~9zkS6p~*7xYXntR_7X3B_UZWcr0 zPH+7#lLPx|$d;?%iajQ~ow2(M+yNChyM-m@v+oF?MXx9Fnn_@x@`W{EXnsTp?RkVL zXps`%`}Nipo-dAn@SzU#3DS$1Xvr>oJ(VeAEVeeYeZ06c5f8hpId67i<}AwKAooL! z+y6K*?mEb^-N#^)f392sOvv2FvuYuOKt<_Hq07QW|L8tfPfB8cM%21OOO=L!72^GO zGhB<`jA{ktwnMAyp)m(+R_Wc^Qb@a$f7{X;y`FSJ9SsY@rf6F^wL(DWPgV6cbUux4 z2V=b<*F~X8aW?-gAo3ePlEz@0XCf$Fa7et|fl-j^Ga$Ru*8)`&5{7crQ^bjI#6A6p z6i3>pP0R7{YWt^kf_Y5q61gK}pU#Rw%Vo4l@Zn~|f|#(LLq1Gz024KsXsE`^jW_uc zLK=u~^i6)jW>KZ}lL9*4aC6QKj`&PxZ3Y9`+Huk2Sr0^4rUslCcrpU^!seJ+ShExj zSRE?$TJ;MsXr<7LAF%>ewr}omQn2k0jXZX)kCcwIc96nf-&yNXBkrC?he(1?=ftG1 z7y;{G8nZ>}5#h7;mFvw3i0oAW=N{h&{&Gx~#D%Xvnb>0(ASE8Na@}9KuT`mceR2Zq zvM)Xd6$-X#Irav@$xyACVqS}1dNq2s=QmI+uG3z+g_MX>rtPn9kD4baCjWxeP&V63 z$oS{9A2pQ7m2Q{z1z{1|Fb!k_onrlW?MO-PJ*Xr1VR;*L2;d7*8?8#dZS<8YZ^4Hb zooCy_Ef*L}e9D`G4O!559zH77C6k2XO8ECJ_%^4UiGT+{o6KAI8+!Sy1~NDj-P!J} z;QH%~4YWP3Ev~I!G(Mq?9LLYnhyj5KC4DY)ZyDr5y7v=%0@DW9<^_xiLG`-WgV9JL zg28^I4YB$vKq)mxY&Ne;ELAvGbO~wJ_wkwTc8K=9;0q#1IP{Jx4R87&G1|=XkrsWI zAs0JFJ{;LV4}tAw7&b$CM>KpHl8%}DQpNtWjqbj9wNyeG$To<5XkJ5ElDLmWu)T$G zcEMgG(YBdM6*7PpQvZZSjL;=QOK;bX&UN*9Exxexuxx135QX zp~){2^pL~RU};<7G|1Xh0#Fk1BH6GJ16}4|-lNBUu~Z^L?MKT&)`y_j3>J;Guxei# zvg~o`(eEcrE1MG!l{x{hwJM%pGSbvVzHy)$1yLHg!QFyDVGA^#ttVntfr$k6iC+b1 zk};*%LeQeR%++SlWs9J)Xn_2>=urnRpry|nW!H)_InWJlhmUa0MTNT)KU zd*EJ)*)4ZttPphq2BFya9niVkicshhkz6nY}-okx3`+F{@p+7doqK` zWzUUhzJ074FP@94&#x`K|84efB+G~&VQ%FM$`bsI_Nn3%w&y=e|1B;rh=49rl3(Mi0h7rSCQy@sZxuYmp{Oj?&#T?l(av{3WC36JhyVq;9f@px~ z@WZWVUyu*nCDA_REWxaBzokVm#;J-hA;`)R-P88!WW#mZC}DryFM<#}pNA$&ULOU1 zvv!;|YF`1*SHmAtP4U^Ync;cYymgxX1_mm8X#w4VOicz;1lQ~IPv^UDIg|C`eftEj z{>AIg1(U`3ESdS%wQi8eb@{QF&98i$`L&ui^$oBw^H{Pa*V8vVq_t|+5C<0bHEJ|- z+45ppnx_naK{qolwQB0~JHR|X7W$F6OxxI=)#pD743zoDGP_VS0{913xr9P*P%>X~ zjd`f#UHUW=!ma> z`5nn_vA&^u$nUH{;d*Pw;q8%VzC~)*|De-Gr>{L`hZxAFcN%>cCyFc)z*MhC8*@l0 zU!&zFP>e|k_KP2Utn=-gH$#uF)4jvnlJOTaZ|`rZH@@9^;)V=&Y%4C(vB_>2H*F@c z(KOU78nQhBi`0X3MT6+hTLOo6pl`P=DT+Cg_ur{MQl|{xszL32?e+KX7A$>~&5{QXW+_W((H`>NZzdkBkxW9CZH&-Vv$?<7;Smoi65 zndPrpm1=|qIuT`*=eP;Nq?K8H9@o(SH{T{4)_ctx5fg zh*KdDu3yw}mlv2iYFjzB)Xun#WTM6ByKp7-W&JEfr{lTax+?%>a(a_$Me7lbWDr=M z+6aZN3bMrgQ*Ech8anL2uaTtV8&Xb>Gq$EgB{A!Us(BdF{w|Ys2WDO`F1cjC!vX6X zZg8eijhSRav|@>K?)cqw$%H$g<J}JSnzj}E*As%Mdp*WQ8gfPWKTrU#76?q`~fgX&X341v=C6BImDJm_(L?B%6A^wmGQ5QH;IL%tVI-a*Z9krT~$DX=WSsTkPi*%$TeJ&#l|~jQMzMf z6UNjvxfaU#Gpr9Z9Ag>+wM0aGZFRH1K>QXaB=3_XtcPf^$Ah{x=4BKyLwWW^HAgBf zj|whI;v8cT)agl9R_x$jQE$FFWba@s&*@Ae3}8$N0L_4r@O-OYCTwY}G3>E! z0+So9Af5vhAbDQxj2+9JFYZLSi_cZ4M6cbL&zr4?eqPpB+v5DbX3)#^!arKnuUVA& zy4|Q6=!+ku-%PMG=bPAGmY1?V(y1TYWTn}eN%0{H&@{Fz5Nl_WUC0s4_`&b#TiSOf zV4b}wFGwunOS5?N&gVUeK$I&*cwV^p>^j_Yw<@{0xb0N!9yf<~d&Jpg@N<>l&5VL} zmZL~7>L2Q^-n>f;0mE86c2FEyQi*JIdOzJU`BZEk^7?j}Fsb9e!$m~IKdaist~!z~ z%}VZ_2Sjd!wpCHlO?5bY8;*q01=|`jO;{NY@8K+GV71DwxmDGc^mlkXR*B_c5hr=c zxpNu?9h1IjQ+=Q1+dZ6*`*R!7Y`#Mjmrt^ZDFh@&F^;@q$r|7s&>?#1=cVkV(WzJJ zy_h7pFb^%)?;_KeTRZX?MhbJD+Y~>H>eo^hlHKFZaP@1C#!G?*1?ymz)GKcEKA49h zL}soIWnRGup1dwuF8eybujZGs(`feRH&Xw30?m^m8JAWnfAtWm-uH)%N)rqAjc%cO?POn~Njo^vy zC{HxH{_i3Expx}SbFk){>USpjO71y6P;i2qZHJ?2DnZ~)52G?We4XP+$IomiC=9g! z{tMs{P&)gl*FMc*A0mI4;j>sevXx7jA(1|;#)Tvs0Bi}Y?la_m_}toaEzT6oz(p+? z-|K1LSN7oOh!C7}V6IR!dbw-!>y?FQ={htE+hAF@RucPTMHf|*v*Wct7w`PpbvF{b zp|&sLmw7R1S$dzoV9v-JND{L^iMHe0Fja!DP!kl~yA1vRlycqgY_M(HeqxW7T1o7x z)zY9vD)tPm8WmfMs2Z(NvxqHrDdM$9sW)b7R*C2nH7d5+Vmw9_t=Q$u^Bu?c7ks~7 z$93O7Ue|e^_j%qR4Vll~?d00_JcG5bwUk6TI0b`v35g8MI+^?#bhXQCFAMp`S_Xy& zhN*PL>i0$^5K^=R5}cvJ-@az)mM0i|k_AmOKBy33ZPvhEw}0`4u+ji-y^AE8_M52P z^gjp=Py}@iuAgR4vw3sD>qUdYnX&f->k|Al6FL_{M<2lEq6r1{E;eEOSj3kgFTmEy zYI22r`Zi&doWWl*iKeu)*3si!)#0?aZV(&_VYRpWQ+&`aod6Qw4&Ol?A&}KVA&3+0 zuoFDs6|chGg)ZEA4Al{G@lB0+v~awy_5@g(S-BWbv4#jH*IIY(VY?;?-+sr>_)fpa z8oYeqgx;aDC&!>iXqeD&%!-ELdtbX#)+lSI4B(q?s#tIk{*i_6OV9*3^iOC%gEnf3mme9xFhJA_pQ z!AjDG-@wUs>B~W1E0IX^5z^V8Go6={=F{(hZg{$EPc&s#hzGfgw7F?iLi1~SpU#j5 z129YHf|ttk?c}tIpy%rT(QCTs(ZPf@!iTVq^C4RuPd)RQ&Xci}54V3>Aa_FDtGgLe z>nPvE@M`7{V!(W<<|GTTFUl}_O$r110A&Bg?oFg8WaaI5%Z)$RXUU8Z>8tIXfH=J- zdj?xNWuHty1(fsRP0J6pr28Vibl%+c2=pcm_5@9m77$4FvS`!O^a^>?f}>nCKI!u< zrA@F7k5x$liT3ehMb>p1-u%TLHF3jH-NCRKzLAYxrHJc-V_C1;mX}yXB0r{)tRwc5 za-*j7%vS1&9o?3t&WK?!lxANz@dt{61Tf}a@yz;73o_M;*-lJ=TMR}+aewbxGc1>J zNAq>XPNDi92}08@c-I(M%s^t5srSFNlLH}fH)q|C!r;05y*g&8n3m`{WzZAgCu50@{ zTaS7B1ru&3j3M3o0?F4gG6%ZSy`m?bQ0W2Ht44hdl5G25XPU8J9O>uC80fR=?xwu< zd1>Y8wCcR`gvMUXFY5Y8cxSEMNkpg3-LD~1sN<$v8>xwdNa+S2OcOR7pKroPE=n$V z|2_6H)C$liJ9heiJz^X6;IzmZU#CCRTWcy8K3&q|{)_!Hfw^~kEK;5~aws>Fa#UXN zFXm%SRaG_+zgx)a^uowp-Ko)PQPO|9?S&R}$W`2Jj^k}j_cz6aAZ_2$_98BpH!&mc zq{vPePW@Hk5r05FjV|3P@X!0?#HYrKK7#Qpl8iST#YXP@&=&10Op9JPX0@S8s+;VP z2aqR0_1=;oDsr=2u0-8B_>jFAVna`eO062WQ4y0#gF~%l4NHl<{@P^aL;J%}tyfv{ zUS6xZ#-LgzYb0xYi${o3tI8mzaCsMH)Lt2JLr{oGDxZLL7F4NKPA!RM@tNqEp%4F4Gb)VSOzlc-EG>)o&_z7=M@(#qkU zN!=PZa%GVlm}3zC9FaQ2g`b?|@O^5~{IbK?oC&UdCByP>zI55)aB~*8HYW$Wi|3n( zh0(uvmvnzm%N^@c%UiIn{H*glK*`h*5aNh6q&f=tj?y^e_{V}555D3KKXpw`K--AM z@5L?0;$ABuInJi-F;skEysr={Q8%iu024>+(-a1L;cR(Z&GZw1Dyb1W2*X4*^P?EV z7{{lTOm=<%(}%5xMrF1TbXD@fOl=0V5AwH`mu{TCX}K$r|HD8MECYnxXIsEAHA<*!(*)~jX7YIR z@RHC%By`5F7|(1J3#mG)L}*l!(|u0~C>&8@BmtNf@!kE`hNTA%vUg^zyFDa35IH-r z1St7%w71Y*0Y=OoBBV+~O7GT39o&Kx{UKd{W2=e7ZA9kngkJcje@Kt?lQ*FJ8hui{ z(+&H588P%r_-(m8XqG5BqM3E6@x|#0=4wyLBP5>6bW!D4 zn(#9mAXZ#?_nByjk%^FvS8|bddA3{5P|R3P?zI_HS_QupNLSyw*4cknD=fFO+ReboY9f0ZN~e{sCkla7_VZ)G zo^$M*v;CgOmh z*#v=+>j8Hgmt=la+ssds61FMK3gI#VqJ_flTI`mSne{Y~)3WAdNg{Jk$wgsfN^bn$ zEZm-p09p1VRrTn>rZK*^yG&c=t8cvljw1(xe<2Zn%{5p>_2uDE)T|8~d#ekQarj!- zx5dSxi+p-YToIkKYGoR-Oo{Y^fwJwf6=MF z@*oS@;B3yEZ79=b5KFRtSX@%0|J!Z)xAnx)YzrZQOpEZBa8 zGFns}oHN~e$Ki%}TC4TRMQW_n)ITH#hE_sa+?8-p1hC1SDB(<|#; zyT73A$}U68!Y?ox%_{J2F{TUoXYak`$!73QW>TLxgk6sPmB`OV|6ZtLQ_&Gv%Hi_%Z-~>U zSHP1vR7@~q3ztnao^nL+FiP1r03F^zK7=>vu`sIZ)a}062W$}%0VbZ?w+~2hq-i^ zT0Izn@QWa@58xLxrLS~MWJ~=Im5U#nZe4=2uSzQ)@$qDLgH(>Mb{7;`dSP6!QEl&R z817-F?&Dxu{J=SQNF`B8KSo{i(#Bjgyd`tNbg4ritUSCIxwLp^u|7A!bbEsnG?4x> zxBGDQH9fD+zB9YAzouiLCm%#8T85kR?^>ujbQ)IdZW!@3@?P@|>;Rf{i$~%H8pxk2 zRIOhQf3VxS!k^bo8XOl^ttFW3LHNpP1=#zMFnxL@!Hm(U6sBhok^fg|lfy2QCvn8` TC!G3u9F38lnQoo7GwOc;OC$b# literal 0 HcmV?d00001 diff --git a/sips/sip-026/deposit flow.png b/sips/sip-026/deposit flow.png new file mode 100644 index 0000000000000000000000000000000000000000..e4fa79045afd00a8fba91c59c96cd52941e39560 GIT binary patch literal 19060 zcmc$`Rd5_l5GE)b+46{K#9%SYVrFJ$mMmtrn8speW@cuvn3UA%@3ysf+}+#H%`2#{Zx)wRpO~0jUE6$KE}-XxHQ$3Lv>q^PUzT6qtTL!Mn^4%Ug|Mr~`0)`-^p!sI$ZJ}?c zsJMKjZ4m;F<74OZE2ZetN@l^v^5QP(+CV*1wzErg%dUf&hGkO!IdRaze{;LZ+Tuya9=z7*A6$+$o4W^d8Nd!POLRvSSvd z!4|tlDHoIdva2Z9%rIT)4#-VUdL|W3R)k}7mlsT>`miuH34jkn8+(-9{xU z@849~P-+jAIj>s`ye4lFNfuqAmR2k3n>khL#pv#nY%+iC4(OwfE#k5nQIhg^n#Gp8 zDtQX23#7@}53%pT(w9?Y1k4qxAUYPv7N^uPfg@~RH-G+y>`Dsl7RS~`5_hv1kRdSG z-r-n8_X#%%#e9?Sq|(eHHl>~EWu@C|q4F=XZnqjs8~6nppTL3xS`VSy_{;U7#OYuo zcJnX*Jmcg7W0Q-Us3p?C@)kkK3(K@Jx%;S-vV`3* zDvz|Ft;)hX3!Eqmiu+P2D;xvl)=MkkVnTCq+NvN_us1k}?>=~IuqUlfBoYka0vh6cnmn>68XwFXp*Sn)k3A3=rA~F?FD7fd<_tetd zI-|0gsu$=PPOD6Ee-%GdU{zT$R7VT@iP0~$suG0x#UQ5*7nnfP9{<&gxF@DJv6{oh zJb~JhI*#LDcyM!uSPQ~4P~c1cS?vK)PULc!NF%Zd5LfnuR!VBdkuq3`qj3@j3cc1s z8Z++5RQ&Gs3G6KwGtfof9o@c)`#2P|_Cu52Hf^y$%?_F!pr>o$d1WaScwBxqYx%0u z0S&Aumo6)FMPk%wIMCp+adkeExF874O&@n3)B>0Z)>1KWyn@ttAZC#E$SRr5{dsh zBtMp6)fR8@>#r5t2I9J%-^*9Ufy@FOS;uR238N`;lAGXKHwR_{oC;;BfKwvbV&$O? zF0zJN03J`y!?HxiHX3@Yx2a6L) z9eNP)Xoj3>_36oZ(Q1tX?Di5@4_2?o4jzLRYO!&SrbTKTrM;{MPc~%s`_mj*f7yK; z9%ksiU4(Cnb4X$fMdW>vyehE#k@&D>^Y+)C0mso3A!xry{Ng?@9RF&pcSqBm%6HZ6 z6B1lM7S7=AC4cc{M1u;0JCXT|!E)M0@Ad#^)SFZQQ-hltQ1|$Y@sK?rSLA|r=vgVi zUywTceyQwFE#LFE+^|$MIO^yG1B0id|LrvW3{V`tZJ`0)$l$j6AUhhdws?_7d<7DN$rR{N=kdoF z+Bd>0Oz?@p#|0>Iv8-M7Ve$+m3{gScj|>CMWmORDLDmvBN9ZQ^ANnT{F$OIn4}$gM zr*WW&mwE+!Tr~~{CZ}=ahI+gdyq-oJQhWV4DY3Nr46O~)ynjrZB%-!1R6Y(`i*sLN z?%CKlAColz_Sp=pwZO#Lw-MQX;pcU)sl!U4c>8X6LRRjE2#qL%)3mWBG=vm8`dzS9 zWK#`1_pvLOy(aZ0;Wuu5xN^tpZ!ikBn76OLB9FdKNKeMeG!1M!cMQ0v+H0|Cucb?y zBU~9D$L#Y`e1Jjoq+Jocv*?`5LG|V5p|8_~EeW}T zsELQ>^Vve+nc-t&ptmu{X|-12!WV9)FFhnJRmF=61W{tQ24A#SFa*ek<6h>{Io)N3pR5oJNr`aZJz(I5k^0<%H_0eJ%h6pO*4=>O{gm4F1gbqpWoM*z@d$RK9d ziTDg$dvmxlfBOyI@Po_~Ge_X&w66InYNO(b2V&q5^o(5}DnyP%0A7vN2BSyZv*qQitZqqg8>K zP+(1ALt?VA)QVyuzu#)=)n76R0<{+pa_-TWHXN0n`y=A8zDudE3B2b>b@_r`EGG6) zPq~JbS1y1QweC2=rW|wA6f$WH%2ZP#8G!4B|hBsQxuWdJ-wfNb0}! zPIqfhDEzDaJ(~1xcALLdnuzT?$UQk5dQ%$Xlf&K0(|o<~dtcJ59z9L33JOSoM;KIRDgwSdEvwKtIb=ENI0RRfsNz>j=z(lbi11RKh}hY& zL`4in0620Gb)JqrRpNkGSW@5A~gIKxboj21IX4R%@L&C@!DC3(JH0rkSzNp>Ef_W z;K;U81U7^ji22v=9wImd=cyG+U^lqphLh_|GAI$GNxOt%?Ha+A_A(X>d;mvEHaKBn z+@^l1&r;F(h@S@*0%~dQ*S18DRyYlx16@owl!NvLCUEkJIOo;ajcJRwj8&E~0-y=4 z0o*_mCIITosxa9WiOQd1+FO-MNLAq zvOTC#6kOoQp!DO=4D-RiOCW_S<>TIQsxCCI>L8U*m`%2bB5;IXzCu^3DM!$9s)Q(J z4_DXq+b8HZhAb-kOq0GkW|Z9Zogr|qfXyRvCAT3X!j>NgZ(cBrNcR-OpGuTsd*!r% z&=HK_Bt?>uIH5%_>7IUp0yySc1OloqdO;d7q1RyfoS6@-h=w$kgg*RralYSUI9D)e zu_o50+aD5`k0ThB1*S7l=sT@IM%Hb_F$@Xp_%R+>3GsUgwCf2BTp)n%2h)C4?N(hi zH0b%EXKWy3b$!r-bM5YeHVzT3=LxF&4#kqH>(8!*a5L;YHv9{8O`}+fq78HaOryLX z0-$R{5kyX?&Wu47yVr|<9BZuaJ{^P=bl(Uc_g$J6!6rw1s*Ulu6H#~ZtWxbc9Ww$Cf zLM($h5G~U{YBdtPAYk^|mY+WHLLHnR) zN4V4UG=4(|O!a!#E7)#m_-OBjXA-Hp#X9RIDtn0CIcU+(l)tF|+>Xzv=@HAO-EO>h z`pz{XVEyMxv<)HoIe=M@Aas4JrJ>#TpC?=sEN;d37=NiGMg|F4eaW_aV*UD0Ms@!e zi(sJsxuT)<|6AjqGEC6`(9+P~z)3mx{d_w&(zOwZ8D|Y9m5Sfev^s6OeIAd;R-rkl zrV9MHqy5$btJ{_GyK&g!mMSkdK5Q)QnW3e?_$OJB912ctapI@={%pK(zONzX!rcEy zvVJB8tS7vcC`wAgjlrxXWIvbhVSL)?@b~wuO%J%nTgjpxwgJr3oV(Mj0IR}$<*aE+T!!F2IFA46Y)QlW7tatUO>}^4ET8!swCau zhYZv~B2SRJ>fEuUmVgrZS62Zms@1wSE4k^U4XS-;?srQ#@8}i=1Ol_ml~E>yoqeq+ZulT-hSO8 z;|$9RuyV($l@gEyXH~=C0qz#1$IY9oV*AQHE^EbBKD|4|TQYF`Wq7f9I`7Too3C(JPmG8*k9QD@tpb2-?McHzVlw8M@W>vJJf^#kx?Xn^9;q(lld){`mA4|$Iiz0$y~dZEn5i44gBf^R;9wsn-PKX4I{6y&BulH)b=?{J&$F2<3usT_bmdM<$GE)NTpw?< zqbM@~T&&b{mUA&%^F2OZG_j6}axawq#3bR6pC8j{X@;N4P)!kae0=k!haU<;MNzKj zK~x>0CM^r&`&McA-Hu5_p>caWi>{tg`^YiOC%XKOcPlG3c14#(%O%U>rmHPW6u)-V zLQXK7cWZ^y4Kp?MA~j&cTTbz(n{9jKxaOquXjJN0l;pi#YO5>PI@RJ)nm)MLGfIRdUnFfm0yv;F<6&Kd@*V%HQ^R=PiY zmH*=q2>zwsBRfQGBIE0aG>rVfD=3fino}=j%HJ%ouMtIHj@X29yE6}kNQ;rzcxJVx zFJiadf0Zn+rB;p1lite<1 zrOlt>(hw%mLMHwZ4jVE!ld<-|wEa^6$~Z+-*lKyWt5?g#tTn(^3|?;EV~{`GmDH$_ z9pvb>gRP>c>S&|u#WvvD-x{5wN*EZ*L|H$qdyj1es&9{OSVG1{jcwu%gzg)1H6e%E z%z(@Ionp-Yd$A@t@bX``D+<@(V|IGI$cFKkFV2YvsNmsZuhq)EQTuFmwyAjO7|UG) zAYjx`^i1-T(Dmc-sh8?zW+lq?7cM(((~A_d5ncKg8gMX#DDHpz^`Buf@qj-?oG$P# zMfIPGZQIXiqWCg?wr+bJKtC z_>-^WEY0BtXQNU*or!=@+%8LsRB0GU46kc2fxA1nH#SFKMNKSKO%xiCS?X=M$5zCD?UGZd`PI!X^Bl-GK^%GctX~Xv4Im zWp0mFu+*p4k(Z7$0l8Gc{qNR?RW?04EoYWN!oz39JGM-WPUGhL1jO8N(`GzvfqkhG z6=Eb*>h+F_^NSmwJkp*Y)eyW_=8(};Wc@-S<>18{6eMA}*67XZZ=5QTlL-1+78Q0PKhQ&YxL>&=vD8wNB*x}#N=E})>y z)FSin&L8t(!c;Jjgh^&x*SPH`Ue+`Vd&VZ=y2XD3v&^p2w)-#B4k? zAIGIDK8t0cB8k!Gj17rwzFUL&D=*$84!&F9(~pXA$208Ba7P;lG=ra0D4oc3!w=)L zEjs21o;OUCIlxv%C;UwZcvUY|2vLzK-~F7tv-*Ba=%;7be!6Y{({)5))hQ}2`j?2` z(LWzy$*?3f9z&s`hf1125Dgw~#e#L*<(SvKLRQNogE*^Str3nnZ{C3Z^UZ*gl^lbR z`h`zNy9&d@b0g^eh%{BoG>K!j^VYu=f*FDuQ>ki3zYPI5c#}Js6IL})fGgexu#I&K z4Mz#G=GsLnCRNVsLnahU8LUIn+)qwMq@L}kzWhVrIW(U7LO6m^Bja2Go(X+J=duEw z!0S+l)zrFVh&HPMZi z@s6({?Dk!Z{&n9GRDyqxc{lLCf31C~+U%yrG;)U%ZogIr#{PK}YiTwEGIcQjdD(C{ zjVJq8-9=sM|39j`|DWXaKk}7b!W~1*6q5{pE5l(j<^CVZO>;Thy;sdDiYLqu z{n>ui11F&F7{+~kKTl-~pToR-_l`b^zU=SvpQFVRfJ~K+43v+^uMT~U-cZClQtJN; zE;7g1F$YA|qc6Q<0Dj37l z5H3(qQsgc{>8Y##?WSQH3cw1zwjom_J*R}tWwMb6<3U!Mo@?F+q7Qb#0a#@kYPMNX z=gHo{|F&)mq>U}MUYdpJ(2p&xtC9?`vXsgX<#XsY*Z;(!!L z`#WYKQNbg$ElS7@s46puDX%FuqaD3aSCQ9>URX$;3W%hYEaZ-_n>S_tGi!y#S^JEV<+cXbWS|C z3-n4e4ZS=iE(SrgQJEQ0JqH*fVh6UdLaq=c&i5_Q=!cHnDZ7I8k}ovez>6KaPvP4j zQb8^H$JP6c-p?}WoyPr~A;l(G>3rTL%+W&68NzVO3XB~~Go%z9BwnxMw$z{67&fX{4 zEi8a7lS}pqZH!{d@l~eTX?KZ3byPp%#4AcL&2nsR($~@f!Bnm|MsW1q1=f2fgMUCE z_2GnzLvc1f{=(nIEcDog%)!jd5-FSi>#1J%%oH_6y09YmFPG&p-f6Dqc|5+M9N3&0 zyUcZjsg$K6KQkO!p9hSj-J zUh8)|N0aQPnUG)jN%QzQ^e^Yg_GKH;GsFNwVeu>1aL3v9&M2du$XmOCzqVt4FWd5o zyvq&33QY{1!m}82*&a`9ZZ&5QnMDnOdgKyUm(fkUI;&qF1=HKbY+6t zU}8cGFG!2Eb<-N1>xJhehiX+;(Z1Z@92E)c>nO@m^NQ)n(vq{=dWr;vhCIoArA^jlcQn~)9H&CI9k z`BsHg>O5PNND|z%L)>5Ubw)^hXsTsoAn%KUNe_gN2~=2o*a+2xg8`P~pqtbzdcML~ zkxD`gb!!Z-azcNB-;sZ=#uYIUmyKZ)i<#gvMOa{E-sGU_Fhd0vJmic_uoK1Ec(gKyS+DLNOf5e z{=4H5T1jIK+UJ(8GpQw_SkAnKVOn)o3>LPMb3cD4dUfU&nh@vG6tziaDG4@{7h{?x zE!gzx%z6!33FMm0h$IvgcHU}fDJeNiVZ~`FVuYW^^?}xZsLJTV2y-Wgi#a~XgBr}- zOQW$$KkQWzNgZ3d>L`L&d^!*2UJ;&7@Hs;0rUN=@smma23&s?k2WRHcGwF@PQP?}- zN0`Q>6EQh90A~{1=;;A$Xpy)w)Aup7)x4^UbR&7kdEZ^_rAzZ^b4S(`?Zc^!Lk+y` z%ksYOC^*{!XUcZlY*|rmk~CMyyQp3rV2!P&XY9ThiAOSY?*vb?(_Fa)kTk#Gr5aZU`yT*Hr#zlUL%;VX|; zI6u!Rh7g9l69c;W-F^ah&#~1PGSbJe!yN6zF0at_tOLpMHzM|(&G0+tuHHoR%A!ts ziZiNGY}@Im>jOv_VMhKZ7hr{LfZGA{UR}BG_Zar(s+D^u-u$M)@JZfxtkpJmHxw&~ ztNg6@)Q{>YciZ9y*D{3xCr6VaagvuJ(cg>WPiXt)BT(%7b zR1K1 zLrs^HdnfWelL$WL^rE9XXBl#zoSsogz?IuKlpe;uGgh%HGmx-}(bUg+A-P_MJWJv& zs#F5Nc`p1eqA-hto4)-UMCT%ljbk>Y`2`exOCN-Tcn2+@Q8@Wsn0%{SL`w04X5ht9 z!THE{{%&TfAR9xt!C;$gHUZn9r9La0ZVD&was4mXbB13Lt-&w`>J%*cin0A=Hk#`9 zU+kU_OaiixNv+|e8J^~OnEg6}f7R92I10IsI29F8u?8SQu|H!D>9rV;{y<%f{)6b{U$yfg@U!w2eqHEECaY5mN!dm|A^AFZ%FZC&S5($J1F z-W46ne_V7j<1H78fGtjVMG|5<(hQ7Z^1HETR*_ZNpth&Ft{D>iTHP4La}=!ZcDK|F z&HNWf?J`q+dmPkJ>pLAmy?t4?8)@kVI~vO-Sw^cEQ`0I^GXQ}jX=Q-%L?WzSNT*y_ zlIPnUo@2Hw3z>NP@fDrSy>AmL1$2hDo^^)^CP76|Utc!5ft`M&59>JZ!no`t+bHLd zYABb>gP4I}0BE;lHxgt2GHj(jVkkeXtWq23WLtYxv4JKX4l@pI?mpGlAa2&3t!mSB zSph>$kMlAB>dz5Y3tf)WApu;lK9WatywG-0Sq1n@DrCV+@0?X!Zvf~PIvxap*#fGr z@n3=X&O^95bu68

3B6=u;;fUysc3C+Eqw_pb4DUGFC1JibM z;u7f6rK%(Ge{YEPB!jNssW-LPEX1!*Q)VuR27V$8T?}0e()a2kqLM)9X|GQ;bMBT$ zZC~QO)@MOO6Ts9Zv)qM;r$zfi9Z1KMW(JT3tFeat5Y#SOf<3n923kb;A2M5nPs(_0 zgy`|Qsc7lV(q;;VOg`c4(c)z~whE$;AT4QEymp=a03-t30)Va;CTaM@@1avkN(i&4|f@h=pCC!IUyo8 zU9qSrm?$*ltDK0D9UAX5Z%I8@3L1K0?-0l-s848MtjO-`UVz!x89Altlgs(IIBj6w zZ~sg#CC$qhP~1peao|2W4UYEEAkH#HEG(}lU*5Pf9{}F2m=2yF=Qj+J@Juc~r!smt z15=KhNRBCD1j%;^+M&`C;8llcxu^?WVUvf6xr`+x&|5Y+z5S5_-Hl$7ZRl<$@EVlJF%{syV3K%g zNfi}87YD|Vs-*K^ACa5IGb=KmxFm0sGy6MjW;vi)^|)`iIzTIuw%}lXr2LOClL@a3 z;U#@-w)qb22~28i;E2~vi*w8U(|66r_65_`oT{un$o@dXnLU(YPD&@Pu<+or33={7 zdDFy+{||B}O^4dAyAN@zw=5*+i+l7S=UCLRjUNb+u4Nf&;ZSl=>H^=UuwqJ|*C z=+RMIsqcukjad{^JOckQVGw@}Fx&M&Q3y_vD0v&x`uEzSJWp87C~Bj8vvKx~hM$sR zb)cAZ$A4LVvEInCc(gG~YSEtpk}Zi1%CL9Ojl(l}eGANz=6IZ%Qf1DCjvjXEr$kTC z$>kkW5Xp@HNE5+bX+*?#^DzB+e>Z*1V>&UklQEYx4D z0jpE7)C7XRswN$A24m*nr%^fwu8^#u!ZFEN9v^u4$McMGLzq87z5!;3__Ucfs5|YP+5=k|bv-%PnM1Zc86coxVAegB*HdDxJReD(B|l{GV)LoqFu?^$&KzN)Nj9m| zhi=wGeSYHFxq%(?N=buBjR^|Q$yCqU^@5+&U|lylt(Z<4j^CxfpY=Lm;e-_n+pDB< ze{5hZ)J@JxB0&>OYdhYdqgNMG>E_&oWb?y#R_GiNsNunN>7Sm0RMvKisR`IjWvMJY z+5AK&6@DtZ^ePrARnX5UkAX9`zH+L!B|gCgt}G2rFK|e?xPjidk7^S*Rr6KfLRv43 zHQ)oTE4Pt1XS{g;s%j^Qt46~i)S0(T&MpM=A%rV&V<2cB9Fp(T8+&Uq|IEfwm~csJ zqkPXa9re>O9Z()DUKgH56%b525K(r97!Y6jafJsx*v}b>k1F9i6$@{yi zdI3M_fl}A5I}`*_kJ7~8zmZg#_8G{1{Ok=_Mo$VtKw>a*pW1)JzxKSk`{fVzPb`|V zB`|VmlYEM9#6nfKoXO8$x5j$ZWqkUk;Lc8-t!&060$mX=v9=-;YiDrjV*D_bj%wND zLvIwJVNP&DZUzZ}tF*;P!_4Dar7m(#gu9mKaR9W61?nLCCXf6dAj6-YamTvcj<#@} z7$i-L|9!UDDK}G42sjkN`@Y_oO-l^^UQpgzI+jJ;Zy%IEk>^gO?=1l02<2AM4036e)n(q#m5=a7 zSD0$RZryrVTXd3GH}fFNVhKe_D&?ZEFrOs38-{Pvl57Kd^A%H3xySI7(6T&ZF2{vd z#FC;J9VQqvVxYJV2ua-^As5m6 z(S1E_Pb2nRrL`=DZP;mfHqAQpprGMP_|UPhqi_4;p|Ak6!Wz4PuQ8AsX+nGI&%G|EUl_21x#bBOYPL z-sHWsvQlt(m0Y2!<6AegHbU?fux6K6VX80;Y$fDO8` zceg>HrmojbQj1Ter;|)bI!~fv%m4F9LaIlZp^pK54-c)$EaqKEICY3!GCv&=8sFv7 z-^ngp_)Gi9j&kAb{H+O_e3F>R`c|auKTNe{?L1o(I!ib(Q8qB2 z?)PGxXuoT*DI`@>%_04rf}Dp(Y~SSp?qbjW0jA(SO{H3>;cdQP7dpcM+9+CEZyYg)G#>vUSHeo-1@3Jf2Yqv! zvNXj}b@G;}MoUaUl8cqzLSHj4ezvw#}|J_DI zxsFb@eCL$=2N>h~n%2FzJXv1R!b>^iO!8}91QVm5zhMM1ll5WZDv=)Z%c>t!f2`Vf zX&gng9Y5$pSOAR&C3XWXX5r<0)1o#o;kRHRXDcv{r=7MnycxPH&>wHO{E$%^kp-%Z znfM_zO%Qnkr5=i=6hS-3#hRrNUJ$tJJ|P=MiDLhg|2eosq4&Qo`lBzroGs`5DEL$qjq5X z$1+ZYwU0tM3Ln@fJ0iZnWUxQ97;=!2L^9*S!TR_Y60kNZ-%*E4RNJ)edoicvLOV-h zQYM6Rt1rn`Ef~|?A&(4+5sZ3F$hh6C=(;fav;HRO*qCVdIW4yG?j|OtcuBFF>=0XM za}WR?wxT2KD}l=8XbwqABE;4-Vq7;E4(oIGX{-givvDi!f`o%9sVd!lQ_XNE)sUvsl5v@||7y_^1Y;tUZ3Fo=EWW7Ipfa5&0d`zj~ox z5=y_-U;Zi5U)}2-OvFglAqW)TM1Wza^H{yV-8LDN|H)R!p6n~pF(yBVmDI88{$(bd z&#VSu_#BO>!)FpJew_6y!>yt?kI$P1!k$j8FLAshYyHCyfBt2 zg4yFZUl7{2f62bjSK~~WVi|-W7Be68zM@zY`chkx<1ij&guWAx!b zimw_0uSvY|$aX-NvwpJu3#^y^McXQU>G~Yi%A2XQwkI%wAKi#l1ock1?Cof+L zG<|J8>TBLl3%;CbsLdH1)|NsD;>j_+qE(U5g3QYr}r;J~RJ zO*R>>%pAiRhh7-B)9Z-9jU3b-82q(976fZ@HeqMv`U2a~+PG}T@(b>DaPnyYa?(FH z2#!7_DQ}^ni(f;X_;#=?iQ<+fpFH_iUK0=1@_SE=Dgel7E<`K=0c_!D@dfZPSE{bh zc?FLzsZG3L24+xbOC{lfYLa`6Ys=rJi9kHtZhTfLb~N{qM@{TFo*L}G7ENwa z(0axebDmp=;jHNGhIucQb0HV!aGQs_yMxgT{|GC#Zrrwqd(XWVa(@KyHH2XkR)fk~ z`yd)y?Hc;|VlkvOYXCnX5(ydmYd`$OoB|=!_=N+;jk!tw8X)ii;tXCi&R`57!2Z#Y zNZxi#!%rmoALEPm%vUQX4%X|q#d9w5oNe!*cAGl__p=?>^_p6xp-#PbwuwN|JKNqb zm|01c8h$e%(j% z{yS1>-vNvbrd4q}VCM$OwEpJB?a1gOQF~^; zJTdoVf9lFZ2&o})R*t-AL9bBaZk#4dvqpgYS<$9_e|qp4i_Fwn|Lkht+XGt@W95K` zRl$L%buKGMXO^q2=dX7`8KJmnNWAza2w-#5>~@30_#y5uXvXma=L!loyt6^f3vg45 z4JEH!EB@Ht@5VW%i#6r}KuE2T#XLo7$4te3q@k}wTpu43i{*BO6rdq0!mHfk8v2Kw z3IKy#n<+wy?HdAR-H*Gp3JlmXo_U}AMG_*C*TQrIdO9yU++9|VLUMx=00VsKP&B&rbLWKC?8GS#w&PJGfcL9V@5PTf5+%}YntD70> zr9bmW>o$Y-sL%PM+vE zdS%vCLdDH)ualGuOtAH*^NHNp%>2ve1pF! zj#$wM^oM?%c6M`)!WDg04miC1JjLkY8+=4HU`_)+^EW@Ytx1&d+Z+jwHg8x z_H20qMu1274qojJmk^?u$5ehMGuwP`F70ACFZiW^$+se$t>ij(k6%+7Y z0q%=z_2V(DX%9qhfvu+d*ac5iBEi1L`7tu?Y0rp-07I*-u~m(o0`H;#k}(2f|D+MZ zQh$#%-0T!Kt`V>7jDYDOrm%Hyc$oQuF;e`X#?k~_p@VT)oA;cP?I|*ZjI!I?GSL~b z$YAs0?E|Eg{bugd00K-5oCgo4DDMSlp&YzW%jWUOH`6yFC@}LNn2^%p4BWJ|?!yP+ zv#956%>!;CcNJy#xuRwxWElL2N`C>tnMnB4x+wT~ZwlpSSg%)V?&qkZx}v z_d6(d1K)aciM)A+ic{^l9gac}_(^VdAK*jU_&a2r7k&CXZ!a|li*E%(kpNYPOJN8m zqCTirWJWc=W<{P$#gGeE<7YpyXPGto-gsHxcSE*V8Rx}T7VTHV%yOd_16)rf@EE7X zpLTjDxr>}DI?~-fW}*y?K&YfQEJWCK^Zgr-J8#w zf>F=u+2EbxTK@`FKw+1Edru#^kC#XkbNkxQF5j9l&O*Dtln9aallu21&Z_r-s9G8osE3o zYkisjJW?wJ6wD^uzKRY1*A7enVT^Y1BJAiQzPK8t)$l)MM{5S05e~`JN{15i;eJMg6wQfF();SNKCR27@f?tg! zSF4NqE~EyOMTAo0N3j;1#=C1W9;BBNabE7qrub`{~zK45{VheM|;>k{{Jf!Ct5aL;-=qrWt_RpoZOv$s&~0bilOx4%Kd zJXyVg2D|QjZR$7#_&S9~T6$d^oL-!)Laq(jTYCe1MXbM={=%Ud{iBorWY!-#T!m9a zOP4Jqj7It!RNVY->zJ}NzT>a_Vl>BS3G^8x?@E6QG`!|fyqU-#eqsu+aj+NaJO4-; zn8v9&uY{C$>0?|`Oz#Nh2CW*;U zA!d@T<&Zz09O<<Uk&X3GbFlbJ8b<>qt3)Su?JmS$KaP7sz zfGaPYryna?E1Hy*CXbOv)+`lf{)7alvxUP2XeBCxu0xG!z=8aJWn|mUd1~bi#mHC=8LKMg{$pOLu&{xe2ZbFh(v@^U z^R%LFlt8gd!!xvGkVpn5xp`eAx=F+6LCL9PWemi~BC!dfFc`1m0ZvF+%&XrTAUM!X zZQ~;B1+kId;1z>}$9$tODtgD*A%JuofPYkFwAYU$#dt{uA%Rx-tWOkysF%iKp22I8 zZAmWQ4V-xksclg;RSQh6?uxMY*svqYG8K*{PkDpmxAbkoX=$2-1Xj`_QYB2#db_g^~2bclvdjnSq`s}m<{jA|3 zt}!zmG)L@3{hM^zMa@K(PL$F(bZ7C^=X|}1TgEr38bd17MsX{lfk4eQgPtt@wW%fQ ztU-M(=qyAS9#tFkA-NICgGNlIV^5c^V8VZ8UmYL#9No1-&-iI!IYwxhdKOb0tC8MJ z(N$Bxa^~_jqm3R*Q8DH?G#}F!zptvW|E@7MHwM}?y7yQeh|Nv*1?~B*Oi3~2O}Vn0 z8U;S+xRX_&t7u8-4;n3dBQ1-I_-YO8IW>S;=RQ5LlGQvhOmPn~{wQIerXLW3NUj7a z43MPnlD7#p?>J7`(ZGL-;A$YsJJSq&6w&=EpN7tP$N8hqfd92uG53IA%?#bEp2R zcJin#Wzj4_p_n|UVO6=xGvPpu8Wy&_Y^{j=qvFDqIpBK1JLo7mP_MylFM+*!_W?jX z+nyM9L%tquXSVcsv>I*qV13JUW21Pr$ENJ1ZCfAdwm0&M4PNK}dzZf0<5;yzPs|vy zD1srQ=)X)9#+J#%qKM3*C^-`&{F!(!j(8ByRHz@X?;=HQiy(ORr8$Apa7oGNW=K|A zvPDn&B+T(b&l!0?yB=&H)#`CEhG2mB>HQ1)ZWaW^m?Vg`u_%xEovT=2>SoC4B2#!B z0(hbLt8zf+5fGpB^qiLV`R5A_-EsV(i>ZIZS45?~yw`t$weDj_9SBS0;IHMM;o`vdbImzMg#^0FF<_&wBd1z9)4GJ8rE zKa2s(mdc_EBM4Dv```~~c21hX^2Kd9m}#4pMEF^Ye#6^|-s^3z!2D(@aUP4k!plFm zeP0gkZ~twklZG}E?9r9Mx#Lxl6v!jU|~vVx~Nk z0w8Ppy}`E_BbxVNdZZcIq+e%$6m>$@=ff+I5qnEV`*d{VFovmGmKaqsPlDoz4i3b$|ZK-*IFNm3t16 ztE)8l-W`4qXdKxS?#{@llQhGPalH(n;M}YANQdAKWkV$i(3%_`t{!wwGc{pF7o&G>aj8 z*NujoXG0eUF{HxC2FkMu!Y!FR$2NkF!uZsXJ~`y7B`&5>oe0HT^fQcPTL1gh7>2q_ zZZy^9In2ymXt#KP<>=h{%=el2f>8fTy)1x{*I4{$xz_Bj(|Bue#l>J2j|?8`2HZWI+NGb3TR4wKdz-{_$bFkQn76w(OqG#G#vQZD z6?{>VM@}7<78M@~-JPj@4- z`;Q4k67B`|+rBllUf==G!Hf2OhP00aH=_$kR!>u79WGXyVN{F8ovajEwQ!0Fb}YZs zw_Rk0ItF>o|KfIVm9nvkwl{aJ7=_U3=rQ9)^Y&XTV!v1OK|p-{{@;HAWbsoE`&0S3 z(7v(S5|St75BwU{z{2&^zfaZ>R(XB?i{J^Y9qd0BF!i;!!>4y;-m#@)W?LdOGQZ(a zC%`=0pD!v9swng284_;H+wzPZE9#-@bIgm3O+ zs~qK=(pN({Q-(ITx#s#fvK&1q$~9{E2(ujfFw3#B`j)HQ_kCaE!yLnB-@oGfFT8(v zKOV2w>-l<7F^Ud3V7ob%Lsa?uV82SWh(P0pn;8wez|}rzaP#FkxC>X|r3P-$BzD)N zMmD;OuzGS!5H?K0r!tC9V&)B>Fny@XOI@59;1n^P?x{KMha*sVKIZWWb1n+B0%#PF zXJ@=es63WMPddxIGn@EycYy-w@CRyhD}>j=8og)UUFclyDr5V~qeXBJruTTsLHdHi znxhOJkP{K|4M>&{y4SwlzNHDA6OeN5>jkR6PVI-^A&dqf2Qd&)ji23~B6S}c!yZaA zwGl1#(|W?1TauJfN;A$M+BrY_p4QewC}z#7@ndQsU=wld5*40A(ZNUMHh=XeD0FzI zH3__x5eGvsZMC~!@>V`iYLK>xTfYY4ff$b-7Dh>EJ7;h^d2GEh%hxESkIo z`J@1xG=L;IgSFQzRVc6reis>mLMeslJRAUrO)b!%XS8 z@uhx&Ko(p!Zq#R=@aW?;7-5nWR5vI?g%Dl#!)h{Sr1Xd(Lp!BGocywcTKapVBKwBg zs%1=|#oAH+^frg=u1@_YE(i~P-MS<(fhLxkThY>97Qqx7+K1@Uo#b#Wx=ybmB$+`U zIe0o3aWauk=AxZQ_4p07OMp@ReG}#>CN3-_MksBX@20wJ;=tD7o7jX53I&aQK*!;5 zv4ub_BBU9Kvo<=`z&joXWKk*57I?5ZMUXz&BZFQ3*&U*GD3%E|Amye3@T8XdOl2S6 z)l$t@Dw2cRi=JL;wsjK?;Zi$C9y@&|emksQ%-F_=S&u$*oZt7E7}-y`P5{cF!O@kD zR7yY-C1pHtgJDx(LO;Z_@9$xl$ z`G6ewlvZj<7j;z2DN@+!2sAtD$kp>zZ9pm7go3F;*?0-t1=?UOiqF}$H0!(SNrAh@ zY`tsyf3&n6$M)<%XG~rOsjTjfbYKKDVrfo@wFI7DEA$t@*#UwD_lrziJ5Lh|Ch*wbKjx%C zgPwL{fvd@fh|C}qgRNl{O|1EZ`)`h(EJH}ZdH$y4Vit?OULAJ(2Q48{h)k*8<>%n;x; ze1H3~pHYbYJl0hypA8vM)P%jR_EF|dn5uYOZG9E3qgdhacH^6DL?f)^iLO_#g^gX6 z()txyZggG|K6mEx;tP>Y=E?!V7@O?r>eo4W5E;@V^K5wPL|eGB5WqjmE4(80G9Hkr za4tgmZAsM!8{gYc&pdZc41E*d)9cMFT}EFx9|f;nw7ou^J;7i_1f5tU4SvU-U$fv8 zYS+B;8r{2KsPx_3K-I>+MlHmwt>lrV`watc(_&M>`_D%#erdHsGdK~?0xfswpIn%| zIeS}96sQ!A37DAQB@EQC)SV;*T~tUj->s&9^ZW6RnhZ1DLYf}|8TJSJ=p5wNt@ZsQ z+o}_zSENJa*)4`$^hZ7ZEY?-Mg9nO&LaUf+!SgQC*?=`)SFoU7cNaWN*%^pxqKg zAImVUm~GcN3E0p4(x!=Tk%^YocW!Yf7l&QyFqA$nC;mHTXS#o)2L$)GB;TLtNS5&_ zi0N~PP+!FRQvdgWoh&ya_Nl2+#|QKkJb!8s%0yhC3E5U7%Z_raoh<*`hPFgc;pl9h z?0TNt$!iKdT=O`rSN~iPI-D#G&Y*OfbdHwgg(3B!oX7%zq4lZWDn@Zn*^4GYTdzX8 z@RktL<=Blx*y|!>_+6{J7VPS41NsiDs*1JwjiuQKS;{=5{`8>n@F(lFuqYUee55LO zL|A^3K%W|tjXsoSFeC<(;?t&!Uj4r&hfaCPoO$J6;-c={O(h-+Gh5T@+ivmy0K&0o A^8f$< literal 0 HcmV?d00001 diff --git a/sBTC SIP b/sips/sip-026/sip-026-sbtc_peg.md similarity index 100% rename from sBTC SIP rename to sips/sip-026/sip-026-sbtc_peg.md From c678d96f55a632ff5a4ccc76be1467e187ec9f77 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 22 Jul 2024 19:13:27 -0400 Subject: [PATCH 04/66] Edited with feedback from Technical CAB and steering committee --- .DS_Store | Bin 0 -> 8196 bytes sips/.DS_Store | Bin 0 -> 6148 bytes sips/sip-026/.DS_Store | Bin 0 -> 6148 bytes sips/sip-026/sip-026-sbtc_peg.md | 229 ++++++++++++++++--------------- 4 files changed, 117 insertions(+), 112 deletions(-) create mode 100644 .DS_Store create mode 100644 sips/.DS_Store create mode 100644 sips/sip-026/.DS_Store diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..71774b7a982a5b5302125b7073fc118fa1be6c9b GIT binary patch literal 8196 zcmeHMU2GIp6u#fIz>FQ}6bqE)XBSoqY6C4Tq$uFF1uO+D>280imff9!j!b9j&g?GG zkdzpsg8E?87ax$QFFp`|@Fy|&_h3wnF`9-1jK(NNo_x_4j1bSAJKMAc^vw{No7{Wu zIp>};d(M34-rgx=46S*+fw3CKm`t5ht%8OdG_L3Ux+VpZa-tx6mMOZU8OzBK|G{;u zLqV8yhQ_fswvQg$vy}xHhEz|Yt>(4_fE1xxcjyy-MkRMJCJH@1z z_VR9PI=7E=DaWxgrFlBjV;aRFt-8&zy|if?Ip4t44O%kTYudU~Y<2Rs?)tV#p^z0> z8PaOT#+o)Z)WsU>*B`5kjcrh1F8@I>ExkTfMdJ&#-X5ONuD^}gJu4&Vj)*ZV#Cn~k7`D(Sg zu(x2kX2vqQi>B@k_ov;gVe6)SaDXyvd*%Vt$SGB*Q&M(%#F&_`RaMq3jzs$M8S}Bc z=^fGHvMhWpkHi%1U3pNaAG62Nxux!FBFiIp$?`rfZ_61p3bDF6a<`(T<&;Z_5H9M} zwTk8{sYCRdg=vG@C~LaXZKX4YB}5z5W?9>%^cF;fLRhVCmX*G&GcrOy+7+?~A}zA^ zh5QJA@b0whb&eV~J)4KnwmcH)=kgX^H}oKaNPDD1*1nYo+~IW2=qwWUgroMzL$d6@ zSCVs2+jY}(CY4=WshM`cBv@0<1-j*UBE8?weLS&7yo0zPjQP1#G=5?&W3{ZA&c+lw zz#Mj*J;P41v+NxEh<(M*vme+c_8Ysx{$y9#HIzZc0xUue7GoviScO_NVl%d2D>{%w z3O(q>APgM9FihAe;xLY4499T-C-E$v!%H}YS8y6{;2oUBdw3t8<7-^NMSO=#_yxb> zGJeNjxQc6%CM}jC(h_N{v`%W4TBHuCQ`#$HkV@4vP>Ly#cM+Z34XAp8uX)nTH?E%O zgY7#z)D5?M^<0?8>*dbs1q&C&co8*kX_-Wu0A~r0Q*rJ?ds;#G(Dq;dOjuG?Em^uu zjdm0Ejl(mmu~enn9A1m^1Yf;kr5e>{QFREmb~UlHsWJq6Z(TI1NmP)6t#62`S{ap_ z;@fVhBNhR(={{A}%Bk>#ZtF5)S-`ZmksDq{^1lQ6AL0BByU2cIm)Rfe3TC4M8lqT( zwP+&n?m#=fcr3jeLjc}5`-VcA$TYdjE@kIAIB4T5>Mf2JdYRfq7UZNconbV zb)3PQcnfdiL!86M_ynKgGkl2&e2<@IKz8?Z$l~XzkS!#0w&mCdNmhdR^yMKpB?Dz* zUc>MI+i(8;e~Lvo4KomC;Qy8Zly6IJYo(}ewr5JDi&5WCoj1O2Tu|SH2EK&L{p&c< k$$uEqJQnB@0UZ~VG}Qj{4*}u%f8#%B!}H(A2@4f8-w4G?SEOJ)MMR@=#CBv~Uh{7SJTwO#-sAgR?O~O>y`X=C1oJzk|pU)3E z&4z5dtwlr54_j_S9<)1)Ma9|K-9I|*Kg5rTdNx!F{MBjMvY5jQE|$6q)7v<}Z%HLf zp(lTw#45SNNWNjd5hF9e3@`(0$$&lVoa$P3$4xN<%)oCLpz}eZ5_%RhgZk(|qelS5 z61uhEnq~>Akrq9RnL&)82vdq^N`)OUgegbAw0WMz%%CX;VTTW4pDgTzBJ|U7f2q?! zcm~-r1I)lz259y}snPv^^7H(!lh`l=%)ojwAWA*I*TvrK-MZ2x-L(?+29<>JGJ_u_ kxX@QI=F(MMN7aIUNee{JVrCFMDEvo2)4+xq_)`Yn0XRHQod5s; literal 0 HcmV?d00001 diff --git a/sips/sip-026/.DS_Store b/sips/sip-026/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..5008ddfcf53c02e82d7eee2e57c38e5672ef89f6 GIT binary patch literal 6148 zcmeH~Jr2S!425mzP>H1@V-^m;4Wg<&0T*E43hX&L&p$$qDprKhvt+--jT7}7np#A3 zem<@ulZcFPQ@L2!n>{z**++&mCkOWA81W14cNZlEfg7;MkzE(HCqgga^y>{tEnwC%0;vJ&^%eQ zLs35+`xjp>T0 Date: Mon, 22 Jul 2024 19:19:02 -0400 Subject: [PATCH 05/66] Fixed typo --- sips/sip-026/sip-026-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-026/sip-026-sbtc_peg.md b/sips/sip-026/sip-026-sbtc_peg.md index aa0215f9..551bcfd7 100644 --- a/sips/sip-026/sip-026-sbtc_peg.md +++ b/sips/sip-026/sip-026-sbtc_peg.md @@ -1,7 +1,7 @@ # SIP-028: sBTC Bootstrap - **SIP Number:** 028 -- **Title:** A Decentralized, Programmable Asset Backed 1:1 with BTC +- **Title:** A Decentralized and Programmable Asset Backed 1:1 with BTC - **Consideration:** Technical, Economics - **Type:** Standard - **Status:** Draft From eb4ea89d245beac1447f170fae137f140a0f864f Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 23 Jul 2024 09:45:26 -0400 Subject: [PATCH 06/66] Delete DS_Store --- .DS_Store | Bin 8196 -> 8196 bytes .gitignore | 2 ++ 2 files changed, 2 insertions(+) create mode 100644 .gitignore diff --git a/.DS_Store b/.DS_Store index 71774b7a982a5b5302125b7073fc118fa1be6c9b..9fde2c48448e4b305208e8619e3e2c9f902e4857 100644 GIT binary patch delta 1243 zcmeH_TWkzb9LE3OvGj~i^=x%(P1%wXQKfY)aa(O&yOeZG)g|5SOk-lZyLJ{SqV6x$ z%O(gCPlQO^)h&@oL_{KjC2>jI;zdG)L|q;@yR!su-p#|DneTrt|L=FcZQgC(Qy+z= zBp3~uR=m9YF<3W8_a0eX>6xwOX!Q#hHK>h=yZNq!=4>l#FqjRgX465$E|*JrFnMM)cHbJzdc}+91xCr1YwoA>X#F4$+1xBEbEYY{uTA zR2`uROYyHX!q>nn5Hv#ecH`9XT+}Fw))+C%jD&4*qB@y7QK~dFM_OBD z^Oh}pwMs5-^5v<+eE}<88#Ti6{FKpZkESh7>C<%G&@(Qy*;)-3_jseVA`mlb*M^N) zGA~QolZD#E`#cvgzkGGk_7e)-`bi%g1=6|&YugP}-}h#krVuHdi470sMAdyeY+ znK;kyiF?$`&X}v9&wy0$DkdeE>uN=IX_3m6q)b-f_z9{i95Mw;vaqk_R;Q?5MMh6h zx>{LPR3uV2%6YN(U+CYW`}Bxj&|69WyX3CGje!_~;i$k=OhYxMV}_)?0CkdheVTX> z&Ct;*sjo^?-++zSgw2xuPV7Pl_DJyit26A6;3$saIL@IH7jX%faRt|LTi(GFJhf5& dB0Tp`!gzi5cEKo|&2oQou>V9PoHUU#`~V4W9a8`R delta 1269 zcmeH_+iwg}9LLXhdU1x)o~`X|u#0MoG*#--in7(9dQoY&-L`~GJ5xQhv$ZpAm4_0< zUBcqU1A-S1Qd&Gn>+&EH5g{c}A>tCAybuX-o7riIOZ)}S!~F95{?7TG-}%gUyKlR% z=N-$;XlQHUhMAKy1R*LqCUyiBM~;$4%l_(`fK*q@8-sck-=u|`-CbdqE3rGxmqQ{; zJQtTdZeseh>9g_+7A+~Q7>sAG1j#KW1vE)3pi0mR=r7EUY9#rjl@TH>`;rB}>W{nIZbubKTh^&yaE{Q^o2Qr9o?Py3LXDC@U2M z9a_lXLERDE(tIk`HU?W;t*H%1TPSxIQg(~3wr?&|46~w5)2++xM-+Kvxz5%LRaH}m z-yj#uC6wK#^+vN2(keQ2E#!16mX}kyhQ&v8yVGKoo53H&O1sFo-oZ`9v_`73Lc2lJ zd{Dv@$9TFK2qoi52FW8n;wMccNVbxF Date: Tue, 23 Jul 2024 09:57:53 -0400 Subject: [PATCH 07/66] Changed SIP type --- sips/sip-026/sip-026-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-026/sip-026-sbtc_peg.md b/sips/sip-026/sip-026-sbtc_peg.md index 551bcfd7..42c09c7f 100644 --- a/sips/sip-026/sip-026-sbtc_peg.md +++ b/sips/sip-026/sip-026-sbtc_peg.md @@ -3,7 +3,7 @@ - **SIP Number:** 028 - **Title:** A Decentralized and Programmable Asset Backed 1:1 with BTC - **Consideration:** Technical, Economics -- **Type:** Standard +- **Type:** Informational - **Status:** Draft - **Authors:** - Andre Serrano From 7bd22c571e16ef765158868d1094b78b8b22ee50 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 23 Jul 2024 11:29:25 -0400 Subject: [PATCH 08/66] Update Abstract --- sips/sip-026/sip-026-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-026/sip-026-sbtc_peg.md b/sips/sip-026/sip-026-sbtc_peg.md index 42c09c7f..96ee9c59 100644 --- a/sips/sip-026/sip-026-sbtc_peg.md +++ b/sips/sip-026/sip-026-sbtc_peg.md @@ -20,7 +20,7 @@ sBTC is a SIP-010 token on the Stacks blockchain, backed 1:1 against BTC, and op While Bitcoin on its own cannot be used with smart contracts, sBTC provides a bridge of value from the Bitcoin Blockchain to the Stacks Blockchain to enable users who only own BTC to utilize the capability of smart contracts without switching to a new currency. This SIP aims to describe the high level sBTC system and the criteria for signer selection. -The sBTC Bootstrap phase is part of an iterative release process to simplify implementation and accelerate the sBTC release timeline. The initial phase does not include the complete feature set described in the [original sBTC design documents](https://github.com/stacksgov/sips/blob/e6b3233e76c22cfd6ef02f21add66696b9e4c314/sips/sip-025/sip-025-sbtc.md). This SIP does not attempt to describe the low-level technical details of any subsequent releases, which will be provided in a future SIP addendum. +This first iteration of sBTC is purely at the application layer and does not affect network consensus or operation. This SIP does not attempt to describe the technical details of this or any subsequent sBTC releases; it only seeks to get community approval for the requirements of the sBTC bootstrap signers. ## Introduction From 75dc1fcb8b93899ebe2bf0205d1b3bf8196a1712 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 23 Jul 2024 13:21:34 -0400 Subject: [PATCH 09/66] Update sips/sip-026/sip-026-sbtc_peg.md Co-authored-by: wileyj <2847772+wileyj@users.noreply.github.com> --- sips/sip-026/sip-026-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-026/sip-026-sbtc_peg.md b/sips/sip-026/sip-026-sbtc_peg.md index 96ee9c59..b6530f24 100644 --- a/sips/sip-026/sip-026-sbtc_peg.md +++ b/sips/sip-026/sip-026-sbtc_peg.md @@ -83,7 +83,7 @@ Auxiliary features of the sBTC Bootstrap protocol are described below. ### Responsibilities The sBTC bootstrap signers are responsible for accepting or rejecting all sBTC operations submitted, and for a transaction to be fulfilled at least 70% of the signers need to approve the fulfilling of the transaction; this means that the liveness and reliability of the signers is crucial to the success of the protocol. -While up to 30% of the signers can be down without a user impact to 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. +While up to 30% of the signers can be down without any user impact to 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 the required 70% approval when less than 70% are online. An operation that isn’t approved will become spendable by the user without bridging to the other blockchain after a period of time without Signer interaction. From de90a7170c92470737282ac24831d3b335e21466 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Thu, 29 Aug 2024 17:58:59 -0400 Subject: [PATCH 10/66] Updated Signer criteria --- .gitignore | 2 - sips/.DS_Store | Bin 6148 -> 6148 bytes sips/sip-026/Withdrawal flow.png | Bin 20293 -> 0 bytes sips/sip-026/deposit flow.png | Bin 19060 -> 0 bytes sips/sip-026/sip-026-sbtc_peg.md | 171 ---------------------- sips/{sip-026 => sip-028}/.DS_Store | Bin sips/sip-028/sip-026-sbtc_peg.md | 217 ++++++++++++++++++++++++++++ 7 files changed, 217 insertions(+), 173 deletions(-) delete mode 100644 .gitignore delete mode 100644 sips/sip-026/Withdrawal flow.png delete mode 100644 sips/sip-026/deposit flow.png delete mode 100644 sips/sip-026/sip-026-sbtc_peg.md rename sips/{sip-026 => sip-028}/.DS_Store (100%) create mode 100644 sips/sip-028/sip-026-sbtc_peg.md diff --git a/.gitignore b/.gitignore deleted file mode 100644 index 9bea4330..00000000 --- a/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ - -.DS_Store diff --git a/sips/.DS_Store b/sips/.DS_Store index a46993569697c3ffef1e35b9f8b1ed35bae3a8d0..50e7fd248bd0575ee1e99c892887134d9fb063d0 100644 GIT binary patch delta 14 VcmZoMXffEZfQivy^FpR%Q2-{91iAnK delta 14 VcmZoMXffEZfQiv?^FpR%Q2-{F1iJtL diff --git a/sips/sip-026/Withdrawal flow.png b/sips/sip-026/Withdrawal flow.png deleted file mode 100644 index fe5fe4d48f3b29196743b67da8bcef011be03ae0..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 20293 zcmd43Ra6~K&^C&@ySoN=cXtWyo(%*I?(XgmI|O&wNYKE>31Q;|_u%e&c)$Pq*E%=n z{>;rxclDa7)m`2F)Kk?HtEsMljzWS01qFq!q$sNm1qBU)f`WlUg8isjGqjKUxWRst zR?u=x7=`ce11@&3M9`TlXOmEW(vySjPR)Yda| zOP-#dO?R&rmz460iTCyOXJzNTZ&w=_S&WQ~|NC<_+zh$8x=xMA$E9Xk=uEP)aXy=S z3JMCZE9~f~06#32t_>gfxP+@}>PsnT@JlHDnSvxFrNsD{cl_*(2uZ|d7Vi8J3XQ>0 zoK|%*S#WT0xU#Ya1w*#GyXWR$G13s*)ZCgGti6cv<`tdx#V!AT*qb+vGN6nq$-tSeIZI2{ZImEhFk+k3F5 zzNEvNpMl&s!;Hl5W;UfeW$lpGGi^BxYfM%?Fx(d z7r->}fHYPUkfLff9t9=X86^ozER`b{GtMp^!^oj+%%O3sp{6Mrchm{t3WEB58uu*cEu7A$;57Z;p+s{T-pS5JN{0X zM{&2BNnTIyuBA4#7G%w2P$(J3SwD#D&RO$cIR3!Kx(Uk`ikNMXT#;Re2Xf^*WUhvq zsrJUM;*Abp^7g>dCvAx&B%WlCjk%$}u@5o4lpRz{R~R$SL#v%p@ezltSn~G(er_Eg z%gvJU9DgG1C?@R`C1q+ki7<7K&(&t-yup*B-2fpnNGP(GPHm=rrO_<~|ELP2i*p#!{A0d;_f>~^1tuTMvS8L+t z<=zhNCG_{(@hFO&scKbHNajxqzhD~b&h}Z1^IUyVO+U%rJ=S1Hal(QRS}nzZWPOhR zTA(J@fi>(6m zWMUMe{6#*MdT3EIJr*b*Sb?A3WTgEb9%CU)@0?lfn8< z@zNHt?m^-)D?0_@HzQL`yfTor-Nx}Z5r}zZ_L+g@ttTNZpooB3dgjgfZS`YubK4*7 z&hav%AReP!4Gho|BBuXt5QQ7(7M(}^TMOnTv?eEHO`%Dvx3(-ZJSJ58>%c7yQ0M4T z{wWa?5|$H`tH+?^5L)4?%0|GCi^}$sp1YHjB}ycWRUK0%4orhL#)Oq^O8z`9KWJOe z=r=Au8U&qN<`%vLIW(x9?pfL%r_tjVwEG3^B}AgkPS0Q2wAGgcl|v#FT(t`gBI!^R z;%5LMdVS}mF6Mld>xr-%RFRLB`2(Zzd#h6A(bbllL{y429$G*KmiSPZJ0~|8gD_bx zygu$N0XMJbk}3u&kLVVU;l|Mqvq0j4S;4FkD9ojMC9;F_(#?*d7G1mm7Y5VOBtC4m z`uB%3bvQv!sC?R{!GU|HM5NdR!+rw8YN`?$Czfu;@F2~W|2Hz6tzOQ#uWi_y6nCRj zZ6wBri$}vn^cL7?`AMO(bds(WUs`gZ4W;{)ldI;+?enncYAwv|4*9sSq@;Ml_pyoG zRaw!4h+3*r2)=1R#(OIvrqf?C?343j#RYP$A}LfIH6Vf-t7wqgxC34#gv39pxm@Mx z+(myz8AAvjca?`*npQ!Z_hN_Yh`rndj%fPp30wJG*=)1b+j#JNg~xohJtk+vG_gGx z5aHQH$TkHXPz(grHb*>5yrh9A(}LP)=P#r&2@FFBuFOl;j1=VAKHMxS^Uh3SaU&yj zH6V#e5F6C$386a~h$fQTiozX40{Y}3#9Jd7`|V~A&gJ#|wc`;nTFxjaMQJyt#?V)A zDVYqjh|~N$=czG=hy~Wk&t!&^gt>;R!)Bol!_83svFaDLAB&rWT;b6PkA`2ur&Ogi zd9N*<8;QWuk88PQ;xN$&`Xswl|oGB+B1OvLzuL=B7^* z;ek>CZ(aiNlD6WQ%k-pLPW)+cLeR_ma|V9VOp5fh(zRD<{^{Mo1?|ld9ZNr<=IX*< z09rc+HPO-;W*yzx;y27P?BPhbppoAE3~wG_j0mo>UjeFGDd-uBarl#)9`eN8f$Xyu zDlx!-xQIWX7aXG$>CfZq9tDO*v1CBnCY1Fdn3hbjMgj9AhE7CtwV$A}Ne2r!`U~RC z0VdN5Ij$a0Vvr$L_PF1?NCcdPeTofCpT}?+^2jXqt8rJ0hi>U zjvCzlNF8FMdTBBVd@BC!VXa2X43bwg^aQPp&}1T_IcOtZi=q-P`EO&YFMwazGLb35 z2U(Gdn;xMV-`1Aysp$ZE#7ka=fX-w;%gHJ&YB`5T`fFwkmP!RVhITG88U z)db}*W2Q0I;O=(&H?g!Q{x#HW8+`t<{$t!`1--cR|D4$b4evi&2%-_L&? zT?`qr%S88>l9hzhNKKIB*n^;i5`^raR&pE~_=zQtPLLk{pcJU?1KimaQS_@PTIpBo zXHI-ZdaK@7X$HD|1ACHvuOCh0G>rH#6z+THDlg9C9}M!fkkNzL``Xhs|a{K{A? z9z44l1~(!0=gtG^&!Kun2t>OYPsH+D*QO%PVS)5gMaT9h{BZ}L}DmljZ2j1?d3TtD)IfR2s;i1m?yeL+ottwIOMW$q4WfpZ99)jdmLJ{|y1>2umij%4)RlYcuT}E*3Zb zwN{%SREr@e5>u`IWFS7c{TwfWYl>Z0lNKBx{13M3g@xD7m>iA@&OA5?lgS6?7;Xd>I#1!` zCS|ea=C8c?Ar_#UK)m=|ND1RKV%>=3c*zJL)SU}RiiU5YzN~ig;GM;n1=|)v9Bme; zf2ml(7DthG%3DafPaXj_wa81iEEb&sW#-iqqK3afd?xQ@W>wL^ zL5FJJR75g|`~lzT=@t35>_~w%ek2>5Cg@7=Us!UDb~`LH)-C((Og97`pIw7T~o#gMbVRN4MYCL zVdP|iHXKtAk;>-|6$1b=TkT&$y%7>4zv}*Is*NzqF>lZMr{uy+QJ ze3vW9h4HO-$>;yB81)zOb!D}B2ATwphP7=?a=ZV$pW&kT(^3JV-HMLWiuxw}OIgfN zHUx=deXTb}(fz-UsDL=Y6kO}QjqZ+ALw}rtDw-u5UYNcy&?iOuRah0x@&S;#Hv`l@bjEl6e}tPduuc&mukE9 zU)E59lmo8FyIl%slK7L?-cZ#A=NLQcMw|r#RDXfydqjY|_4~TmewNp#_;zZEV~Y?3 z+dRvbwttdT-~D27d0~`paTgP*l##gsBn}s~h(T&`COGC~tF-x4UD%RTG&m|eywrH7 zVW3mIhd%@+Z0=;G;cK-;!y?8bpnN5qp090x*iLl_8cK58234?vz>fV3R3|Pu$dbr1 zW1!Qpg%pD-%O%50a1HWtjiB&! zOHlaze$3gqMmD_D-4p(AGVIp9WG@6tPyDBwJ`&r1RVLJ+nr6_+gZ?#H(fHNikC;B# zQzD%l%DdRtmeK@?^7o^I`rxvzf-){;VU*M$A%fJSwA`#J59E4cvEf7V^16R;I~Rix zxw8AiGxN~><=Ap5coK)Ha~IZz*ms*W8!;hb_jw19ZY%1CEEmozDU#O z9mDG?KZDIccoc}F7l{ZeX2>Ax#4VrA_-t#_5Jn*}mw?!7TEO0n`%h8z@r~QzbPn_+ zQFt~QM-CfECD;MOB$i0Ovoh`sQ?L*SiO`aL0NO;mlDeVw5pBbcG001FZ;fBbGy1+j z^R8dsy_lhzgxE2J*<3L!nF<$3elvto%T!hRj2T^J^h9u1jT{mM`Xo84Iu?1aJ}x)I zE7&V(HX}1bxENXBGdjxFJs+LbCRId56zx{@lu$aYuX>6HlBE6%#rsKC{8L%%#NnK= zO8oY)B4w#N$H06&6Jn);8!2^?OrPkrUyPk=NGZDl!5U8pPa+XL|A%Y$1!6Gi{g*RU zw6C<2T!vG}tj3~ryU}PU<0UD??FiO)tQ}5cdopT~%QZX`jTOl_TLFE8naFGeRZYB~ zfNaVOZGv;At%j{&29FO>99bT*kJRT8Smvae31m{wPILu(Msg)q*6Z)@QV<%!5~CEl z2JDtfOeuJyx;GcHJ#H>>U;<-psc{7p3A=FIY3OVd=9_oMinvv z8b`ZemU1KX!Bww6+zPSGyV;OLEuibiz=Rl7^tZ@^cSRDzigO}mS+M}4>^Xk{IO0wB zKQxR`K|OeUOIVUi7WPOr-KSmt_>R^8P7GH(X}!%G*KTq!CR9e@0NUWyJ_nY!-!si} zxR9BFf-pNMH7RTMK{EM{PN`OkJaR3n^Nt0u(mfJWCtRK+3U`B_U<|220rW~X97&{N zuDo6j87G{hE^G1_x2)^KkGRUe8ToU5C|~;fpX~NC-w^Va0K5rNC=f;cZ$Rc$oN;>k z%=kIHyzy>9q>gbw<`Dm~MQM0E-rT<=w^rB4zDmr$jQrjFIoV&4|YyTdqj5s(P7Z z{wzH`VaX+vqs_E{VO0Q7TU@%dqp07~ZFp?5ABVgmc)B8#NRB}44TiU{1|dV&*43!Z z*3z8tGn4|dXL3*&LBCh`Ts|(6EEGxZt~~*255-B+%}mHyX49WJs~UpQ;C%{T{1rsN z5jF`C9G*U0US$~H4I1GBy;e*YcQNF&@N%W^~IJ2C{>?j0+ zQ5==)?jND+($=JA4|-zIV{7%&x?1St8D9V}lGlRu{Fy3c^_gX@Gt34<<%`Eb&?K-! z`k6e+%$XiFNnKjG`S4KZ_`EJk7VgRjiA`vQ$7y@R%3HF8j5+x!d(>eP&AiEbkAWk~ zz)&$hKFR%R4pz2s`I$~Dm@}?jC)jO#SXMUbB96%6v|a(PsjG{{wdGyiWjpctwjU_S zkCRbSt2_QGxYhIh`R}`PDMTANTl);*2m-P42!u~`(iJ1&f2mYD6OdY%2&!8+Bwe zj8G;MBO(|fX&A)2djVyt`L^o~bSQBawh$&Da|D8ZxW82ITlOIy^4C~d$OaM?@6e?P5`X8OhYXqfnmqj;X?v` zY2j*&ZjJMYb4eMSpYkI%Y@5ySDDu13xCx&sB`tsOsoB>MVAzu6$543D!lJNKhTB(} zeOCScTWo;86i0d$8<_~LiP}q)y5@T>In#&_X})$yyU|R5wF70AeRO7XF0pJ%r#O&_ z$+Qw3zW-gY@W8Fxci^+U{4G{SfdjS@=68OZwJPLSUP~J%8JoZ!CdceM0h!%KWXQh)EuLDZ-7mr~g4GM!WKKhd&wHmY;&U5NSt z9545HsyAGghcgatsB-Suxo_LHT{u3bXDt|@xUTBx@wZZ8;qYXvM80|Pw^zE(Go29E zH>Ll!-v_e1zlRYFp~E8NSG71SfWoL1H?VRAcBkh2nT_2JQrPgd1DI2ofrI{nYm5HG zFfwYk$uN-&wTc(Ga}j&ri}OT?l&a3>0s(|6GI_yCI+FazKqW!}mwA|0@$pfwF z)5;>9O$$O6FBt*INx?nEh97Q`muAJYz0Fa9E|c~#cE!H3Smu8=^WwG`0APxc7q=w0 zx~g;37Cn5AUdt0UyH)OuGi!u*<{#o(-C(oP=Xsh~HV+*B!^U##Fmtu!OrK>N=Uv(#wv~aRQwncRc12k@A~Th?RK5hj_Emm<(k`G<-;ZIjR2hQ;bf z%v(1@g`0knloKJ3bdsMaJ7=(>;j_cz_^jyiJMQ+ z2Z@<#TmuTPfj$MZ zS|(yYzGCGuJ3OVhm_5KxHkG5>CoAQjgvM4SPFtP z;C~40#T(GKAeH`KC)PLO^8PO<`(GJSH9{VN^*$svjQ zn!ff21cM11=$j$|yLUa=axUFdcD&3t zz&|a4q%J}cLyS{aD~InyW+z{TKrNLC;ZUak=ZO@t|HdlP=tGS2NeZj5PVOed9q=!O zLP3kZ?N2AvJ>xjAP-bV(f(or#2xOcdkQJ55!5r_q2E6=VG6~ zx_5u!uU?7fr(VO;jmP=2`fF1(j}(moL31V%Sz#Iv?%mym z8{yv93i=1>%&E+d!{-Soy?J{M-VS7pPdw_wm5B5Op;-kd^WB$%2ZpVyGjHKRb*iLO zb~e=2hPlM)x><_kPO4c4K)Z|V+|XRNy~+Kc?G*ozyS|DKI^|QeSNJ$^t;8A2=%*I| zz&e{gCeJugjn$v;E?}(sxxv$%oa?OTk<4okRovIzYmExjf0=5OTPsHRmEn-YL(!7; zf#t_>j-GNu(o)L&pjn`v@P~o>ABhBIea{CGo6R zoDo%8>C11`QZcB)UI01ti*?F-Z~u&ar+)h!FlgBL`VH65T`B z=ptU2x(I0rh^G`U#D>2P153?N4Orzm45EcHBi?W>UOAPj`OYOtJ5`jW$s;d*nF+Uy zKt7_(V;fxMPw$-2Y06t#y_UX(5hwkn9>~`=;_7_Xo}?yc0{{Ne%NYjz*f! zYsAKFwi$Z5REpJUmDO$j5YN-&kF@x5$X_jr1zWuE*GMGG5IvqN?o(7@{Trk`93E1L z@Z2oGPn#j}KHbA2xwq=ij30?i_L$Y#E-c^Yam{oV8LK#A7VBmZL)~nr+0U)GWpwG9 zH;-PLFyC0`MTj$Y9y_KwW2YoVa0O{Z*0DIy^BmBw_=;#W5mN#dTQI}ysJ?Pw>_!4lC&HQ@1 z=v#AfgH$zpT%m?;)WiJJ#Pn2HnL7ETfJ3`88&R?*-O#`md3mouYMv z1GRjSKs%#MUOJ@vm{dX;xokGJx4f+4jjz1j>U6xSM!YBG7$0M#s?g3%woS?X*Q;N^N)u5UNt>3%%b0>PI?sW2xvqnig ziTHe0ETjxx3VL{V)!f?q^0rB@bOb|MWb^J1nTZ`Aj;mkfU+tKyQTJPwUBB_$d?%s@ zW#P3~O<&2I8v)Zor)vgEP$2y73Jirg>Dr0=L_QNbBJ}VjnJV&Z$7?1Cg1eQW7O!AF zbI8oYAg6DUCta379xj9PK{YxvHW_XRgFMY;fJ}>%UJIPDn(tCuR*oHw2QTL=!c-S} zDK++cUIe>~zN=MG(6BiORFaR;NbJu`Z&9{yT`z*4q0PIW)x^!^usST@x0A*Rbkj2< zmT&)Om_Ttq+-fnv+`Ed7Pylr0YcRUvEVZ`e9+iL21}`U|irH=kFTwhceRM=SAATcr zo{fuu(~4x;@s8{@uHKc5fPH7}Kjgfw`BhCtARo-HFP3A-Cq3kiX9SY|?B@?{xI%U| zUBPztosr!nOPa*9Er$s^NW9Gj@Y;fyNkj@QTvV136jX|+mE3<Vb-i_onHA@Ne3ozXpF)> z0%@jp4`=a~N{l=}@P1V8*q-%x8OHsuy!HjTtC#WE;3lpU5DUR|X!6gx#;-?YMaXZ^ zL9@)vGg{Y6IWj~TdNqm3BXFC>_l^$qFqlAcp#^DQ6C;GTDBDbuhfZylZlN7I z`fxc@9fge=k|OVQ3703e-boA^um|*gu_skM+c!9&ShK!>OS~S#woa0??!0Kr>g?tU z(-A9X_H|XVjyuG70Zi;mh1tGus ziueP2rZ{ewH^aNGTwDI*`rdfl8Ynr z$zb1PC;uWf0X05kwrcu4`HSE)(Q?i~m9m!KXUB&Q2X|qt={DdGzBU{c80-u>>CfD; zLx1I^Zhy^LXbkOB=fY}P`N_ig<|W3_O4V9D*M34tBUhAM@k$wvGI*{zNCkG1s}jV` zsqj<+77ys7h>BO?tthja==?{=C1Jsu&5lHj!|pVnS5=3R-3sEcX7FGSJ^!XK(#P1_ zfRF6%v(g;VT6y32xMoLe^BDQ_)s6vqE+vPpm@;`BI`w4;!{~%ZW1EY-6K=5WlG_23 zQKQYFq?)Jd7MSM-R@>!g*mqETD+iLqh!B*NPt*(tNFS`3!;b9ed%jchRG*15^vHb~ zFy?oc0A;{an0Om6rG_0!u1U~m`XS3~-lS9-ZT(JRT7hhh_AuZ5`%F95BHKq$*l(3T zLFYtRN)$&Ejq$VQyUPz4dZdjD; zf;zP2LY@j4-C;K_99IWNEP{Iv#DJfkTgSG*?M9Eji&(Xrq;-Y?IIq!d4XCYGE*TT* zSXY>UOtZ;ozipkIEtKfMKUa)mKPGy`4YLl%uknu*3#@*stOqqXM(OkYGoBnyyL*NH z?Y&$)JjeP3>l?%tF)F7}M2(cNb=YBrGz?d9ZNX&q$PApJo3)m;5}fW^DfXKA*`xN> zbMkqOk+(ie&vauHtl8R_CmiiJ=cCH1#(8s@P(?gvP~=%*{gS~;RV_=S_u&rQsI#3? zo@otYt((z$W_>~od;gm?1QAq77F9Xc^EC?iVa_GbU_wD0T@ zQDZ9rlt{nkLAmb=59z&FwR@;H%y|+mc_A{2^$=xpCqBZ^{PqjFpi9SAu{FFlU0uJp zBs0~8t%Z?YBFZi*(|X$0!QLN1_HbG1Vj=VEDdl8uH~G>z5?`1%J+-5cL&f)?kT(=o zwf6zokQQ$z-K&bqz8M;t(qN6l9~@ssD2JjUn{APiwJ+PIbE`CSysEfBr}S=bLj_r5 zj|7@x@cYS-{N2Pa@j&!ckELfF7K@%y56!F8o;Pk@rj@D_zE}L@Sq(h3C@f7}2iOK3 zzC4?3&9k)Fid*E&z@h`Vd3ov`OuL<%%CD#J&2X@6pNbc#dZC;QpR`4vxp-wFmRqXr zKiN|f=**(G^K&Sr5%w2LhoMc*UGTS3=!X4Zhl_0lM=tZa$Y@gx$j5>xuFK)(ucVRe zbsN^KyKz{horaCKiIrl4*2L>%!YYJ53(S7v!%bU2}u+F3(t z={|lea=`^K$HFBH4jTJ3Y?rHa@;c#6rt7h1HBcwsyO!cu3PhHpd?zA?n(q%~?0_@s zkD+rd42=mj|H2a03!tdI`kpnM(ux@dt)TIxAZ%P$bVoVHBiGF|n1=w&Ex9#g#+{;7 z+L5MTzGHUu$V8hb)r?$0s={9DCKkHIQ2AR8an;ADOuaVZvI~8`q7x%2$kscm9(DC%1kC|PKr8oVM(}_g#_nih0$0= zSvG`$ukOBS)Fs6RyIyFT9mRcfR#VrcBmyC8=+z) z(+#{=n1A(uTCeW5r%F%xROvvC$F)fp!Z+EFGpuKgIyf^o`b-t_Vyl8HLSNbGMRLeU z>lDaJY5+BDJ!8&)If4k_X-1>K*8rSr8X&{Ybjhb>#rVr2_^#+S7aie3f>vfmIVslh zU!1UD5W%{-_VM$yyo>kRfPGRx(L@bX!k!{vNpn|S8`pGHxzy0k{z*k8KeUY84%0@lxh%z2w!{{d#Ce;` zkVZpdiz2xF9|`Lub$=1FubPtD1SnAQ2#OgL_V=%_e~}t)Ke;@4)+rW%sFo$XoJ7$! zwv67`zd<;On7b+ z<2^Tv#43uYuusR^IMSxsVy{SSrWmkcvdZVoaCs+*Rm3@lI^X%l)zt8hTC^JbzS?6v zaLn`IPhx5zt?(=|Lhi>a-G{(bD80Z~#rhZ#;mn&8Ld!(;-tubCSr+ zv%i%$t9u*%1|bIFh2gzv<;q8j^LIA=9v#h*z9FI^leD2$jqHGXYh?7RoY2b3xpQ>> z#ih!K<^K^{V<>NxMHsffsYF%GVJEH^xedc|Fq~Z`!gz}g>QYrHRY0z`S&4}BGZIcz zH!6Q*iYE$O+Oxg2U3dPDfh-GybgV{)rzi`Eaz#2E2rV4dMkS|f;)lw#;2}e_rBDv5 z8!M0eXUlflSj}D#I_5B_q;TC4IqNW}qY>$CQajHSVca zcQ-ql^kmkL#8KI%pvobv*^6mi2h-HH{D=5_ks5v&I+gOcAijfT1WS#w-LkJ<$PDUT zmA$a*&w6F~oOHs`Io`pE#aZ!L)`ue+A622ZvxwI|F%lIA{+X5g>0WT5SkvPN+Iiof zZ0fuqWTPnt@V_1r1)ClOdYk<;r(Bwqdf&5;cNxEdw6==9ZL?P2U(+2#_a*eXaK7QM zp@Wh=;Ok!czP~6za69Gyb2}jT(p|;er!s4dpb!2iu+A|eEBnK1N&Js21+x5CsOVk5 z|1bXc;i$+1d~>~|Km3$-5blT9lHl29|E~c%kG81uC>?TfTQ{WRT;z1QCv~AE^IYr@ z{FGE2QC@PE$>u+NqmD-X7&X3f;hXWMTUi23ml&Hxg_}>&CoxI2p)8!XW&x};HYmXe z_qDN-n$#E47_X5I;s#vjY=m}lv<(lnNi{lX9i-`z2IJWVA8R0xjyAfM zvhf)9c-X0Jn|Ok1)z6hAe5Qgf^p6^R@vNzeGQRpY z%a4eC5Tx?>Y*lf(w>I^=rsMf0vSp~kNgLtAKXC7PJaY5Vp)hq%waHqTr_u0TI(gG4 zPkkjiF##^OqIE|@C?_gM;y|(3pQQ%xhTa&b`jmn%JZoYg|2a0P6`c(adJO~)yS+DW z0Uq7SESTz`-A^OoD~`s!^Z>4)7T_mM6MjT-Tj2P}hHN(RCoU->GaCN72`E>HPYqLTQI;hm~ge`QtFofq;dCo-u{L-JqzJBu9WPbFs)Nd$g9 z=``9+vYVDUAe{-fDlw+!KN8u#+P5nU)!n zoY`_lnTrE}#vg4FcLE0Qo4cJo@rOrJ+^1s*o77J4-RQ54e~&Aj%m8!3TU5+$ljIM+PHI%5-MM1GD?i{+kSFC)a-^sk^6o??0=LvAL-(L8+D zXnE`D5Trc5P5v@pG?iXa4Ucp453lX5?TQ$V^*$v($ID|K_P*&p6Zt^nPes-v{*mQ7 z`K0%k5Ow+oF@X8ReYlPg=rgjJ49mh+@DeA{~_Bhqb{KtR-Md%inhBV3P6u13$1oMT2! z?t2BH757Lo=7?If&Y?=r!^Njd?B#%71GLg0F*%T*>TLJund|Qfb9IbUoiKe!6!yxFPEFq+`LMHH6mt_%Y02*10KcaU0OF zOb)E0jK8&n1clIYMWGBkcSKpQfZsad8HvSNqq=VW^nU}z4*els)10ljPY$|YhhF(G zj81C&odc z2cafAHR%Q$w0m7vzI6-?ZM|5MCmzuTYyAe2->#+ftr=OnAbPipnG?p-h7hpES$HP1 z^lg|we%nNded>4cZd9WTpAERUsNP6kko(X-9x5c=E3vfflmIL=Nczh6LU1I4Hb!}b zN?C9~6GR2scWT_R#5h&j0P)6f9XYuIh(Xa>ApbCg%favS)%Vo(tZjrff~e0WH%BA! zh97biakzhWrJ4gHfg;UKCMkdIh{>=db#Fm0$8?P7 z)!?_sE8OSE_?Mo;)5QDqkk$=t(ZbPyEjn@(>e_OoYh;`(<_78%LiE1+cHL=`+1f4x z;9?2;JH_CVvyF@{AYs*DQQ@eUx&^DVM8({;qVu>wv_UV6{4PFOP7R3r{X?xwmVKRW z$TQX%=Avd*UV~9k&6*2-ya?KRi4JVgF*P0OpRJ-Vwwue>N@^Bd_xcuonilxRfr3G2 zQYXa=s|%X#XP7`LW0^e?t3P)n=>hUAE*QWgt6Qjlet-reArNC=JMl3v5P-p&WQ3XA z^Re7Kkc7zErNhJ!{1t|ohLR4G}ay*~9zkS6p~*7xYXntR_7X3B_UZWcr0 zPH+7#lLPx|$d;?%iajQ~ow2(M+yNChyM-m@v+oF?MXx9Fnn_@x@`W{EXnsTp?RkVL zXps`%`}Nipo-dAn@SzU#3DS$1Xvr>oJ(VeAEVeeYeZ06c5f8hpId67i<}AwKAooL! z+y6K*?mEb^-N#^)f392sOvv2FvuYuOKt<_Hq07QW|L8tfPfB8cM%21OOO=L!72^GO zGhB<`jA{ktwnMAyp)m(+R_Wc^Qb@a$f7{X;y`FSJ9SsY@rf6F^wL(DWPgV6cbUux4 z2V=b<*F~X8aW?-gAo3ePlEz@0XCf$Fa7et|fl-j^Ga$Ru*8)`&5{7crQ^bjI#6A6p z6i3>pP0R7{YWt^kf_Y5q61gK}pU#Rw%Vo4l@Zn~|f|#(LLq1Gz024KsXsE`^jW_uc zLK=u~^i6)jW>KZ}lL9*4aC6QKj`&PxZ3Y9`+Huk2Sr0^4rUslCcrpU^!seJ+ShExj zSRE?$TJ;MsXr<7LAF%>ewr}omQn2k0jXZX)kCcwIc96nf-&yNXBkrC?he(1?=ftG1 z7y;{G8nZ>}5#h7;mFvw3i0oAW=N{h&{&Gx~#D%Xvnb>0(ASE8Na@}9KuT`mceR2Zq zvM)Xd6$-X#Irav@$xyACVqS}1dNq2s=QmI+uG3z+g_MX>rtPn9kD4baCjWxeP&V63 z$oS{9A2pQ7m2Q{z1z{1|Fb!k_onrlW?MO-PJ*Xr1VR;*L2;d7*8?8#dZS<8YZ^4Hb zooCy_Ef*L}e9D`G4O!559zH77C6k2XO8ECJ_%^4UiGT+{o6KAI8+!Sy1~NDj-P!J} z;QH%~4YWP3Ev~I!G(Mq?9LLYnhyj5KC4DY)ZyDr5y7v=%0@DW9<^_xiLG`-WgV9JL zg28^I4YB$vKq)mxY&Ne;ELAvGbO~wJ_wkwTc8K=9;0q#1IP{Jx4R87&G1|=XkrsWI zAs0JFJ{;LV4}tAw7&b$CM>KpHl8%}DQpNtWjqbj9wNyeG$To<5XkJ5ElDLmWu)T$G zcEMgG(YBdM6*7PpQvZZSjL;=QOK;bX&UN*9Exxexuxx135QX zp~){2^pL~RU};<7G|1Xh0#Fk1BH6GJ16}4|-lNBUu~Z^L?MKT&)`y_j3>J;Guxei# zvg~o`(eEcrE1MG!l{x{hwJM%pGSbvVzHy)$1yLHg!QFyDVGA^#ttVntfr$k6iC+b1 zk};*%LeQeR%++SlWs9J)Xn_2>=urnRpry|nW!H)_InWJlhmUa0MTNT)KU zd*EJ)*)4ZttPphq2BFya9niVkicshhkz6nY}-okx3`+F{@p+7doqK` zWzUUhzJ074FP@94&#x`K|84efB+G~&VQ%FM$`bsI_Nn3%w&y=e|1B;rh=49rl3(Mi0h7rSCQy@sZxuYmp{Oj?&#T?l(av{3WC36JhyVq;9f@px~ z@WZWVUyu*nCDA_REWxaBzokVm#;J-hA;`)R-P88!WW#mZC}DryFM<#}pNA$&ULOU1 zvv!;|YF`1*SHmAtP4U^Ync;cYymgxX1_mm8X#w4VOicz;1lQ~IPv^UDIg|C`eftEj z{>AIg1(U`3ESdS%wQi8eb@{QF&98i$`L&ui^$oBw^H{Pa*V8vVq_t|+5C<0bHEJ|- z+45ppnx_naK{qolwQB0~JHR|X7W$F6OxxI=)#pD743zoDGP_VS0{913xr9P*P%>X~ zjd`f#UHUW=!ma> z`5nn_vA&^u$nUH{;d*Pw;q8%VzC~)*|De-Gr>{L`hZxAFcN%>cCyFc)z*MhC8*@l0 zU!&zFP>e|k_KP2Utn=-gH$#uF)4jvnlJOTaZ|`rZH@@9^;)V=&Y%4C(vB_>2H*F@c z(KOU78nQhBi`0X3MT6+hTLOo6pl`P=DT+Cg_ur{MQl|{xszL32?e+KX7A$>~&5{QXW+_W((H`>NZzdkBkxW9CZH&-Vv$?<7;Smoi65 zndPrpm1=|qIuT`*=eP;Nq?K8H9@o(SH{T{4)_ctx5fg zh*KdDu3yw}mlv2iYFjzB)Xun#WTM6ByKp7-W&JEfr{lTax+?%>a(a_$Me7lbWDr=M z+6aZN3bMrgQ*Ech8anL2uaTtV8&Xb>Gq$EgB{A!Us(BdF{w|Ys2WDO`F1cjC!vX6X zZg8eijhSRav|@>K?)cqw$%H$g<J}JSnzj}E*As%Mdp*WQ8gfPWKTrU#76?q`~fgX&X341v=C6BImDJm_(L?B%6A^wmGQ5QH;IL%tVI-a*Z9krT~$DX=WSsTkPi*%$TeJ&#l|~jQMzMf z6UNjvxfaU#Gpr9Z9Ag>+wM0aGZFRH1K>QXaB=3_XtcPf^$Ah{x=4BKyLwWW^HAgBf zj|whI;v8cT)agl9R_x$jQE$FFWba@s&*@Ae3}8$N0L_4r@O-OYCTwY}G3>E! z0+So9Af5vhAbDQxj2+9JFYZLSi_cZ4M6cbL&zr4?eqPpB+v5DbX3)#^!arKnuUVA& zy4|Q6=!+ku-%PMG=bPAGmY1?V(y1TYWTn}eN%0{H&@{Fz5Nl_WUC0s4_`&b#TiSOf zV4b}wFGwunOS5?N&gVUeK$I&*cwV^p>^j_Yw<@{0xb0N!9yf<~d&Jpg@N<>l&5VL} zmZL~7>L2Q^-n>f;0mE86c2FEyQi*JIdOzJU`BZEk^7?j}Fsb9e!$m~IKdaist~!z~ z%}VZ_2Sjd!wpCHlO?5bY8;*q01=|`jO;{NY@8K+GV71DwxmDGc^mlkXR*B_c5hr=c zxpNu?9h1IjQ+=Q1+dZ6*`*R!7Y`#Mjmrt^ZDFh@&F^;@q$r|7s&>?#1=cVkV(WzJJ zy_h7pFb^%)?;_KeTRZX?MhbJD+Y~>H>eo^hlHKFZaP@1C#!G?*1?ymz)GKcEKA49h zL}soIWnRGup1dwuF8eybujZGs(`feRH&Xw30?m^m8JAWnfAtWm-uH)%N)rqAjc%cO?POn~Njo^vy zC{HxH{_i3Expx}SbFk){>USpjO71y6P;i2qZHJ?2DnZ~)52G?We4XP+$IomiC=9g! z{tMs{P&)gl*FMc*A0mI4;j>sevXx7jA(1|;#)Tvs0Bi}Y?la_m_}toaEzT6oz(p+? z-|K1LSN7oOh!C7}V6IR!dbw-!>y?FQ={htE+hAF@RucPTMHf|*v*Wct7w`PpbvF{b zp|&sLmw7R1S$dzoV9v-JND{L^iMHe0Fja!DP!kl~yA1vRlycqgY_M(HeqxW7T1o7x z)zY9vD)tPm8WmfMs2Z(NvxqHrDdM$9sW)b7R*C2nH7d5+Vmw9_t=Q$u^Bu?c7ks~7 z$93O7Ue|e^_j%qR4Vll~?d00_JcG5bwUk6TI0b`v35g8MI+^?#bhXQCFAMp`S_Xy& zhN*PL>i0$^5K^=R5}cvJ-@az)mM0i|k_AmOKBy33ZPvhEw}0`4u+ji-y^AE8_M52P z^gjp=Py}@iuAgR4vw3sD>qUdYnX&f->k|Al6FL_{M<2lEq6r1{E;eEOSj3kgFTmEy zYI22r`Zi&doWWl*iKeu)*3si!)#0?aZV(&_VYRpWQ+&`aod6Qw4&Ol?A&}KVA&3+0 zuoFDs6|chGg)ZEA4Al{G@lB0+v~awy_5@g(S-BWbv4#jH*IIY(VY?;?-+sr>_)fpa z8oYeqgx;aDC&!>iXqeD&%!-ELdtbX#)+lSI4B(q?s#tIk{*i_6OV9*3^iOC%gEnf3mme9xFhJA_pQ z!AjDG-@wUs>B~W1E0IX^5z^V8Go6={=F{(hZg{$EPc&s#hzGfgw7F?iLi1~SpU#j5 z129YHf|ttk?c}tIpy%rT(QCTs(ZPf@!iTVq^C4RuPd)RQ&Xci}54V3>Aa_FDtGgLe z>nPvE@M`7{V!(W<<|GTTFUl}_O$r110A&Bg?oFg8WaaI5%Z)$RXUU8Z>8tIXfH=J- zdj?xNWuHty1(fsRP0J6pr28Vibl%+c2=pcm_5@9m77$4FvS`!O^a^>?f}>nCKI!u< zrA@F7k5x$liT3ehMb>p1-u%TLHF3jH-NCRKzLAYxrHJc-V_C1;mX}yXB0r{)tRwc5 za-*j7%vS1&9o?3t&WK?!lxANz@dt{61Tf}a@yz;73o_M;*-lJ=TMR}+aewbxGc1>J zNAq>XPNDi92}08@c-I(M%s^t5srSFNlLH}fH)q|C!r;05y*g&8n3m`{WzZAgCu50@{ zTaS7B1ru&3j3M3o0?F4gG6%ZSy`m?bQ0W2Ht44hdl5G25XPU8J9O>uC80fR=?xwu< zd1>Y8wCcR`gvMUXFY5Y8cxSEMNkpg3-LD~1sN<$v8>xwdNa+S2OcOR7pKroPE=n$V z|2_6H)C$liJ9heiJz^X6;IzmZU#CCRTWcy8K3&q|{)_!Hfw^~kEK;5~aws>Fa#UXN zFXm%SRaG_+zgx)a^uowp-Ko)PQPO|9?S&R}$W`2Jj^k}j_cz6aAZ_2$_98BpH!&mc zq{vPePW@Hk5r05FjV|3P@X!0?#HYrKK7#Qpl8iST#YXP@&=&10Op9JPX0@S8s+;VP z2aqR0_1=;oDsr=2u0-8B_>jFAVna`eO062WQ4y0#gF~%l4NHl<{@P^aL;J%}tyfv{ zUS6xZ#-LgzYb0xYi${o3tI8mzaCsMH)Lt2JLr{oGDxZLL7F4NKPA!RM@tNqEp%4F4Gb)VSOzlc-EG>)o&_z7=M@(#qkU zN!=PZa%GVlm}3zC9FaQ2g`b?|@O^5~{IbK?oC&UdCByP>zI55)aB~*8HYW$Wi|3n( zh0(uvmvnzm%N^@c%UiIn{H*glK*`h*5aNh6q&f=tj?y^e_{V}555D3KKXpw`K--AM z@5L?0;$ABuInJi-F;skEysr={Q8%iu024>+(-a1L;cR(Z&GZw1Dyb1W2*X4*^P?EV z7{{lTOm=<%(}%5xMrF1TbXD@fOl=0V5AwH`mu{TCX}K$r|HD8MECYnxXIsEAHA<*!(*)~jX7YIR z@RHC%By`5F7|(1J3#mG)L}*l!(|u0~C>&8@BmtNf@!kE`hNTA%vUg^zyFDa35IH-r z1St7%w71Y*0Y=OoBBV+~O7GT39o&Kx{UKd{W2=e7ZA9kngkJcje@Kt?lQ*FJ8hui{ z(+&H588P%r_-(m8XqG5BqM3E6@x|#0=4wyLBP5>6bW!D4 zn(#9mAXZ#?_nByjk%^FvS8|bddA3{5P|R3P?zI_HS_QupNLSyw*4cknD=fFO+ReboY9f0ZN~e{sCkla7_VZ)G zo^$M*v;CgOmh z*#v=+>j8Hgmt=la+ssds61FMK3gI#VqJ_flTI`mSne{Y~)3WAdNg{Jk$wgsfN^bn$ zEZm-p09p1VRrTn>rZK*^yG&c=t8cvljw1(xe<2Zn%{5p>_2uDE)T|8~d#ekQarj!- zx5dSxi+p-YToIkKYGoR-Oo{Y^fwJwf6=MF z@*oS@;B3yEZ79=b5KFRtSX@%0|J!Z)xAnx)YzrZQOpEZBa8 zGFns}oHN~e$Ki%}TC4TRMQW_n)ITH#hE_sa+?8-p1hC1SDB(<|#; zyT73A$}U68!Y?ox%_{J2F{TUoXYak`$!73QW>TLxgk6sPmB`OV|6ZtLQ_&Gv%Hi_%Z-~>U zSHP1vR7@~q3ztnao^nL+FiP1r03F^zK7=>vu`sIZ)a}062W$}%0VbZ?w+~2hq-i^ zT0Izn@QWa@58xLxrLS~MWJ~=Im5U#nZe4=2uSzQ)@$qDLgH(>Mb{7;`dSP6!QEl&R z817-F?&Dxu{J=SQNF`B8KSo{i(#Bjgyd`tNbg4ritUSCIxwLp^u|7A!bbEsnG?4x> zxBGDQH9fD+zB9YAzouiLCm%#8T85kR?^>ujbQ)IdZW!@3@?P@|>;Rf{i$~%H8pxk2 zRIOhQf3VxS!k^bo8XOl^ttFW3LHNpP1=#zMFnxL@!Hm(U6sBhok^fg|lfy2QCvn8` TC!G3u9F38lnQoo7GwOc;OC$b# diff --git a/sips/sip-026/deposit flow.png b/sips/sip-026/deposit flow.png deleted file mode 100644 index e4fa79045afd00a8fba91c59c96cd52941e39560..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 19060 zcmc$`Rd5_l5GE)b+46{K#9%SYVrFJ$mMmtrn8speW@cuvn3UA%@3ysf+}+#H%`2#{Zx)wRpO~0jUE6$KE}-XxHQ$3Lv>q^PUzT6qtTL!Mn^4%Ug|Mr~`0)`-^p!sI$ZJ}?c zsJMKjZ4m;F<74OZE2ZetN@l^v^5QP(+CV*1wzErg%dUf&hGkO!IdRaze{;LZ+Tuya9=z7*A6$+$o4W^d8Nd!POLRvSSvd z!4|tlDHoIdva2Z9%rIT)4#-VUdL|W3R)k}7mlsT>`miuH34jkn8+(-9{xU z@849~P-+jAIj>s`ye4lFNfuqAmR2k3n>khL#pv#nY%+iC4(OwfE#k5nQIhg^n#Gp8 zDtQX23#7@}53%pT(w9?Y1k4qxAUYPv7N^uPfg@~RH-G+y>`Dsl7RS~`5_hv1kRdSG z-r-n8_X#%%#e9?Sq|(eHHl>~EWu@C|q4F=XZnqjs8~6nppTL3xS`VSy_{;U7#OYuo zcJnX*Jmcg7W0Q-Us3p?C@)kkK3(K@Jx%;S-vV`3* zDvz|Ft;)hX3!Eqmiu+P2D;xvl)=MkkVnTCq+NvN_us1k}?>=~IuqUlfBoYka0vh6cnmn>68XwFXp*Sn)k3A3=rA~F?FD7fd<_tetd zI-|0gsu$=PPOD6Ee-%GdU{zT$R7VT@iP0~$suG0x#UQ5*7nnfP9{<&gxF@DJv6{oh zJb~JhI*#LDcyM!uSPQ~4P~c1cS?vK)PULc!NF%Zd5LfnuR!VBdkuq3`qj3@j3cc1s z8Z++5RQ&Gs3G6KwGtfof9o@c)`#2P|_Cu52Hf^y$%?_F!pr>o$d1WaScwBxqYx%0u z0S&Aumo6)FMPk%wIMCp+adkeExF874O&@n3)B>0Z)>1KWyn@ttAZC#E$SRr5{dsh zBtMp6)fR8@>#r5t2I9J%-^*9Ufy@FOS;uR238N`;lAGXKHwR_{oC;;BfKwvbV&$O? zF0zJN03J`y!?HxiHX3@Yx2a6L) z9eNP)Xoj3>_36oZ(Q1tX?Di5@4_2?o4jzLRYO!&SrbTKTrM;{MPc~%s`_mj*f7yK; z9%ksiU4(Cnb4X$fMdW>vyehE#k@&D>^Y+)C0mso3A!xry{Ng?@9RF&pcSqBm%6HZ6 z6B1lM7S7=AC4cc{M1u;0JCXT|!E)M0@Ad#^)SFZQQ-hltQ1|$Y@sK?rSLA|r=vgVi zUywTceyQwFE#LFE+^|$MIO^yG1B0id|LrvW3{V`tZJ`0)$l$j6AUhhdws?_7d<7DN$rR{N=kdoF z+Bd>0Oz?@p#|0>Iv8-M7Ve$+m3{gScj|>CMWmORDLDmvBN9ZQ^ANnT{F$OIn4}$gM zr*WW&mwE+!Tr~~{CZ}=ahI+gdyq-oJQhWV4DY3Nr46O~)ynjrZB%-!1R6Y(`i*sLN z?%CKlAColz_Sp=pwZO#Lw-MQX;pcU)sl!U4c>8X6LRRjE2#qL%)3mWBG=vm8`dzS9 zWK#`1_pvLOy(aZ0;Wuu5xN^tpZ!ikBn76OLB9FdKNKeMeG!1M!cMQ0v+H0|Cucb?y zBU~9D$L#Y`e1Jjoq+Jocv*?`5LG|V5p|8_~EeW}T zsELQ>^Vve+nc-t&ptmu{X|-12!WV9)FFhnJRmF=61W{tQ24A#SFa*ek<6h>{Io)N3pR5oJNr`aZJz(I5k^0<%H_0eJ%h6pO*4=>O{gm4F1gbqpWoM*z@d$RK9d ziTDg$dvmxlfBOyI@Po_~Ge_X&w66InYNO(b2V&q5^o(5}DnyP%0A7vN2BSyZv*qQitZqqg8>K zP+(1ALt?VA)QVyuzu#)=)n76R0<{+pa_-TWHXN0n`y=A8zDudE3B2b>b@_r`EGG6) zPq~JbS1y1QweC2=rW|wA6f$WH%2ZP#8G!4B|hBsQxuWdJ-wfNb0}! zPIqfhDEzDaJ(~1xcALLdnuzT?$UQk5dQ%$Xlf&K0(|o<~dtcJ59z9L33JOSoM;KIRDgwSdEvwKtIb=ENI0RRfsNz>j=z(lbi11RKh}hY& zL`4in0620Gb)JqrRpNkGSW@5A~gIKxboj21IX4R%@L&C@!DC3(JH0rkSzNp>Ef_W z;K;U81U7^ji22v=9wImd=cyG+U^lqphLh_|GAI$GNxOt%?Ha+A_A(X>d;mvEHaKBn z+@^l1&r;F(h@S@*0%~dQ*S18DRyYlx16@owl!NvLCUEkJIOo;ajcJRwj8&E~0-y=4 z0o*_mCIITosxa9WiOQd1+FO-MNLAq zvOTC#6kOoQp!DO=4D-RiOCW_S<>TIQsxCCI>L8U*m`%2bB5;IXzCu^3DM!$9s)Q(J z4_DXq+b8HZhAb-kOq0GkW|Z9Zogr|qfXyRvCAT3X!j>NgZ(cBrNcR-OpGuTsd*!r% z&=HK_Bt?>uIH5%_>7IUp0yySc1OloqdO;d7q1RyfoS6@-h=w$kgg*RralYSUI9D)e zu_o50+aD5`k0ThB1*S7l=sT@IM%Hb_F$@Xp_%R+>3GsUgwCf2BTp)n%2h)C4?N(hi zH0b%EXKWy3b$!r-bM5YeHVzT3=LxF&4#kqH>(8!*a5L;YHv9{8O`}+fq78HaOryLX z0-$R{5kyX?&Wu47yVr|<9BZuaJ{^P=bl(Uc_g$J6!6rw1s*Ulu6H#~ZtWxbc9Ww$Cf zLM($h5G~U{YBdtPAYk^|mY+WHLLHnR) zN4V4UG=4(|O!a!#E7)#m_-OBjXA-Hp#X9RIDtn0CIcU+(l)tF|+>Xzv=@HAO-EO>h z`pz{XVEyMxv<)HoIe=M@Aas4JrJ>#TpC?=sEN;d37=NiGMg|F4eaW_aV*UD0Ms@!e zi(sJsxuT)<|6AjqGEC6`(9+P~z)3mx{d_w&(zOwZ8D|Y9m5Sfev^s6OeIAd;R-rkl zrV9MHqy5$btJ{_GyK&g!mMSkdK5Q)QnW3e?_$OJB912ctapI@={%pK(zONzX!rcEy zvVJB8tS7vcC`wAgjlrxXWIvbhVSL)?@b~wuO%J%nTgjpxwgJr3oV(Mj0IR}$<*aE+T!!F2IFA46Y)QlW7tatUO>}^4ET8!swCau zhYZv~B2SRJ>fEuUmVgrZS62Zms@1wSE4k^U4XS-;?srQ#@8}i=1Ol_ml~E>yoqeq+ZulT-hSO8 z;|$9RuyV($l@gEyXH~=C0qz#1$IY9oV*AQHE^EbBKD|4|TQYF`Wq7f9I`7Too3C(JPmG8*k9QD@tpb2-?McHzVlw8M@W>vJJf^#kx?Xn^9;q(lld){`mA4|$Iiz0$y~dZEn5i44gBf^R;9wsn-PKX4I{6y&BulH)b=?{J&$F2<3usT_bmdM<$GE)NTpw?< zqbM@~T&&b{mUA&%^F2OZG_j6}axawq#3bR6pC8j{X@;N4P)!kae0=k!haU<;MNzKj zK~x>0CM^r&`&McA-Hu5_p>caWi>{tg`^YiOC%XKOcPlG3c14#(%O%U>rmHPW6u)-V zLQXK7cWZ^y4Kp?MA~j&cTTbz(n{9jKxaOquXjJN0l;pi#YO5>PI@RJ)nm)MLGfIRdUnFfm0yv;F<6&Kd@*V%HQ^R=PiY zmH*=q2>zwsBRfQGBIE0aG>rVfD=3fino}=j%HJ%ouMtIHj@X29yE6}kNQ;rzcxJVx zFJiadf0Zn+rB;p1lite<1 zrOlt>(hw%mLMHwZ4jVE!ld<-|wEa^6$~Z+-*lKyWt5?g#tTn(^3|?;EV~{`GmDH$_ z9pvb>gRP>c>S&|u#WvvD-x{5wN*EZ*L|H$qdyj1es&9{OSVG1{jcwu%gzg)1H6e%E z%z(@Ionp-Yd$A@t@bX``D+<@(V|IGI$cFKkFV2YvsNmsZuhq)EQTuFmwyAjO7|UG) zAYjx`^i1-T(Dmc-sh8?zW+lq?7cM(((~A_d5ncKg8gMX#DDHpz^`Buf@qj-?oG$P# zMfIPGZQIXiqWCg?wr+bJKtC z_>-^WEY0BtXQNU*or!=@+%8LsRB0GU46kc2fxA1nH#SFKMNKSKO%xiCS?X=M$5zCD?UGZd`PI!X^Bl-GK^%GctX~Xv4Im zWp0mFu+*p4k(Z7$0l8Gc{qNR?RW?04EoYWN!oz39JGM-WPUGhL1jO8N(`GzvfqkhG z6=Eb*>h+F_^NSmwJkp*Y)eyW_=8(};Wc@-S<>18{6eMA}*67XZZ=5QTlL-1+78Q0PKhQ&YxL>&=vD8wNB*x}#N=E})>y z)FSin&L8t(!c;Jjgh^&x*SPH`Ue+`Vd&VZ=y2XD3v&^p2w)-#B4k? zAIGIDK8t0cB8k!Gj17rwzFUL&D=*$84!&F9(~pXA$208Ba7P;lG=ra0D4oc3!w=)L zEjs21o;OUCIlxv%C;UwZcvUY|2vLzK-~F7tv-*Ba=%;7be!6Y{({)5))hQ}2`j?2` z(LWzy$*?3f9z&s`hf1125Dgw~#e#L*<(SvKLRQNogE*^Str3nnZ{C3Z^UZ*gl^lbR z`h`zNy9&d@b0g^eh%{BoG>K!j^VYu=f*FDuQ>ki3zYPI5c#}Js6IL})fGgexu#I&K z4Mz#G=GsLnCRNVsLnahU8LUIn+)qwMq@L}kzWhVrIW(U7LO6m^Bja2Go(X+J=duEw z!0S+l)zrFVh&HPMZi z@s6({?Dk!Z{&n9GRDyqxc{lLCf31C~+U%yrG;)U%ZogIr#{PK}YiTwEGIcQjdD(C{ zjVJq8-9=sM|39j`|DWXaKk}7b!W~1*6q5{pE5l(j<^CVZO>;Thy;sdDiYLqu z{n>ui11F&F7{+~kKTl-~pToR-_l`b^zU=SvpQFVRfJ~K+43v+^uMT~U-cZClQtJN; zE;7g1F$YA|qc6Q<0Dj37l z5H3(qQsgc{>8Y##?WSQH3cw1zwjom_J*R}tWwMb6<3U!Mo@?F+q7Qb#0a#@kYPMNX z=gHo{|F&)mq>U}MUYdpJ(2p&xtC9?`vXsgX<#XsY*Z;(!!L z`#WYKQNbg$ElS7@s46puDX%FuqaD3aSCQ9>URX$;3W%hYEaZ-_n>S_tGi!y#S^JEV<+cXbWS|C z3-n4e4ZS=iE(SrgQJEQ0JqH*fVh6UdLaq=c&i5_Q=!cHnDZ7I8k}ovez>6KaPvP4j zQb8^H$JP6c-p?}WoyPr~A;l(G>3rTL%+W&68NzVO3XB~~Go%z9BwnxMw$z{67&fX{4 zEi8a7lS}pqZH!{d@l~eTX?KZ3byPp%#4AcL&2nsR($~@f!Bnm|MsW1q1=f2fgMUCE z_2GnzLvc1f{=(nIEcDog%)!jd5-FSi>#1J%%oH_6y09YmFPG&p-f6Dqc|5+M9N3&0 zyUcZjsg$K6KQkO!p9hSj-J zUh8)|N0aQPnUG)jN%QzQ^e^Yg_GKH;GsFNwVeu>1aL3v9&M2du$XmOCzqVt4FWd5o zyvq&33QY{1!m}82*&a`9ZZ&5QnMDnOdgKyUm(fkUI;&qF1=HKbY+6t zU}8cGFG!2Eb<-N1>xJhehiX+;(Z1Z@92E)c>nO@m^NQ)n(vq{=dWr;vhCIoArA^jlcQn~)9H&CI9k z`BsHg>O5PNND|z%L)>5Ubw)^hXsTsoAn%KUNe_gN2~=2o*a+2xg8`P~pqtbzdcML~ zkxD`gb!!Z-azcNB-;sZ=#uYIUmyKZ)i<#gvMOa{E-sGU_Fhd0vJmic_uoK1Ec(gKyS+DLNOf5e z{=4H5T1jIK+UJ(8GpQw_SkAnKVOn)o3>LPMb3cD4dUfU&nh@vG6tziaDG4@{7h{?x zE!gzx%z6!33FMm0h$IvgcHU}fDJeNiVZ~`FVuYW^^?}xZsLJTV2y-Wgi#a~XgBr}- zOQW$$KkQWzNgZ3d>L`L&d^!*2UJ;&7@Hs;0rUN=@smma23&s?k2WRHcGwF@PQP?}- zN0`Q>6EQh90A~{1=;;A$Xpy)w)Aup7)x4^UbR&7kdEZ^_rAzZ^b4S(`?Zc^!Lk+y` z%ksYOC^*{!XUcZlY*|rmk~CMyyQp3rV2!P&XY9ThiAOSY?*vb?(_Fa)kTk#Gr5aZU`yT*Hr#zlUL%;VX|; zI6u!Rh7g9l69c;W-F^ah&#~1PGSbJe!yN6zF0at_tOLpMHzM|(&G0+tuHHoR%A!ts ziZiNGY}@Im>jOv_VMhKZ7hr{LfZGA{UR}BG_Zar(s+D^u-u$M)@JZfxtkpJmHxw&~ ztNg6@)Q{>YciZ9y*D{3xCr6VaagvuJ(cg>WPiXt)BT(%7b zR1K1 zLrs^HdnfWelL$WL^rE9XXBl#zoSsogz?IuKlpe;uGgh%HGmx-}(bUg+A-P_MJWJv& zs#F5Nc`p1eqA-hto4)-UMCT%ljbk>Y`2`exOCN-Tcn2+@Q8@Wsn0%{SL`w04X5ht9 z!THE{{%&TfAR9xt!C;$gHUZn9r9La0ZVD&was4mXbB13Lt-&w`>J%*cin0A=Hk#`9 zU+kU_OaiixNv+|e8J^~OnEg6}f7R92I10IsI29F8u?8SQu|H!D>9rV;{y<%f{)6b{U$yfg@U!w2eqHEECaY5mN!dm|A^AFZ%FZC&S5($J1F z-W46ne_V7j<1H78fGtjVMG|5<(hQ7Z^1HETR*_ZNpth&Ft{D>iTHP4La}=!ZcDK|F z&HNWf?J`q+dmPkJ>pLAmy?t4?8)@kVI~vO-Sw^cEQ`0I^GXQ}jX=Q-%L?WzSNT*y_ zlIPnUo@2Hw3z>NP@fDrSy>AmL1$2hDo^^)^CP76|Utc!5ft`M&59>JZ!no`t+bHLd zYABb>gP4I}0BE;lHxgt2GHj(jVkkeXtWq23WLtYxv4JKX4l@pI?mpGlAa2&3t!mSB zSph>$kMlAB>dz5Y3tf)WApu;lK9WatywG-0Sq1n@DrCV+@0?X!Zvf~PIvxap*#fGr z@n3=X&O^95bu68

3B6=u;;fUysc3C+Eqw_pb4DUGFC1JibM z;u7f6rK%(Ge{YEPB!jNssW-LPEX1!*Q)VuR27V$8T?}0e()a2kqLM)9X|GQ;bMBT$ zZC~QO)@MOO6Ts9Zv)qM;r$zfi9Z1KMW(JT3tFeat5Y#SOf<3n923kb;A2M5nPs(_0 zgy`|Qsc7lV(q;;VOg`c4(c)z~whE$;AT4QEymp=a03-t30)Va;CTaM@@1avkN(i&4|f@h=pCC!IUyo8 zU9qSrm?$*ltDK0D9UAX5Z%I8@3L1K0?-0l-s848MtjO-`UVz!x89Altlgs(IIBj6w zZ~sg#CC$qhP~1peao|2W4UYEEAkH#HEG(}lU*5Pf9{}F2m=2yF=Qj+J@Juc~r!smt z15=KhNRBCD1j%;^+M&`C;8llcxu^?WVUvf6xr`+x&|5Y+z5S5_-Hl$7ZRl<$@EVlJF%{syV3K%g zNfi}87YD|Vs-*K^ACa5IGb=KmxFm0sGy6MjW;vi)^|)`iIzTIuw%}lXr2LOClL@a3 z;U#@-w)qb22~28i;E2~vi*w8U(|66r_65_`oT{un$o@dXnLU(YPD&@Pu<+or33={7 zdDFy+{||B}O^4dAyAN@zw=5*+i+l7S=UCLRjUNb+u4Nf&;ZSl=>H^=UuwqJ|*C z=+RMIsqcukjad{^JOckQVGw@}Fx&M&Q3y_vD0v&x`uEzSJWp87C~Bj8vvKx~hM$sR zb)cAZ$A4LVvEInCc(gG~YSEtpk}Zi1%CL9Ojl(l}eGANz=6IZ%Qf1DCjvjXEr$kTC z$>kkW5Xp@HNE5+bX+*?#^DzB+e>Z*1V>&UklQEYx4D z0jpE7)C7XRswN$A24m*nr%^fwu8^#u!ZFEN9v^u4$McMGLzq87z5!;3__Ucfs5|YP+5=k|bv-%PnM1Zc86coxVAegB*HdDxJReD(B|l{GV)LoqFu?^$&KzN)Nj9m| zhi=wGeSYHFxq%(?N=buBjR^|Q$yCqU^@5+&U|lylt(Z<4j^CxfpY=Lm;e-_n+pDB< ze{5hZ)J@JxB0&>OYdhYdqgNMG>E_&oWb?y#R_GiNsNunN>7Sm0RMvKisR`IjWvMJY z+5AK&6@DtZ^ePrARnX5UkAX9`zH+L!B|gCgt}G2rFK|e?xPjidk7^S*Rr6KfLRv43 zHQ)oTE4Pt1XS{g;s%j^Qt46~i)S0(T&MpM=A%rV&V<2cB9Fp(T8+&Uq|IEfwm~csJ zqkPXa9re>O9Z()DUKgH56%b525K(r97!Y6jafJsx*v}b>k1F9i6$@{yi zdI3M_fl}A5I}`*_kJ7~8zmZg#_8G{1{Ok=_Mo$VtKw>a*pW1)JzxKSk`{fVzPb`|V zB`|VmlYEM9#6nfKoXO8$x5j$ZWqkUk;Lc8-t!&060$mX=v9=-;YiDrjV*D_bj%wND zLvIwJVNP&DZUzZ}tF*;P!_4Dar7m(#gu9mKaR9W61?nLCCXf6dAj6-YamTvcj<#@} z7$i-L|9!UDDK}G42sjkN`@Y_oO-l^^UQpgzI+jJ;Zy%IEk>^gO?=1l02<2AM4036e)n(q#m5=a7 zSD0$RZryrVTXd3GH}fFNVhKe_D&?ZEFrOs38-{Pvl57Kd^A%H3xySI7(6T&ZF2{vd z#FC;J9VQqvVxYJV2ua-^As5m6 z(S1E_Pb2nRrL`=DZP;mfHqAQpprGMP_|UPhqi_4;p|Ak6!Wz4PuQ8AsX+nGI&%G|EUl_21x#bBOYPL z-sHWsvQlt(m0Y2!<6AegHbU?fux6K6VX80;Y$fDO8` zceg>HrmojbQj1Ter;|)bI!~fv%m4F9LaIlZp^pK54-c)$EaqKEICY3!GCv&=8sFv7 z-^ngp_)Gi9j&kAb{H+O_e3F>R`c|auKTNe{?L1o(I!ib(Q8qB2 z?)PGxXuoT*DI`@>%_04rf}Dp(Y~SSp?qbjW0jA(SO{H3>;cdQP7dpcM+9+CEZyYg)G#>vUSHeo-1@3Jf2Yqv! zvNXj}b@G;}MoUaUl8cqzLSHj4ezvw#}|J_DI zxsFb@eCL$=2N>h~n%2FzJXv1R!b>^iO!8}91QVm5zhMM1ll5WZDv=)Z%c>t!f2`Vf zX&gng9Y5$pSOAR&C3XWXX5r<0)1o#o;kRHRXDcv{r=7MnycxPH&>wHO{E$%^kp-%Z znfM_zO%Qnkr5=i=6hS-3#hRrNUJ$tJJ|P=MiDLhg|2eosq4&Qo`lBzroGs`5DEL$qjq5X z$1+ZYwU0tM3Ln@fJ0iZnWUxQ97;=!2L^9*S!TR_Y60kNZ-%*E4RNJ)edoicvLOV-h zQYM6Rt1rn`Ef~|?A&(4+5sZ3F$hh6C=(;fav;HRO*qCVdIW4yG?j|OtcuBFF>=0XM za}WR?wxT2KD}l=8XbwqABE;4-Vq7;E4(oIGX{-givvDi!f`o%9sVd!lQ_XNE)sUvsl5v@||7y_^1Y;tUZ3Fo=EWW7Ipfa5&0d`zj~ox z5=y_-U;Zi5U)}2-OvFglAqW)TM1Wza^H{yV-8LDN|H)R!p6n~pF(yBVmDI88{$(bd z&#VSu_#BO>!)FpJew_6y!>yt?kI$P1!k$j8FLAshYyHCyfBt2 zg4yFZUl7{2f62bjSK~~WVi|-W7Be68zM@zY`chkx<1ij&guWAx!b zimw_0uSvY|$aX-NvwpJu3#^y^McXQU>G~Yi%A2XQwkI%wAKi#l1ock1?Cof+L zG<|J8>TBLl3%;CbsLdH1)|NsD;>j_+qE(U5g3QYr}r;J~RJ zO*R>>%pAiRhh7-B)9Z-9jU3b-82q(976fZ@HeqMv`U2a~+PG}T@(b>DaPnyYa?(FH z2#!7_DQ}^ni(f;X_;#=?iQ<+fpFH_iUK0=1@_SE=Dgel7E<`K=0c_!D@dfZPSE{bh zc?FLzsZG3L24+xbOC{lfYLa`6Ys=rJi9kHtZhTfLb~N{qM@{TFo*L}G7ENwa z(0axebDmp=;jHNGhIucQb0HV!aGQs_yMxgT{|GC#Zrrwqd(XWVa(@KyHH2XkR)fk~ z`yd)y?Hc;|VlkvOYXCnX5(ydmYd`$OoB|=!_=N+;jk!tw8X)ii;tXCi&R`57!2Z#Y zNZxi#!%rmoALEPm%vUQX4%X|q#d9w5oNe!*cAGl__p=?>^_p6xp-#PbwuwN|JKNqb zm|01c8h$e%(j% z{yS1>-vNvbrd4q}VCM$OwEpJB?a1gOQF~^; zJTdoVf9lFZ2&o})R*t-AL9bBaZk#4dvqpgYS<$9_e|qp4i_Fwn|Lkht+XGt@W95K` zRl$L%buKGMXO^q2=dX7`8KJmnNWAza2w-#5>~@30_#y5uXvXma=L!loyt6^f3vg45 z4JEH!EB@Ht@5VW%i#6r}KuE2T#XLo7$4te3q@k}wTpu43i{*BO6rdq0!mHfk8v2Kw z3IKy#n<+wy?HdAR-H*Gp3JlmXo_U}AMG_*C*TQrIdO9yU++9|VLUMx=00VsKP&B&rbLWKC?8GS#w&PJGfcL9V@5PTf5+%}YntD70> zr9bmW>o$Y-sL%PM+vE zdS%vCLdDH)ualGuOtAH*^NHNp%>2ve1pF! zj#$wM^oM?%c6M`)!WDg04miC1JjLkY8+=4HU`_)+^EW@Ytx1&d+Z+jwHg8x z_H20qMu1274qojJmk^?u$5ehMGuwP`F70ACFZiW^$+se$t>ij(k6%+7Y z0q%=z_2V(DX%9qhfvu+d*ac5iBEi1L`7tu?Y0rp-07I*-u~m(o0`H;#k}(2f|D+MZ zQh$#%-0T!Kt`V>7jDYDOrm%Hyc$oQuF;e`X#?k~_p@VT)oA;cP?I|*ZjI!I?GSL~b z$YAs0?E|Eg{bugd00K-5oCgo4DDMSlp&YzW%jWUOH`6yFC@}LNn2^%p4BWJ|?!yP+ zv#956%>!;CcNJy#xuRwxWElL2N`C>tnMnB4x+wT~ZwlpSSg%)V?&qkZx}v z_d6(d1K)aciM)A+ic{^l9gac}_(^VdAK*jU_&a2r7k&CXZ!a|li*E%(kpNYPOJN8m zqCTirWJWc=W<{P$#gGeE<7YpyXPGto-gsHxcSE*V8Rx}T7VTHV%yOd_16)rf@EE7X zpLTjDxr>}DI?~-fW}*y?K&YfQEJWCK^Zgr-J8#w zf>F=u+2EbxTK@`FKw+1Edru#^kC#XkbNkxQF5j9l&O*Dtln9aallu21&Z_r-s9G8osE3o zYkisjJW?wJ6wD^uzKRY1*A7enVT^Y1BJAiQzPK8t)$l)MM{5S05e~`JN{15i;eJMg6wQfF();SNKCR27@f?tg! zSF4NqE~EyOMTAo0N3j;1#=C1W9;BBNabE7qrub`{~zK45{VheM|;>k{{Jf!Ct5aL;-=qrWt_RpoZOv$s&~0bilOx4%Kd zJXyVg2D|QjZR$7#_&S9~T6$d^oL-!)Laq(jTYCe1MXbM={=%Ud{iBorWY!-#T!m9a zOP4Jqj7It!RNVY->zJ}NzT>a_Vl>BS3G^8x?@E6QG`!|fyqU-#eqsu+aj+NaJO4-; zn8v9&uY{C$>0?|`Oz#Nh2CW*;U zA!d@T<&Zz09O<<Uk&X3GbFlbJ8b<>qt3)Su?JmS$KaP7sz zfGaPYryna?E1Hy*CXbOv)+`lf{)7alvxUP2XeBCxu0xG!z=8aJWn|mUd1~bi#mHC=8LKMg{$pOLu&{xe2ZbFh(v@^U z^R%LFlt8gd!!xvGkVpn5xp`eAx=F+6LCL9PWemi~BC!dfFc`1m0ZvF+%&XrTAUM!X zZQ~;B1+kId;1z>}$9$tODtgD*A%JuofPYkFwAYU$#dt{uA%Rx-tWOkysF%iKp22I8 zZAmWQ4V-xksclg;RSQh6?uxMY*svqYG8K*{PkDpmxAbkoX=$2-1Xj`_QYB2#db_g^~2bclvdjnSq`s}m<{jA|3 zt}!zmG)L@3{hM^zMa@K(PL$F(bZ7C^=X|}1TgEr38bd17MsX{lfk4eQgPtt@wW%fQ ztU-M(=qyAS9#tFkA-NICgGNlIV^5c^V8VZ8UmYL#9No1-&-iI!IYwxhdKOb0tC8MJ z(N$Bxa^~_jqm3R*Q8DH?G#}F!zptvW|E@7MHwM}?y7yQeh|Nv*1?~B*Oi3~2O}Vn0 z8U;S+xRX_&t7u8-4;n3dBQ1-I_-YO8IW>S;=RQ5LlGQvhOmPn~{wQIerXLW3NUj7a z43MPnlD7#p?>J7`(ZGL-;A$YsJJSq&6w&=EpN7tP$N8hqfd92uG53IA%?#bEp2R zcJin#Wzj4_p_n|UVO6=xGvPpu8Wy&_Y^{j=qvFDqIpBK1JLo7mP_MylFM+*!_W?jX z+nyM9L%tquXSVcsv>I*qV13JUW21Pr$ENJ1ZCfAdwm0&M4PNK}dzZf0<5;yzPs|vy zD1srQ=)X)9#+J#%qKM3*C^-`&{F!(!j(8ByRHz@X?;=HQiy(ORr8$Apa7oGNW=K|A zvPDn&B+T(b&l!0?yB=&H)#`CEhG2mB>HQ1)ZWaW^m?Vg`u_%xEovT=2>SoC4B2#!B z0(hbLt8zf+5fGpB^qiLV`R5A_-EsV(i>ZIZS45?~yw`t$weDj_9SBS0;IHMM;o`vdbImzMg#^0FF<_&wBd1z9)4GJ8rE zKa2s(mdc_EBM4Dv```~~c21hX^2Kd9m}#4pMEF^Ye#6^|-s^3z!2D(@aUP4k!plFm zeP0gkZ~twklZG}E?9r9Mx#Lxl6v!jU|~vVx~Nk z0w8Ppy}`E_BbxVNdZZcIq+e%$6m>$@=ff+I5qnEV`*d{VFovmGmKaqsPlDoz4i3b$|ZK-*IFNm3t16 ztE)8l-W`4qXdKxS?#{@llQhGPalH(n;M}YANQdAKWkV$i(3%_`t{!wwGc{pF7o&G>aj8 z*NujoXG0eUF{HxC2FkMu!Y!FR$2NkF!uZsXJ~`y7B`&5>oe0HT^fQcPTL1gh7>2q_ zZZy^9In2ymXt#KP<>=h{%=el2f>8fTy)1x{*I4{$xz_Bj(|Bue#l>J2j|?8`2HZWI+NGb3TR4wKdz-{_$bFkQn76w(OqG#G#vQZD z6?{>VM@}7<78M@~-JPj@4- z`;Q4k67B`|+rBllUf==G!Hf2OhP00aH=_$kR!>u79WGXyVN{F8ovajEwQ!0Fb}YZs zw_Rk0ItF>o|KfIVm9nvkwl{aJ7=_U3=rQ9)^Y&XTV!v1OK|p-{{@;HAWbsoE`&0S3 z(7v(S5|St75BwU{z{2&^zfaZ>R(XB?i{J^Y9qd0BF!i;!!>4y;-m#@)W?LdOGQZ(a zC%`=0pD!v9swng284_;H+wzPZE9#-@bIgm3O+ zs~qK=(pN({Q-(ITx#s#fvK&1q$~9{E2(ujfFw3#B`j)HQ_kCaE!yLnB-@oGfFT8(v zKOV2w>-l<7F^Ud3V7ob%Lsa?uV82SWh(P0pn;8wez|}rzaP#FkxC>X|r3P-$BzD)N zMmD;OuzGS!5H?K0r!tC9V&)B>Fny@XOI@59;1n^P?x{KMha*sVKIZWWb1n+B0%#PF zXJ@=es63WMPddxIGn@EycYy-w@CRyhD}>j=8og)UUFclyDr5V~qeXBJruTTsLHdHi znxhOJkP{K|4M>&{y4SwlzNHDA6OeN5>jkR6PVI-^A&dqf2Qd&)ji23~B6S}c!yZaA zwGl1#(|W?1TauJfN;A$M+BrY_p4QewC}z#7@ndQsU=wld5*40A(ZNUMHh=XeD0FzI zH3__x5eGvsZMC~!@>V`iYLK>xTfYY4ff$b-7Dh>EJ7;h^d2GEh%hxESkIo z`J@1xG=L;IgSFQzRVc6reis>mLMeslJRAUrO)b!%XS8 z@uhx&Ko(p!Zq#R=@aW?;7-5nWR5vI?g%Dl#!)h{Sr1Xd(Lp!BGocywcTKapVBKwBg zs%1=|#oAH+^frg=u1@_YE(i~P-MS<(fhLxkThY>97Qqx7+K1@Uo#b#Wx=ybmB$+`U zIe0o3aWauk=AxZQ_4p07OMp@ReG}#>CN3-_MksBX@20wJ;=tD7o7jX53I&aQK*!;5 zv4ub_BBU9Kvo<=`z&joXWKk*57I?5ZMUXz&BZFQ3*&U*GD3%E|Amye3@T8XdOl2S6 z)l$t@Dw2cRi=JL;wsjK?;Zi$C9y@&|emksQ%-F_=S&u$*oZt7E7}-y`P5{cF!O@kD zR7yY-C1pHtgJDx(LO;Z_@9$xl$ z`G6ewlvZj<7j;z2DN@+!2sAtD$kp>zZ9pm7go3F;*?0-t1=?UOiqF}$H0!(SNrAh@ zY`tsyf3&n6$M)<%XG~rOsjTjfbYKKDVrfo@wFI7DEA$t@*#UwD_lrziJ5Lh|Ch*wbKjx%C zgPwL{fvd@fh|C}qgRNl{O|1EZ`)`h(EJH}ZdH$y4Vit?OULAJ(2Q48{h)k*8<>%n;x; ze1H3~pHYbYJl0hypA8vM)P%jR_EF|dn5uYOZG9E3qgdhacH^6DL?f)^iLO_#g^gX6 z()txyZggG|K6mEx;tP>Y=E?!V7@O?r>eo4W5E;@V^K5wPL|eGB5WqjmE4(80G9Hkr za4tgmZAsM!8{gYc&pdZc41E*d)9cMFT}EFx9|f;nw7ou^J;7i_1f5tU4SvU-U$fv8 zYS+B;8r{2KsPx_3K-I>+MlHmwt>lrV`watc(_&M>`_D%#erdHsGdK~?0xfswpIn%| zIeS}96sQ!A37DAQB@EQC)SV;*T~tUj->s&9^ZW6RnhZ1DLYf}|8TJSJ=p5wNt@ZsQ z+o}_zSENJa*)4`$^hZ7ZEY?-Mg9nO&LaUf+!SgQC*?=`)SFoU7cNaWN*%^pxqKg zAImVUm~GcN3E0p4(x!=Tk%^YocW!Yf7l&QyFqA$nC;mHTXS#o)2L$)GB;TLtNS5&_ zi0N~PP+!FRQvdgWoh&ya_Nl2+#|QKkJb!8s%0yhC3E5U7%Z_raoh<*`hPFgc;pl9h z?0TNt$!iKdT=O`rSN~iPI-D#G&Y*OfbdHwgg(3B!oX7%zq4lZWDn@Zn*^4GYTdzX8 z@RktL<=Blx*y|!>_+6{J7VPS41NsiDs*1JwjiuQKS;{=5{`8>n@F(lFuqYUee55LO zL|A^3K%W|tjXsoSFeC<(;?t&!Uj4r&hfaCPoO$J6;-c={O(h-+Gh5T@+ivmy0K&0o A^8f$< diff --git a/sips/sip-026/sip-026-sbtc_peg.md b/sips/sip-026/sip-026-sbtc_peg.md deleted file mode 100644 index b6530f24..00000000 --- a/sips/sip-026/sip-026-sbtc_peg.md +++ /dev/null @@ -1,171 +0,0 @@ -# SIP-028: sBTC Bootstrap - -- **SIP Number:** 028 -- **Title:** A Decentralized and Programmable Asset Backed 1:1 with BTC -- **Consideration:** Technical, Economics -- **Type:** Informational -- **Status:** Draft -- **Authors:** - - Andre Serrano - - Ashton Stephens - - Joey Yandle - - Mårten Blankfors - - Jesus Najera - - Jude Nelson - - Friedger Müffke - - Tycho Onnasch - -## Abstract -sBTC is a SIP-010 token on the Stacks blockchain, backed 1:1 against BTC, and operated by a decentralized set of signers such that only a 70% majority can access the funds to maintain the protocol. - -While Bitcoin on its own cannot be used with smart contracts, sBTC provides a bridge of value from the Bitcoin Blockchain to the Stacks Blockchain to enable users who only own BTC to utilize the capability of smart contracts without switching to a new currency. This SIP aims to describe the high level sBTC system and the criteria for signer selection. - -This first iteration of sBTC is purely at the application layer and does not affect network consensus or operation. This SIP does not attempt to describe the technical details of this or any subsequent sBTC releases; it only seeks to get community approval for the requirements of the sBTC bootstrap signers. - -## Introduction - -### Glossary - -| Term | Definition | -|--------------------|---------------------------------------------------------------------------------------------------------| -| SIP-10 Token | A token on the Stacks blockchain that adheres to the fungible token standards outlined in [SIP-10](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). | -| 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. In this release, the sBTC signer is wholly separate from the Stacks Signer | -| 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 | API exposed by the sBTC Signer that handles basic low level commands. Remains private except to the Deposit API. | -| Deposit API | A third party API that communicates with the sBTC Bootstrap Signers via the sBTC Signer API. | - -## Problem Statement -Bitcoin is limited in its programmability and scalability. While its security and censorship-resistance make it a compelling platform to build decentralized applications, transaction confirmation times do not meet the modern needs of users and developers. - -- **Bitcoin’s Limited Programmability:** Bitcoin’s script has limited programmability, making it unsuitable for most decentralized applications. This leaves users with very few options to use financial applications, like lending and trading, without entrusting their Bitcoin to centralized entities. This also exposes users to counterparty risk, which has the potential to result in lost funds. -- **Bitcoin’s Slow Transaction Times:** Bitcoin is limited in its ability to process large amounts of data quickly and efficiently. Today, Bitcoin creates new blocks every 10 minutes on average, an interval which is longer than some alternative blockchains. This prohibits many types of applications that require faster confirmation times. - -## Proposed Solution -sBTC aims to solve Bitcoin’s limitations by combining the capability of the Stacks Blockchain with the stability of Bitcoin’s value. By enabling 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. 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](https://docs.stacks.co/clarity/overview) 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 more. -- **Fast Blocks:** The Stacks Nakamoto Upgrade, proposed in [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md#proposed-solution), 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 -This proposal describes a system in which the following are true: - -- sBTC is a SIP-10 token backed by 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. -- sBTC can be converted into Bitcoin within 6 Bitcoin blocks. This ensures sBTC on and off ramps are faster than other BTC assets on the market. -- The sBTC SIP-10 token contract remains consistent across sBTC releases. This provides reliability for users and developers, meaning no adjustment from builders will be needed as the system evolves through subsequent sBTC releases. - -## Overview of the sBTC Bootstrap Release -In the bootstrap phase, the criteria for sBTC Signers is determined through the community governance process of ratifying this SIP. sBTC Signers will be responsible for signing sBTC deposit and withdrawal transactions on the network. During this phase, 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. - -Management of the sBTC peg wallet on the Bitcoin blockchain is decentralized, involving the sBTC signer set rather than a single custodian. This ensures a more resilient and trustworthy system, where signers are economically incentivized to execute peg-out transactions efficiently. 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. - -### Differences in the sBTC Bootstrap Phase: -- Eligibility criteria to become an sBTC Signer will be selected through an open community governance process. The eligibility criteria to become an sBTC signer is described below and will take into account Signer performance and availability. -- sBTC Bootstrap Signers are separate from Stacks Signers. The bootstrapping period uses a separate subset of Stacks signers to secure the sBTC protocol 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 deposit fulfillment must be initiated via an API call to alert the signers to the presence of a deposit. - -### Auxiliary Features -Auxiliary features of the sBTC Bootstrap 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](https://github.com/stacks-network/stacks-core/issues/4235), sBTC users will be able to nearly spend sBTC as gas by getting support from an existing STX holder. -- **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 DKG. - -## sBTC Bootstrap Signers - -### Responsibilities -The sBTC bootstrap signers are responsible for accepting or rejecting all sBTC operations submitted, and for a transaction to be fulfilled at least 70% of the signers need to approve the fulfilling of the transaction; this means that the liveness and reliability of the signers is crucial to the success of the protocol. - -While up to 30% of the signers can be down without any user impact to 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 the required 70% approval when less than 70% are online. - -An operation that isn’t approved will become spendable by the user without bridging to the other blockchain after a period of time without Signer interaction. - -### Eligibility Criteria -For the sBTC Bootstrap release Signers will run the sBTC binary in addition to the core Stacks signer software and must meet the following criteria in order to strongly ensure reliable functioning of the sBTC protocol at all times. - -The following eligibility criteria has been used to identify the sBTC Bootstrap Signers: -- **Stacks 2.5 Participation:** Active participation running a signer on Stacks 2.5 testnet or mainnet. -- **Technical Performance and Uptime:** Consistency in operational status and network stability. -- **Communication & Availability:** Running an sBTC Signer is a pivotal role in the Stacks ecosystem, which requires a high degree of availability and communication with Stacks core developers. Signers should generally be able to respond to updates within 24 hours. -- **Ecosystem Alignment:** Commitment to the growth of the Stacks ecosystem with contributions to support the network. Examples include (but are not limited to): publishing independent research or contributing to a Stacks working group. - -### Selection Process -The sBTC Bootstrap Signers will be selected from the group of eligible signers by the [sBTC working group](https://github.com/orgs/stacks-network/discussions/469). - -## Comparison to Other Protocols - -### [WBTC](https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf) -WBTC 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](https://whitepaper.io/document/691/tbtc-whitepaper) -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](https://rootstock.io/static/a79b27d4889409602174df4710102056/RS-whitepaper.pdf) -Rootstock’s (RSK) 2-way peg protocol is called “the Powpeg”. Peg operations settle to Bitcoin via merge mining on the RSK side-chain. Peg operators are incentivized by earning a portion of Rootstock 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 200 Bitcoin blocks. - -## Activation -sBTC Bootstrap is designed to activate on Stacks Nakamoto as defined in [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). 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 Bootstrap 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 transaction 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, 66% of all liquid STX committed by voting must be in favor of the proposal. This precedent was set by [SIP-015](https://github.com/stacksgov/sips/blob/feat/sip-015/sips/sip-015/sip-015-network-upgrade.md). - -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. -1. **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 fee suggestion or max_fee -2. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Signer binary API -3. **Deposit accept:** -4. **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. -5. **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. -1. **Withdrawal request:** An sBTC holder calls the withdraw-request function in the .sbtc contract. - - This transfers the requested amount of sBTC to the .sbtc contract & mints the user a non-transferable locked-sBTC as a placeholder -2. **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 .sbtc contracts 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. -3. **Withdrawal reject:** If instead the request is rejected, the sBTC signers will call the withdraw-reject function in the .sbtc smart contract. This function does the following: - - Returns the sBTC to the holder. - - Records the signer votes. diff --git a/sips/sip-026/.DS_Store b/sips/sip-028/.DS_Store similarity index 100% rename from sips/sip-026/.DS_Store rename to sips/sip-028/.DS_Store diff --git a/sips/sip-028/sip-026-sbtc_peg.md b/sips/sip-028/sip-026-sbtc_peg.md new file mode 100644 index 00000000..4d6ebd68 --- /dev/null +++ b/sips/sip-028/sip-026-sbtc_peg.md @@ -0,0 +1,217 @@ +# 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 ([andre@bitcoinl2labs.com](mailto:andre@bitcoinl2labs.com)) +- Ashton Stephens ([ashton@trustmachines.co](mailto:ashton@trustmachines.co)) +- Joey Yandle ([joey@trustmachines.co](mailto:joey@trustmachines.co)) +- Mårten Blankfors ([marten@trustmachines.co](mailto:marten@trustmachines.co)) +- Jesus Najera ([jesus@stratalabs.xyz](mailto:jesus@stratalabs.xyz)) +- Jude Nelson ([jude@stacks.org](mailto:jude@stacks.org)) +- Friedger Müffke ([friedger@ryder.id](mailto:friedger@ryder.id)) +- Tycho Onnasch ([tycho@zestprotocol.com](mailto:tycho@zestprotocol.com)) +- Daniel Jordon ([daniel@trustmachines.co](mailto:daniel@trustmachines.co)) + +## 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 + +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: + +1. **Deposit request:** A bitcoin holder creates a transaction on Bitcoin. +2. The deposit transaction contains a UTXO (deposit UTXO) spendable by sBTC Signers, with an OP_DROP payload. +3. 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. +4. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Signer binary API. +5. **Deposit accept:** +6. **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. +7. **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: + +1. **Withdrawal request:** An sBTC holder calls the `withdraw-request` function in the `.sbtc` contract. + - This transfers the requested amount of sBTC to the `.sbtc` contract & mints the user a non-transferable locked-sBTC as a placeholder. +2. **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 `.sbtc` contracts 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. +3. **Withdrawal reject:** If instead the request is rejected, the sBTC signers will call the `withdraw-reject` function in the `.sbtc` smart 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. From 5ad951004fc70ec733c31adf84ec7871b9b37cc1 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Thu, 29 Aug 2024 18:20:15 -0400 Subject: [PATCH 11/66] Fixed links --- sips/sip-028/sip-026-sbtc_peg.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/sips/sip-028/sip-026-sbtc_peg.md b/sips/sip-028/sip-026-sbtc_peg.md index 4d6ebd68..a4757122 100644 --- a/sips/sip-028/sip-026-sbtc_peg.md +++ b/sips/sip-028/sip-026-sbtc_peg.md @@ -18,7 +18,7 @@ ## 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 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](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on [threshold signatures](https://eprint.iacr.org/2020/852.pdf), 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. @@ -30,7 +30,7 @@ This SIP outlines but does not describe in technical detail the workings of the | Term | Definition | |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **SIP-10 Token** | A token on the Stacks blockchain that adheres to the fungible token standards outlined in SIP-10. | +| **SIP-10 Token** | A token on the Stacks blockchain that adheres to the fungible token standards outlined in [SIP-10](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). | | **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. | @@ -53,11 +53,11 @@ sBTC aims to mitigate Bitcoin’s limitations by combining the capability of the ### 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. +[Clarity](https://docs.stacks.co/clarity/overview) 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 Stacks Nakamoto Upgrade, proposed in [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md#proposed-solution), 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. @@ -67,7 +67,7 @@ While the first sBTC implementation is under development, the wrapped nature of - 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. +- 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](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) in order to maintain the peg wallet correctly across forks. ## Specification @@ -88,10 +88,10 @@ Overview of tasks the sBTC signers carry out: - 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. + - The process for UTXO consolidation of the BTC peg wallet is described in this [issue](https://github.com/stacks-network/sbtc/issues/52). - 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. + - The process for handling transaction fee estimates is described in this [issue](https://github.com/stacks-network/sbtc/pull/186). - 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. @@ -118,25 +118,25 @@ The criteria described above will be used to identify sBTC Signers that are able ### 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. +The sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria, by the [sBTC working group](https://github.com/orgs/stacks-network/discussions/469). 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](https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf) 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 v2](https://whitepaper.io/document/691/tbtc-whitepaper) 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](https://rootstock.io/static/a79b27d4889409602174df4710102056/RS-whitepaper.pdf) -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. +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. +sBTC is designed to activate on Stacks Nakamoto as defined in [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). 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 @@ -169,7 +169,7 @@ Solo stackers only can also vote by sending a bitcoin dust transaction (6000 sat 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. +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](https://github.com/stacksgov/sips/blob/feat/sip-015/sips/sip-015/sip-015-network-upgrade.md). 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. @@ -210,7 +210,7 @@ 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. +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](https://github.com/stacks-network/stacks-core/issues/4235), 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 From 447e9cf8779cc52a0511e9dc75034a56aaf0eb81 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Thu, 29 Aug 2024 18:29:52 -0400 Subject: [PATCH 12/66] typo --- sips/sip-028/{sip-026-sbtc_peg.md => sip-028-sbtc_peg.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sips/sip-028/{sip-026-sbtc_peg.md => sip-028-sbtc_peg.md} (100%) diff --git a/sips/sip-028/sip-026-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md similarity index 100% rename from sips/sip-028/sip-026-sbtc_peg.md rename to sips/sip-028/sip-028-sbtc_peg.md From 76bcf39ca3777c47a17b8eefad9f00be7c43fd04 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Tue, 1 Oct 2024 14:02:09 -0700 Subject: [PATCH 13/66] Delete sips/.DS_Store --- sips/.DS_Store | Bin 6148 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 sips/.DS_Store diff --git a/sips/.DS_Store b/sips/.DS_Store deleted file mode 100644 index 50e7fd248bd0575ee1e99c892887134d9fb063d0..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6148 zcmeHK%}T>S5T0$TO(;SS3OxqAR*Y>ah?h|73mDOZN=;1BV9b`LwTDv3SzpK}@p+ut z-H5h&5=6=j%zo4P*>t~@oeltq-ZVM@r~`n7N?5XS`9>&Cx*{dxDI*HChYKy}hO=xG zCM((O_>TaHmGkO%XAXN>2RzH;%JB|R~K;_$yrZM(b>gl+@qtZcm z8hK>~n1Qbh(Cmj&r~ZHP^Zc)pcwq*Zf%RlSRQi6uhi5arb>)=QYaP@ZR1(U|HGY(! jp;|HKQY&ttDnY+P2BK#$*N7ez{v)7h;Ds6ZQwH7vBG^xy From 888001a476575eb258022e7e3671ea08d32d1954 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Tue, 1 Oct 2024 14:02:37 -0700 Subject: [PATCH 14/66] Delete sips/sip-028/.DS_Store --- sips/sip-028/.DS_Store | Bin 6148 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 sips/sip-028/.DS_Store diff --git a/sips/sip-028/.DS_Store b/sips/sip-028/.DS_Store deleted file mode 100644 index 5008ddfcf53c02e82d7eee2e57c38e5672ef89f6..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6148 zcmeH~Jr2S!425mzP>H1@V-^m;4Wg<&0T*E43hX&L&p$$qDprKhvt+--jT7}7np#A3 zem<@ulZcFPQ@L2!n>{z**++&mCkOWA81W14cNZlEfg7;MkzE(HCqgga^y>{tEnwC%0;vJ&^%eQ zLs35+`xjp>T0 Date: Tue, 1 Oct 2024 14:02:56 -0700 Subject: [PATCH 15/66] Delete .DS_Store --- .DS_Store | Bin 8196 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 .DS_Store diff --git a/.DS_Store b/.DS_Store deleted file mode 100644 index 9fde2c48448e4b305208e8619e3e2c9f902e4857..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8196 zcmeHMUu+ab7@u!jVAgKw6k8};+B>X@lv7$-3k1aLwG~T?tz1h>`E%X7UFe4GZn@pN zf)!IW`XJ(?5;gHjqand)u%bSh7-L9`iB=NOMAZ0Vq7S|x`k>$J>^1#EUyLyXcaoWJ z=9~Fu_WSMco4uJMgg_#vHxg1s2%(s{WF=VKAn|^l7bGdr6r%*RC+Tr_ENwYyY+qO~ zI#h%Rgb0KPgb0KPgb3UW2;euHC%VXYU-X7$h(L(I{}KVdKSVKe84u*7kp9+zg?|J< z$&Ubj!aCy>l+i%O134)q_Fw{Gic*+DaKr#%j{0aYE*{89A%!`C;P3&#$`G7Tz+WBb zkNU$2#DxsY5P=YZg$VHQDJCv4$ry2GpWoACmg#y84VOSFDqga58C^z8=)vTOGoJJ` zFXtw-?0(+ra~vyOsB7uHrZJvk6>W~~X{K#teFIZBaL9oH)7G8wgp;#%*SAfI4k}YQ z#i}MInp+xU(WZt?Cu7lxt(zKR(dMR>lP6_bS+{Z9p43rm)OMZ|EuSOeMC`x!JjJyf8^Urlv1^S@4%oklwvFL_~1Qbp6S@`UL)(GOtCT-9qi0Fc5l|; z{R0`t%8lA?ij`+HE0eP{&uF!*r1_YEx-vJDbu6pbaZNtWzCq78?(x0_U4uiell9vC z$x@8vTw{-cbD4Rg9cOe0O!XRUZE&M2%YVj zhfO2fKW^&Y$Ue=@7`ATOM+WkyYo;xu&(=l_HYLlxQPpZy9n7W8V>#11!RjcTUct)C zlv*_^v-ju$9T(p1=zK!m?@?>jJ1O1I^=(-LOQBZQsq1B?(LNWSPfQV0?vt4-_Z`L8 zD@+@eCdzcV-_p{CB~&fS7RtKhfxN(0D7PsO&~k{$gBfRZ6y0%!I<6)t`-~pqYjGzw3=WJz7F;+1Pr=jh3_J@jz)NrjUV&HPbvOra!#nUUd<++18oq{0@Eu%* zAK*v$6|TYWa9t{qDx^wjrLJrZ`6(VSV!MQ-+hjL~|zz7O%^rY8r z96^zt4|ncTx^LbHy1ZP(Oy$Z|Q65N}x3|vlO)#`T%GqT1`8_8pe17``m`_X$t?D&3 zN~9kHz&O5GII?A&>U5fqUVDcUVM{PXMDy--*j$R?A(|UvkqDD8Dn+xQF`}>{j5*o2 zEr~^xpt@zNqOf9&J$br%wOXa@P~tKMJR|o@S1Bw1yl)gy5BA3bc(NEg&`_G}fHPYYW{8H5b From d5b1ac0750e2d5c5690f87a8f5473ad755019545 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Wed, 2 Oct 2024 09:17:51 -0700 Subject: [PATCH 16/66] pass 1 to address PR comments --- sips/sip-028/sip-028-sbtc_peg.md | 53 ++++++++++++++++---------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index a4757122..227c1b75 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -6,19 +6,19 @@ **Type:** Standard **Status:** Draft **Authors:** -- Andre Serrano ([andre@bitcoinl2labs.com](mailto:andre@bitcoinl2labs.com)) -- Ashton Stephens ([ashton@trustmachines.co](mailto:ashton@trustmachines.co)) -- Joey Yandle ([joey@trustmachines.co](mailto:joey@trustmachines.co)) - Mårten Blankfors ([marten@trustmachines.co](mailto:marten@trustmachines.co)) +- Daniel Jordon ([daniel@trustmachines.co](mailto:daniel@trustmachines.co)) +- Friedger Müffke ([friedger@ryder.id](mailto:friedger@ryder.id)) - Jesus Najera ([jesus@stratalabs.xyz](mailto:jesus@stratalabs.xyz)) - Jude Nelson ([jude@stacks.org](mailto:jude@stacks.org)) -- Friedger Müffke ([friedger@ryder.id](mailto:friedger@ryder.id)) - Tycho Onnasch ([tycho@zestprotocol.com](mailto:tycho@zestprotocol.com)) -- Daniel Jordon ([daniel@trustmachines.co](mailto:daniel@trustmachines.co)) +- Andre Serrano ([andre@bitcoinl2labs.com](mailto:andre@bitcoinl2labs.com)) +- Ashton Stephens ([ashton@trustmachines.co](mailto:ashton@trustmachines.co)) +- Joey Yandle ([joey@trustmachines.co](mailto:joey@trustmachines.co)) ## 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](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on [threshold signatures](https://eprint.iacr.org/2020/852.pdf), 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 SIP 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](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on [threshold signatures](https://eprint.iacr.org/2020/852.pdf), 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. @@ -32,7 +32,7 @@ This SIP outlines but does not describe in technical detail the workings of the |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **SIP-10 Token** | A token on the Stacks blockchain that adheres to the fungible token standards outlined in [SIP-10](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). | | **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 operation** | An smart contract function call 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. | @@ -49,7 +49,7 @@ Doing this in an open-membership peer-to-peer setting has been shown to be a dif ## 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. +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 which will benefit from faster block times than Bitcoin. 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 @@ -57,9 +57,9 @@ sBTC aims to mitigate Bitcoin’s limitations by combining the capability of the ### Fast Blocks -The Stacks Nakamoto Upgrade, proposed in [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md#proposed-solution), 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 Stacks Nakamoto Upgrade, proposed in [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#proposed-solution), 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. +The sBTC protocol not only addresses the limitations of Bitcoin's scripting system but also provides a secure and decentralized solution for utilizing Bitcoin in various applications. ## Design @@ -67,11 +67,11 @@ While the first sBTC implementation is under development, the wrapped nature of - 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](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) in order to maintain the peg wallet correctly across forks. +- 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](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) 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. +Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by the proposed set of signers through a democratic process, 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. @@ -82,19 +82,18 @@ While up to 30% of the signers can be offline without a user impact on the funct ### 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](https://github.com/stacks-network/sbtc/issues/52). -- 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](https://github.com/stacks-network/sbtc/pull/186). -- 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. +- Accept requests to deposit BTC. +- Fulfill requests to withdraw BTC. +- Complete deposit and withdrawal requests in a timely manner. +- Maintain industry standard operational security around any hosts and private data (to include private keys). +- Move BTC to a new UTXO when private keys are rotated. +- Signers must perform UTXO consolidate as it is deposited [1]. +- Signers must deduct transaction fees from users in order to fund BTC withdrawal transactions: + - Ensure that the transaction fee is paid for (e.g., they deduct it from the user, and they set a minimum sBTC withdrawal amount). + - Transaction fee must be estimated proportionally for the requested operation [2]. +- Collectively, the signers must coordinate to calculate and advertise the fee parameters of the system: + - A minimum sBTC peg-out. + - 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](#auxiliary-features) section of this document. ### sBTC Signer Eligibility Criteria @@ -174,6 +173,8 @@ For this SIP to pass, 66% of all liquid STX committed by voting must be in favor 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 +[1] https://github.com/stacks-network/sbtc/issues/52 +[2] https://github.com/stacks-network/sbtc/pull/186 ### Specification @@ -185,7 +186,7 @@ The main steps of the sBTC Deposit flow will be as follows: 2. The deposit transaction contains a UTXO (deposit UTXO) spendable by sBTC Signers, with an OP_DROP payload. 3. 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. -4. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Signer binary API. +4. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Deposit API. 5. **Deposit accept:** 6. **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. 7. **Mint:** The sBTC Signers finalize the deposit acceptance making a Clarity contract call that mints the sBTC on the Stacks Layer. From 99ffc4a783c65fc558fb1bcbba8b79b02712bfa8 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Wed, 2 Oct 2024 09:20:59 -0700 Subject: [PATCH 17/66] formatting --- sips/sip-028/sip-028-sbtc_peg.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 227c1b75..91fb5ba2 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -174,6 +174,7 @@ The act of not voting is the act of siding with the outcome, whatever it may be. ## Appendix [1] https://github.com/stacks-network/sbtc/issues/52 + [2] https://github.com/stacks-network/sbtc/pull/186 ### Specification From 91ce0b64bd03c643983dba7a587ae08be57d1f16 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Wed, 2 Oct 2024 10:21:42 -0700 Subject: [PATCH 18/66] remove mention of fork --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 91fb5ba2..d9985c75 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -75,7 +75,7 @@ Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by 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. +Throughout this release, sBTC will have an unchangeable and distinct signer set that will not explicitly be part of Stacks consensus. Given that there will be 15 unique signers that shall comprise the system, and each unique signer is allocated exactly one vote, 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. From 321d118f5dd48f1f526bd6d9cfd89497878ac98b Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Wed, 2 Oct 2024 13:40:18 -0700 Subject: [PATCH 19/66] more pr comments --- sips/sip-028/sip-028-sbtc_peg.md | 38 +++++++++----------------------- 1 file changed, 10 insertions(+), 28 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index d9985c75..ea0f2209 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -18,7 +18,7 @@ ## Abstract -This SIP 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](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on [threshold signatures](https://eprint.iacr.org/2020/852.pdf), 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 SIP proposes 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](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on [threshold signatures](https://eprint.iacr.org/2020/852.pdf), 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. @@ -101,17 +101,12 @@ Signers will run the sBTC binary in addition to the core Stacks signer software 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. +- Does the proposed sBTC signer have a demonstratable operating history which shows their experience and reliability in running blockchain services? +- Has the proposed sBTC signer participated in running a Stacks signer instance on Stacks 2.5 testnet or mainnet, and can they provide metrics showing this (ex: amount of stacks stacked over past several cycles)? +- Does the proposed sBTC signer agree to use reasonable efforts to maintain >99% uptime on the sBTC Signer? + *Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity.* +- Does the proposed sBTC signer commit to a direct communication channel to be set up with the sBTC core engineers in order to respond to urgent updates within 24 hours? +- 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/issue, 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. @@ -145,8 +140,7 @@ Users can vote to approve this SIP with either their locked/stacked STX or with 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." +- At least 80 million Stacked STX must vote, with least 66% (48 million) voting "yes". The voting addresses will be: @@ -160,7 +154,7 @@ 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. +tackers (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. @@ -168,7 +162,7 @@ Solo stackers only can also vote by sending a bitcoin dust transaction (6000 sat 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](https://github.com/stacksgov/sips/blob/feat/sip-015/sips/sip-015/sip-015-network-upgrade.md). +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](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md). 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. @@ -205,15 +199,3 @@ The main steps of the sBTC withdrawal flow are as follows: 3. **Withdrawal reject:** If instead the request is rejected, the sBTC signers will call the `withdraw-reject` function in the `.sbtc` smart 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](https://github.com/stacks-network/stacks-core/issues/4235), 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. From a16238c938ece52db29876a24cdff7116d08e6e7 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Wed, 2 Oct 2024 14:07:41 -0700 Subject: [PATCH 20/66] add gitignore with sane defaults --- .gitignore | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 00000000..4f0ffba1 --- /dev/null +++ b/.gitignore @@ -0,0 +1,5 @@ +*.swp +.DS_Store +*.orig +*.rej + From 671ad9d3dc0b9824dac635552d6f68762d724bff Mon Sep 17 00:00:00 2001 From: Adriano Di Luzio Date: Thu, 3 Oct 2024 12:49:49 -0400 Subject: [PATCH 21/66] Add more info on timeout --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index ea0f2209..0abb2871 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -77,7 +77,7 @@ sBTC Signers are responsible for accepting or rejecting all sBTC deposit and wit Throughout this release, sBTC will have an unchangeable and distinct signer set that will not explicitly be part of Stacks consensus. Given that there will be 15 unique signers that shall comprise the system, and each unique signer is allocated exactly one vote, 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. +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 reclaimable by the user after a timeout has elapsed. The timeout is specified by the user when preparing the deposit request and is measured in Bitcoin blocks. ### sBTC Signer Responsibilities From f09f23623ac709d96bc721d00e9c029600abdf86 Mon Sep 17 00:00:00 2001 From: Adriano Di Luzio Date: Thu, 3 Oct 2024 13:38:07 -0400 Subject: [PATCH 22/66] Generate addresses and explain how --- sips/sip-028/sip-028-sbtc_peg.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 0abb2871..fb28dcdb 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -144,17 +144,19 @@ In order for this SIP to activate, the following criteria must be met by the set The voting addresses will be: -- **Bitcoin Yes Address:** `3Jq9UT81fnT2t24XjNVY7wijpsSmNSivbK` -- **Bitcoin No Address:** `3QGZ1fDa97yZCXpAnXQd6JHF4CBC6bk1r4` -- **Stacks Yes Address:** `SP36GHEPEZPGD53G2F29P5NEY884DXQR7TX90QE3T` -- **Stacks No Address:** `SP3YAKFMGWSSATYNCKXKJHE2Z5JJ6DH88E4T8XJPK` +| **Vote** | **Bitcoin Address** | **Stacks Address** | Message | ASCII-encoded message | Bitcoin script | +| -------- | -------------------------------- | ------------------------------------- | ------------ | ------------------------------------------ | ----------------------------------------------------------------------------------------------- | +| yes | `11111111111mdWK2VXcrA1e7dnvidC` | `SP00000000001WPAWSDEDMQ0B9J72P0KAK2` | `yes-sip-28` | `000000000000000000007965732d7369702d3238` | `OP_DUP` `OP_HASH160` `000000000000000000007965732d7369702d3238` `OP_EQUALVERIFY` `OP_CHECKSIG` | +| no | `111111111111ACW5wa4RwyeKYEAzMD` | `SP000000000006WVSDEDMQ0B9J73E2TN78` | `no-sip-28` | `00000000000000000000006e6f2d7369702d3238` | `OP_DUP` `OP_HASH160` `00000000000000000000006e6f2d7369702d3238` `OP_EQUALVERIFY` `OP_CHECKSIG` | -which encode the hashes of the following phrases into bitcoin / stacks addresses: +The addresses have been generated as follows: -- **Yes to A Decentralized Two-Way Bitcoin Peg** -- **No to A Decentralized Two-Way Bitcoin Peg** +- Encode `` in ASCII, with 0-padding. +- Use the resulting `` in the Bitcoin script`OP_DUP` `OP_HASH160` `` `OP_EQUALVERIFY` `OP_CHECKSIG`. +- The Bitcoin address is the `base58check` of the hash of the Bitcoin script above. +- The Stacks address is the `c32check-encoded` Bitcoin address. -tackers (pool and solo) vote by sending a stacks dust to the corresponding stacks address from the account where their stacks are locked. +Stackers (pool and solo) vote by sending 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. From 31684ba4fe74fb18cf5c75a8413558eaca1c2fb1 Mon Sep 17 00:00:00 2001 From: Adriano Di Luzio Date: Thu, 3 Oct 2024 13:46:20 -0400 Subject: [PATCH 23/66] Fix comma --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index fb28dcdb..fc7a170f 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -126,7 +126,7 @@ tBTC is an open membership system, where the BTC is managed by a rotating set of ### [RBTC](https://rootstock.io/static/a79b27d4889409602174df4710102056/RS-whitepaper.pdf) -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. +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 From 4c899423b6c3da6d8cba001ef005b19b6d856a98 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Thu, 3 Oct 2024 18:19:53 -0700 Subject: [PATCH 24/66] Update sips/sip-028/sip-028-sbtc_peg.md Co-authored-by: _jiga --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index fc7a170f..7ca57e08 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -32,7 +32,7 @@ This SIP outlines but does not describe in technical detail the workings of the |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **SIP-10 Token** | A token on the Stacks blockchain that adheres to the fungible token standards outlined in [SIP-10](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). | | **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 smart contract function call that initiates some action from the sBTC protocol. | +| **sBTC operation** | A smart contract function call 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. | From 394dc2b43a60c939272f556a332b65bedd6ee3d1 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Thu, 3 Oct 2024 18:20:10 -0700 Subject: [PATCH 25/66] Update sips/sip-028/sip-028-sbtc_peg.md Co-authored-by: _jiga --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 7ca57e08..5050a612 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -2,7 +2,7 @@ **SIP Number:** 028 **Title:** Signer Criteria for sBTC, A Decentralized and Programmable Asset Backed 1:1 with BTC -**Consideration:** Technical, Economics +**Consideration:** Technical, Economic **Type:** Standard **Status:** Draft **Authors:** From 06647014f264de02a0f09158c54c40c1d9e31847 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Thu, 3 Oct 2024 18:20:27 -0700 Subject: [PATCH 26/66] Update sips/sip-028/sip-028-sbtc_peg.md Co-authored-by: _jiga --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 5050a612..c70e2f91 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -39,7 +39,7 @@ This SIP outlines but does not describe in technical detail the workings of the | **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. | +| **Deposit API** | A third-party API that communicates with the sBTC Signers via the sBTC Signer API. | ## Problem Statement From cdb1fae89d44cab2faae8c822efb5c67ea3ac8fa Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Thu, 3 Oct 2024 18:20:42 -0700 Subject: [PATCH 27/66] Update sips/sip-028/sip-028-sbtc_peg.md Co-authored-by: _jiga --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index c70e2f91..d7a89339 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -87,7 +87,7 @@ Overview of tasks the sBTC signers carry out: - Complete deposit and withdrawal requests in a timely manner. - Maintain industry standard operational security around any hosts and private data (to include private keys). - Move BTC to a new UTXO when private keys are rotated. -- Signers must perform UTXO consolidate as it is deposited [1]. +- Signers must perform UTXO consolidation as it is deposited [1]. - Signers must deduct transaction fees from users in order to fund BTC withdrawal transactions: - Ensure that the transaction fee is paid for (e.g., they deduct it from the user, and they set a minimum sBTC withdrawal amount). - Transaction fee must be estimated proportionally for the requested operation [2]. From fc01fe6b2e206d4cec18ab9dd45f2201483f2dfe Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Thu, 3 Oct 2024 18:21:24 -0700 Subject: [PATCH 28/66] Update sips/sip-028/sip-028-sbtc_peg.md Co-authored-by: _jiga --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index d7a89339..bac90289 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -106,7 +106,7 @@ The following eligibility criteria will be used to identify the sBTC Signers: - Does the proposed sBTC signer agree to use reasonable efforts to maintain >99% uptime on the sBTC Signer? *Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity.* - Does the proposed sBTC signer commit to a direct communication channel to be set up with the sBTC core engineers in order to respond to urgent updates within 24 hours? -- 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/issue, providing feedback on Stacks core development, or contributing to a Stacks working group. +- 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/issue, 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. From cacede5c8ab5a6ec457c877bfec18859e2748021 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Thu, 3 Oct 2024 18:23:56 -0700 Subject: [PATCH 29/66] Remove outdated link --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index bac90289..5e8257f4 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -93,7 +93,7 @@ Overview of tasks the sBTC signers carry out: - Transaction fee must be estimated proportionally for the requested operation [2]. - Collectively, the signers must coordinate to calculate and advertise the fee parameters of the system: - A minimum sBTC peg-out. - - 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](#auxiliary-features) section of this document. + - STX transaction fee for minting the sBTC. This fee is paid by the user and can be sponsored by a 3rd party. ### sBTC Signer Eligibility Criteria From bf05f2466ba418791cdac460270de77f4355c4ce Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Fri, 4 Oct 2024 07:57:00 -0700 Subject: [PATCH 30/66] Update sips/sip-028/sip-028-sbtc_peg.md Co-authored-by: _jiga --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 5e8257f4..ea13b94a 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -101,7 +101,7 @@ Signers will run the sBTC binary in addition to the core Stacks signer software The following eligibility criteria will be used to identify the sBTC Signers: -- Does the proposed sBTC signer have a demonstratable operating history which shows their experience and reliability in running blockchain services? +- Does the proposed sBTC signer have a demonstrable operating history which shows their experience and reliability in running blockchain services? - Has the proposed sBTC signer participated in running a Stacks signer instance on Stacks 2.5 testnet or mainnet, and can they provide metrics showing this (ex: amount of stacks stacked over past several cycles)? - Does the proposed sBTC signer agree to use reasonable efforts to maintain >99% uptime on the sBTC Signer? *Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity.* From cbcd4cb2c1a18d1630634ac0a97a81e470bf8125 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Fri, 4 Oct 2024 07:58:37 -0700 Subject: [PATCH 31/66] Update sips/sip-028/sip-028-sbtc_peg.md Co-authored-by: _jiga --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index ea13b94a..55af4dc6 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -71,7 +71,7 @@ While the first sBTC implementation is under development, the wrapped nature of ## Specification -Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by the proposed set of signers through a democratic process, 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. +Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by the proposed set of signers through a democratic process, 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 are 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. From 8ad1b34a625048f03b602851e5deec36d051cc1f Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Fri, 4 Oct 2024 13:07:53 -0400 Subject: [PATCH 32/66] Changed to Stacks 3.0 --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 55af4dc6..1af89890 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -130,7 +130,7 @@ rBTC, Rootstock’s (RSK) 2-way peg protocol, called “the Powpeg”, is a clos ## Activation -sBTC is designed to activate on Stacks Nakamoto as defined in [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). 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. +sBTC is designed to activate on Stacks 3.0 as defined in [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). 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 From 527e031085d05f25a5ec7f77ba57d1380ebcfce0 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Fri, 4 Oct 2024 13:12:37 -0400 Subject: [PATCH 33/66] Reordered SIP authors --- sips/sip-028/sip-028-sbtc_peg.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 1af89890..5890faeb 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -6,15 +6,16 @@ **Type:** Standard **Status:** Draft **Authors:** -- Mårten Blankfors ([marten@trustmachines.co](mailto:marten@trustmachines.co)) +- Adriano Di Luzio ([adriano@bitcoinl2labs.com](mailto@adriano@bitcoinl2labs.com)) +- Andre Serrano ([andre@bitcoinl2labs.com](mailto:andre@bitcoinl2labs.com)) +- Ashton Stephens ([ashton@trustmachines.co](mailto:ashton@trustmachines.co)) - Daniel Jordon ([daniel@trustmachines.co](mailto:daniel@trustmachines.co)) - Friedger Müffke ([friedger@ryder.id](mailto:friedger@ryder.id)) - Jesus Najera ([jesus@stratalabs.xyz](mailto:jesus@stratalabs.xyz)) +- Joey Yandle ([joey@trustmachines.co](mailto:joey@trustmachines.co)) - Jude Nelson ([jude@stacks.org](mailto:jude@stacks.org)) +- Mårten Blankfors ([marten@trustmachines.co](mailto:marten@trustmachines.co)) - Tycho Onnasch ([tycho@zestprotocol.com](mailto:tycho@zestprotocol.com)) -- Andre Serrano ([andre@bitcoinl2labs.com](mailto:andre@bitcoinl2labs.com)) -- Ashton Stephens ([ashton@trustmachines.co](mailto:ashton@trustmachines.co)) -- Joey Yandle ([joey@trustmachines.co](mailto:joey@trustmachines.co)) ## Abstract From 37f8e1c667255914682eb14c722e2b88f4b8296a Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Fri, 4 Oct 2024 15:35:39 -0400 Subject: [PATCH 34/66] Fixed formatting in the deposit flow --- sips/sip-028/sip-028-sbtc_peg.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 5890faeb..a4409d79 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -181,13 +181,13 @@ The act of not voting is the act of siding with the outcome, whatever it may be. The main steps of the sBTC Deposit flow will be as follows: 1. **Deposit request:** A bitcoin holder creates a transaction on Bitcoin. -2. The deposit transaction contains a UTXO (deposit UTXO) spendable by sBTC Signers, with an OP_DROP payload. -3. The payload contains the recipient address of the sBTC among other relevant info for the deposit. +- 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. -4. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Deposit API. -5. **Deposit accept:** -6. **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. -7. **Mint:** The sBTC Signers finalize the deposit acceptance making a Clarity contract call that mints the sBTC on the Stacks Layer. +2. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Deposit API. +3. **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) From 79451a514fc6467d38ddf9fb5b50f299de60034d Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Fri, 4 Oct 2024 15:56:28 -0400 Subject: [PATCH 35/66] Updated Preamble Changes: - Type to Operation because it includes nodes and miners - Consideration to Governance because it involves the governance of how signers are selected. - General formatting --- sips/sip-028/sip-028-sbtc_peg.md | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index a4409d79..91c592ac 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -1,10 +1,9 @@ -# SIP-028: sBTC Signer Criteria +# Preamble **SIP Number:** 028 + **Title:** Signer Criteria for sBTC, A Decentralized and Programmable Asset Backed 1:1 with BTC -**Consideration:** Technical, Economic -**Type:** Standard -**Status:** Draft + **Authors:** - Adriano Di Luzio ([adriano@bitcoinl2labs.com](mailto@adriano@bitcoinl2labs.com)) - Andre Serrano ([andre@bitcoinl2labs.com](mailto:andre@bitcoinl2labs.com)) @@ -17,6 +16,22 @@ - Mårten Blankfors ([marten@trustmachines.co](mailto:marten@trustmachines.co)) - Tycho Onnasch ([tycho@zestprotocol.com](mailto:tycho@zestprotocol.com)) +**Consideration:** Governance + +**Type:** Operation + +**Status:** Draft + +**Created:** 2024-06-21 + +**License:** BSD 2-Clause + +**Sign-off:** +- Andre Serrano andre@bitcoinl2labs.com (SIP Editor) +- Jason Schrader jason@joinfreehold.com (Governance CAB) +- Jude Nelson jude@stacks.org (Steering Committee) + + ## Abstract This SIP proposes 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](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on [threshold signatures](https://eprint.iacr.org/2020/852.pdf), 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. From 888948e0e2c764e27ce282d8db2dff19b470632b Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Fri, 4 Oct 2024 16:00:58 -0400 Subject: [PATCH 36/66] Added Discussions-To Preamble --- sips/sip-028/sip-028-sbtc_peg.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 91c592ac..d88a0bfc 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -31,6 +31,8 @@ - Jason Schrader jason@joinfreehold.com (Governance CAB) - Jude Nelson jude@stacks.org (Steering Committee) +**Discussions-To:** +- [sBTC Working Group Discussions](https://github.com/stacks-network/sbtc/discussions) ## Abstract From 92acc6af2e26bd247ac1289fafbdf0f2eb02af2d Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Fri, 4 Oct 2024 16:02:14 -0400 Subject: [PATCH 37/66] Formatting --- sips/sip-028/sip-028-sbtc_peg.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index d88a0bfc..fac53fc7 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -198,13 +198,13 @@ The act of not voting is the act of siding with the outcome, whatever it may be. The main steps of the sBTC Deposit flow will be as follows: 1. **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. + - 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. 2. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Deposit API. 3. **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. + - **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) From 09944a5ecc79ca0852b3ef2cea9e2b7c407d1644 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 7 Oct 2024 14:19:41 -0400 Subject: [PATCH 38/66] Update to the sBTC Signer selection process --- sips/sip-028/sip-028-sbtc_peg.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index fac53fc7..0b71ab1e 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -129,8 +129,17 @@ The following eligibility criteria will be used to identify the sBTC Signers: 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 initial sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria. The results will be published as a dicussion in the [sBTC Working Group](https://github.com/stacks-network/sbtc/discussions/624). + +The selection process is as follows: +1. **Nomination Phase**: Open a call for nominations within the community. +2. **Evaluation & Community Feedback**: The proposed signer set will be published to provide transparency. +3. **SIP Vote**: The community will vote on the signer criteria and proposed signer set. +4. **Final Selection**: The final list of signers will be selected based on community feedback and successful completion of SIP-028. + +### Updating The sBTC Signer Set +In the event that the sBTC Signer Set needs to be updated (for example, if a signer is no longer available to complete their responsibilities) sBTC Signers can perform a threshold vote to agree on the updated set. This process will also be performed if a signer needs to rotate their cryptographic keys. -The sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria, by the [sBTC working group](https://github.com/orgs/stacks-network/discussions/469). 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 From f577ec773974c15165049ee6bb00fda3caef13ea Mon Sep 17 00:00:00 2001 From: Adriano Di Luzio Date: Mon, 7 Oct 2024 14:20:59 -0400 Subject: [PATCH 39/66] Fix typo --- sips/sip-028/sip-028-sbtc_peg.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 0b71ab1e..83f21448 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -129,16 +129,16 @@ The following eligibility criteria will be used to identify the sBTC Signers: 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 initial sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria. The results will be published as a dicussion in the [sBTC Working Group](https://github.com/stacks-network/sbtc/discussions/624). +The initial sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria. The results will be published as a discussion in the [sBTC Working Group](https://github.com/stacks-network/sbtc/discussions/624). The selection process is as follows: -1. **Nomination Phase**: Open a call for nominations within the community. +1. **Nomination Phase**: Open a call for nominations within the community. 2. **Evaluation & Community Feedback**: The proposed signer set will be published to provide transparency. 3. **SIP Vote**: The community will vote on the signer criteria and proposed signer set. 4. **Final Selection**: The final list of signers will be selected based on community feedback and successful completion of SIP-028. ### Updating The sBTC Signer Set -In the event that the sBTC Signer Set needs to be updated (for example, if a signer is no longer available to complete their responsibilities) sBTC Signers can perform a threshold vote to agree on the updated set. This process will also be performed if a signer needs to rotate their cryptographic keys. +In the event that the sBTC Signer Set needs to be updated (for example, if a signer is no longer available to complete their responsibilities) sBTC Signers can perform a threshold vote to agree on the updated set. This process will also be performed if a signer needs to rotate their cryptographic keys. ## Related Work From 3aece3aad3fab822bf7ef7056a07990f02b73c05 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 7 Oct 2024 17:20:25 -0400 Subject: [PATCH 40/66] Added note to spec referencing appendix --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 83f21448..4447f3c2 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -91,7 +91,7 @@ While the first sBTC implementation is under development, the wrapped nature of Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by the proposed set of signers through a democratic process, 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 are 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. +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. Additionally, more details on sBTC deposit and withdrawals are included in the appendix of this SIP. Throughout this release, sBTC will have an unchangeable and distinct signer set that will not explicitly be part of Stacks consensus. Given that there will be 15 unique signers that shall comprise the system, and each unique signer is allocated exactly one vote, it would require at least 11 out of 15 signatures for an sBTC operation to be fulfilled. From 0abe397308d1a59f71501bae6be32d0681abccd8 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 8 Oct 2024 17:21:24 -0400 Subject: [PATCH 41/66] Update related works --- sips/sip-028/sip-028-sbtc_peg.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 4447f3c2..525a0564 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -153,7 +153,13 @@ tBTC is an open membership system, where the BTC is managed by a rotating set of ### [RBTC](https://rootstock.io/static/a79b27d4889409602174df4710102056/RS-whitepaper.pdf) -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. +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 (roughly 200 Bitcoin Blocks). + +This new system shares similarities with existing models but introduces some key distinctions: +- **Decentralized Custody**: sBTC is secured by a decentralized network of signers rather than a central custodian. +- **Permissionless Minting**: Any user is able to initiate mint and redeem requests. +- **Faster Deposit & Withdrawal Times**: sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through [Stacks 3.0]((https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which inherits finality from Bitcoin. +- **Bitcoin-Aligned Solution**: Unlike models built on Ethereum or EVM-compatible platforms, sBTC fills the gap for users seeking a solution that iterates on these systems and directly aligns with Bitcoin's security principles. ## Activation From c358f81d57658783a6c7c5756ac781e59d41ab56 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 8 Oct 2024 17:40:13 -0400 Subject: [PATCH 42/66] Added note on the Stacks event observer --- sips/sip-028/sip-028-sbtc_peg.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 525a0564..246ffb09 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -121,8 +121,9 @@ The following eligibility criteria will be used to identify the sBTC Signers: - Does the proposed sBTC signer have a demonstrable operating history which shows their experience and reliability in running blockchain services? - Has the proposed sBTC signer participated in running a Stacks signer instance on Stacks 2.5 testnet or mainnet, and can they provide metrics showing this (ex: amount of stacks stacked over past several cycles)? -- Does the proposed sBTC signer agree to use reasonable efforts to maintain >99% uptime on the sBTC Signer? - *Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity.* + * Note: The sBTC signer is a Stacks event observer, meaning that the experience of running a Stacks node signer directly translates to running an sBTC signer. +- Does the proposed sBTC signer agree to use reasonable efforts to maintain >99% uptime on the sBTC Signer? + * Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity.* - Does the proposed sBTC signer commit to a direct communication channel to be set up with the sBTC core engineers in order to respond to urgent updates within 24 hours? - 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/issue, providing feedback on Stacks core development, or contributing to a Stacks Working Group. From 95a12a1514bcdb3564a3e4e1cab8b35402f6d3b2 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Thu, 10 Oct 2024 04:52:46 -0700 Subject: [PATCH 43/66] Reword sBTC signer set def. https://github.com/stacksgov/sips/pull/186/files/75dc1fcb8b93899ebe2bf0205d1b3bf8196a1712#r1688507188 --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 246ffb09..9e184e3c 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -55,7 +55,7 @@ This SIP outlines but does not describe in technical detail the workings of the | **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 Set** | The set of all sBTC signers. Each is registered with the .sbtc contract and these entities as a group collectively maintain the sBTC's Bitcoin 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. | From bbfd9c74edea3b24478b50613e15bc1b6bd35c41 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 10:14:55 -0400 Subject: [PATCH 44/66] Fixed typo trailing asterisk --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 9e184e3c..8f2f07e8 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -123,7 +123,7 @@ The following eligibility criteria will be used to identify the sBTC Signers: - Has the proposed sBTC signer participated in running a Stacks signer instance on Stacks 2.5 testnet or mainnet, and can they provide metrics showing this (ex: amount of stacks stacked over past several cycles)? * Note: The sBTC signer is a Stacks event observer, meaning that the experience of running a Stacks node signer directly translates to running an sBTC signer. - Does the proposed sBTC signer agree to use reasonable efforts to maintain >99% uptime on the sBTC Signer? - * Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity.* + * Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity. - Does the proposed sBTC signer commit to a direct communication channel to be set up with the sBTC core engineers in order to respond to urgent updates within 24 hours? - 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/issue, providing feedback on Stacks core development, or contributing to a Stacks Working Group. From 6dca8270c37b0ccb82797ec950c5449cfa41ba62 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 10:19:59 -0400 Subject: [PATCH 45/66] Removed "Bitcoin Alignment" from Related Work --- sips/sip-028/sip-028-sbtc_peg.md | 1 - 1 file changed, 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 8f2f07e8..d2b1e5b7 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -160,7 +160,6 @@ This new system shares similarities with existing models but introduces some key - **Decentralized Custody**: sBTC is secured by a decentralized network of signers rather than a central custodian. - **Permissionless Minting**: Any user is able to initiate mint and redeem requests. - **Faster Deposit & Withdrawal Times**: sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through [Stacks 3.0]((https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which inherits finality from Bitcoin. -- **Bitcoin-Aligned Solution**: Unlike models built on Ethereum or EVM-compatible platforms, sBTC fills the gap for users seeking a solution that iterates on these systems and directly aligns with Bitcoin's security principles. ## Activation From 8dcdf9ee2443476091701c13cc4426b62a993377 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 10:24:20 -0400 Subject: [PATCH 46/66] Updated selection process --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index d2b1e5b7..9cb65b2b 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -130,7 +130,7 @@ The following eligibility criteria will be used to identify the sBTC Signers: 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 initial sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria. The results will be published as a discussion in the [sBTC Working Group](https://github.com/stacks-network/sbtc/discussions/624). +The initial sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria. The results will be published as a discussion in the [sBTC Working Group](https://github.com/stacks-network/sbtc/discussions/624). The signer set the community votes on will be the signer set for sBTC. No further additions or removals will be done once the SIP vote begins. If a signer withdraws, then the vote should be restarted. The selection process is as follows: 1. **Nomination Phase**: Open a call for nominations within the community. From 7fbef8d6e6235f36baef161df4443c7404845577 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 10:35:03 -0400 Subject: [PATCH 47/66] Updated specification of sBTC signer set --- sips/sip-028/sip-028-sbtc_peg.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 9cb65b2b..f98d5957 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -89,12 +89,10 @@ While the first sBTC implementation is under development, the wrapped nature of ## Specification -Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by the proposed set of signers through a democratic process, 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 are determined through the community governance process of ratifying this SIP. +Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by the proposed set of signers through a democratic process, 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 and each unique signer is allocated exactly one vote. The system requires at least 70%, or 11 out of 15 signatures, for an sBTC operation to be fulfilled. The eligibility criteria to become an sBTC Signer are determined through the community governance process of ratifying this SIP. For this release, sBTC will not be part of Stacks consensus. 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. Additionally, more details on sBTC deposit and withdrawals are included in the appendix of this SIP. -Throughout this release, sBTC will have an unchangeable and distinct signer set that will not explicitly be part of Stacks consensus. Given that there will be 15 unique signers that shall comprise the system, and each unique signer is allocated exactly one vote, 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 reclaimable by the user after a timeout has elapsed. The timeout is specified by the user when preparing the deposit request and is measured in Bitcoin blocks. ### sBTC Signer Responsibilities From 0b5a719e3662f9e355a2bcc784a20a7ba47f3c5a Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 16:49:45 -0400 Subject: [PATCH 48/66] Updated signer responsibilities --- sips/sip-028/sip-028-sbtc_peg.md | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index f98d5957..fa4fc1e3 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -96,20 +96,23 @@ sBTC Signers are responsible for accepting or rejecting all sBTC deposit and wit 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 reclaimable by the user after a timeout has elapsed. The timeout is specified by the user when preparing the deposit request and is measured in Bitcoin blocks. ### sBTC Signer Responsibilities - -Overview of tasks the sBTC signers carry out: -- Accept requests to deposit BTC. -- Fulfill requests to withdraw BTC. -- Complete deposit and withdrawal requests in a timely manner. -- Maintain industry standard operational security around any hosts and private data (to include private keys). -- Move BTC to a new UTXO when private keys are rotated. -- Signers must perform UTXO consolidation as it is deposited [1]. -- Signers must deduct transaction fees from users in order to fund BTC withdrawal transactions: - - Ensure that the transaction fee is paid for (e.g., they deduct it from the user, and they set a minimum sBTC withdrawal amount). - - Transaction fee must be estimated proportionally for the requested operation [2]. -- Collectively, the signers must coordinate to calculate and advertise the fee parameters of the system: - - A minimum sBTC peg-out. - - STX transaction fee for minting the sBTC. This fee is paid by the user and can be sponsored by a 3rd party. +The sBTC signers play a critical role in the security and operations of the sBTC system. Their responsibilities can be grouped into two categories: tasks mandated by the sBTC protocol and operational best practices to effectively manage the sBTC system. + +**Protocol-Mandated Tasks:** +- Signers must accept and process BTC deposit requests. +- They must fulfill BTC withdrawal requests in a timely manner, ensuring accurate execution. +- Signers are responsible for moving BTC to a new UTXO when private keys are rotated. +- Signers must perform UTXO consolidation as BTC is deposited to optimize the number of unspent outputs [1]. +- Signers are required to deduct transaction fees from users to fund BTC withdrawal transactions. This includes: + - Ensuring that the transaction fee is deducted from the user. + - Setting a minimum sBTC withdrawal amount to cover the estimated transaction fees. + - Estimating the transaction fee proportionally based on the requested operation [2]. + +**Operational Best Practices:** +- Signers must maintain industry-standard operational security (opsec) around hosts and private data, including private keys. +- They should collectively coordinate to calculate and advertise the fee parameters of the system, including: + - The minimum sBTC peg-out amount. + - The STX transaction fee for minting sBTC. This fee is paid by the user and can be sponsored by a 3rd party. ### sBTC Signer Eligibility Criteria From cfbf68c2ffdc1ffdddf3341fffe8ad359d24e7c0 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 17:01:53 -0400 Subject: [PATCH 49/66] Fixed typo --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index fa4fc1e3..be53b6e5 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -160,7 +160,7 @@ rBTC, Rootstock’s (RSK) 2-way peg protocol, called “the Powpeg”, is a clos This new system shares similarities with existing models but introduces some key distinctions: - **Decentralized Custody**: sBTC is secured by a decentralized network of signers rather than a central custodian. - **Permissionless Minting**: Any user is able to initiate mint and redeem requests. -- **Faster Deposit & Withdrawal Times**: sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through [Stacks 3.0]((https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which inherits finality from Bitcoin. +- **Faster Deposit & Withdrawal Times**: sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which inherits finality from Bitcoin. ## Activation From 3d680c1a2c2061a1c7ac8aa7622298e19b488621 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 17:14:20 -0400 Subject: [PATCH 50/66] Add details on sBTC WG to Selection Process --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index be53b6e5..e75547c6 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -131,7 +131,7 @@ The following eligibility criteria will be used to identify the sBTC Signers: 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 initial sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria. The results will be published as a discussion in the [sBTC Working Group](https://github.com/stacks-network/sbtc/discussions/624). The signer set the community votes on will be the signer set for sBTC. No further additions or removals will be done once the SIP vote begins. If a signer withdraws, then the vote should be restarted. +The sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria. The [sBTC Working Group](https://github.com/orgs/stacks-network/discussions/508) will conduct the vetting process and the results will be published as a discussion in the [sBTC Github repository](https://github.com/stacks-network/sbtc/discussions/624). The signer set the community votes on will be the signer set for sBTC. No further additions or removals will be done once the SIP vote begins. If a signer withdraws, then the vote should be restarted. The selection process is as follows: 1. **Nomination Phase**: Open a call for nominations within the community. From 6a13de4f2a6a05d76e1f69bd490168afa4399044 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 18:10:59 -0400 Subject: [PATCH 51/66] Updated related work --- sips/sip-028/sip-028-sbtc_peg.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index e75547c6..a7a6fd44 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -147,20 +147,21 @@ In the event that the sBTC Signer Set needs to be updated (for example, if a sig ### [WBTC](https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf) -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. +**WBTC** is a closed membership system 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. Until recently, BTC was held in a Bitcoin multi-sig wallet secured solely by BitGo. Now, two of the three multi-sig keys are held by BitGo, while one is held by BiT Global. ### [tBTC v2](https://whitepaper.io/document/691/tbtc-whitepaper) -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. +**tBTC** is an ERC-20 wrapped asset launched in May 2020. BTC is currently held and secured by a permissioned set of 35 Beta Staker Nodes from the Threshold Network. Seven DeFi protocols including Aave and Synthetix manage the minting and burning process, with Guardians monitoring to veto suspicious behavior. tBTC is natively minted on Ethereum and Arbitrum. ### [RBTC](https://rootstock.io/static/a79b27d4889409602174df4710102056/RS-whitepaper.pdf) -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 (roughly 200 Bitcoin Blocks). +**rBTC** is a wrapped BTC asset natively minted on Rootstock, an EVM-compatible sidechain. BTC is secured by a 5-of-9 multi-sig Bitcoin wallet controlled by the Powpeg Federation. Peg operations settle to Bitcoin via merge mining. 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 (roughly 200 Bitcoin Blocks). This new system shares similarities with existing models but introduces some key distinctions: - **Decentralized Custody**: sBTC is secured by a decentralized network of signers rather than a central custodian. -- **Permissionless Minting**: Any user is able to initiate mint and redeem requests. -- **Faster Deposit & Withdrawal Times**: sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which inherits finality from Bitcoin. +- **Bitcoin Finality** sBTC inhereits Bitcoin finality from [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which ensures that sBTC transactions receive the same level of security provided by the Bitcoin network. +- **Faster Deposit & Withdrawal Times**: sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through the finality rules described above in [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). + ## Activation From 558713ef63e0c5244dcc32c4248990715d5b148d Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 18:13:47 -0400 Subject: [PATCH 52/66] Add link to voting page --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index a7a6fd44..e9c64038 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -197,7 +197,7 @@ Solo stackers only can also vote by sending a bitcoin dust transaction (6000 sat #### 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. +Users with liquid STX can vote on proposals directly at [sbtc.vote](sbtc.vote) 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](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md). From 24c82ba445d3efb0b79f97a5597382bf1f9a8750 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 14 Oct 2024 18:16:48 -0400 Subject: [PATCH 53/66] typo --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index e9c64038..4bfa5463 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -197,7 +197,7 @@ Solo stackers only can also vote by sending a bitcoin dust transaction (6000 sat #### For Non-Stackers: -Users with liquid STX can vote on proposals directly at [sbtc.vote](sbtc.vote) 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. +Users with liquid STX can vote on proposals directly at [sBTC.vote](https://sbtc.vote) 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](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md). From 49557ae7ce3840a83e2c241c947493bef0510df5 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 15 Oct 2024 09:53:50 -0400 Subject: [PATCH 54/66] Update sip-028-sbtc_peg.md --- sips/sip-028/sip-028-sbtc_peg.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 4bfa5463..bf172915 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -75,7 +75,7 @@ sBTC aims to mitigate Bitcoin’s limitations by combining the capability of the ### Fast Blocks -The Stacks Nakamoto Upgrade, proposed in [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#proposed-solution), 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 Stacks Nakamoto Upgrade, proposed in [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#proposed-solution), enables fast blocks where user-submitted transactions will now take on the order of seconds, instead of tens of minutes. Thus, sBTC on Stacks will offer an improvement to Bitcoin’s current transaction times. The sBTC protocol not only addresses the limitations of Bitcoin's scripting system but also provides a secure and decentralized solution for utilizing Bitcoin in various applications. @@ -136,7 +136,7 @@ The sBTC Signer Set will be finalized from the list of eligible Signers, based o The selection process is as follows: 1. **Nomination Phase**: Open a call for nominations within the community. 2. **Evaluation & Community Feedback**: The proposed signer set will be published to provide transparency. -3. **SIP Vote**: The community will vote on the signer criteria and proposed signer set. +3. **SIP Vote**: The community will vote on the sBTC signer criteria. 4. **Final Selection**: The final list of signers will be selected based on community feedback and successful completion of SIP-028. ### Updating The sBTC Signer Set @@ -158,9 +158,9 @@ In the event that the sBTC Signer Set needs to be updated (for example, if a sig **rBTC** is a wrapped BTC asset natively minted on Rootstock, an EVM-compatible sidechain. BTC is secured by a 5-of-9 multi-sig Bitcoin wallet controlled by the Powpeg Federation. Peg operations settle to Bitcoin via merge mining. 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 (roughly 200 Bitcoin Blocks). This new system shares similarities with existing models but introduces some key distinctions: -- **Decentralized Custody**: sBTC is secured by a decentralized network of signers rather than a central custodian. -- **Bitcoin Finality** sBTC inhereits Bitcoin finality from [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which ensures that sBTC transactions receive the same level of security provided by the Bitcoin network. -- **Faster Deposit & Withdrawal Times**: sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through the finality rules described above in [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). +- **Decentralized Custody:** sBTC is secured by a decentralized network of signers rather than a central custodian. +- **Bitcoin Finality:** sBTC inhereits Bitcoin finality from [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which ensures that sBTC transactions receive the same level of security provided by the Bitcoin network. +- **Faster Deposit & Withdrawal Times:** sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through the finality rules described in [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). ## Activation @@ -169,7 +169,7 @@ sBTC is designed to activate on Stacks 3.0 as defined in [SIP-021](https://githu ### 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. +Users can vote to approve this SIP with either their locked/stacked STX or with unlocked/liquid STX, or both. The SIP voting page can be found at [sbtc.vote](https://sbtc.vote). The criteria for the stacker and non-stacker voting is as follows. #### For Stackers: From 3266c2a13e3c8ba059c8253e68d84ccaa96fd491 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 15 Oct 2024 09:57:53 -0400 Subject: [PATCH 55/66] Updated Spec liveness details --- sips/sip-028/sip-028-sbtc_peg.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index bf172915..d569dd40 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -93,7 +93,8 @@ Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by 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. Additionally, more details on sBTC deposit and withdrawals are included in the appendix of this SIP. -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 reclaimable by the user after a timeout has elapsed. The timeout is specified by the user when preparing the deposit request and is measured in Bitcoin blocks. +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. To protect users from a liveness failure during deposit, a deposit UTXO shall be made satisfiable by one of two spending conditions: (1) the signer set spends the UTXO, or (2) the user spends the UTXO after a fixed number of Bitcoin blocks have passed. Then, if there is an indefinite liveness failure, users will be able to reclaim their in-flight BTC [3]. + ### sBTC Signer Responsibilities The sBTC signers play a critical role in the security and operations of the sBTC system. Their responsibilities can be grouped into two categories: tasks mandated by the sBTC protocol and operational best practices to effectively manage the sBTC system. @@ -208,6 +209,8 @@ The act of not voting is the act of siding with the outcome, whatever it may be. [2] https://github.com/stacks-network/sbtc/pull/186 +[3] https://github.com/stacks-network/sbtc/issues/30 + ### Specification #### Deposits From 0e94dbf487b5ab0dfe30c00b422f124cda68e194 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 15 Oct 2024 10:02:17 -0400 Subject: [PATCH 56/66] Updated Selection Process - Final Selection --- sips/sip-028/sip-028-sbtc_peg.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index d569dd40..c82d411f 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -132,14 +132,15 @@ The following eligibility criteria will be used to identify the sBTC Signers: 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. The [sBTC Working Group](https://github.com/orgs/stacks-network/discussions/508) will conduct the vetting process and the results will be published as a discussion in the [sBTC Github repository](https://github.com/stacks-network/sbtc/discussions/624). The signer set the community votes on will be the signer set for sBTC. No further additions or removals will be done once the SIP vote begins. If a signer withdraws, then the vote should be restarted. +The sBTC Signer Set will be finalized from the list of eligible Signers, based on the above criteria. The [sBTC Working Group](https://github.com/orgs/stacks-network/discussions/508) will conduct the vetting process and the results will be published as a discussion in the [sBTC Github repository](https://github.com/stacks-network/sbtc/discussions/624). The selection process is as follows: 1. **Nomination Phase**: Open a call for nominations within the community. 2. **Evaluation & Community Feedback**: The proposed signer set will be published to provide transparency. 3. **SIP Vote**: The community will vote on the sBTC signer criteria. -4. **Final Selection**: The final list of signers will be selected based on community feedback and successful completion of SIP-028. +4. **Final Selection**: If SIP-028 is ratified, then the proposed signer set voted upon in step 3 shall be the initial signing set for sBTC. If the signer set changes during the vote, such as by the withdrawal of one or more candidates, then the vote will be restarted in a subsequent reward cycle (to be determined if this comes to pass). + ### Updating The sBTC Signer Set In the event that the sBTC Signer Set needs to be updated (for example, if a signer is no longer available to complete their responsibilities) sBTC Signers can perform a threshold vote to agree on the updated set. This process will also be performed if a signer needs to rotate their cryptographic keys. From 5e3d0de8dcb1530ac7e047115e43485954c401d3 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Thu, 17 Oct 2024 11:43:46 -0400 Subject: [PATCH 57/66] Update Related Work --- sips/sip-028/sip-028-sbtc_peg.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index c82d411f..95b5da92 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -159,8 +159,19 @@ In the event that the sBTC Signer Set needs to be updated (for example, if a sig **rBTC** is a wrapped BTC asset natively minted on Rootstock, an EVM-compatible sidechain. BTC is secured by a 5-of-9 multi-sig Bitcoin wallet controlled by the Powpeg Federation. Peg operations settle to Bitcoin via merge mining. 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 (roughly 200 Bitcoin Blocks). -This new system shares similarities with existing models but introduces some key distinctions: -- **Decentralized Custody:** sBTC is secured by a decentralized network of signers rather than a central custodian. +The following table summarizes the main design differences between these systems: + +| Feature | WBTC | tBTC | rBTC | sBTC (this SIP) | +|------------------------|-----------------|------------------|------------------|--------------------| +| Spending threshold | 2 of 3 | 51 of 100 | 5 of 9 | 11 of 15 | +| Bitcoin finality | No | No | Yes | Yes | +| Expected Peg-in speed | 1 hour | 1-3 hours | 16 hours | 0.5 hours | +| Expected Peg-out speed | 1 hour | 3-5 hours | 33.3 hours | 1 hour | +| Custodian rotation | No | Yes | No | Yes | +| Fee structure | % of BTC moved | % of BTC moved | Transaction fees | Transaction fees | + + +In conclusion, the sBTC system shares similarities with existing models but introduces some key distinctions: - **Bitcoin Finality:** sBTC inhereits Bitcoin finality from [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which ensures that sBTC transactions receive the same level of security provided by the Bitcoin network. - **Faster Deposit & Withdrawal Times:** sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through the finality rules described in [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). From 2dfc68d59e67ffc85e359e2f1806658638699ce1 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Thu, 17 Oct 2024 14:59:00 -0400 Subject: [PATCH 58/66] Update sip-028-sbtc_peg.md --- sips/sip-028/sip-028-sbtc_peg.md | 1 - 1 file changed, 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 95b5da92..0e7f0eb2 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -27,7 +27,6 @@ **License:** BSD 2-Clause **Sign-off:** -- Andre Serrano andre@bitcoinl2labs.com (SIP Editor) - Jason Schrader jason@joinfreehold.com (Governance CAB) - Jude Nelson jude@stacks.org (Steering Committee) From 505ee4431c43ae5c1f7d9f6e41701ab236154092 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Tue, 22 Oct 2024 13:26:54 -0700 Subject: [PATCH 59/66] spelling typo --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 0e7f0eb2..26b41611 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -171,7 +171,7 @@ The following table summarizes the main design differences between these systems In conclusion, the sBTC system shares similarities with existing models but introduces some key distinctions: -- **Bitcoin Finality:** sBTC inhereits Bitcoin finality from [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which ensures that sBTC transactions receive the same level of security provided by the Bitcoin network. +- **Bitcoin Finality:** sBTC inherits Bitcoin finality from [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md), which ensures that sBTC transactions receive the same level of security provided by the Bitcoin network. - **Faster Deposit & Withdrawal Times:** sBTC enables BTC withdrawals without the long delays associated with block confirmations in other systems. This is achieved through the finality rules described in [Stacks 3.0](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md). From 02df3fde8c1d84c0a280a120edda322285503ee4 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Thu, 24 Oct 2024 14:20:47 -0400 Subject: [PATCH 60/66] Added geographic distribution to criteria --- sips/sip-028/sip-028-sbtc_peg.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 26b41611..c1bb6053 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -127,6 +127,7 @@ The following eligibility criteria will be used to identify the sBTC Signers: * Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity. - Does the proposed sBTC signer commit to a direct communication channel to be set up with the sBTC core engineers in order to respond to urgent updates within 24 hours? - 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/issue, providing feedback on Stacks core development, or contributing to a Stacks Working Group. +- Does the geographic distribution of the proposed sBTC signer support a diverse and distributed signer set? 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. From 264382c68009261e1e17be7fe75483bf58deacba Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Thu, 24 Oct 2024 14:32:03 -0400 Subject: [PATCH 61/66] Update glossary and abstract --- sips/sip-028/sip-028-sbtc_peg.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index c1bb6053..66e4af4a 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -35,7 +35,7 @@ ## Abstract -This SIP proposes 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](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on [threshold signatures](https://eprint.iacr.org/2020/852.pdf), 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 SIP proposes a new wrapped Bitcoin asset, called sBTC, which would be implemented on Stacks as a SIP-010 token. sBTC enables seamless and secure integration of Bitcoin into the Stacks ecosystem, unlocking decentralized applications and expanding Bitcoin's utility through smart contracts. Stacks today offers a smart contract runtime for Stacks-hosted assets, and the forthcoming Stacks [3.0 release](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on [threshold signatures](https://eprint.iacr.org/2020/852.pdf), 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. @@ -57,6 +57,7 @@ This SIP outlines but does not describe in technical detail the workings of the | **sBTC Signer Set** | The set of all sBTC signers. Each is registered with the .sbtc contract and these entities as a group collectively maintain the sBTC's Bitcoin 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. | +| **Wrapped Bitcoin** | A tokenized version of Bitcoin on another blockchain, designed to maintain a 1:1 peg with BTC. It acts as a derivative asset that allows Bitcoin to be utilized in various decentralized applications and ecosystems. | ## Problem Statement @@ -214,7 +215,7 @@ Users with liquid STX can vote on proposals directly at [sBTC.vote](https://sbtc 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](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md). -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. +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 [1] https://github.com/stacks-network/sbtc/issues/52 From 919514d64a8605b50bab992e7350df770dde2bb7 Mon Sep 17 00:00:00 2001 From: wileyj <2847772+wileyj@users.noreply.github.com> Date: Fri, 25 Oct 2024 09:10:14 -0700 Subject: [PATCH 62/66] Update sips/sip-028/sip-028-sbtc_peg.md Co-authored-by: Ashton Stephens --- sips/sip-028/sip-028-sbtc_peg.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 66e4af4a..cd717875 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -232,8 +232,7 @@ The main steps of the sBTC Deposit flow will be as follows: 1. **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. + - The payload contains the recipient address of the sBTC and the maximum fee the depositor is willing to have go towards the consolidation of the deposits into a single UTXO. 2. **Proof of deposit:** The bitcoin holder submits a proof of deposit on Stacks by invoking the Deposit API. 3. **Deposit accept:** - **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. From 4332defb8df659dd6759b7991e146cda70caa1ab Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 28 Oct 2024 11:00:55 -0400 Subject: [PATCH 63/66] Typo: activation threshold --- sips/sip-028/sip-028-sbtc_peg.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index cd717875..c6d92615 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -189,7 +189,7 @@ Users can vote to approve this SIP with either their locked/stacked STX or with 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, with least 66% (48 million) voting "yes". +- At least 80 million Stacked STX must vote, with least 70% (56 million) voting "yes". The voting addresses will be: @@ -213,7 +213,7 @@ Solo stackers only can also vote by sending a bitcoin dust transaction (6000 sat Users with liquid STX can vote on proposals directly at [sBTC.vote](https://sbtc.vote) 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](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md). +For this SIP to pass, 70% of all liquid STX committed by voting must be in favor of the proposal. 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. From 157339f6e5ff6774e332e8a53be2dd0be65a3023 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 5 Nov 2024 10:44:16 -0500 Subject: [PATCH 64/66] Specify approval threshold for updating the signer set --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index c6d92615..cc3f759c 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -143,7 +143,7 @@ The selection process is as follows: ### Updating The sBTC Signer Set -In the event that the sBTC Signer Set needs to be updated (for example, if a signer is no longer available to complete their responsibilities) sBTC Signers can perform a threshold vote to agree on the updated set. This process will also be performed if a signer needs to rotate their cryptographic keys. +In the event that the sBTC Signer Set needs to be updated (for example, if a signer is no longer available to complete their responsibilities) sBTC Signers can perform a threshold vote to agree on the updated set, which would require the same 70% approval threshold as sBTC operations. This process will also be performed if a signer needs to rotate their cryptographic keys. ## Related Work From 4b96b8d508a50ca8a8395119755c5e2066f57f23 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Tue, 5 Nov 2024 12:19:23 -0500 Subject: [PATCH 65/66] Update Signer Specification --- sips/sip-028/sip-028-sbtc_peg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index cc3f759c..12602e98 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -93,7 +93,7 @@ Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by 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. Additionally, more details on sBTC deposit and withdrawals are included in the appendix of this SIP. -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. To protect users from a liveness failure during deposit, a deposit UTXO shall be made satisfiable by one of two spending conditions: (1) the signer set spends the UTXO, or (2) the user spends the UTXO after a fixed number of Bitcoin blocks have passed. Then, if there is an indefinite liveness failure, users will be able to reclaim their in-flight BTC [3]. +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 until at least 70% come back online and operational. In the event that 30% of signer set goes permanently offline, the BTC in the peg wallet will become locked. While not currently planned for the initial sBTC release, it is possible to add a clawback mechanism that would allow recovering the BTC. To protect users from a liveness failure during deposit, a deposit UTXO shall be made satisfiable by one of two spending conditions: (1) the signer set spends the UTXO, or (2) the user spends the UTXO after a fixed number of Bitcoin blocks have passed. Then, if there is an indefinite liveness failure, users will be able to reclaim their in-flight BTC [3]. ### sBTC Signer Responsibilities From 69d40a5f4f0ad98eb448ba44e7c31ca054820aa3 Mon Sep 17 00:00:00 2001 From: Andre Serrano <44974743+andrerserrano@users.noreply.github.com> Date: Mon, 18 Nov 2024 09:26:38 -0500 Subject: [PATCH 66/66] Update Glossary --- sips/sip-028/sip-028-sbtc_peg.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/sips/sip-028/sip-028-sbtc_peg.md b/sips/sip-028/sip-028-sbtc_peg.md index 12602e98..e43c024b 100644 --- a/sips/sip-028/sip-028-sbtc_peg.md +++ b/sips/sip-028/sip-028-sbtc_peg.md @@ -44,20 +44,21 @@ This SIP outlines but does not describe in technical detail the workings of the ## Introduction ### Glossary - | Term | Definition | |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **.sbtc contract** | A smart contract (or a collection of contracts) defining the sBTC token and functions related to it. | +| **Deposit API** | A third-party API that communicates with the sBTC Signers via the sBTC Signer API. | | **SIP-10 Token** | A token on the Stacks blockchain that adheres to the fungible token standards outlined in [SIP-10](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). | +| **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** | 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** | A smart contract function call 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 these entities as a group collectively maintain the sBTC's Bitcoin 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. | -| **Wrapped Bitcoin** | A tokenized version of Bitcoin on another blockchain, designed to maintain a 1:1 peg with BTC. It acts as a derivative asset that allows Bitcoin to be utilized in various decentralized applications and ecosystems. | +| **sBTC Signer Set** | The set of all sBTC signers. Each is registered with the .sbtc contract and these entities as a group collectively maintain the sBTC's Bitcoin UTXO. | +| **Two-way peg** | A two-way peg allows assets to move between two blockchains in a trustless manner. This proposal focuses on implementing such a peg between Bitcoin and Stacks, enabling users to lock BTC on Bitcoin and mint an equivalent amount of sBTC on Stacks. | +| **Wrapped Bitcoin** | A tokenized version of Bitcoin on another blockchain, designed to maintain a 1:1 peg with BTC. It acts as a derivative asset that allows Bitcoin to be utilized in various decentralized applications and ecosystems. | + ## Problem Statement