Migrating BTC from tBTC v1 to tBTC v2

[pdyraga]

TBTC v1 <> TBTC v2 VendingMachine deployed at 0x6590DFF6abEd7C077839E8227A4f12Ec90E6D85F holds currently more than 400 TBTC v1 and minted equal amount of TBTC v2.

All of BTC backing TBTC v1 locked in the Vending Machine is deposited in tBTC v1 bridge.

We need to design the mechanism for moving the BTC from tBTC v1 bridge to tBTC v2 bridge without requiring holders to unwrap their v2 tokens into v1 and redeem BTC.

Tools we have available are:

• VendingMachine contract is Ownable and TBTC v2 contract is Ownable. Ownership of the token can be transferred to TBTCVault so that the vault can mint and redeem TBTC.
• BTC can be deposited into the Bridge and transferred under TBTCVault address to bring back the balance.

Who will redeem from v1 Bridge? Do we need a trusted party? How to make the transition safe for TBTC holders?

We need to document the mechanism and confirm it is possible to execute with smart contracts implemented. Please also take into account the fact the ownership of TBTC v2 token needs to be transferred to TBTCVault at some point.

[beaurancourt]

In either case, we're going to need a truckload of eth to pay for all of the gas for the redemption transactions, but here are the two fundamental options that we have:

Option 1: Bitcoin Loan

First, we create an active wallet. (Multiple would be good, because the operators will eventually be the custodian of ~$17m+ worth of BTC, so spreading that risk over multiple wallets is better). Say that the donation address is 0xDONATE for that wallet.

Then, we get a 400 (or whatever the final amount we of locked v1->v2 tokens we end up with) BTC loan. Say the repayment address in bitcoin land is 0xLOAN. The loan should be sent directly to 0xDONATE (or someone we trust to forward the BTC to 0xDONATE).

Then we make sure the tokens land in the wallet and do the accounting eth side. At this point, all of the v2 tokens are doubly backed. You could redeem into btc by unwrapping into v1 and then redeeming, or you could do the v2 redemption flow since the wallet actually has btc now.

Next, we start redeeming all of the underlying v1 tokens and set the redemption address to 0xLOAN. If all goes well, the end result is that all of the v1 tokens get redeemed, the loan is paid off (from the redemptions), and the v2 wallet has 400 BTC backing it directly (from the loan). At no point was there ever less BTC backing the v2 than there v2 tokens in the wild.

Downside: Loans are hard / expensive

Option 2: Float

First, we create an active wallet. (Multiple would be good, because the operators will eventually be the custodian of ~$17m+ worth of BTC, so spreading that risk over multiple wallets is better). Say that the donation address is 0xDONATE for that wallet.

Then, we let folks know that redemptions won't be possible for a little while. We start redeeming all of the underlying v1 tokens and set the redemption address to 0xDONATE. After we finish, we do the accounting eth-side. If all goes well, the end result is that the v1 tokens are redeemed and the v2 wallet has 400 BTC backing it directly (from the redemptions). During each redemption -> donate maneuver there will be less BTC backing the protocol than v2 tokens in the wild.

Downside: spooky temporary de-pegging

[beaurancourt]

Thinking about this a little bit more: if we want the underlying BTC to land in multiple wallets anyway, and if the BTC is going to come from a ton of sources (all of the individual v1 redemptions) there's not a pressing need to do this all in one shot. We could build a flow around it and let the redemptions trickle in over weeks/months during low-gas periods in ethereum.

Even in the Float option, we can be in a state where the value of a v2 token is partially backed by v1 tokens (which are backed by btc) and partially backed by btc from the wallet directly. If all of the wallets run out of funds and someone still wants to redeem, they can unwrap from v2 -> v1 and then go through the v1 flow (or we can do that for them).

As a sort of third option, we could make it so that the first 400 BTC redeemed from v2 gets lazy-loaded from v1 using this mechanism.

Example: Someone wants to redeem 17 tBTCv2. We find appropriate v1 deposits to redeem until we have at least 17 BTC in the v2 wallet and then we ship them off to the redeemer. This has the benefit of never making it so that one wallet has an outsized amount of risk with regards to held BTC.

[benlongstaff]

@beaushinkle wouldn't it be simplest to just wait until v2 minting with BTC is live and then

mint tBTC v2 with BTC --> unwrap tBTC v2 tokens to tBTC v1 tokens via vending machine --> redeem tBTC v1 to BTC --> mint tBTC v2 with BTC

and repeat in whatever batch size is comfortable until the vending machine is empty?

That way no loan is required and there is no de-pegging.

[beaurancourt]

Let me see if I'm understanding correctly:

Step 1) Acquire some amount of BTC (either through a loan, or someone just has it, or whatever). Let's say it's 5 to make it concrete. Step 2) Mint 5 BTC into 5 tBTCv2 via the regular v2 minting flow. Step 3) Redeem 5 BTC tBTC. Rather than using the wallet's BTC (that was just deposited), unwrap v2 tokens to v1 tokens and redeem tBTC v1

We could make the governable param for fees extraordinarily low during this period and try to churn through that BTC, but I think this is another good viable option, and is really similar to the slow burn I talked about here: https://github.com/keep-network/tbtc-v2/issues/140#issuecomment-1054707759 since we could do the churn as quickly or slowly as we want (over multiple weeks/months to spread the funds out)