TIP-069: RFC 12 Implementation

General
1

This post is originally authored by Lukasz and reviewed by Engin.

As you may know, the Keep team is implementing RFC 12 which aims to address the most urgent problem of the wallet coordinator being the SPOF to the tBTC system. The implementation is close to be completed and testnet UATs are supposed to start in the next days. Once UATs are completed, the Keep team will be technically ready to release a new version of the keep-core wallet client. This release will have a significant impact. Once beta operators update their nodes to the new keep-core version, the wallet coordinator currently controlled by Keep will be disabled. From this moment, wallet coordination will be decentralized and managed by the wallets themselves (as described in RFC 12). That means Keep will no longer be able to block the existing problematic redemptions nor push back future redemptions originating from suspicious addresses. That said, before RFC 12 implementation is released, two topics must be discussed and agreed within the DAO:

  1. We need a clear decision regarding what should happen with the stalled redemptions. From technical standpoint, possible options are:

  • 1A: The DAO brings back the 20 years redemption timeout to a reasonable level so anyone can timeout the stalled redemptions before Keep team releases RFC 12. In this case, TBTC Bank balance (do not confuse with TBTC ERC20 tokens) would go back to the redeemers.

  • 1B: The DAO leaves stalled redemptions as is and let the wallets handle them once the Keep team releases RFC 12. In this case, redeemed BTC would go back to the redeemers

  • 1C: Another option special-casing the stalled redemptions. In this case, the Keep team would probably need to propose an upgrade of the Bridge contract and the DAO would have to attest it

  1. We need a clear decision regarding future redemptions coming from suspicious sources. From technical perspective, possible options are:

  • 2A: The Keep team just releases RFC 12 implementation and let the system handle all redemptions without any control. In this case, the system would be 100% censorship-resistant but wouldn’t have any protection against illicit redeemers. Moreover, there would be no possibility to block redemptions in case of a Bridge hack

  • 2B: The Keep team releases RFC 12 and after that, implements the contract-side veto mechanism presented in a future optimistic redemptions TIP (the DAO must attest the contract upgrade). The benefit of this option is that RFC 12 implementation would not depend on the veto mechanism. It would go live sooner thus eliminate the wallet coordinator SPOF much earlier. The downside is that there would be a period where redemptions are not controlled but ultimately, the veto mechanism will fill this gap.

  • 2C: The Keep team postpones the RFC 12 release until the contract-side veto mechanism is implemented and releases them together (the DAO must attest the contract upgrade). This is a safer option than 2B but the wallet coordinator SPOF will be there for a longer time.

  • 2D: Another option not involving veto mechanism

Please take those topics under consideration as soon as possible.

1 Like
2

To be explicit, this means the blocked redeemer(s) would be able to claim TBTC ERC20 tokens against the TBTC Bank balance though, correct?

1C: Another option special-casing the stalled redemptions. In this case, the Keep team would probably need to propose an upgrade of the Bridge contract and the DAO would have to attest it

Is it necessary for past redemptions to be processed in this case? Rather than special-casing the blocked redemptions, can the Bridge instead just process future redemptions, which would de facto exclude the past, blocked ones?

This is a safer option than 2B but the wallet coordinator SPOF will be there for a longer time.

Some clarification around what a “longer time” means in practice is needed for people to make an informed decision.

2 Likes
3

  1. Correct. Redeemers will just get back those funds in form of a Bank balance and will be able to mint ERC20 TBTC tokens using it.

  2. From Bridge’s perspective, those hung redemptions are not blocked. They are valid ones still waiting to be processed. They are not handled just because the current wallet coordination mechanism managed by a single maintainer does not propose them for processing. As explained in the post introduction, RFC 12 will replace the current maintainer-based wallet coordination so once released, nothing will prevent those hung redemptions from being handled. This is why they need to be special-cased if the DAO decides to freeze them.

  3. It’s hard to say as it depends on:

  • Final scope of the optimistic redemptions TIP

  • Implementation time of the TIP

    The former is not yet established so hard to estimate the latter.

1 Like
4

I would love to see a temp check on 1B + 2A course of action.

5

“Today, that address is controlled by a US-owned company, disallowed from approving the FTX-associated redemption.”

I think giving the hackers a way to mint v2 tokens from the bank balance after time out is something that should be discussed with the disallowing entities.

I would be more inclined to have the timeout be FUBAR than antagonize an entity that has the ability to disallow a client team from taking an action.

Doesn’t really feel like an “ask forgiveness rather than permission” type situation.

6

Temp check snapshot on 1C & 2C passed: Snapshot

A proposal with next steps has been drafted and will be shared soon.

7

We can add to this proposal the code name TIP-069.
For further information, all coded proposals are indexed in our proposals database.