Sort of. I actually think the problem here is that we’re accidentally discussing tBTC v2 design when we should be discussing DAO design. v2 contracts can be made more or less resilient than the DAO, depending on what they need.
Let’s skip digging deeper into v2 and zoom out. Is the above a DAO design that can act as the governing system of tBTC v2? Is it flexible enough for growth and resilient enough from capture?
In particular, it’s worth a call out that this idea…
… is not supported by GovernorBravo unless we do it for all votes — a total non-starter for the token holder DAO, IMO. If we do decide there are actions that should have a higher threshold for consensus, we need to make that decision upfront.
In general, I agree with @mhluongo re: the need to incrementally improve v2 after launch: the likelihood of hitting the target perfectly on launch is nil. But @Agoristen’s concern about potentially compromising the entire point/value of tBTC is well-taken.
If there are ways to reduce the actual and perceived risk of the emergency security multi-sig without practically invalidating our ability to fix a vulnerability before it’s exploited (e.g. if the multi-sig can only temporarily pause the contract while a formal DAO approval is required to deploy a fix/change) that makes sense to me.
For the purposes of this proposal and proceeding to a snapshot, I’d suggest we remove tBTC (and other apps) from consideration and consider limiting the described emergency process to the DAO and Threshold-level contracts (i.e. NU/KEEP<> T vending machine, treasury, main T staking contract).
Applications (tBTC, PRE, etc.) can be left to make their own choices based on their specific requirements, which may vary.