sBTC Research - Cap on BTC in Peg Wallet #316
Replies: 7 comments 6 replies
-
Currently under investigation by @andrerserrano |
Beta Was this translation helpful? Give feedback.
-
Research summarized here. |
Beta Was this translation helpful? Give feedback.
-
Some discussion here as well https://discord.com/channels/621759717756370964/1100888369380212757/1166541727365087333 |
Beta Was this translation helpful? Give feedback.
-
It's become pretty clear from previous discussions that a capped sBTC will be a disaster for DeFi protocols on Stacks. We had an initial open discussion here: https://forum.stacks.org/t/making-sbtc-ready-for-defi-prime-time/14421 There's really no way that DeFi with sBTC can succeed when there's a cap on minted sBTC As a user, I personally won't use sBTC as collateral in DeFi when there is a cap (extreme long tail liquidation risk) |
Beta Was this translation helpful? Give feedback.
-
I'm supportive of the removing the cap for the following reasons:
It's important that we communicate this change clearly, since it does introduce some new trust assumptions. We can also emphasize our strategy to work with high-reputation signers to mitigate any potential concerns. Long-term we plan to do continued R&D on technologies like BitVM and DLCs to explore potential avenues to reduce the trust assumptions of the peg. |
Beta Was this translation helpful? Give feedback.
-
I think the key thing to understand here is that the cap vs no cap choice is actually a choice between two different underlying designs: (a) A design where signers are mostly anonymous and the only security guarantee is the STX capital locked The evolved sBTC design is (b) and not (a) and the whitepaper needs to be updated to reflect that. There is a huge difference between the security properties of the two systems. In (a) the system is very much dependent on the STX/BTC price and the economic security whereas in (b) the final backstop for security is the > 30% of institutional signers regardless of STX/BTC price. I personally would feel more comfortable with (b) given Stacks is still a relatively small ecosystem and STX/BTC price can be volatile. More importantly, design (a) absolutely requires a cap on sBTC supply and that is a bootstrapping issue. If Stacks marketcap was north of 10B and the sBTC cap could be in billions then you could explore design (a) more. Having a cap of 100M or even 200M immediately puts a small ceiling on potential DeFi usage and discourages large players from even entering the system. Given these market realities and what the BD working group has learned from parties that want to use sBTC in DeFi, the uncapped version with trust-assumption of institutional signers as final backstop seems like the clear path forward. We should also keep in mind that the goal here is to deliver a practical system that is usable in 2024-2025, not some theoretical perfect thing that doesn't work in short-term (say due to practical limitations like low cap). There is rapid innovation happening at Bitcoin L1 e.g., with BitVM that can potentially reduce trust assumptions for BTC pegs. As those technologies mature or if Stacks marketcap matures at a much higher number, the devs and community can revisit some of these design choices. As far as the Nakamoto release is concerned I think setting these design parameters concretely helps everyone. So there is less confusion and it's super clear what exactly is the system that is being built here. Appreciate the discussion here. I think it's an important topic. An important next step will be to update the whitepaper (which is open-source and the working group updates it). I can try to help with it -- thanks! |
Beta Was this translation helpful? Give feedback.
-
The sBTC working group is in agreement with these points and will pursue design (b). The hard cap will not be included in the protocol implementation. Next step is to update the whitepaper and prepare other educational materials on this design choice. |
Beta Was this translation helpful? Give feedback.
-
This is a research discussion post meant to be edited with research notes surrounding adding a hard cap on the BTC in the peg wallet.
The primary concerns are:
Beta Was this translation helpful? Give feedback.
All reactions