-
Notifications
You must be signed in to change notification settings - Fork 42
V1 upgradeability path for tBTC #139
Comments
Basic idea for upgrades is that Try to sync this work with RFC-9 from |
I am generally a fan of upgrading via migration, by a one-way peg (burn 1 tbtcV1, get 1 tbtcV2), but you might have issues coordinating with exchanges. |
I'm in the same boat re: social migrations, just trying to draw the fully nuanced line here. I think we get close with
So new signature schemes can be opted into by individual depositors, as can larger or smaller lot-sizes. System-wide economic concerns need global opt-in (social upgrade). I don't think we can assume 1-way pegs between tokens, since there will be BTC locked up in the "old" token in some situations and we need to maintain the supply peg. Instead, folks can redeem their BTC and move it to the new token via a deposit. What do you think @gakonst? It feels like a practical middle ground while leaning heavily toward social upgrades |
OK I agree with this. Basically just add a killswitch to prevent new deposits from being created - no further interference with the system. Also fine with redeeming the TBTCv1, getting back your BTC and redepositing to get TBTCv2 vs burning-TBTCv1-mint-TBTCv2. |
We've opted for an even more extreme version, removing all "kill switches". Caveat emptor folks |
Details on the slim governance surface area that has been included can be found here |
Figure out how upgrades are going to work in tBTC for the first version and externalize it into some document (RFC?)
The text was updated successfully, but these errors were encountered: