Threshold Network DAO Proposal — v2

Here’s another great example of why a quorum is not an effective safeguard ~on its own~:

UNI quorum is widely considered a high quorum. They’ve even attempted to lower it (although that failed), link. A delegated council is very important to avoid common pitfalls.


To me this sounds like a great proposal with good changes and additions to the v1 proposal.

Very cool to see this being implemented:


While I can sympathize with the reasoning behind many of these proposals, (e.g fixing security vulnerabilities quick) I find that it goes completely against the ethos of this space and especially the initial promise of tBTC as a trustless Bitcoin wrapper on Ethereum. That’s what drew me to Keep Network and I’d hate to see you sell out on that dream just to move fast and break things.

In essence, what is suggested here is 2 admin keys - straight into the heart of the protocol. The core of the trust relies on less than 12 people to not conspire against the system. In reality we’re talking about 3 developers, because the multisig council is likely easy to persuade.

Get ready for a real pounding from Chris Blec.

It kills the idea of a trustless BTC on ETH.

Governmental powers needs to be limited in any way they can.

At the very least TBTC v2 should be a separated concern and go through extensive testing and auditing before release and then need very few changes, if any.

tBTC v1 did not need admin keys, why do we need it now?

The ability to upgrade TBTC v2 can be useful, but it doesn’t need to happen in 2 days. Make the timelock 6-months and maybe the BTC maxis will think of giving you a pass.

The proposal needs to include something like separation of concerns, we can’t have people vote on changes to tbtc v2 any day of the week. With the current proposal I see very little advantage over using any of the other bitcoin wrappers on ethereum.

This is all so disappointing. Why am I the only one complaining?

Once you go down this road the project loses all its appeal.

1 Like

Maybe someone with a more solid technical understanding should address this concern: @pdyraga .

I think you’re right to have those concerns and I’m glad you voiced them. Although, in the event of a bug being discovered, if the bug isn’t addressed in a clean and discrete manner, it could result in the same outcome. As much as we might want to, we can’t count on code having no zero-days.

If certain vital contracts were made non-upgradable, do you think that would address your concern? If so, I think we should have a community call / forum discussion to discuss the contracts that should be immutable.


Yes, if everything related to TBTC v2 was made immutable, or at the very least extremely hard to change (like bitcoin itself), then I’d be more inclined to agree with the proposal. I care first and foremost about the trustlessness of TBTC v2 and so should you, because that’s the only selling point we have over the competitors.

If the T token is not trustless is less of a concern. The selling point for TBTC v2 should be a trustless BTC, if we can’t promise that we offer nothing of value over renBTC or WBTC.

As for bugs, I rather have the code prove itself over time than to forever leave the trust in a handful of humans. If you must, at least limit this trust period to the first 3-6 months and then permanently remove the ability. But even that would not be a great look. I think the need for fixing zero-day bugs is overrated as long as proper proactive action is taken. TBTC v1 is proof that it’s possible to accomplish. Let’s stick to the original principles.


I understand your concerns here so thanks for surfacing this. There is a reason this process has included multiple proposals and multiple rounds of community discussion. Nothing is set in stone until a proposal passes a snapshot in both communities. Even then there is flexibility built into the process as the Token Holder DAO can enact changes to the governance system if a need arises.

With that said, the intention here (as you know) is not to stifle decentralization of tBTC but rather to provide a meaningful fall back security mechanism for the protection of the entire network and community. The tradeoffs there have always been interesting. For clarity there are multiple checks here -

  1. Two dev teams on the Emergency Security Developer Multisig. At least one member from each must vote yes for proposal to go through
  2. The elected council executes a proposal

Furthermore, the intention is that this is only used in an emergency situation similar to Pause Guardian on Compound but with more checks on the process. We can both agree that “emergency only” is a social gate without hard enforcement mechanisms. Thus, I do understand your point that it would be possible to coordinate interests here. However, I don’t think realistically it would be that easy to pull off.

@Agoristen what do you think is a better way to handle this?

One solution is to keep the fallback security mechanism as is but add a modification separating tBTC out from the responsibility list. This way there is protection for the network if needed, but - there are no longer concerns about introducing any roundabout more centralized rights over tBTC.

1 Like

FWIW what I’m looking for here is a safe harness to launch v2 into, as well as a network that can grow in other directions. I am not interested in dev teams being able to take custody of BTC for any period of time.

There’s a spectrum between idea and complete product. In v1, we tried to hit that at launch, and have had some expensive protocol design learnings.

In v2, I’d like to hit that after launch — which I think will mean fallbacks for security until they can be removed safely.

That said, I’m still chewing on this. I’m all for elected members vetoing (negative power), I’m not a big fan of elected groups executing (positive power)


Thinking about it, maybe the confusing bit in this discussion is saying what an emergency role can or can’t do.

I’ve been assuming we add the emergency role through governance for new contracts, then remove them when there’s confidence, on a per contract basis. I don’t think we should have an emergency multisig with the full powers of the DAO, that’s kinda crazy.

Does that make sense to you @Agoristen? Eg how the dev team had an expiring pause button for tBTC v1?


The " Emergency Security Developer Multisig" attributions need to be defined better on what it can do and what it cannot do. I am in favor of giving room to the dev team to be able to react if there is a vulnerability. But what does “react” mean here, I think that needs to be clarified / defined better.
Maybe this needs to be discussed separately in a different proposal, as there is a lot in this particular proposal.


Can you give some examples of where an emergency multisig might be required, how funds could be lost if the multisig didnt exist and what that multisig could and couldn’t do?


What I find puzzling, from a legal perspective, is how any developers willingly are signing up for a 3-of-4 multisig that in principle can take control of BTC in custody with the approval of the multisig council.

Let’s be realistic, the multisig council will not be validating all code changes or have the expertise to do so, they will in fact be trusting the developers to make the right decision. The lines between decentralization and centralization are starting to blur here when there’s a handful of people making the decision.

Sobering reminder for the devs considering to participate in this multi-sig: gold standard for breaking money transmitting laws is ~20 years in jail. You’re putting your life on the line, even with honest intentions.

With that said, from a user perspective this is also terrible because you no longer trust code, but people. Yes, the developers are most likely honest, I have no reason to doubt your integrity. But once we move outside the community we have to attract people who do not necessarily trust the project team. The selling point is trustlessness, that has to be the focal point.

Wasn’t part of the appeal of tbtc v1 to attract bitcoin maxis who previously ignored DeFi due to all the trusted ramifications?

3 people is realistically all it takes to hijack the contract according to the proposal. The multisig council will listen to the developers. This isn’t even check and balances. It’s decentralization theater.

Yes, decentralization theater has been playing out for a while in DeFi, mostly without incident. But prosecutions will be ramping up in the coming years. You’re not going to want to be blurring lines here. That’s a nice little reminder that you’re more useful here then rotting in a cell. I’ve been here since e-currencies in the early 2000s, I have seen enough injustice happen over the years to know money is no laughing matter – Even if legally you’re able to get away with this now, the regulations will tighten in going forward. Multisig control has no future, decentralization does.

So what is the alternative?

Don’t assign yourself these powers over TBTC v2. Ideally, the contract would be immutable, forcing deployment of new contracts for upgrades. That’s the best approach from a trustlessness perspective.

Some projects do this successfully, like Liquity. However, I recognize the issues with this approach given that TBTC v1 stagnated. A compromise would be to let the contract be upgradable, but it doesn’t have to happen often. Every 6 months should be plenty. This is after all about having BTC on ethereum. We won’t need all the bells and whistles of the hottest DeFi degen farm. Just a simple, secure and trustless protocol that works.

Ok, so maybe 6 month is too much right after launch. Make it 3 months, heck even 1 month. But be clear about the direction. The protocol should solidify over time into a stable and trusted protocol that rarely needs to change.

These changes could be voted on in the DAO, but I would prefer there to be 90-95% consensus on any upgrade. Not holders, but 90-95% of the votes. Combined with Quorum. This will make it easy to prevent any bad changes and hard for malicious actors to change the system to their benefit.

Elected members vetoing (denying changes) should be fine as a second security check.

If you want to keep the 3-of-4 multisig + multisig council for other parts of the protocol that’s fine, I wouldn’t want to be a part of that myself (for the reasons stated above), but as long as you leave TBTC v2 alone, I don’t have too many complaints.

Similarly, the suggestion of @mhluongo to add a pause type of functionality to the multisig, but not full upgrade rights would also be fine in my view - assuming people are able to get their BTC out without permission. It all boils down to permissions and trust and we can’t have neither in a trustless BTC wrapper. Legally, you’re probably also much better of as a participant in a multisig that holds no real power. Something to think about.

Update once a month will require more testing & auditing, but will pave the way to the purest BTC on ethereum there is. Instant upgrades, as suggested, means we’re just the new clown on the block. Let’s be better than that.


This is I think more or less I think what Matt and Agoristen are proposing below, and was also thinking if something in between could be a good trade-off.

The ability to prepare and implement a fix for a security issue without making it public to reduce the chance for it being exploited.

The selected dev group & multi-sig would have the ability to pause the system. The dev team will prepare and propose a fix during the pause.

The fix is published, can be reviewed and is voted upon by the Staker DAO. Once implemented the pause is released. It’s ofc not ideal, but maybe a good trade-off.


If we set up an emergency mechanism that shuts down the system and allows only withdrawals, wouldn’t it be better to give control over this mechanism to the dev team directly? That will enable quicker execution and the trust model doesn’t change much (if you are a multisig signer and suddenly the team reaches out to you in an emergency and tells you to execute a function because funds are at risk, will you stop and take some time to for due diligence or will you just do exactly what the dev tells you to do as quick as possible?)


Yes! Though the “dev team” role is hazy and will keep getting hazier, this is where a developer “quickdraw” multisig shines.

Sure. Caveat that this list is me trying to be helpful, not making recommendations… I expect it’s clear that I’m with @Agoristen in the general sentiment that a small multisig shouldn’t be privileged to take custody, for example.

A few different scenarios to consider for mitigation in tBTC v2

  1. A BTC deposit & redemption exploit is found, ala tBTC v1 rc.0. That particular issue put stakers at risk of slashing without impacting depositors or the peg.
  2. A minting contract exploit is found, allowing more tBTC to be minted than BTC than was deposited.
  3. An arbitrary wallet selection exploit is found, allowing a malicious majority to seize control of a wallet, moving all funds and leaving the peg undercollateralized.

A dev multisig that can quickly pause deposits was a great solve for 1. in rc.0, but will be less effective in v2 since deposits can’t be paused, only minting. For 2., depending on the bug, pausing plus slow proper upgrades it likely enough. For 3, pausing wallet selection to allow proper governance time to upgrade the contract is enough.

One class of scenario where a pause might not be enough is where there are funds locked in a contract that’s being actively exploited, and the pause doesn’t mitigate the exploit. I can imagine this happening with something like coverage pools or staking contracts.


I like this, because pauses can be time-limited or similar and only 1-shot… then the DAO upgrade can “reset the counter” if the pauser was found to have made a good call, or remove the pauser’s role in the new contract if it was found to be ill-advised or malicious.

NB, all of this can be “per contract”, where contracts start with a privileged emergency role that’s removed over time.


Am I correct in assuming that contracts relating to these functions would have no access to / interactions with tbtc contracts?

It would be helpful some of the more technical members of this community could help us put together an overview of the contracts and permissions. Would anyone be willing to volunteer for this? I think it would elevate the communities ability to discuss this.


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.


Split out the ESDM discussion into a new thread here: Network-level and application-level emergency security mechanims

Snapshots for this proposal are now live:

KEEP Snapshot

NU Snapshot

Edited to update: The snapshot in both communities passed unanimously.