TIP-002: Threshold Network DAO Proposal — v2

Proposals
1

After discussion and feedback from both client teams and the community, @Will and I have put together a revised Threshold DAO proposal.

What’s changed?

The fundamentals of the v2 proposal are very similar to the v1 proposal. The primary differences and improvements as described throughout this document involve:

  • Delegations
  • Proposal thresholds
  • Quorum
  • Vote delay
  • Emergency security
  • Veto power

For easier readability, deletions have been struck through. New sections are marked with :heavy_plus_sign:, and additional language in existing sections is bolded.

Introduction

The upgraded Threshold network will offer the best of what the Keep and NuCypher networks offer today. As our communities continue to merge, we’ll need a single community DAO to govern the new network.

There are two major constituencies in the Threshold network: active stakers and token holders. Both NuCypher and Keep governance today privilege active stakers.

We’d like to propose a bicameral DAO with an elected multisig council to govern the new network, addressing both groups of stakeholders and better aligning all participants. The DAO, based on Compound’s GovernorBravo, will give the bulk of governance power to active stakers, with the exceptions of

Token Holders:

  • treasury management
  • token issuance
  • governance system changes

Elected Multisig Council:

  • staking rewards management
  • :heavy_plus_sign: proposal vetos

This design follows the principle that no party should be trusted to “vote themselves a salary” and implements meaningful checks on power within each portion of the network’s governance. Stakers are the best positioned party in the network to approve contract upgrades and other changes relevant to applications on the network, and are required to be highly engaged to mitigate slashing and other concerns.

The goal of this system is to enable the combined Threshold community to propose, vote on, and implement changes that support and improve the upgraded network.

Implementation

The bulk of this DAO will be implemented using two instances of GovernorBravo and a separate multisig council.

For those unfamiliar, GovernorBravo is the latest iteration of Compound’s DAO which is also used to power a number of other projects in the space. Documentation for the contracts can be found here.

Token Holder DAO

The first instance of GovernorBravo will be the token holder section of the DAO. T holders will be able to add proposals on-chain, delegate votes, and execute proposals.

Initially, vote power in the Token Holder DAO is accrued by liquid T holders, T stakers and those who deposit T to coverage pools. If possible, in the future vote power accrual will expand to other areas where T is put to work including LPs on AMMs.

The Token Holder DAO will manage the treasury and be the owner of the T token contract. The Token Holder DAO will have the power to deploy the treasury, and mint additional T tokens. Its minting powers can be restricted, enforcing a hard limit on any inflation.

:heavy_plus_sign: Staker DAO

The second instance of GovernorBravo will be the Staker DAO. Stakers will be able to add proposals on-chain, delegate votes, and execute proposals.

The Staker DAO will have a major modification over GovernorBravo as deployed today being that vote power will be determined by stake weight on the network without the introduction of a separate token.

:heavy_plus_sign: Delegations

The v2 DAO proposal introduces delegations for the Token Holder DAO. This means that T holders will be able to delegate their vote power regardless of if the T is wrapped from KEEP or NU. The StakerDAO will also support delegations of stake weight.

:heavy_plus_sign: Proposal Thresholds

Proposal threshold is the amount of T vote power or stake weight a community member must own to be eligible to submit proposals onchain. The amount can be reached through delegations. Proposal thresholds are critical for the Threshold DAO because they help safeguard the network against dangerous proposals and act as an enforcement layer for what proposals make it onchain. Without a proper proposal threshold anyone can go rogue and bypass the temperature check period in the community by simply submitting a proposal onchain.

The initial proposal threshold on both the TokenHolder and StakerDAO will be set at .25% of vote weight and stake weight accordingly.

When applicable we plan to use delegations to ensure elected council members and other core community members hold enough vote weight to submit proposals on-chain in either instance. After a proposal passes a temperature check these community members will meet requirements to move proposals onchain. In this sense, council members and core community members will act as quasi gatekeepers in the Threshold DAO ensuring that the quality of proposals that make it onchain remain high. This allows our governance system to remain committed to reducing engagement friction while still safeguarding against potentially dangerous proposals.

The Token Holder DAO holds the power to adjust proposal threshold numbers in both instances of GovernorBravo if the need arises.

:heavy_plus_sign: Quorums

Quorum is the amount of vote required in favor of a proposal for it to be successful. After quorum is hit a proposal passes if the majority of votes fall in favor of the proposal.

During community discussion around the v1 proposal it was decided to implement lower quorum requirements in both sections of the Threshold DAO compared to other relevant DAOs to avoid self imposed blockers in our community for strong proposals passing.

The initial quorum on both the TokenHolder and StakerDAO will be set at 1.5% of vote weight and stake weight accordingly.

The TokenHolder DAO holds the power to adjust quorum overtime as the network and its governance grows and the need arises. Furthermore, the community can explore ways to set different quorum requirements for different types of proposals in the future similar to the AAVE Governance Module.

:heavy_plus_sign: Vote Delay

A vote delay is the amount of time between a proposal’s submission on-chain and the vote period officially beginning. During this time community members will be made aware that a proposal has passed the temperature check period and the onchain vote is about to begin. The vote delay will be initially set at 2 days for both the Token Holder DAO and the Staker DAO. 2 days is current industry standard.

Multisig Council

Why?

We are proposing a nine seat multisig council that retains the power to manage per application staking rewards on the new network. This is a critical governance role on the upgraded network, and delegating this responsibility to an elected council services the upgraded network and combined community in many ways. First, it sets up our governance system in a manner that avoids continuous community friction between parties with competing application level interests on the network. Second, individual accountability for critical network wide decisions is better upheld when executed on a council than an entire token holder constituency. Simply stated - our community needs to ensure these decisions are made in a responsible and transparent manner. Under this proposal the community council will meet quarterly to make per application rewards adjustments on the upgraded network.

Council Elections

The inaugural upgraded network council should hold fair representation from both existing communities. Thus, we propose that the Keep community elects 4 members and the NuCypher community elects 4 members. The final seat will be determined by an appointment or vote by the Keep and NuCypher teams.

Terms for the multisig council will last for one year with elected members expected to be contributing members of the upgraded network community for the duration of their term. Second term elections will take place before the inaugural term ends. If a council member decides to step down, a by-election for the seat may be considered by the community. There is no term limit for council members.

The multisig council is controlled by the token holder DAO and council members can be removed early subject to a DAO vote if necessary. For example, if a council member fails to fulfill their duties, acts in a manner that harms the network or is inconsistent with the wishes of the community, they can be removed via a DAO proposal prior to their term ending.

:heavy_plus_sign: Council Vetoes

The elected council will hold the power to veto any proposal that passes from either the Token Holder DAO or the Staker DAO. This is intended to be an extra security mechanism in the event that a dangerous proposal passes in either DAO subsection. The exact process will be determined later as the DAO approaches a launch.

:heavy_plus_sign: Emergency Security Developer Multisig

This ESDM has been removed from the Threshold DAO Proposal v2 as a result of community discussion. For for an explanation on why this happened and to see what the next steps are please review this forum post - Threshold DAO v2 Proposal Edit - Removing the Emergency Security Developer Multisig - #4

Proposal Community Process

… or, “How a proposal becomes a law” :grin:

Below is a potential process for TIPs, or “Threshold Improvement Protocols”. As community discussion continues to form around vote processes and governance cadence, this process will always be subject to change through a Token Holder DAO proposal.

Step One — Temperature Check

A Threshold community member posts a potential proposal on the Threshold governance forums. Community members who post the initial proposal are encouraged to get active in Meta governance discussions within the community on forums and in Discord to earn support for the proposal. There is no minimum token threshold required to create a new proposal on the forums. Temperature checks require offchain snapshots to pass. If a proposal receives majority support during the temperature check snapshot it is eligible to move onto the second step. Community mods reserve the right to moderate proposals during a temperature check by simply deleting the proposal from the forums.

Step Two — Proposal Creation

A community member holding enough vote weight or stake weight submits the proposal on-chain. The proposal enters a two day vote delay period before voting officially begins.

Step Three — Vote Period

Proposal voting remains open for 10 days. If the proposal passes according to requirements outlined above it moves onto step four. If the proposal fails it is canceled. Creators and supporters of the proposal may bring a modified proposal forward again but it must be sufficiently different and pass requirements outlined in step one.

Step Four — Execution

Once a proposal passes, it will be executed. Proposals are executed by the particular GovernorBravo instance hosting them.

Conclusion

Keep and NuCypher are community driven projects and this will continue with the upgraded network. This proposal is a second iteration of the governance system for the upgraded network. We encourage community members to review, ask questions, discuss and add ideas in the thread below. If there is no significant push-back, this proposal will be taken to a snapshot in both communities, moving us one step closer to a complete protocol merge.

17 Likes
3

The council veto power as a safeguard against dangerous proposals is an important addition: it can prevent some of the bribing/vote buying attack’s mentioned in Vitalik’s recent post, Moving beyond coin voting governance.

8 Likes
4

Bravo, Gov’nor! (see The Regular Show :grinning:)

In addition to being a culmination of the prior proposal and much fruitful discussion, this is very clearly articulated and compelling.

I’m excited to see the bicameral approach in action - balancing DAOs for the main stakeholders (token hodlers - including delegates - and stakers) - plus the council, which has aspects of an executive branch (veto) and higher court (the highest court is the entire community, in a sense, as our strength will be in overall engagement among all stakeholders).

I will reflect on it in more depth tonight, but the only question that came to mind so far was Vitalik’s argument against simple stake-weight voting, so thanks for addressing that @maclane. I agree the council veto is a safeguard for this - and more.

4 Likes
5

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.

6 Likes
6

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

Very cool to see this being implemented:

2 Likes
7

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.

2 Likes
8

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.

3 Likes
9

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.

5 Likes
10

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.

2 Likes
11

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)

4 Likes
12

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?

3 Likes
13

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.

3 Likes
14

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?

5 Likes
15

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.

10 Likes
16

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.

4 Likes
18

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?)

4 Likes
19

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.

5 Likes
20

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.

4 Likes
21

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.

3 Likes