From 3cda94e4544ae9fc57a34d1f7035e8265e15d406 Mon Sep 17 00:00:00 2001 From: kenny Date: Mon, 7 Oct 2024 15:19:11 -0600 Subject: [PATCH] Remove sbtc design folder --- concepts/sbtc/sbtc-design/README.md | 18 -- .../sbtc/sbtc-design/clarity-contracts.md | 263 ------------------ .../sbtc-requests-and-responses/README.md | 40 --- .../commit-reveal-system.md | 94 ------- concepts/sbtc/sbtc-design/security-model.md | 69 ----- .../sbtc-design/stacker-responsibilities.md | 21 -- 6 files changed, 505 deletions(-) delete mode 100644 concepts/sbtc/sbtc-design/README.md delete mode 100644 concepts/sbtc/sbtc-design/clarity-contracts.md delete mode 100644 concepts/sbtc/sbtc-design/sbtc-requests-and-responses/README.md delete mode 100644 concepts/sbtc/sbtc-design/sbtc-requests-and-responses/commit-reveal-system.md delete mode 100644 concepts/sbtc/sbtc-design/security-model.md delete mode 100644 concepts/sbtc/sbtc-design/stacker-responsibilities.md diff --git a/concepts/sbtc/sbtc-design/README.md b/concepts/sbtc/sbtc-design/README.md deleted file mode 100644 index f79a2c209a..0000000000 --- a/concepts/sbtc/sbtc-design/README.md +++ /dev/null @@ -1,18 +0,0 @@ -# sBTC Design - -In Introduction to sBTC we established that sBTC is a fungible token on the Stacks blockchain, and explained how users interact with the protocol. This chapter takes a closer look at the major entities in the sBTC protocol and briefly explain how they interact. The following chapters goes into more details on each component. - -sBTC builds on the Proof-of-Transfer (PoX) consensus mechanism defined in [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md). This SIP introduces the concept of stacking, which is to lock STX for a period of time to earn Bitcoin rewards. Stacking is performed through a special smart contract, called the PoX contract. People who stack are called stackers. - -In sBTC we introduce the following changes to Stacks consensus: - -* A new Clarity contract is created to include sBTC as a [SIP-010 fungible token](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). -* Stacks miners must include sBTC mint and burn transactions in their blocks in response to valid sBTC requests on the Bitcoin chain. -* Stackers must collectively generate a Bitcoin address every reward cycle and publish it in the PoX contract as the sBTC wallet address. -* Stackers are required to respond to sBTC withdrawal requests. - -The following chart illustrates the main components of sBTC. - -
- -Now that we have established the main components of sBTC, we're ready to dig deeper in the actual workings of it. The following three chapters explains different aspects of the sBTC design and can be read in any order. diff --git a/concepts/sbtc/sbtc-design/clarity-contracts.md b/concepts/sbtc/sbtc-design/clarity-contracts.md deleted file mode 100644 index fbbf1e0092..0000000000 --- a/concepts/sbtc/sbtc-design/clarity-contracts.md +++ /dev/null @@ -1,263 +0,0 @@ -# Clarity Contracts - -One of the key pieces of the sBTC system is the set of Clarity contracts that facilitate the operations of the sBTC token. - -Recall that sBTC is a [SIP-010 fungible token](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md) on the Stacks chain. This provides an easy-to-use interface for interacting with sBTC. - -Upon successful deposit and withdrawal transactions the signer system will call functions in this contract. Here we'll walk through the contracts and explain what each piece is doing so you have a thorough understanding of the Clarity code running sBTC. - -:::note It's important to note that sBTC is currently in Developer Release. This is a developer preview so developers can begin learning and experimenting with sBTC before moving to the fully decentralized version. As such, these contracts are subject to change. ::: - -The Clarity contracts live in the [`romeo/asset-contract/contracts`](https://github.com/stacks-network/sbtc/tree/main/romeo/asset-contract/contracts) folder of the [`sbtc` repo](https://github.com/stacks-network/sbtc). - -In that folder you'll see three files: - -* `asset.clar` -* `clarity-bitcoin-mini-deploy.clar` -* `clarity-bitcoin-mini.clar` - -The `asset` contract is what does the heavy lifting for sBTC operations. The `clarity-bitcoin-mini` library is a stateless utility library to make it easier to interact with Bitcoin. This is a key feature of sBTC and this library provides several helper functions to handle that. - -The `clarity-bitcoin-mini-deploy` contract is exactly the same, except debug mode is set to false for production. - -Now, let's go through the `asset` contract. - -```clojure -;; title: wrapped BTC on Stacks -;; version: 0.1.0 -;; summary: sBTC dev release asset contract -;; description: sBTC is a wrapped BTC asset on Stacks. -;; It is a fungible token (SIP-10) that is backed 1:1 by BTC -;; For this version the wallet is controlled by a centralized entity. -;; sBTC is minted when BTC is deposited into the wallet and -;; burned when BTC is withdrawn from the wallet. -;; Requests for minting and burning are made by the contract owner. - -;; token definitions -;; 100 M sats = 1 sBTC -;; 21 M sBTC supply = 2.1 Q sats total -(define-fungible-token sbtc u2100000000000000) - -;; constants -;; -(define-constant err-invalid-caller (err u4)) -(define-constant err-forbidden (err u403)) -(define-constant err-btc-tx-already-used (err u500)) - -;; data vars -;; -(define-data-var contract-owner principal tx-sender) -(define-data-var bitcoin-wallet-public-key (optional (buff 33)) none) - -;; stores all btc txids that have been used to mint or burn sBTC -(define-map amounts-by-btc-tx (buff 32) int) - -;; public functions -;; - -;; #[allow(unchecked_data)] -(define-public (set-contract-owner (new-owner principal)) - (begin - (try! (is-contract-owner)) - (ok (var-set contract-owner new-owner)) - ) -) - -;; #[allow(unchecked_data)] -(define-public (set-bitcoin-wallet-public-key (public-key (buff 33))) - (begin - (try! (is-contract-owner)) - (ok (var-set bitcoin-wallet-public-key (some public-key))) - ) -) - -;; #[allow(unchecked_data)] -(define-public (mint (amount uint) - (destination principal) - (deposit-txid (buff 32)) - (burn-chain-height uint) - (merkle-proof (list 14 (buff 32))) - (tx-index uint) - (block-header (buff 80))) - (begin - (try! (is-contract-owner)) - (try! (verify-txid-exists-on-burn-chain deposit-txid burn-chain-height merkle-proof tx-index block-header)) - (asserts! (map-insert amounts-by-btc-tx deposit-txid (to-int amount)) err-btc-tx-already-used) - (try! (ft-mint? sbtc amount destination)) - (print {notification: "mint", payload: deposit-txid}) - (ok true) - ) -) - -;; #[allow(unchecked_data)] -(define-public (burn (amount uint) - (owner principal) - (withdraw-txid (buff 32)) - (burn-chain-height uint) - (merkle-proof (list 14 (buff 32))) - (tx-index uint) - (block-header (buff 80))) - (begin - (try! (is-contract-owner)) - (try! (verify-txid-exists-on-burn-chain withdraw-txid burn-chain-height merkle-proof tx-index block-header)) - (asserts! (map-insert amounts-by-btc-tx withdraw-txid (* -1 (to-int amount))) err-btc-tx-already-used) - (try! (ft-burn? sbtc amount owner)) - (print {notification: "burn", payload: withdraw-txid}) - (ok true) - ) -) - -;; #[allow(unchecked_data)] -(define-public (transfer (amount uint) (sender principal) (recipient principal) (memo (optional (buff 34)))) - (begin - (asserts! (or (is-eq tx-sender sender) (is-eq contract-caller sender)) err-invalid-caller) - (try! (ft-transfer? sbtc amount sender recipient)) - (match memo to-print (print to-print) 0x) - (ok true) - ) -) - -;; read only functions -;; -(define-read-only (get-bitcoin-wallet-public-key) - (var-get bitcoin-wallet-public-key) -) - -(define-read-only (get-contract-owner) - (var-get contract-owner) -) - -(define-read-only (get-name) - (ok "sBTC") -) - -(define-read-only (get-symbol) - (ok "sBTC") -) - -(define-read-only (get-decimals) - (ok u8) -) - -(define-read-only (get-balance (who principal)) - (ok (ft-get-balance sbtc who)) -) - -(define-read-only (get-total-supply) - (ok (ft-get-supply sbtc)) -) - -(define-read-only (get-token-uri) - (ok (some u"https://gateway.pinata.cloud/ipfs/Qma5P7LFGQAXt7gzkNZGxet5qJcVxgeXsenDXwu9y45hpr?_gl=1*1mxodt*_ga*OTU1OTQzMjE2LjE2OTQwMzk2MjM.*_ga_5RMPXG14TE*MTY5NDA4MzA3OC40LjEuMTY5NDA4MzQzOC42MC4wLjA")) -) - -(define-read-only (get-amount-by-btc-txid (btc-txid (buff 32))) - (map-get? amounts-by-btc-tx btc-txid) -) - -;; private functions -;; -(define-private (is-contract-owner) - (ok (asserts! (is-eq (var-get contract-owner) contract-caller) err-forbidden)) -) - -(define-read-only (verify-txid-exists-on-burn-chain (txid (buff 32)) (burn-chain-height uint) (merkle-proof (list 14 (buff 32))) (tx-index uint) (block-header (buff 80))) - (contract-call? .clarity-bitcoin-mini was-txid-mined burn-chain-height txid block-header { tx-index: tx-index, hashes: merkle-proof}) -) -``` - -Although powerful, the sBTC contract is actually relatively simple. The `mint` and `burn` functions of the contract will not be interacted with directly by a developer or a user, but instead will be called by the sBTC signer system upon successful deposit and withdrawal requests. The `transfer` function, however, will often be called by developers for users looking to transfer their sBTC. - -Up at the top we are setting some variables, most notably the sBTC supply, which is set to match 1:1 with BTC supply. - -We also have the contract owner and Bitcoin wallet public key which will be set by the sBTC protocol. As per the design documentation, the Bitcoin public key will change every stacking reward cycle to the new threshold wallet. - -Next we have two basic public functions to set those two variables. - -Finally we are defining a map to define all deposit and withdrawal transaction IDs to ensure that once a particular Bitcoin transaction has been used in a sBTC operation, it can not be used again. - -The next three functions comprise the bulk of the sBTC functionality. - -Before we get to those, let's take a look at the `verify-txid-exists-on-burn-chain` towards the bottom of the contract. This utilizes the helper contract to ensure that a transaction actually happened on the Bitcoin chain. - -This native integration with the Bitcoin L1 is one of the great parts of Clarity, as we can verify directly from our smart contracts whether or not a Bitcoin transaction was actually mined, all on chain. - -```clojure -(define-read-only (verify-txid-exists-on-burn-chain (txid (buff 32)) (burn-chain-height uint) (merkle-proof (list 14 (buff 32))) (tx-index uint) (block-header (buff 80))) - (contract-call? .clarity-bitcoin-mini was-txid-mined burn-chain-height txid block-header { tx-index: tx-index, hashes: merkle-proof}) -) -``` - -This takes in a transaction ID, the Bitcoin block height the transaction was in, and a merkle proof. All of this information is passed to the library to verify that the transaction actually occurred. - -For some more context on how this process works and to see how to use it your own projects, be sure to check out the [Bitcoin Primer](https://bitcoinprimer.dev). - -### Mint - -```clojure -;; #[allow(unchecked_data)] -(define-public (mint (amount uint) - (destination principal) - (deposit-txid (buff 32)) - (burn-chain-height uint) - (merkle-proof (list 14 (buff 32))) - (tx-index uint) - (block-header (buff 80))) - (begin - (try! (is-contract-owner)) - (try! (verify-txid-exists-on-burn-chain deposit-txid burn-chain-height merkle-proof tx-index block-header)) - (asserts! (map-insert amounts-by-btc-tx deposit-txid (to-int amount)) err-btc-tx-already-used) - (try! (ft-mint? sbtc amount destination)) - (print {notification: "mint", payload: deposit-txid}) - (ok true) - ) -) -``` - -Now we get to the `mint` function. This is the function that is called when a deposit transaction is initiated and processed on the Bitcoin side. The signer will detect that and call the `mint` function. - -This function takes in some information that is all read directly from the provided Bitcoin transaction. It includes the Stacks principal to mint the sBTC to, and all of the required Bitcoin transaction information required to verify it. - -It then checks to make sure the contract owner (the signer system) is calling it, makes sure the Bitcoin transaction actually happened, updates the map of Bitcoin transactions that have been used in sBTC operations, and mints the token to the specified Stacks principal. - -### Burn - -```clojure -;; #[allow(unchecked_data)] -(define-public (burn (amount uint) - (owner principal) - (withdraw-txid (buff 32)) - (burn-chain-height uint) - (merkle-proof (list 14 (buff 32))) - (tx-index uint) - (block-header (buff 80))) - (begin - (try! (is-contract-owner)) - (try! (verify-txid-exists-on-burn-chain withdraw-txid burn-chain-height merkle-proof tx-index block-header)) - (asserts! (map-insert amounts-by-btc-tx withdraw-txid (* -1 (to-int amount))) err-btc-tx-already-used) - (try! (ft-burn? sbtc amount owner)) - (print {notification: "burn", payload: withdraw-txid}) - (ok true) - ) -) -``` - -The `burn` function works much the same except it is called upon a successful withdrawal request, when a user wants to convert their sBTC back to BTC. - -### Transfer - -```clojure -;; #[allow(unchecked_data)] -(define-public (transfer (amount uint) (sender principal) (recipient principal) (memo (optional (buff 34)))) - (begin - (asserts! (or (is-eq tx-sender sender) (is-eq contract-caller sender)) err-invalid-caller) - (try! (ft-transfer? sbtc amount sender recipient)) - (match memo to-print (print to-print) 0x) - (ok true) - ) -) -``` - -Finally we have a basic transfer function that allows users to transfer sBTC between each other. - -The rest of the functions are basic `read-only` functions that are used to retrieve information about the asset. diff --git a/concepts/sbtc/sbtc-design/sbtc-requests-and-responses/README.md b/concepts/sbtc/sbtc-design/sbtc-requests-and-responses/README.md deleted file mode 100644 index 0e407b7913..0000000000 --- a/concepts/sbtc/sbtc-design/sbtc-requests-and-responses/README.md +++ /dev/null @@ -1,40 +0,0 @@ -# sBTC Requests and Responses - -Requests to the sBTC system happen on the Bitcoin blockchain. In this chapter, we explain the two requests that users can create. We go over all information they must contain, and how the sBTC protocol responds to the requests. For a more in-depth reference on how these requests are represented on the Bitcoin blockchain, see Bitcoin Transactions. - -### Deposit Request - -When a user wishes to deposit BTC in favor of receiving sBTC, they create a deposit request transaction. This is a bitcoin transaction sending the requested deposit amount of BTC to the address provided by the Stackers. In addition, the transaction must also specify to which Stacks address the sBTC should be minted. - -The sBTC deposit request transaction will therefore contain the following data: - -* Recipient address: The Stacks address which should receive the sBTC. -* sBTC wallet address: The Bitcoin address maintaining custody of the deposited BTC. -* Amount: The amount to deposit. - -#### How the protocol responds to a deposit request - -When a deposit request is mined on the Bitcoin blockchain, the next Stacks block must contain an sBTC mint transaction to the recipient address with the designated amount. - -This is enforced on a consensus level in Stacks, so that Stacks blocks which do not respond to deposit requests are considered invalid by Miners. - -If for some reason the sBTC mint does not materialize, there is a timeout function that will return the user's BTC to them once the subsequent reward cycle finishes. - -### Withdrawal Request - -An sBTC withdraw request is a bitcoin transaction containing data and two outputs. The first output of this transaction marks the recipient address of the BTC to be withdrawn. The second output of this transaction is a small fee subsidy to the stackers intended to cover the transaction cost of fulfilling the withdrawal. Finally, the transaction specifies the amount to be withdrawn and signs the amount and recipient address with the Stacks address from which the sBTC should be burned. - -To summarize, the sBTC withdrawal transaction will contain the following data: - -* Recipient address: The Bitcoin address which should receive the BTC. -* sBTC wallet address: The Bitcoin address maintaining custody of the deposited BTC. -* Amount: The amount to withdraw. -* Sender address: The Stacks address holding the sBTC to be burned. - -#### How the protocol responds to a withdrawal request - -When a withdrawal request is mined on the Bitcoin blockchain, the next Stacks block must contain a sBTC burn transaction burning the requested amount from the sender address. Once the withdrawal request is final[^1] on the Stacks blockchain, Stackers must fulfill the withdrawal request on the Bitcoin chain by creating a fulfillment transaction. - -The fulfillment transaction is a bitcoin transaction sending the requested withdrawal amount to the designated recipient address specified in the Withdrawal request. - -[^1]: Block finality is a property introduced in the [Nakamoto release](https://stx.is/nakamoto) of Stacks, and a requirement for sBTC. diff --git a/concepts/sbtc/sbtc-design/sbtc-requests-and-responses/commit-reveal-system.md b/concepts/sbtc/sbtc-design/sbtc-requests-and-responses/commit-reveal-system.md deleted file mode 100644 index b0b5437b8a..0000000000 --- a/concepts/sbtc/sbtc-design/sbtc-requests-and-responses/commit-reveal-system.md +++ /dev/null @@ -1,94 +0,0 @@ -# Commit-Reveal System - -Thus far, we have have been introduced to some of the Bitcoin transactions that make it possible to interact with sBTC. However, one big drawback of the transaction formats we have been talking about is that they require the creation of custom Bitcoin transactions, which is a moderately sophisticated use case of Bitcoin and thus remains unsupported by some wallets as well as a lot of custodian solutions that are widely used in the current landscape. Cutting out this portion of the Bitcoin ecosystem from being able to use sBTC is not ideal. As a protocol, it is super important that sBTC is accessible to anyone who wants to use it, and this translates to allowing sBTC compatible transactions to be sent from any viable Bitcoin wallet. - -To accommodate for this use case, sBTC also supports an alternate transaction wire-format that has universal compatibility with any Bitcoin wallet. Since this scheme uses two transactions to fulfill a sBTC operation, we call it the commit-reveal scheme. As the name suggests, one of the transactions _commits_ the intent of the user and the second transaction _reveals_ it to the protocol. - -Note that commit-reveal does not introduce new sBTC operations, but rather an alternate way to _express_ the same operations . From the perspective of the sBTC protocol, these two schemes are completely compatible and interchangeable with each other, in terms of how they are interpreted by the protocol and the effects they produce. - -Let's dig a little deeper into the details. - -### Operation format - -Fundamentally, all sBTC transactions on Bitcoin have to embed some data into the blockchain itself that highlights the intent of the user to interact with the sBTC protocol. The protocol then identifies these intents from the chain and verifies and executes them, thus executing the intent of the user that was previously embedded in the chain. - -As long as we have a reliable way to achieve this cycle of embedding an intent into Bitcoin, reading it and processing it, we can fulfill any sBTC operation. Both the direct scheme (SIP-021 style transactions) and transactions that fulfill commit-reveal scheme achieve this, only differing slightly in how the data is embedded into the chain itself. - -In the direct scheme, we embed the data directly in the transaction itself, by using an `OP_RETURN` output. - -In the commit reveal scheme, this embedding is done in two stages: the commit transaction and the reveal transaction. - -#### Commit transaction - -The commit transaction is a very simple transaction with only one requirement: it must contain an output to either a `p2tr`, `p2wsh`, `p2sh-p2wsh` or `p2sh` address. We need to use these types of addresses because all of them require a user to reveal a script to be spent. We require the revealed script to have the following format: - -``` - OP_DROP -``` - -where the `DATA` part of the script is similar to the corresponding data format of the direct scheme using `OP_RETURN`, minus the first two magic bytes (that part will be dealt with in the reveal transaction that follows). The data is at most 86 bytes long (the opcode + payload is at most 78 bytes) and also contains an 8 byte chunk that specifies a fee subsidy, i.e. the amount of funds that the reveal transaction is allowed to spend as transaction fees. - -The `DATA` section of the script thus looks like this: - -``` -0 1 n n + 8 -|--|----------------------------|--------------| - op sBTC payload fee subsidy -``` - -where the first byte is the opcode of the sBTC transaction, the payload is essential data required for the specific sBTC operation and the fee subsidy limits the maximum amount of money the reveal transaction is allowed to use as fees. - -#### Reveal transaction - -The reveal transaction is also fairly simple in construction and MUST satisfy the following: - -1. It MUST consume an UTXO from a commit transaction as its first input. -2. The first output MUST be an `OP_RETURN` output with a three byte payload where the first two bytes are the magic bytes (the same ones we promised to add back) that specify the network they are running on - `T2` for mainnet and `X2` for testnet, and the last two bytes is an opcode and a script version byte. - - ``` - 0 2 3 4 - |------|--|---------| - magic op version - ``` - -The opcode identifies which type of script is revealed. It is `w` if the script is embedded in segwit witness data, and `r` if the script is in a p2sh redeem script. - -The version identifies the SegWit witness version. It is `0` for `p2wsh` scripts and `1` for `p2tr` scripts. If the opcode is `r`, this version byte may be omitted. - -Because the reveal transaction consumes the UTXO from the commit transaction, the data that was embedded in the script of the commit transaction is _revealed_. Thus, when the sBTC protocol observes a bitcoin operation with the opcode `w` or `r`, it indicates a reveal transaction and the data for the intended operation by the initiator of the commit transaction can be found in either the witness or redeem script of the first input. - -Any remaining outputs of the reveal transaction must be of the same form as in the direct scheme. For instance, the reveal transaction representing an sBTC withdrawal request must contain two additional outputs (just like its direct scheme counterpart) in order: - -1. the BTC recipient address -2. the funding of the fulfillment transaction. - -### Processing the commit-reveal scheme at the protocol level - -Now that we understand how the low level representations of commit-reveal transactions and what they represent, we need to talk about how the sBTC protocol itself interacts with the scheme to ensure fulfillment of such transactions. - -On a high level, this diagram summarizes the interactions between the various parties involved in the fulfillment of the commit-reveal scheme: - -
- -More importantly there are three parts of the process that need to interact: - -1. The _Committer_ (the person the submitting the _commit_ transaction, initiating the scheme) -2. The _Revealer_ (the person that consumes _commit_ transactions and initiates reveal transactions) -3. The Bitcoin blockchain itself, which provides the underlying data layer which is used to express the scheme - -The _Committer_ can be thought of as a system that interacts with a user wallet and constructs _commit_ transactions (like the sBTC bridge). - -The _Revealer_ can be thought of a specific system that participates in the sBTC protocol, maintaining a wallet and can consume _commit_ transactions and broadcast _reveal_ transactions. They probably have convenient API endpoints for the _Committer_ to use to construct Witness data. - -Here is an example flow of data through the protocol (for illustration purposes only): - -1. User interacts with a web UI of a _Committer_, providing operation data to construct the commit transaction -2. The _Committer_ constructs a witness script that can be spent by the _Revealer_ -3. The _Committer_ then sends this witness script and any other associated data that might be required to construct a reveal transaction to the _Revealer_ -4. The _Committer_ returns the address to send the _commit_ operation to the user -5. User broadcasts the _commit_ transaction by making a payment to the given commit address -6. The _Revealer_ reads the _commit_ transaction, having already processed the witness script -7. The _Revealer_ broadcasts the _reveal_ transaction (there can be economic incentives here that makes the _Revealer_ not reveal a _commit_ transaction. For example, if the cost of revealing the transaction is too high, the _Revealer_ might choose to ignore it altogether) -8. The sBTC protocol picks up the _reveal_ transaction and fulfills it (by interpreting the operation data from the witness script) - -NOTE: _It is entirely possible for the Revealer to steal the witness data and use it for its own benefit, although this will be entire visible on the Bitcoin chain data itself and can be completely traced. Thus, there needs to be some degree of cryptoeconomic incentives present that discourage the Revealer from doing this._ diff --git a/concepts/sbtc/sbtc-design/security-model.md b/concepts/sbtc/sbtc-design/security-model.md deleted file mode 100644 index c5470b26a3..0000000000 --- a/concepts/sbtc/sbtc-design/security-model.md +++ /dev/null @@ -1,69 +0,0 @@ -# Security Model - -Unlike other BTC bridges, sBTC is not supported by a central custodian or a federation: instead, sBTC is secured by an open network of signers, making sBTC the most decentralized, Bitcoin-backed asset. - -In this article, we’ll cover the fundamentals of the sBTC security model, the role of sBTC Signers, and how the sBTC working group is enabling a more scalable sBTC protocol design. - -### A Bitcoin-Backed Asset Worthy of Bitcoin - -sBTC embraces the core principles of Bitcoin: decentralization, permissionless, and trust-minimization. The system is: - -* Open Membership: sBTC operates as an open network, where anyone can become a validator, increasing the decentralization and inclusivity within the sBTC ecosystem. In contrast, other alternatives have closed groups of signers. -* Decentralized: The software libraries for sBTC can support over 150 validators, surpassing the limitations of current multi-sig implementations. This allows for a broader and more diverse set of participants, further strengthening decentralization. -* Trust-Minimized: sBTC provides users and developers with a trust-minimized option—you interact with a decentralized network instead of a central custodian or small group of signers, aligning with the core principles of Bitcoin. -* Collateral-Backed: Unlike alternative multi-sig approaches, which have zero collateral backing their respective Bitcoin pegs, sBTC has $250M+ of collateral in STX tokens deposited in the protocol, providing a substantial incentive to maintain the peg. - -### Who Are the Signers? - -The sBTC asset is supported by this network of “validators.” There can be up to 150 of them, and anyone can join/leave the signer network as they desire. We expect these validators will be a combination of: - -* Trusted institutions (including exchanges and custodians, such as [Figment](https://flight.beehiiv.net/v2/clicks/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJodHRwczovL2ZpZ21lbnQuaW8vaW5zaWdodHMvZmlnbWVudC10by1lbmFibGUtYml0Y29pbi1sMi1yZXdhcmRzLXdpdGgtdXBjb21pbmctc3VwcG9ydC1vZi10aGUtc3RhY2tzLWxheWVyLz91dG1fc291cmNlPXd3dy5iaXRjb2lud3JpdGVzLmNvbSZ1dG1fbWVkaXVtPXJlZmVycmFsJnV0bV9jYW1wYWlnbj1hLW1vcmUtc2VjdXJlLWJ0Yy1icmlkZ2UtdW5kZXJzdGFuZGluZy1zYnRjLXMtc2VjdXJpdHktbW9kZWwiLCJwb3N0X2lkIjoiY2M3ZDYyNGItZWNiYS00ZjA2LWFiZjYtNDFjZDdkODVhNTc4IiwicHVibGljYXRpb25faWQiOiIwNGYyNjRlOS02MjZiLTQ4OGYtYmMzYS0wOTQzNDVmOWZjZDIiLCJ2aXNpdF90b2tlbiI6ImNlZTQ1ZjUxLWU1ZjYtNDAwOC1iZTE4LWYzZjdiZTU1MGRkYyIsImlhdCI6MTcwNTk1OTYwNywiaXNzIjoib3JjaGlkIn0.r6zVSbBoqzl8oPj\_KBelC8PLxkq\_pzEI6O2BlRM3JVY) and [Copper](https://flight.beehiiv.net/v2/clicks/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJodHRwczovL2NvcHBlci5jby9pbnNpZ2h0cy9jb21wYW55LW5ld3Mvc3RhY2tzLWxheWVyLWJpdGNvaW4tc3VwcG9ydD91dG1fc291cmNlPXd3dy5iaXRjb2lud3JpdGVzLmNvbSZ1dG1fbWVkaXVtPXJlZmVycmFsJnV0bV9jYW1wYWlnbj1hLW1vcmUtc2VjdXJlLWJ0Yy1icmlkZ2UtdW5kZXJzdGFuZGluZy1zYnRjLXMtc2VjdXJpdHktbW9kZWwiLCJwb3N0X2lkIjoiY2M3ZDYyNGItZWNiYS00ZjA2LWFiZjYtNDFjZDdkODVhNTc4IiwicHVibGljYXRpb25faWQiOiIwNGYyNjRlOS02MjZiLTQ4OGYtYmMzYS0wOTQzNDVmOWZjZDIiLCJ2aXNpdF90b2tlbiI6ImNlZTQ1ZjUxLWU1ZjYtNDAwOC1iZTE4LWYzZjdiZTU1MGRkYyIsImlhdCI6MTcwNTk1OTYwNywiaXNzIjoib3JjaGlkIn0.5ZwOvwnfmqtHg3QhJz9Qq6-dzgr\_3R4uOaQgMI0GbSQ)) -* Stacking pools (such as [Xverse](https://flight.beehiiv.net/v2/clicks/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJodHRwczovL3Bvb2wueHZlcnNlLmFwcC8\_dXRtX3NvdXJjZT13d3cuYml0Y29pbndyaXRlcy5jb20mdXRtX21lZGl1bT1yZWZlcnJhbCZ1dG1fY2FtcGFpZ249YS1tb3JlLXNlY3VyZS1idGMtYnJpZGdlLXVuZGVyc3RhbmRpbmctc2J0Yy1zLXNlY3VyaXR5LW1vZGVsIiwicG9zdF9pZCI6ImNjN2Q2MjRiLWVjYmEtNGYwNi1hYmY2LTQxY2Q3ZDg1YTU3OCIsInB1YmxpY2F0aW9uX2lkIjoiMDRmMjY0ZTktNjI2Yi00ODhmLWJjM2EtMDk0MzQ1ZjlmY2QyIiwidmlzaXRfdG9rZW4iOiJjZWU0NWY1MS1lNWY2LTQwMDgtYmUxOC1mM2Y3YmU1NTBkZGMiLCJpYXQiOjE3MDU5NTk2MDcsImlzcyI6Im9yY2hpZCJ9.TPIBy5jzj4l7ytNVqUeIckhqdzRW2dWA-g6JdgrUxrk)) -* Individual node operators - -These signers lock up Stacks tokens (STX) in order to be a signer on the network, and for their work to maintain the sBTC peg, earn BTC rewards, making honest behavior the most profitable course of action. - -Greater than 70% of these signers are required to approve deposit and withdrawals from the system. This means that as long as at least 30% of validators are honest, the BTC deposited in sBTC is secure. To steal the BTC deposits, malicious actors would need to convince a number of validators that represent > 70% of the stacked STX capital to collude in order to steal the BTC funds. This is highly unlikely in practice given Stacks validators are geographically dispersed entities with significant business risk for behaving maliciously. - -For more technical details on the implementation and design of sBTC, please refer to the [SIP025](https://flight.beehiiv.net/v2/clicks/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJodHRwczovL2dpdGh1Yi5jb20vc3RhY2tzZ292L3NpcHMvYmxvYi9lNmIzMjMzZTc2YzIyY2ZkNmVmMDJmMjFhZGQ2NjY5NmI5ZTRjMzE0L3NpcHMvc2lwLTAyNS9zaXAtMDI1LXNidGMubWQ\_dXRtX3NvdXJjZT13d3cuYml0Y29pbndyaXRlcy5jb20mdXRtX21lZGl1bT1yZWZlcnJhbCZ1dG1fY2FtcGFpZ249YS1tb3JlLXNlY3VyZS1idGMtYnJpZGdlLXVuZGVyc3RhbmRpbmctc2J0Yy1zLXNlY3VyaXR5LW1vZGVsIiwicG9zdF9pZCI6ImNjN2Q2MjRiLWVjYmEtNGYwNi1hYmY2LTQxY2Q3ZDg1YTU3OCIsInB1YmxpY2F0aW9uX2lkIjoiMDRmMjY0ZTktNjI2Yi00ODhmLWJjM2EtMDk0MzQ1ZjlmY2QyIiwidmlzaXRfdG9rZW4iOiJjZWU0NWY1MS1lNWY2LTQwMDgtYmUxOC1mM2Y3YmU1NTBkZGMiLCJpYXQiOjE3MDU5NTk2MDcsImlzcyI6Im9yY2hpZCJ9.MpRVoPOtDQKxXZt-vIS2dwloDaYT4aEUVcpR4oyGUho). The SIP is currently under community review, pending approval on a future date to be announced. - -### Inheriting Bitcoin’s Security - -sBTC has a number of traits that make it more secure than other Bitcoin-backed assets. - -#### sBTC has read access to Bitcoin. - -Because Stacks smart contracts have read access to Bitcoin, users can send simple Bitcoin L1 transactions to interact with Stacks and deposit BTC for sBTC. In contrast, moving BTC to a chain that is not designed to work with BTC, like Solana or Ethereum, do not have this read access, which brings different security assumptions. - -#### Stacks forks with Bitcoin. - -A lot of complexity is introduced to Bitcoin-backed projects on other chains, given that Bitcoin and the other L1 are independent of each other. When Bitcoin forks, the other chain won’t care, and each fork can destabilize the peg as large numbers of transactions can be forced to roll back after the fact. - -Unlike those projects, Stacks auto-follows all Bitcoin forks and derives its security from Bitcoin. There is no risk of the sBTC peg being deprecated by a Bitcoin fork because the entire Stacks blockchain will reorg alongside Bitcoin, bringing the peg back into alignment with Bitcoin. - -#### sBTC is reorg-resistant. - -Taking this one step further, the security properties of a Stacks transaction are the same as doing a Bitcoin transaction. As soon as a Bitcoin block arrives, Stacks transactions start getting Bitcoin finality. This is not possible with other systems. In other words, Stacks does not have a separate security budget. The security level of a Bitcoin L1 transaction in a Bitcoin block is the same as a Stacks transaction that gets packaged into that Bitcoin block. - -#### Does sBTC have a hard cap/liveness ratio? - -The original white paper proposed a liveness ratio, essentially a cap on the amount of sBTC that can be minted based on the value of STX locked into the protocol. This concept came from a security model of economic incentives, in which stackers have full signing control over a Bitcoin wallet containing the locked BTC. In the original white paper this was set to 60% of locked STX (i.e. if there is $200M of STX locked, the system capacity is $120M of BTC). - -However, after further research and consideration, the sBTC working group concluded that such a cap would significantly limit potential DeFi usage and discourage large players from entering the system. Given these findings and market realities, the sBTC design no longer has this liveness ratio, and instead relies on the trust-assumption of honest institutional validators as the final security backstop. - -The research concluded that a hybrid system that has both (a) anonymous signers with locked STX _and_ (b) known, institutional signers that collectively hold > 30% locked STX, is arguably more secure than a system with just anonymous signers with locked capital. This is because institutional participants have significant incentives to behave honestly and thus bolster the organic economic incentives of the system. - -For more information on this topic, see these resources: - -* [Making sBTC ready for DeFi prime time](https://flight.beehiiv.net/v2/clicks/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJodHRwczovL2ZvcnVtLnN0YWNrcy5vcmcvdC9tYWtpbmctc2J0Yy1yZWFkeS1mb3ItZGVmaS1wcmltZS10aW1lLzE0NDIxP3V0bV9zb3VyY2U9d3d3LmJpdGNvaW53cml0ZXMuY29tJnV0bV9tZWRpdW09cmVmZXJyYWwmdXRtX2NhbXBhaWduPWEtbW9yZS1zZWN1cmUtYnRjLWJyaWRnZS11bmRlcnN0YW5kaW5nLXNidGMtcy1zZWN1cml0eS1tb2RlbCIsInBvc3RfaWQiOiJjYzdkNjI0Yi1lY2JhLTRmMDYtYWJmNi00MWNkN2Q4NWE1NzgiLCJwdWJsaWNhdGlvbl9pZCI6IjA0ZjI2NGU5LTYyNmItNDg4Zi1iYzNhLTA5NDM0NWY5ZmNkMiIsInZpc2l0X3Rva2VuIjoiY2VlNDVmNTEtZTVmNi00MDA4LWJlMTgtZjNmN2JlNTUwZGRjIiwiaWF0IjoxNzA1OTU5NjA3LCJpc3MiOiJvcmNoaWQifQ.3Q8GK4GhEb8EZou9r7y1JZ\_lcRLFjpFTysv1wyZon8g) -* [sBTC Research - Cap on BTC in Peg Wallet](https://flight.beehiiv.net/v2/clicks/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJodHRwczovL2dpdGh1Yi5jb20vc3RhY2tzLW5ldHdvcmsvc2J0Yy9kaXNjdXNzaW9ucy8zMTY\_dXRtX3NvdXJjZT13d3cuYml0Y29pbndyaXRlcy5jb20mdXRtX21lZGl1bT1yZWZlcnJhbCZ1dG1fY2FtcGFpZ249YS1tb3JlLXNlY3VyZS1idGMtYnJpZGdlLXVuZGVyc3RhbmRpbmctc2J0Yy1zLXNlY3VyaXR5LW1vZGVsIiwicG9zdF9pZCI6ImNjN2Q2MjRiLWVjYmEtNGYwNi1hYmY2LTQxY2Q3ZDg1YTU3OCIsInB1YmxpY2F0aW9uX2lkIjoiMDRmMjY0ZTktNjI2Yi00ODhmLWJjM2EtMDk0MzQ1ZjlmY2QyIiwidmlzaXRfdG9rZW4iOiJjZWU0NWY1MS1lNWY2LTQwMDgtYmUxOC1mM2Y3YmU1NTBkZGMiLCJpYXQiOjE3MDU5NTk2MDcsImlzcyI6Im9yY2hpZCJ9.YYbye-GFds4tBWFq6PL-J0-f1otxKQdGVjLVVKoo9cs)[ ](https://flight.beehiiv.net/v2/clicks/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJodHRwczovL2dpdGh1Yi5jb20vc3RhY2tzLW5ldHdvcmsvc2J0Yy9kaXNjdXNzaW9ucy8zMTY\_dXRtX3NvdXJjZT13d3cuYml0Y29pbndyaXRlcy5jb20mdXRtX21lZGl1bT1yZWZlcnJhbCZ1dG1fY2FtcGFpZ249YS1tb3JlLXNlY3VyZS1idGMtYnJpZGdlLXVuZGVyc3RhbmRpbmctc2J0Yy1zLXNlY3VyaXR5LW1vZGVsIiwicG9zdF9pZCI6ImNjN2Q2MjRiLWVjYmEtNGYwNi1hYmY2LTQxY2Q3ZDg1YTU3OCIsInB1YmxpY2F0aW9uX2lkIjoiMDRmMjY0ZTktNjI2Yi00ODhmLWJjM2EtMDk0MzQ1ZjlmY2QyIiwidmlzaXRfdG9rZW4iOiJjZWU0NWY1MS1lNWY2LTQwMDgtYmUxOC1mM2Y3YmU1NTBkZGMiLCJpYXQiOjE3MDU5NTk2MDcsImlzcyI6Im9yY2hpZCJ9.YYbye-GFds4tBWFq6PL-J0-f1otxKQdGVjLVVKoo9cs) - -#### What happens if the value of STX drops in relation to Bitcoin’s price? - -Even if the price drops, validators will still have STX locked in the protocol, offering economic incentive to behave rationally (and remember, validators are also incentivized to behave honestly through the BTC rewards earned by their work to process deposits and withdrawals.) - -With a combination of institutions, pools, and individuals, the design offers enough flexibility that we believe that at least 30% of signers will remain honest regardless of the price. The decision to utilize a combination of both economic and reputational incentives supports this assumption because institutions are likely to continue normal Signing operations, even if the collateral backing the system declines relative to BTC. - -#### What is the purpose of the STX token? - -The STX asset has two main uses: (a) mining incentives i.e., to keep the mining system open and decentralized; and (b) STX is the capital locked up in consensus that provides economic security to users who mint sBTC. STX will collateralize the sBTC system, offering greater levels security than systems that don’t post any collateral. diff --git a/concepts/sbtc/sbtc-design/stacker-responsibilities.md b/concepts/sbtc/sbtc-design/stacker-responsibilities.md deleted file mode 100644 index 7115adc52f..0000000000 --- a/concepts/sbtc/sbtc-design/stacker-responsibilities.md +++ /dev/null @@ -1,21 +0,0 @@ -# Stacker Responsibilities - -One of the most significant changes to accommodate the sBTC design is that Stackers must now perform active work to continue receiving PoX rewards. Stackers provide partial signatures for BTC withdrawal fulfillment transactions\[the BTC wallet] for the duration of each reward cycle in which their STX are locked. This chapter outlines the new role of the stackers, and how they interact with each other to fulfill their duties. - -### sBTC wallet address generation - -Stackers in sBTC operate in Reward cycles similar to previous versions of [PoX](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md). However, the reward cycle has been modified to consist of three phases: prepare (80 blocks), handoff (20 blocks), and reward (2000 blocks). - -During the prepare phase, miners decide on an anchor block and the next reward cycle's Stackers as before. During the handoff phase, this new set of Stackers MUST collectively determine and provide a single Bitcoin address in the PoX contract to operate as the sBTC wallet address for the next reward cycle. If they fail to do so within the first 10 blocks of the handoff phase, the prepare phase is reinitiated and a new set of stackers will be selected. - -If no valid sBTC address is provided, the current set of Stackers' continue operating as before. Their STX will remain frozen, and they will continue to receive PoX rewards until a successful prepare phase and handoff has occurred. However, once the new set of stackers has provided an sBTC wallet address, the current set of Stackers MUST execute a wallet handoff to this newly generated sBTC wallet address. - -### sBTC Wallet handoff - -An sBTC Wallet handoff is used by the current reward cycle's Stackers to send all deposited BTC to the next reward cycle's Stackers' sBTC wallet address within 10 blocks of the reward cycle starting. Additionally, Stackers MUST transfer an _equal or greater_ number of BTC than the amount of sBTC that existed at the end of their own wallet's lifetime. This implies that Stackers MUST cover any fee costs associated with fulfilling sBTC withdrawal requests. - -### sBTC Withdrawal fulfillment - -To fulfill an sBTC withdrawal request, Stackers send one or more Bitcoin transactions that pay the requested amount of BTC to the withdrawal address stipulated by the withdrawal request. If Stackers have received their sBTC wallet handoff and they fail to fulfill a request within 50 Bitcoin blocks of the request being finalized (i.e. at most 150 Bitcoin blocks after the request is submitted), then the system transitions to Recovery mode and PoX payouts are repurposed for fulfilling pending withdrawal requests. - -If Stackers do not fulfill the pending sBTC withdrawal requests, their STX will be frozen by .pox and any earned BTC used to fulfill these pending requests. Stackers may only receive back their STX and resume earning BTC once all the withdrawal requests for which they were responsible are fulfilled.