sBTC will be a game changer for Bitcoin applications. There are still some open questions with regards to its implementation. It would be great to surface these open questions for a community discussion and discuss the merits of different solutions.
For the uninitiated, sBTC is a decentralized two-way peg to use BTC in fully expressive smart contracts on the Stacks L2 layer. It’s pretty cool. If you haven’t read the whitepaper, I would recommend doing that first
Addressing the concerns of users who wouldn’t want to peg in their BTC to any layer
The Nakamoto release will allow Bitcoin holders to interact with decentralised applications in a way that’s far more secure than any design that’s been tried before. Yet, there is a significant group of Bitcoin holders that’s inherently skeptical about pegging in their BTC to any Bitcoin L2. If we, as the Stacks community, manage to address the concerns of these Bitcoin holders effectively, we will be able to significantly expand the user base of Stacks as a Bitcoin layer.
One way of addressing these concerns is to emphasize the use of sBTC for throughput and offering users ways to interact with decentralised applications on the Stacks L2 with native Bitcoin.
For example, say two Bitcoin holders want to do an NFT transaction. The NFT marketplace could offer payment options in native BTC. The buyer of the NFT simply makes a Bitcoin transaction to buy the NFT → the BTC gets pegged in under the hood into sBTC and the sBTC is held in a smart contract by the NFT marketplace on the Stacks L2 → the NFT marketplace smart contract pegs out the sBTC through a wrapped contract which points the pegged out BTC directly at the Bitcoin address of the seller of the NFT.
sBTC for throughput works well in applications where transactions are instant. However, the challenge is that the primary use-case for BTC in smart contracts is collateral (to borrow cash). And collateral in smart contracts remains idle until a liquidation happens. Conservative Bitcoiners would likely not be compelled to use their BTC as collateral if their BTC will sit in a contract on the Stacks L2 as sBTC for the entire duration of the loan - especially as these loans could be outstanding for years.
Discreet Log Contracts (DLCs) can offer a potential solution to these concerns. A user posts BTC collateral in a DLC & the DLC liquidates directly to the sBTC peg wallet in case of a liquidation. Stacks layer smart contracts have the unique ability to read whether BTC collateral has entered a DLC on the Bitcoin blockchain and can create loans accordingly. A smart contract on the Stacks L2 would signal when the DLC should get liquidated. After this liquidation signal from the Stacks smart contract, a DLC oracle produces a signature to proceed with the liquidation of the DLC to the sBTC peg wallet. The sBTC minted from the peg wallet can automatically end up in a liquidation contract on the Stacks layer, through which it’s put up for auction. The proceeds of the auction would go back into the lending pool on the Stacks L2.
Using DLCs and sBTC in combination allows conservative Bitcoiners to avoid ever holding their assets on any other layer. BTC only moves on the Stacks L2 as sBTC during a liquidation (when the Bitcoiner lost their BTC already).
Now the challenge for using DLCs with sBTC is that in the current whitepaper design, the sBTC wallet address changes every stacking cycle (to allow for new stackers to enter the system). DLCs require a constant BTC wallet address. An implementation that we could consider is one where the sBTC wallet address remains the same, but its private keys rotate (allowing for new stackers to join). Igor Sylvester from Trust Machines has some interesting thoughts here, in part based on this resource (What is proactive secret sharing scheme? - Cryptography Stack Exchange), yet the path remains unexplored. It would be interesting to dive deeper here and potentially fund grants that explore the ways in which DLCs and sBTC can work together.