Skip to content
This repository has been archived by the owner on Mar 28, 2023. It is now read-only.

V1 upgradeability path for tBTC #139

Closed
pdyraga opened this issue May 24, 2019 · 6 comments
Closed

V1 upgradeability path for tBTC #139

pdyraga opened this issue May 24, 2019 · 6 comments
Assignees
Labels
⚙️ system-design Up-front system design tbtc

Comments

@pdyraga
Copy link
Member

pdyraga commented May 24, 2019

Figure out how upgrades are going to work in tBTC for the first version and externalize it into some document (RFC?)

@mhluongo
Copy link
Member

Related to #22 and #119.

Basic idea for upgrades is that Deposits don't change based on dev team actions- once a depositor enters into a deposit it's immutable. The ERC-20 contract is also immutable, and any bugs there will require a social upgrade to a new ERC-20 ("TBTCv2" or similar).

Try to sync this work with RFC-9 from keep-core

@gakonst
Copy link
Contributor

gakonst commented Aug 12, 2019

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.

@mhluongo
Copy link
Member

I'm in the same boat re: social migrations, just trying to draw the fully nuanced line here. I think we get close with

  • No Deposits should change via any sort of upgrade scheme. A new DepositFactory can be enabled via governance. Users can decide which factory they use for new deposits.
  • Old DepositFactorys should have a big red button in case of an exploit, shutting them down.

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

@gakonst
Copy link
Contributor

gakonst commented Aug 13, 2019

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.

@mhluongo mhluongo added tbtc ⚙️ system-design Up-front system design labels Sep 16, 2019
@mhluongo
Copy link
Member

mhluongo commented Apr 8, 2020

We've opted for an even more extreme version, removing all "kill switches". Caveat emptor folks

@mhluongo
Copy link
Member

mhluongo commented Apr 8, 2020

Details on the slim governance surface area that has been included can be found here

@mhluongo mhluongo closed this as completed Apr 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
⚙️ system-design Up-front system design tbtc
Projects
None yet
Development

No branches or pull requests

3 participants