Thread by @mattyTokenomics

1/ The long awaited $sBTC whitepaper just dropped.

Nothing can beat a firsthand read of the paper yourself, but having read through the whole thing, here are a few key takeaways and topics to focus on:

2/ Trustlessly using native #Bitcoin for smart contract applications (dApps, DeFi, etc) has remained an elusive "holy grail".

The fundamental challenge is Bitcoin itself is not programmable. Some may say this is a flaw in Bitcoin, while others believe this is a core strength.

3/ The ethos in the @Stacks ecosystem is to extend #Bitcoin functionality, and leverage its security as the most secure base settlement layer, without modifying or altering Bitcoin itself.

4/ Barring options that would alter #Bitcoin itself, attempts to make BTC more accessible and programmable have required significant tradeoffs.

For example $wBTC, wrapped BTC on Ethereum, is *custodial*, meaning it requires trusting the centralized entity backing wBTC

5/ As we've seen just this year from Celsius, BlockFi, FTX, Hodlnaut, and others, this is far from ideal, and not consistent with the trustless and decentralized ethos of #Bitcoin itself.

6/ Another option that lives between fully-centralized and highly decentralized extremes is to take a federated approach.

#RSK takes this approach with their $RBTC token, requiring users to trust in a federated network of centralized entities backing RBTC with native BTC.

7/ Other approaches which are further decentralized, (in theory) such as $tBTC or $renBTC, still require a degree of trust in network operators, rely on chains that do not ultimately settle to the Bitcoin chain, and/or require inputs from 3rd party oracles to function correctly.

8/ Unlike earlier attempts, $sBTC is the first non-centralized representation of native Bitcoin on a smart contract chain that settles to, and reaches finality on, the Bitcoin chain.

In other words, sBTC is native Bitcoin on Stacks, and the Stacks chain settles to Bitcoin.

9/ $sBTC also leverages some additional traits unique to @Stacks such as smart contracts that can read Bitcoin state, that Stacks natively forks with Bitcoin forks, a built in on-chain price oracle with BTC, and other mechanics from Stack's PoX consensus mechanism.

10/ (I've shared another thread at the end of this one w/ more about Stacks and how it settles to the Bitcoin chain for those interested).

Staying on $sBTC for now...

We've discussed the problem sBTC is solving, but how does it work and what tradeoffs does its approach make?

11/ There are two primary moving pieces to $sBTC to understand:

a) Peg-ins: converting native BTC 1:1 to sBTC on Stacks
and
b) Peg-outs: converting sBTC on Stacks 1:1 to native BTC

We'll begin with peg-ins

12/ To peg-in, users send a native $BTC transaction, sending for example 0.3 BTC to a "threshold signature wallet" - basically a multisig native Bitcoin wallet that requires a certain percentage of signers.

For brevity, I'll refer to this special wallet as the "TS wallet".

13/ When a user send a peg-in request by sending native $BTC to the TS wallet (the threshold signature wallet), they don't pay any fees other than Bitcoin tx gas fees

The @Stacks chain then natively observes when the BTC is received by the TS wallet, with no 3rd parties required

14/ Once the $BTC is received, a 1:1 corresponding amount of $sBTC is minted on the @Stacks chain.

So in our example, for the BTC user who sent 0.3 BTC, their corresponding Stacks wallet would receive 0.3 sBTC after the native BTC transaction is confirmed.

15/ The TS wallet they sent their 0.3 $BTC to is controlled by stackers.

Stackers are the collective group of $STX holders that have locked up their STX in the PoX consensus mechanism for that cycle.

16/ More specifically, the TS wallet is controlled by a threshold of 70% of stackers, meaning it would take 70% or more of stackers to use the wallet for any purpose - well intentioned or not (more on that later).

17/ The TS wallet contains native BTC in a 1:1 ratio to the total existing supply of sBTC. Anyone, at any time, can see on-chain how much native BTC is in the TS wallet, and how much sBTC exists in total.

What though, prevents wallet maintainers from stealing the native BTC?

18/ This brings us to peg-out requests...

Returning to our example, after using their 0.3 sBTC in a variety of DeFi, dApp, and smart contract applications, the user decides to convert their 0.3 sBTC back into native 0.3 BTC.

19/ To do this, they send a peg-out request to stackers that is broadcast as a native Bitcoin transaction on the BTC chain.

Stackers then need to respond within roughly 24 hours - they do so signing a transaction on the BTC TS wallet.

20/ This means that when stackers behave well, they process the sBTC peg-out request, sending a native BTC tx of 0.3 *from* the TS wallet *to* the peg-out requester's BTC address and burning the corresponding 0.3 sBTC.

21/ A quick note for existing stackers wondering how this signing process will work.

Unless a stacker is malicious, signing would be akin to running mining software, signing transactions for peg-out requests that are properly submitted.

22/ So what makes stackers behave well though?

What ensures they sign peg-out requests, instead of doing nothing, or even worse, instead of signing txs to send native BTC from the TS wallet to themselves?

23/ In short, two factors - decentralization and economic incentives.

Firstly, greater than 70% of stackers are required to sign the TS wallet to send native BTC transactions, meaning more than 70% would need to collude in order to send malicious txs.

24/ Secondly, economic incentives come into play. If stackers do not, or can not (because they misused the native BTC) process peg-out requests, then their $STX remains locked, and they additionally forfeit their PoX rewards.

25/ As an additional feature to improve resiliency, if stackers are taking too long to respond to peg-out requests, then the native BTC PoX rewards typically paid to stackers are instead routed to fulfill peg-out requests.

26/ Together, this means for stackers to abuse the TS wallet, there must be a material concentration in stackers that collude and they must either be irrational, or they must be both short-term profit motivated and their collateral must be less than the BTC in the TS wallet.

27/ That isn't to say risks don't exist or that the system doesn't care at all whether stackers behave well or not

While the 1:1 ratio of sBTC to BTC does not depend on value of stacked $STX, the total value of the BTC in the TS wallet to the total value stackers have locked up

28/ The system has limits in place to avoid this happening, such as a cap on the total amount of $sBTC that can created in relation to the total value of what stackers have locked up.

Nevertheless, collateral risks exists, which everyone should be aware of.

29/ In summary, $sBTC is the first trustless peg of native $BTC that is not federated, does not rely on 3rd party oracles, and which exists on a chain that is secured by, and ultimately settles to, the native BTC itself.

30/ Users of $sBTC don't have to pay fees to create sBTC or redeem it for native $BTC beyond native BTC tx gas fees that every BTC tx must pay.

Stackers still earn the yield from PoX consensus, but must now perform even more value for the network to be eligible to do so.

31/ And protocols, dApps, Defi, smart contracts, and more on @Stacks can make use of a programmable asset, $sBTC, redeemable 1:1 for native $BTC, and without any changes made to Bitcoin itself.

32/ Thanks for reading. Nothing replaces reading the whitepaper yourself though, so I highly recommend checking it out if you're interested:

https://twitter.com/muneeb/status/1603065919508709377?s=20&t=rMzu6SEkzBg0DRa1OiZa7Q

33/33 And as promised, here is an earlier thread that gets into @Stacks itself, its PoX consensus mechanism, and how Stacks transactions ultimately settle to the Bitcoin chain itself:

https://twitter.com/mattyTokenomics/status/1491780402016669696?s=20&t=8fwa8julSz2B6MPKf-HH1A