Making sBTC ready for DeFi prime time

[Tycho]

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

Peg collateralisation

Every sBTC will be 1-to-1 collateralised by BTC. The BTC on Bitcoin L1 is kept on a script controlled by an open group of threshold signers. These signers are the ‘stackers’ who lock STX capital in Stacks consensus and earn a BTC reward for performing the work of signing BTC peg out transactions. (STX is the native token of the Stacks L2, used for miner incentives and signer incentives). In addition to the 1-to-1 backing of sBTC with BTC, the current whitepaper proposes an additional >200% collateralisation ratio of STX to BTC.

A fixed collateralisation ratio of STX to BTC introduces a cap on the amount of sBTC that can be minted that can introduce bootstrapping challenges in the early stage of the network.

An example of a bootstrapping issue introduced by a cap on sBTC supply:

The primary use case of BTC in smart contracts is collateral. Users lock BTC to take out a loan against their BTC, allowing users to get liquidity without selling their precious BTC. I expect collateral to be the killer usecase for sBTC.

If a user would take out a USD loan against sBTC and BTC experiences a price drop, the user now needs to top up sBTC collateral. However, when BTC drops it’s likely that STX drops faster. As a result, there’s a non-trivial probability that the sBTC cap will be reached and the user would be unable to peg in fresh BTC to sBTC to top up their collateral → user gets liquidated.

It could be theoretically possible to use a soft cap where it gets more expensive to peg in BTC when the cap is reached (or financially rewarded to peg out), which helps solve the above mentioned potential liquidation issue.

Institutional users are most likely to have problems with a capped sBTC supply, since they would need to peg in/out in size to maintain their positions. For these institutional users, a CeFi loan against their BTC would offer a much better experience than using a capped version of sBTC (if sBTC is close to the cap), especially since large institutions can get a white glove service with CeFi companies (proof of no rehypothecation of collateral, etc).

In an ideal world, a theoretical best solution can be to allow for uncapped sBTC supply. In this case, sBTC would remain backed 1-to-1 with BTC at all times, yet there would be no cap on sBTC in circulation.

If users don’t trust the STX stakers, users can just peg out their sBTC when sBTC supply grows to a level that they’re uncomfortable with (vs stacked STX value). At the same time, for STX stackers to steal BTC from the peg wallet, they would still need to collude. If the signing threshold for processing peg outs is (say) 70%, then >70% of STX stakers would have to collude to steal the BTC. If large institutional players like custodians, exchanges, staking companies etc are part of the signer set then collusion only becomes possible in practice by getting these large custody providers, exchanges, and other large holders of STX to collude with each other. All of these players have reputational risk (and real threat of going to jail!) in addition to just the economic loss. There can be public dashboards to monitor the level of STX locked to sBTC ratio and users can transparently get this information through wallets and make their own decisions i.e., free markets at work.

For the community to make a decision on whether capped or uncapped sBTC supply is the way to go, it would make sense to see which signers will emerge for the sBTC consensus upgrade. If large professional entities like Coinbase Custody, Bitgo, Anchorage etc are signers (and hold more than 30% of the STX supply) then users know that these custodian/exchanges will need to collude with each other to break the system which is a highly improbable event in practice.

For now, it would be great to discuss this question of peg-collateralisation openly. It’s important for the community to be aware of this topic and surface all arguments for/against. Please share your thoughts below

[pipje]

I like this idea. It’s important that there is as little friction as possible when minting sBTC (especially for institutional users as mentioned), since it’s very easy for deep pockets to dismiss something when there’s friction involved. A hard cap on sBTC will make liquidity fundraising + onboarding institutions harder. I imagine most retail users will not directly mint sBTC either, but swap it through an atomic swap or similar (something like Magic?), so the use case to optimise for is definitely big BTC liquidity providers.

Additionally, if you are reaching the hard cap, it might become more expensive to acquire sBTC on-chain. I don’t really like the thought of that (as it breaks 1-1 tradability between BTC and sBTC).

Having said that, I think there might be some risk wrt security and institutions (and generally everyone) might be worried about that as well if there’s no hard cap. I am not entirely sure what the best compromise is here.

Today there’s ~350M STX stacked. It would be helpful to see who these parties are. E.g. there’s about 10 BTC reward addresses who have stacked over 10M STX (and the highest stacks 26M STX). Who are these people? How will that share evolve over time? What’s the risk that they collude?

[jude]

SIP-021, which is the authoritative description of how the system will work, uses a default collateralization ratio of 200%, but requires that the .sbtc contract provide a means of changing or disabling it altogether (see this section).

[Tycho]

Thanks for providing that context.

I think it would be important for the Stacks community to come together and discuss what the default collateralisation ratio should be (and if it should exist at all).

To the outside world, a default collateralisation ratio of 200% is a collateralisation ratio of 200% (I doubt users will think much about whether or not it can be changed).

If I as a user am looking to put some of my BTC up as collateral to borrow against - and I realise that there is a long tail risk of a forced liquidation where the sBTC cap is reached due to the default collateralisation ratio - then I have a strong case to not use sBTC as collateral at all.

I would also like to add some further context that the existing BTC peg-projects on other chains (Ethereum & Cosmos) have moved away from default collateralisation ratios:

1. tBTC first launched with a collateralisation ratio in ETH, and recently relaunched without such a collateralisation requirement (see Threshold for more info).
2. renBTC was a fork of tBTC and also launched with a collateralisation ratio in REN (their native token), in 2022 they removed this collateralisation ratio altogether amidst capital efficiency concerns
3. Nomic (looking to launch a decentralised BTC peg on Cosmos) won’t launch with a collateralisation ratio either, citing capital efficiency concerns and introducing a fee curve model

Nomic writes the following about collateralisation ratios in their design document

However, this requirement is typically very capital inefficient - for a network to safely hold $1B in its reserves, signatories would need to invest more than $1B in other outside capital as collateral. This requirement is also assumed to have prevented adoption of these decentralized custody projects in favor of centralized trusted custodian-based projects such as Wrapped Bitcoin. (source)

[wagmi]

I strongly agree with @Tycho’s point that a fixed collateralisation ratio can lead to negative unintended consequences for sBTC adoption. In fact, the first time I read the whitepaper I identified the cap as the biggest vulnerability in the sBTC design.

I’m in favor of letting the free market regulate itself and not having a collateralisation ratio at all. As Tycho outlined we can make the current collateralisation ratio metric easily and readily available to the wider community (by, for example, in-bedding it on popular Stacks community tools like the explorer, etc.), which in turn allows all market participants to make informed decisions with their capital. If you believe the collateralisation ratio is too high, you simply de-peg.

[Albert-Present]

This issue is essential to resolve. I agree one of the killer use cases is collateral as it is necessary for a fully functioning Bitcoin Defi ecosystem. Thank you Tycho for leading the discussion.

[hank]

I understand the challenge imposed by a collateralized system, but I feel like this is a “can’t have your cake and eat it too” kind of thing. You can’t have an open-membership and decentralized custody model and have no collateralization limit. Or, you can, but the system becomes at-risk due to an economic benefit to steal funds.

I could understand an argument that maybe it’s just best for the market to decide what the collateralization level should be, instead of the protocol. If it becomes too undercollateralized, users will withdraw funds.

I still think you’d have a situation where some users are uncomfortable with the system - if you fix the ‘hard cap’, you introduce custody risk. Either way, you don’t have an unlimited supply

[Tycho]

Appreciate your thoughts! To get all arguments out there in open discussion, I would put forward the following

1. With regards to the point about ‘can’t have your cake and eat it too’, I would suggest that this argument also applies to launching sBTC with a hard cap. A hard capped version of sBTC risks underdelivering on the promise of bringing Bitcoin utility to the Stacks layer. The idea has already been tried numerous times in the market and didn’t live up to it’s promise of decentralised BTC liquidity (Threshold’s tBTC and Ren’s renBTC both moved to uncapped versions after failing to get significant traction). To have a shot at dethroning wBTC, we should seriously consider removing the hard cap. We can’t have our cake and eat it too in that sense.

2. With regards to some users being uncomfortable with using sBTC without a hard cap, I would suggest that these users would likely also be uncomfortable with using sBTC with a hard cap. Even though there is a hard cap in the current design, STX governance could still come together to abolish the hard cap at any time. If a user is really concerned about an incentive compatible system, they will be uncomfortable collateralising their BTC as sBTC to buy a car/house with or without a hard cap. After all, the hard cap can be removed at any time by the network - leaving the user exposed to custody risk after taking out their loan (a loan they can’t pay back immediately if they just made a significant purchase). In other words, if the user that’s uncomfortable with using sBTC without a hard cap is a rational actor, they wouldn’t use sBTC at all.

[xan]

Thanks for bringing this up Tycho - I think it’s a key point to decide on and get right before the launch of sBTC.

While I sympathize with Hank and see his point, I agree more with Tycho’s application of the phrase to the trade offs of launching with a hard cap vs. without. I’m not sure on the correct details of how to launch a system users can feel secure using without a hard cap, but I do know that if we launch with a hard cap we will likely never get sufficient adoption in the system at all.

Anecdotally from conversations I’ve had with some institutions, they generally fall into two camps: (1) those who are unwilling to evaluate and take protocol risk and will only engage in CEFI lending (majority right now), and (2) those who have gotten comfortable evaluating protocol risk and are willing to engage in DEFI lending. Our target market is obviously that second cohort, and for them we need to make a competitive argument for our offering vs. centralized solutions. While the protocol risk is different with a hard cap vs. without, institutions will have to evaluate such a risk either way. In the case of a hard cap, however, I think it’s difficult to make a competitive argument for sBTC against which to weigh any protocol risk.

[JakeBlockchain]

I vote no cap. Full send.

Jk, My thoughts are to default to whatever is less risky to start. With a product this new and innovative, You want to make sure the people who CAN use it have an ideal UX.
Going with a default ratio to start, and stress testing the system before progressively lowering the collateralization ratio based on benchmarks. This might make it harder to market the system though.

On another note. I think either system will have stress points and the free market of Stacks builders will likely build solutions to solve some of them. Things like decentralized mining pools that can redirect STX to stacking when a ratio threshold is hit.
My 2 sats.

Great discussion so far. Thanks for prompting @Tycho

[MattySTX]

At first glance this proposal feels risky - hence the controversy. A collateralization rate is intended to protect against a scenario where the value of BTC in the threshold signature wallet begins to exceed 70% of the total value of stacked STX, because in this case, the stackers have a one-time profit motivation (albeit a short-sighted one) to collude and make off with the BTC.

However, the above theory makes a series of assumptions in practice:

The first assumption is that placing a maximum cap on sBTC is equivalent to placing a maximum cap on the BTC held in the threshold signature wallet at any given time.

This is because the native amount of BTC deposited/held/controlled by the wallet is what actually influences the degree of economic risk (i.e. the risk is people stealing native BTC, not stealing sBTC). Why then, is sBTC capped, and not BTC? Simply because it is not possible to cap BTC held by the wallet. Anyone, at any time, can send additional BTC to the threshold signature wallet, even if/when it is ill-advised to do so, and even if/when they would not expect to receive minted sBTC immediately (because the sBTC cap is currently exceeded).

What this means then in practice, is that this cap, while in theory directly limiting the size of the threshold wallet, is actually relying on users to know when they should or should not send BTC to peg-in, and assumes that not receiving sBTC immediately (until the system is back under the collat ratio) is a meaningful deterrent to sending new peg-in requests.

In other words, the collateralization cap is implicitly assuming that users will already be monitoring the current collateralization rate conditions when they make a new peg-in request.

If users are not doing so, then they will send BTC to the wallet even when the collateralization ratio is exceeded - meaning the cap is ineffective at achieving the goal of limiting the wallet size anyway.

If users are doing so however, it calls into question the need for the cap in the first place, since if users are already monitoring the collateralization level and making a decision about if it makes sense to send new peg-in requests, why not just let them do so without the downsides of a hard cap?

Therefore, the primary benefit of the cap, if not the only benefit in practice, is arguably to encourage people to first look at the collateralization ratio status before deciding to send a peg-in. But since this can’t be done strictly by limiting BTC transactions, and would have to be achieved by UI/UX measures and making the collateralization status very publicly transparent anyway, the question then becomes why not give users the same information via the same means and mediums, but just let them decide for themselves at the time? (and give them tools to monitor and get alerts on collateralization levels - or even ways to automatically trigger peg-out requests if collat ratios hit a target value that is too low for their personal risk preferences)

TL;DR
Personally, I think if the sBTC cap was actually a cap on the native BTC in the wallet, I would be in favor of a system collateralization ratio as a common sense safety measure that could be updated by governance (and thus would still be up to the market).

However, the reality is that we should not mistake a cap on sBTC for a cap on the underlying driver of economic risk. A cap is not really preventing someone from sending BTC to peg-in when they “shouldn’t”, it’s really setting a level at which a big warning sign starts flashing to users in a UI/UX before they decide to do so.

Given that’s the reality of the situation, why not keep the warning sign, but lose the cap?

[Tycho]

Very valuable input @JakeBlockchain and @MattySTX!

[OwensTrevor]

I’m in favor the cap, especially in the first year or so. Whether that’s 250%, 200%, or 150%, it should be modeled out in a security analysis looking at market volatility.

I think this cap is needed to get market adoption. There has already been several well known maxis argue that market volatility of the STX token is the key attack vector of this model. The cap is the key argument against this issue.

Right now we are at only $2.2M in BTC on Stacks via xBTC. Recent interest in Stacks has led to the market cap of stacked STX to reach $236M as of this writing.

Meaning, there’s room for $115M in sBTC to be minted. More than a 50x increase. What makes us think we will exceed this limit from the start? I think this is putting the cart before the horse. Naturally, increased BTC volume on STX will lead to a re-pricing of the network value, and it would be wise to measure this effect before deciding we need to remove the cap which will decrease Stacks’s ability to win the narrative war that this is an innovative and successfully decentralized/safe BTC peg. There may be no need to remove the cap at all to get the desired effect here.

I don’t see any rush. It would be better to make this decision when we have more data and the system is live. $100M in BTC liquidity would be a game changer, so let’s focus on reaching that goal first.

Changing the system to shoot for greater liquidity—when we don’t know where it will come from—is going to shoot us in the foot when we have already seen people criticize the network when they didn’t think about the cap.

In other words:

1. Removing the cap may not be necessary due to the flywheel effect
2. Removing the cap will hurt sBTC in the court of public opinion—we’ve seen this already
3. $100M in BTC is plenty of room to grow
4. We don’t have evidence of demand to warrant removing the cap

[GM-Chung]

I agree with you on the bootstrap side, but due to the still untested protocol environment, I think it would be nice to put some restrictions on it.

This is just my idea. Although it is a centralized asset, if you we xBTC, we can increase liquidity through a stable swap between xBTC <> sBTC, and it will help grow both assets and secure liquidity in an emergency.

And personally, I’m also interested in bringing (non-wrapping) Bitcoin assets via cross-chain messaging.

[Tycho]

Thanks for your comments @OwensTrevor

In general, I would suggest that it’s unlikely that sBTC will get desired traction unless the cap issue is resolved. While it’s tempting to think that this issue can be revisited at a later stage when some initial sBTC will have been minted & there has been a marketcap effect on STX price, sBTC likely won’t get minted in size precisely because there is a cap. sBTC’s killer usecase is collateral and the cap undermines this usecase by introducing long tail liquidation risk. If it isn’t collateral, I wonder where this first $100m of BTC liquidity is going to come from? @xan added a valuable comment on the institutional perspective above.

On this point ‘There has already been several well known maxis argue that market volatility of the STX token is the key attack vector of this model. The cap is the key argument against this issue.’ It’s important to recognise that the volatility of the STX token is an issue when the model is capped, not in a version of sBTC without cap. Especially after FTX, the most common argument is seems to be something along the lines of ‘don’t collateralise your operation with your own token’. A version of sBTC without cap doesn’t rely on any collateral logic to claim incentive compatibility. Rather, this system makes the honest claim that an sBTC user places trust in the Stacks network for the duration of the operation for which they require sBTC (as is also the case when a cap exists, since the Stacks network could choose to abolish the cap at any given time, thus requiring the sBTC user to place trust in the Stacks network regardless of whether or not there is a cap).

PS: it’s also unclear how a cap would get enforced since Bitcoin transactions famously cannot be stopped

[HeroGamer]

May I bring up a slight different angle from governance perspective.

If BTC were pegged in, receiving sBTC derivative & if sBTC were a first class citizen on Stacks. Does this mean $sBTC would receive as much governance voting rights as $STX token. (voting like we did last November~December for Stacks 2.1 activation)
Assuming if it doesn’t receive voting rights at all, then has probably no impact.

However if assuming if sBTC does have some voting rights, then having uncapped sBTC “printing” will mean uncapped “governance” voting power? The result of which means it can have uncapped influence the future Stacks network direction. Cannot think of a solution right now. Will put more thoughts into it as this convo evolves. If my train of thought is wrong I apologize!

Tagging Governance CAB chairperson @whoabuddy for more gov expert view.

[andre.btc]

Thanks for starting this discussion Tycho. I agree it’s critical that we resolve this, given it’s importance for strategic product-market fit.

Initial impressions:

• We could launch an MVP version of sBTC with strict guardrails on the cap. This would allow us to test in production with only a limited amount of sBTC at risk.
• Once the protocol is battle tested and highly reputable signers are confirmed, we can consider lifting the cap. For this stage, it’s important that we have publicly verifiable data for the locked STX, so users can make informed decisions about the level of risk. Moving toward, messaging such as “trust-minimized” can help with broader positioning for this.

@HeroGamer

However if assuming if sBTC does have some voting rights, then having uncapped sBTC “printing” will mean uncapped “governance” voting power? The result of which means it can have uncapped influence the future Stacks network direction. Cannot think of a solution right now. Will put more thoughts into it as this convo evolves. If my train of thought is wrong I apologize!

I think we should limit governance rights to STX. This give additional utility to the STX token to determine network parameters. The decision to lift the cap should be determined by STX token holders.

@Tycho I’d like to invite you to discuss this topic at this weeks GTM meeting, since it deserves community discussion for how to address it. Look forward to having you share your perspective!

[Tycho]

Would be happy to chat more about this in the GTM meeting. I can lay out the arguments that have been surfaced here so far for both sides.

Very much agreed that STX should be the only asset with governance rights (adding another asset will introduce many many edge-cases) + that knowing which signers will participate is an important input for weighing all the pros/cons for cap/no cap.

[ReadyPlayr18]

@Tycho

If a user would take out a USD loan against sBTC and BTC experiences a price drop, the user now needs to top up sBTC collateral. However, when BTC drops it’s likely that STX drops faster. As a result, there’s a non-trivial probability that the sBTC cap will be reached and the user would be unable to peg in fresh BTC to sBTC to top up their collateral → user gets liquidated.

I very much agree capping sBTC could limit institutional and HNW retail adoption, though haven’t fully formed my thoughts about whether uncapped sBTC should be a condition of launch.

As I’ve thought through this, the sBTC cap and collateralization debates seem to be functions of the desired trustlessness of the peg wallet.

ie. in a fully trusted scenario, there could be a single institution managing the peg wallet with no cap and no collateral requirements. obviously, the recent FTX debacle with unbacked wBTC probably makes this a non-starter for most personas required for sBTC to reach meaningful scale

on the other hand, in a fully trustless scenario with a peg wallet managed by cabal of shadowy super coders, collateralization (skin in the game) is pretty much the only defense against dishonest signers. if we’ve learned anything from the $2b+ bridge hacks on other chains (Cross-Chain Crypto Bridge Hacks Hit $2 Billion: Chainalysis - Decrypt), there will be dishonest signers when the stakes are high enough

the most compelling answers i’ve heard in these debates and what I currently believe is the best path forward is to focus on the credibility of the peg wallet signers. a consortium of trusted entities with access to deep pools of liquidity that can be trusted to maintain the peg wallet during periods of extreme market volatility feels like the most promising path forward

not sure if any biz dev conversations have started w potential institutional peg wallet signers and if they have, how far along they are, but my gut says who the peg wallet signers will be is a critical constraint that should be factored into these discussions

also, one other question: does the peg wallet collateral have anything to do with stacking (other than compete with it for STX in circulation)? my current understanding is STX deposited as collateral in the peg wallet can’t also be stacked (and stacked STX can’t be used as collateral in peg wallet)

[stxnomnom]

I find myself more convinced of the arguments against a hard cap. Probably is something best determined by the market and each individual participant and with the appropriate monitoring tools for people to make well-informed decisions.

In addition to this, we could introduce a mechanism whereby on peg-in, a user could indicate their peg-out priority preference. They could indicate something like a minimum collateralization ratio (CR). Those that have specified a lower mimimum CR would have their peg-outs processed first. Of course we’d need a way to incentivize those that indicate a lower liquidity preference as they are essentially performing the service of giving longer term stability to the peg.

Having a mechanism like this can give the market more information about the ‘depth’ of the peg. For instance I may be more comfortable pegging-in if I know I can set a high preference for pegging-out and am able to peg-out before others should the CR get too low for my liking.

I haven’t completely thought through how exactly this would be implemented, but thought it could be an interesting mechanism which could help reduce uncertainty around the peg and give it more stability and just wanted to get the idea out there.