Making sBTC more compatible with the values of Bitcoiners

Core Blockchain
#1

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.

5 Likes
#2

Update: I wrote this post a while ago and just realised that of course the peg-in address is no longer dynamic since the proposal to use OP_DROP passed that @FriendsFerdinand and I drafted.

Now, the peg-in BTC address will be determined by the Stacks address that sBTC peg-ins are directed to

As a result, it would be possible to initiate DLCs between a borrower and a unique static BTC address for peg-ins that contains a liquidator contract on the Stacks side to liquidate the BTC as sBTC once a liquidation event occurs.

The open question remains, how does this unique peg-in address participate in the initiation of a DLC (for which I believe a signature is required somehow). I will continue to think about this open question with @FriendsFerdinand, though if anyone with DLCs can chime in that would be much appreciated :pray:

2 Likes
#3

This is a very important direction to explore to strengthen further the value proposition that sBTC offers, specifically to Bitcoiners that don’t like to wrap their BTC into any layer, of which there are many. I’m excited about the approach and would love to see proposals for tighter integrations with Discreet Log Contracts (DLC).

I colloquially use the name sBTC Savings Account to refer to the mechanism behind a long-term sBTC deposit, possibly built with DLCs.
This is in contrast with the name sBTC Checking Account, which refers to the current effort being worked on.

Unfortunately, the sBTC Eng Working Group does not have the capacity to deliver on this initiative in Stacks 3.0. However, I created the GitHub issue below to invite daring Stacks community members to contribute ideas, proposals, and software to push the initiative forward. If anyone here would like to contribute, please comment on the issue.

3 Likes
#4

I want to put forth my support for the effort of making sBTC available to Bitcoiners that don’t want to wrap into L2s. I think this could unlock a significant portion of the market.

At Hermetica Finance we would welcome the ability to offer DLC collateralized deposits to our option vault products.

3 Likes
#5

This would be a great avenue for the team at DLC.link to explore, given their DLC and Stacks associations. Will forward this along.

#6

Thanks Tycho for kicking off this thread. At DLC.Link we also feel like having a peg-in to an L2 like stacks would be the perfect way to open up many great use-cases for DLCs, and allow people hesitant about L2s to benefit from the great Stacks ecosystem and tech.

Regarding your second post Tycho, sBTC having a stable address is great news! That’s new to me.

And regarding the signing process, yes I believe the “peg” side requires the ability to sign with the same keys both during the DLC creation as well as during the close.

Is it possible for the sBTC system to sign during the DLC creation, and again with the same keys during the liquidation step when the DLC is getting closed?

2 Likes
#7

Thanks for your comment!

Is it possible for the sBTC system to sign during the DLC creation, and again with the same keys during the liquidation step when the DLC is getting closed?

We would have to look into this. I can respond here once we’ve spent some time thinking about it

2 Likes
#8

Assuming sBTC is launched with a hard cap ratio, this would enable borrowers to add to their collateral even if the hard cap ratio is reached. However, I have reservations about launching with a hard cap ratio. See topic here