Deconstructing sBTC, The Whitepaper: Part 2

Analyzing the whitepaper's section on sBTC as a trustless, two-way bitcoin peg

wbnns

• 7 min read

The Decentralized Two-way Bitcoin Peg section of the whitepaper begins by asserting that bitcoin-compatible smart contracts should not operate on the base layer (layer one; L1).

This statement is another way of saying that Script, bitcoin's scripting language for transactions, should continue to be relied upon as the primary mechanism utilized to process transactions on the Bitcoin network. In other words, smart contract interactions should happen elsewhere -- on another layer, Stacks.

Script reliance precludes smart contracts from operating on Bitcoin's base layer due to Script's inability to iterate, a cornerstone functionality in smart contracts and subsequent dapps built on top of them. Why is that important? Because smart contracts are a prerequisite for dapps, and dapps are a prerequisite for defi. Take one ingredient away; there is no recipe for defi with Bitcoin.

So the whitepaper says the status quo is insufficient and that something else will be needed and proposes a peg mechanism between Bitcoin and Stacks, called sBTC.

With sBTC, anyone could send bitcoin (BTC) to a dedicated address on the Bitcoin blockchain. It will, in turn, be held/locked (the whitepaper terms this "locked on the Bitcoin L1"), and upon confirmation of this transaction onto the network, a corresponding amount of sBTC would then be issued on the Stacks layer (layer two; L2).

Note, the word issued here is also synonymous with another word people who are experienced with smart contracts may be familiar with, minted. For those who aren't, minting is a technical term common to token smart contracts that increases the supply of a token. For example, if 6,000,000 BTC gets locked on the Bitcoin blockchain – 6,000,000 sBTC will be minted on the Stacks layer.

The term pegged in the above excerpt means that:

  • For every N sBTC, there is the same number of BTC backing it. A fully transparent POR, or proof of reserve, will be essential. Anyone should be able to independently verify that there are an equal number of BTC at one or more "lock-in" addresses that equal the sum of sBTC on the Stacks layer. Security will also be paramount here because the lock-in addresses will become ideal targets for hackers. The sum of BTC would grow quite large into billions of dollars.
  • sBTC will have the same approximate value (it will still be subject to fluctuating price differences across exchanges in the same manner as BTC). It will trend along the same price trajectory as BTC, meaning that if the price of BTC goes up, so will the price of sBTC. Conversely, if the price of BTC goes down, so will the price of sBTC.

The above excerpt notes that sBTC can be pegged back out to BTC. When this happens, sBTC will get removed from the circulating supply. When this happens, a corresponding amount of BTC, as previously discussed above, will become unlocked and released.

The term destroyed here again is another word people who are experienced with smart contracts may be familiar with, burned. For those who aren't, burning is a technical term common to token smart contracts that decreases the supply of a token. For example, when 1,200,000 BTC is unlocked – 1,200,000 sBTC will have been burned on the Stacks layer.

Quite a bit of what is being discussed thus far in the whitepaper shares similarities to what many people have already used in the cryptosphere – a bridge.

There are various types of bridges found across different networks and chains, and they typically fall into one of three categories:

  • Trustless / decentralized
  • Federated
  • Centralized

A trustless bridge is one that most closely shares similarities to some of the characteristics of the pegging mechanism utilized by sBTC. A trustless bridge is protocol or smart contract based. A trustless bridge utilizes a combination of oracles to provide an atomic swap-like mechanism (usually 1:1) of taking in a base asset in exchange for a bridged asset. A bridged asset is also often termed a wrapped asset or pegged asset.

The above excerpt of the whitepaper concludes that since sBTC is smart contract enabled, it can peg itself out. Note that it is smart contract enabled because it is on the Stacks layer, which natively supports smart contracts. In other words, it can burn itself from supply and unlock the underlying bitcoin that was backing it to intended recipients on the Bitcoin blockchain.

A critical piece of the implementation of sBTC will be how the Stacks and Bitcoin networks can talk to each other. They must be able to communicate when a transaction should be made, trustlessly, how much, and to whom without being compromised or exploited.

An upcoming proposed release to the Stacks protocol named Nakamoto will lay the foundation for sBTC. The Nakamoto release will enable sBTC to be fully permissionless and trustless.

The above excerpt mentions that this is a significant differentiator from other BTC-derived pegged assets, like wBTC on Ethereum, R-BTC on RSK, and L-BTC on Liquid. Tis is because they are either centralized or comprised of a federation of trusted entities (pseudo-centralized).

The paper clarifies that this hasn't been possible with Bitcoin because up until sBTC, there has yet to be a way to connect BTC to smart contract-based interactions, dapps, and defi.  A centralized intermediary has always been required because no protocol-level middleware supports decentralized communication between layers.

The excerpt closes by asserting that unlocking permissionless use of BTC alongside smart contracts opens the possibility of:

  • Hundreds of billions of dollars of BTC liquidity inflows
  • Decentralized BTC lending
  • BTC-backed stablecoins

...and that it will make it a productive asset in generating profits beyond the simple act of holding.

In other words, that it will unlock defi for all holders of bitcoin.

The whitepaper continues to delve into the uniqueness of Stacks and how it works alongside Bitcoin for the benefit of making sBTC a successful peg:

  • It utilizes a Proof of Transfer (PoX) protocol and Bitcoin's Proof of Work (PoW).
  • Stackers, AKA threshold signers, will be able to perform threshold signing for peg-out transactions (withdrawals of sBTC back to BTC).
  • Stackers will receive BTC as an incentive for their service.
  • Maintaining the peg will be the most profitable course of action.

This section continues with more unique characteristics of the Stacks layer and its connection to Bitcoin that will serve to the benefit of sBTC:

  • Users connecting BTC to Stacks (pegging) will pay no wrapping fees. With wBTC, the wrapping fee is approximately 25 basis points per wrap (0.0025%; < 1%). One can expect that they will need to pay network transaction fees on the Bitcoin and Stacks networks; however, these should be small. Note: It is still unclear whether there will be any other fees. For example, when withdrawing back to Bitcoin or who will pay the threshold signers.
  • There is no fork risk on Stacks, and as such, the chain state will be immutable and remain persistent, precluding both Stackers and sBTC holders from losses due to forks.

And a few more differentiators:

  • Stackers will earn BTC rewards (they will be paid bitcoin) for their participation.
  • Stacker selection will be controlled from the Bitcoin blockchain. It cannot be influenced or controlled from the Stacks layer by any group of Stacks miners who validate the chain's state. Stacks miners cannot censor who the Stackers are to their economic advantage.
  • A BTC payout reserve will ensure the timely processing of withdrawal transactions back to the Bitcoin blockchain are happening.

The above excerpt concludes by noting that the design of sBTC is fully scalable. It asserts that sBTC is already capable of processing hundreds of millions of dollars worth of BTC today, aiming to tens of billions in the future.

A Liveness Ratio feature ensures that the sBTC supply cannot exceed a predetermined amount of locked STX capital. Note: STX is the native cryptocurrency of the Stacks layer used to pay transaction fees on the network).

This section of the whitepaper begins by noting that for BTC to be able to be utilized in smart contract based applications, it's critical that there is no centralized or federated party in the middle.

It mentions again Liquid and RSK as insufficient solutions due to their centralized and federated processes.

It's further reiterated once again that with sBTC, anyone can participate in the system and become a signer. To participate, signers will lock in more collateral than the value of BTC that has been pegged in (BTC moved to Stacks). This excess will be released back to signers once they have processed the queue of pending peg-out requests/transactions (withdrawals of sBTC back to BTC).

Lastly, it's clarified that the only way sBTC can be minted/created on the Stacks layer is by depositing BTC via a Script transaction on the Bitcoin blockchain and that there will be proofs of reserves.

Note: There is also a bit of a slight toward wBTC reserves as being less transparent than sBTC will be toward the end of this section, but it should be mentioned that wBTC does provide extensive and fully auditable proof of reserves that anyone can independently review and verify.

The end of the paragraph above concludes the whitepaper's section on sBTC as a trustless, two-way bitcoin peg. It is also the end of Part 2 in this Deconstructing sBTC, The Whitepaper series.

Part 3 focuses on analyzing the whitepaper's sections referencing the design details of sBTC and will be released soon.

Additional resources: