Let us cite the project lead of tBTC, Matt Luongo, for a description of tBTC :
tBTC is a Bitcoin sidechain on Ethereum, built to give Bitcoin the capabilities of Ethereum and bring additional collateral to DeFi. The asset (TBTC) is an ERC-20 pegged to Bitcoin, it can be minted or redeemed for BTC by anyone and without intermediaries. Instead of relying on a single custodian like wBTC or federation of custodians like Liquid, tBTC is supported by a decentralized bonded multi-federated peg model using ECDSA technology.
Its current supply is 628 TBTC and its TVL is of 66M USD, with 38M in KEEP and 20M of ETH backing 8M worth of BTC according to https://keepstats.org/.
wBTC is the most liquid Bitcoin-on-Ethereum ERC20, with a supply of 106K wBTC.
Although there’s currently a vote for implementing a tBTC/[sBTCpool] metapool, this exposes the LPs to compounded tBTC, wBTC, sBTC and renBTC risk. CIP#30 - Introducing a [tBTC, [sBTC]] Metapool
We believe that because many LPs would prefer be exposed to the risks of tBTC and wBTC only, a wBTC/tBTC pool would greatly increase tBTC/wBTC liquidity on Curve and hence reduce slippage for tBTC/wBTC swaps, which will be an important volume driver to Curve.
For:
Reasons why this proposal should be voted for
-Increases tBTC/wBTC on Curve, possibly an important BTC-On-Ethereum market
I would like to provide liquidity through a tBTC / wBTC pool.
wBTC aims to be a centralised custodian for BTC on ETH and complies with the regulations around doing this.
For me the tBTC / wBTC / sBTC / renBTC metapool carries higher risk and requires a higher level of research to gain confidence.
My research into sBTC is still very early. My research into renBTC has raised concerns while RenBTC is centralised. Ren aspires to be decentralised however it is currently operating as a centralised federation of nodes.
I believe renBTC has risks from
All of the BTC being in a single 5 of 13 multi sig wallet.
All the nodes are currently run by the team.
Only components of RenVM have been open sourced.
The system as a whole has not been audited.
I believe the current economic model for REN poses a non-trivial challenge to becoming decentralised.
The REN economic security model requires 300% collateralisation it is currently around 12%
The REN token is the only collateral, if the market loses faith, the incentive to collude and steal funds increases.
Over time the REN token price should correlate to the fees it generates to Darknode operators, however fees are proportionate to mint and burn volume not the total locked value (TLV).
If the utility of renBTC increases I believe there will be less burn volume and the Total Value Bonded (TVB) will not keep pace.
In the graph above the TVB has been calculated using the historical REN price from CoinGecko and the number of nodes from https://darknodes.online/epochs/, the TVL has been calculated from the cumulative mint and burn volumes and the historical BTC price from Coinbase.
All wrapped forms of Bitcoin come with trade-offs, there is no doubt about that. wBTC will be centralized forever and that carries those risks we are aware of. sBTC and tBTC both use the collateral and liquidation model, and that brings with it dangers of a collapse of the peg if there is too much volatility too fast, and problems with scaling liquidity. Ren uses fees and cash flow to secure the system, which requires a level of adoption before it can securely be decentralized (and therefore it starts out centralized as it is now).
This diversification of risk is good for us, because right now we are still so early, and we don’t know very well how things will play out in the future. If any of these models fail, we have other ones to fall back on.
All of those things you listed are underway to change. Just a few days ago we began putting the fee mechanics to work, to collect data on how the market responds. Down the line the fees will be adjusted dynamically to balance the TVL vs. TVB. But while the network is permissioned, the peg is secured regardless of the TVL vs. TVB: https://twitter.com/MaxRoszko/status/1318930909626834950?s=20
A pair with only tBTC and wBTC is inherently less risky for LPs than one that also has renBTC and sBTC. Let me remind you that for a pool with 4 tokenized bitcoins means that if only one of those pegs fails, the LPs can lose all their money.
This means that much greater liquidity should occur in that pool, for the same amount of incentives. If we think tBTC, wBTC is where the vast majority of swaps will occur, there’s no reason to add two other assets. This only brings additional, compounded risk that will lower liquidity for that pair.
Look at renBTC/wBTC, which is more successful than the renBTC,sBTC and wBTC pool. I’d like us to replicate this with tBTC/wBTC. I think tBTC/wBTC is a better place to build tBTC liquidity than the metapool. Thank you.
This is a common misunderstanding of LP pools. Adding more assets doesn’t diversify the risk, it actually only increases it. If only one of the assets in a curve pool suffers a permanent loss of peg, LPs will end up left with only that asset. This means that if tBTC,sBTC,renBTC or wBTC goes to zero tommorow, the LPs will lose everything. A pool with renBTC, sBTC, tBTC and wBTC is by definition more risky than a pool with only tBTC and wBTC.
If you don’t believe me here’s the same information directly from the Curve documentation
the metapool is already launched, I’m not asking to change it : the community wanted to launch a metapool. ( + it’s immutable and can’t be changed anyway)
As you can see in the name of my proposal( sCIP#7 - Adding a tBTC/wBTC pool ) , I’m proposing the community to launch a new tBTC/wBTC pool, as I think this is another useful pool to have, that is less risky to LPs and hence will gather more liquidity.
Proposing a new pool is still a valid proposal IMO, and people have the right to vote for or against as veCRV holders if they agree or not to a a new pool. Multiple pools in Curve share common tokens, and already having a token in a pool does not mean proposals to add new pools with said token are invalid.
I’ve thought a bit more about this and I would say for me it’s a bit early but would consider if volume and liquidity is good for tBTC in the next couple of weeks (for the record I haven’t voted).
I think the rationale for creating a less risky pool matching tBTC with wBTC does make sense and resonates with me as we all (I think) understand the risks and manage their moves accordingly. I can see the appeal to the LP over the current metapool that exposes you to the risk of all four compenents. That said I think we need to give the newly deployed tBTC metapool time to ramp up…as Charlie mentioned to gauge its volume and liquidity before moving down this path. I say we table this for some time before we move to vote. As for me I am generally amenable however the community so far at least based on the votes and comments thus far seem to be less so but given time may become more receptive.
Edit: I would like to let the current pool run for at least two weeks before we decide. Full Disclosure, I am an LP for the current tBTC pool and would not be bothered by this proposal to add this pool but it should make sense and be of benefit to the Curve community.
Edit 2: Seems this vote is trending positively now which is good to see therefore my comments for waiting are moot.
It’s too early for something like this, the meta-pool only has 200 tBTC, so a new pool would compete with this, plus tBTC still has a contract supply cap.
And it’s not clear what demand there would be to trade tBTC only against wBTC, where would the volume come from? It’s easier to get hold of wBTC than it is tBTC, and exiting from wBTC to BTC through tBTC is not UX friendly because you can only redeem in a few lots like 0.1, 0.5, 1.0, 5.0 etc. What happens if you want to redeem 3.75 tBTC, do you have to do 5 transactions just for that?
