TIP-001 Threshold Network DAO Proposal v1

Proposals
1

Introduction:

Our new 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 at the expense of the voices of other token holders.

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,

Multisig Council:

  • staking rewards management.

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. All token holders, including stakers, LPs on AMMs , CDP holders, and anyone with committed asset exposure, should maintain the “power of the purse".

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:

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, used to power Uniswap and 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. If possible, GovernorBravo will be modified to include governance power for T LPs and other wrapped variants that have alignment with the project.

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.

Staker DAO

The second instance of GovernorBravo will be the staker DAO.

The staker DAO will have two major modifications over GovernorBravo as deployed today

  1. Voting will be based on staking weight
  2. StakerDAO upgrades can be vetoed by the token holder DAO.

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.

Elections

The inaugural Threshold 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.

Community Process:

How a proposal becomes a law

Step One - Temperature Check

A T community member posts a potential proposal on the T governance forums. Community members who post the initial proposal are then 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, but the community reserves the right to moderate the forums for the purpose of reducing proposal spam if it becomes an issue.

Step Two - Proposal Creation

After a proposal has earned enough interest from the T community, it is moved to an official DAO proposal. The proposal enters a two day review period before voting officially begins. Meta governance is again encouraged via discussion on the T forums and on Discord.

Step Three - Vote Period

Once a proposal is created, it remains open to voters for 10 days. If the proposal passes the vote threshold it moves onto step four. If it does not pass this step the proposal is over and will not be executed. The creators and supporters of the proposal may bring a modified proposal forward again if the community decides it is sufficiently different from the originally submitted proposal and has garnered additional support.

Vote threshold - a community discussion.

Quorum - a community discussion.

Step Four - Execution

Once a proposal passes, it can 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 first 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 so that together we can build an even stronger proposal ahead of a mutual community vote to implement the new DAO.

13 Likes
2

This looks solid. I’m sure the community will have good suggestions and discussion, but this is an excellent start.

A few initial thoughts:

  • I would consider the NuCypher and Keep teams a stakeholder group, as well, since they are most intimately involved in the protocol and product development. Is the thinking that they are also token holders (and some are stakers, as well), thus represented - and there isn’t a need to represent their POV as team? That makes sense to me, but I do think it’s wise to consider their perspectives as carrying a lot of weight (i.e., they have done a lot to get us here and are not just order takers for a DAO).

  • “StakerDAO upgrades can be vetoed by the token holder DAO” By a simple majority? And what process do we want around this - a comment period, opportunity to modify after a veto, line-item veto capability, etc.?

  • Given that “bulk of governance power [would go ] to active stakers”, I think the Staker DAO section of this proposal should list key roles, even if its role is intended to cover everything not assigned to Token DAO or Council.

  • Is the proposal that the Token DAO would determine the total number of tokens and how many are devoted to rewards as a whole, whereas the Council would allocate from that total to specific applications and activities?

  • Regarding Elections, this is elegant and would project a positive image of unity: “The final seat will be determined by an appointment or vote by the Keep and NuCypher teams.”

  • Community Process: I agree but would add that others should be active, as well (in contrast to a few people who have dropped into Discord recently to crap on the aligned plan they didn’t contribute to). “Community members who post the initial proposal are then encouraged to get active in Meta governance discussions within the community on forums and in Discord to earn support for the proposal.”

  • I take it these mean details are to be determined by community in commenting on this and other proposals? “Vote threshold - a community discussion. Quorum - a community discussion.”

5 Likes
3

Hi John! Thanks for the feedback and thoughtful questions.

On the Keep side - in the past, the entity has refrained from employing KEEP in governance voting processes. However, team members have been encouraged to vote with their own KEEP on proposals they are passionate about. For example, Kris from our community team has voted on almost every staker snapshot up to this point. I expect team members will be actively involved in proposal discussion to express opinions but ultimately Threshold Network is a community driven project and our governance should reflect that.

This process is totally open for community discussion. What are your thoughts for how this can function smoothly? Line-item veto capability does not seem to work practically based on my experience with governance in the past. Especially with longer more detailed proposals like this one. A line-item veto process introduces unnecessary complexities and potentially drawn out blockers on meaningful network updates. Many governable parameters will have time delays which can serve as a window of opportunity for a Token DAO driven veto to begin. Majority is a clean starting point and the Token Holder DAO can always implement governance system changes down the road if something changes.

The point of this proposal was not to get super granular with an actual power list but I imagine this will be an on going discussion with the community as we progress down the path towards aligning together on a final proposal. Early examples of contract level governance parameters that the staker DAO could own can be found in the coverage pools documentation -

Furthermore, while this list will change with tBTC v2 - the list of contract level parameters owned currently by the Keep community multisig in tBTC v1 is here starting on page 34. It’s a good reference point -

The total number of tokens for Threshold Network was determined by both communities as per the successful passing of the rc0 implementation proposal. The number is 10B. Any change to inflation on Threshold Network should require support of all token holders. Correct - the Council would determine and allocate per application rewards.

Thanks! We wanted to find a way for the inaugural Council to represent both communities in a fair way and landed here.

Definitely agree. One of the design goals for this proposal is to create minimal friction for community members to get involved in Threshold Network governance. However, proposal authors are especially encourage to champion or advocate for the benefits of their proposal in the Meta community to win the support they will need heading into vote periods.

Yes - that is what it means. Those two implementation details are up for discussion and will be determined by the community. What are your thoughts? I have examples of how other prominent protocols handle this that I will share as the discussion progresses as reference points for our community thought process. Worth nothing too that really the whole of the governance design will be determined by the community because it will need to pass community votes on both existing networks before any implementation starts. This proposal is a starting point and together we will iterate towards an even stronger one.

Hope this helps and as always let me know if you have any more questions :slightly_smiling_face:

6 Likes
4

Solid proposal for the governance of the Threshold Network.
I’m definitively in favor of this three body Governance System. An elected mulitsig council should help tackle some of the ongoing hurdles seen in other DAOs, like taking ownership of problems, helping with contributions and making decisions.

In this regard I would add that the Multisig Council, besides deciding on staking rewards weighting between apps, should have a an active role in monitoring and proposing (if needed) changes to the governable parameters in the apps.

It’s clear that these decisions will be of the StakerDAO to be made, but I think that them having an explicit responsibility to focus on this, encouraging analyses and actively proposing changes will help spearhead improvements and herd the StakerDAO in the “better network” direction.

4 Likes
5

Thus, we propose that the Keep community elects 4 members and the NuCypher community elects 4 members.

One point I’d like to confirm/clarify: the 4/4/1 NU/KEEP split applies only to the inaugural election and future elections would be done by T holders as a combined community. Is that correct?

Multisig Council

We should consider giving the multisig council the power to modify upgradeable smart contracts in response to a security incident. If someone responsibly discloses a severe security vulnerability in one of the contracts, it would not be ideal to hold a full DAO proposal before the vulnerability can be fixed. But if the multisig council has emergency powers then they can patch the vulnerability and the DAO can ratify the change afterwards.

Obviously, there are non-trivial tradeoffs in giving the multisig council such powers and it impacts the trust assumptions around the network as a whole.

6 Likes
6

Agreed. Elected council members are expected to remain engaged and active in the governance system at large throughout the duration of their term and this is a good specific example of where that can be applied.

2 Likes
7

Yes that is correct. The 4/4/1 council split only applies for inaugural elections to ensure baseline equal representation on Threshold Network. After that all seats will be decided by T token holders as a combined community.

This makes sense to me. However, curious what others are thinking about it because it is true that there are non-trivial tradeoffs here.

1 Like
8

So there would be a team multi sig to deploy the new contract from the deployer address and then the multisig council would sign the transaction to upgrade the existing contracts to use the new address?

9

I like that setup with the DAO for token holders and the subset for stakers, it makes sense.

How will one decide which DAO should vote on one proposal? I expect quorum will be easier to reach upon active stakers so most people will prefer that, even though the token holder DAO can potentially veto it. Probably therefore major votes go to the token holder set, and the rest to the staker set?

It’s not entirely clear to me how and when the token holder DAO can veto a proposal coming from the staker DAO? I expect it’s after a vote is valid there, and there would presumably be therefore another holding period for such a challenge?

1 Like
10

This is an excellent start for the New Threshold Network. I also really like the name and symbol of Threshold Network. Amazing start and Kudos to everyone involved to get $T this far !!

I 100% agree with what John Packel said here " I would consider the NuCypher and Keep teams a stakeholder group, as well, since they are most intimately involved in the protocol and product development."

I like the proposal and I like the 3 body governance. I will support it.

My question is around how would the 4 + 4 + 1 multisig selection process be -

  • who would propose names/how would the voting happen - is this going to be similar to to KEEP multisig which was done sometime back ?
  • Would Multisig members be only active stakers or would it also include passive holders ?
  • Can we also propose KEEP/NU team members for multisig - I know there will be trust issues etc that people bring up but want to see if we can propose couple of names from teams.

Thanks !

3 Likes
11

The proposal as a whole is incredibly thorough and well done, Will.

In general, I’m all for it. This area, however, is one that I could see becoming problematic (based on some of the tribalism notes I’ve seen in discords).

Has there been any consideration of a more neutral and less winner-take-all method for determining the (1) in the 4-4-1?

If this isn’t a concern with the two teams, that would be helpful information since we don’t have much insight into the interoperability of the core teams.

Personally, I have no problem if either Matt or Maclane were appointed to this spot - if that is the consensus view then this is a null point. If it’s not, perhaps it’s worth considering a non-Keep non-Nu fills that role.

Thoughts?

5 Likes
12

Excellent work!

I am pleased to see this proposals attention given to Token holders - As the general publics interest in blockchain technology grows, It is important to recognize token holders, liquidity providers, and in general those that wish to “hodl” and utilize delegation. This will positively impact existing members, and attract new members to join our community.

There are ever growing options for parties to actively actively stake and actively operate nodes in today’s market place. In my opinion this group will seek out platforms that mesh with their technical background, experience, time and equipment.

Token holders on the other hand, have a much wider array of technical experience (sometimes 0), varied levels of commitment to project, and as a result a reduced willingness to risk their assets without cause.

The token holder group is at the same time very important to the health and longevity of this network.
I think this proposal does an excellent job of providing checks and balances for Stakers as well as Token holders, thus alleviating many perceived risks.

I am a long term investor in the KEEP project and not concerned with daily price fluctuations. When I am not directly involved in (node or otherwise) daily operation - I look for a healthy DAO and mechanisms that avert internal greed (e.g. the governances’ ability to limit paying salaries to yourself and limits to new proposal “spam”). This bicameral approach does a good job of establishing a recognizably healthy DAO.

Thank you for the time in putting this proposal together, it is very concise.

5 Likes
13

We could split the on-chain process into two parts:

  • development team initiates a change,
  • multisig council finalizes the change.

This way, there are always two independent parties involved in the decision and by the nature of the change, the development team is involved in this process anyway.

I suggest we use the same method when we work iteratively on contracts and we pass the power to Staker DAO once the contract gets mature and requires fewer modifications. One example are tBTC v2 contracts we want to build in public iteratively. Having the Staker DAO to work on every single update could limit the development speed.

7 Likes
14

I definitely am in favor of the three body governance model. Great job on the proposal!

MacLane covered my biggest question which was the composition of future councils. I definitely think this should be spelled out in the proposal.

I am not sure if this need could ever arise but would there be a process for changing the structure of the mutisig council if deemed necessary or is this a one and done? What if we want 11 seats instead of 9?

3 Likes
15

@Will and others. Thanks for this thoughtful and detailed proposal, and all the efforts that went into this! Overall I feel it’s very solid and I’m in support of this. Also like the discussion on the need for quick response in case of a security incident versus the decentralized nature.

Some questions

  • “After a proposal has earned enough interest from the T community, it is moved to an official DAO proposal.” Are there any specifics already? Like is this automatically gaged what is enough interest, or does this require council / team / community judgement?

  • Any plans / thoughts on incentivizing a person who made a proposal that was implemented? It requires proper research and efforts to come to proper proposals, and something to stimulate this could be worth looking into. Small reward, or maybe a single edition “TIP #…” NFT. Specifically only for implemented proposals.

3 Likes
16

Much of this was discussed at our community call but adding the info again here for those who couldn’t attend.

The general sentiment in our community is that we should go with relatively lower quorums in both DAO instances while Threshold governance is young so that we do not set the bar too high on ourselves for proposals to pass. This follows in line with our goal of creating a governance system with minimum engagement friction. Plus we can learn from other protocols with new governance systems that are having trouble hitting a higher quorum which results in community blocks. As our network and its governance participation grows the token DAO can vote to increase quorum when the need arises.

It’s clear that we need to think more about exactly what the fall back security mechanism in our governance system is for emergency situations. Security, as always, is a huge priority for us so we need to nail this. There will be more info on this in the v2 proposal based on insight from @mhluongo, @maclane, @pdyraga and others.

Gas concerns for participating in governance was discussed at the call. There are gas requirements in GovernorBravo for submitting proposals and voting. The act of delegating requires gas but after the delegation is complete there is no longer gas consumption for a user that delegates.

@julienthevenard each subsection of the DAO will have predetermined responsibilities. This responsibility list determines which section of the governance system votes on a given proposal. The v1 proposal does not specify details for how a token holder DAO veto process will look but as discussed on the thread a time delay for onchain governable parameters introduces a window of opportunity for a veto to start. There are admittedly issues with this approach as some time delays only last a few days and the vote period is 10 days. Any ideas on how we can make the veto system a smooth process?

@chdru appreciate the feedback and support. As discussed at the community call, we are taking it one step at a time and will discuss the election process as a community in more detail after a DAO proposal successfully passes. I expect the process will involve forum-based introductions or nominations for candidates and snapshots for voting. Staking will not be a prerequisite for running for council but I imagine might help a candidacy. Threshold Network is a community driven project and representation on the council should reflect that. As such, and as also discussed at the call - team members can serve on the council but we want to avoid a situation where the council is stacked with team members.

Thanks @jakelynch. This hasn’t been a major concern up to this point for the teams. However, the 4/4/1 inaugural council split is, along with the rest of the proposal, open to community discussion. I remember you suggested that the 4 elected from NuCypher community and the 4 elected from Keep community vote on the last member at our community call. Once again the concern with that approach is that the 4/4 split might result in a stale election. There are neutral third parties and individuals who contribute in both existing communities that would be great candidates for the last seat. Overall, the goal is for our communities to align together behind the Threshold Network as one group. For that to work, those elected to the council are expected to have the long term interest of Threshold in mind not the individual success of either existing network.

@MrsNuBooty the token holder DAO can make an update to the governance system if there was ever a need to change the number of seats on the council.

@Naxsun great question. Other relevant protocols hold snapshots during a temperature check to quantify if a proposal moves onto the next step. One example is Uniswap. More detail on how that process works is found here. I do like that approach but also wonder if it adds engagement friction to our governance process. What do you think? There are not plans to directly incentivize participation in our governance system at the moment. This is something that has been discussed in the community in the past and worth exploring more. Have you seen any other protocols incentivize governance participation in a well done manner?

Thanks for all of the great questions and feedback on the v1 proposal so far. We are working on a v2 proposal that takes into account all of the insight from our community. Really excited for it :pray:

4 Likes
17

One thing that I really would like to stress is that we start with a relatively low quorum requirement. There can be a significant difference between expected and engaged participants, and if we set it too high without properly attaining a baseline of participation, passing proposals could become difficult. Although delegation is intended to address the issue of voter turnout, it’s not a guaranteed fix.

Another tool that could be used to address this is the idea of governance amplifiers - delegating KEEP organizational token weight to engaged community members. Discussed in the governance amplifiers thread

Although these may help, there really is no substitute for finding the baseline engagement with $T and working to set reasonable quorum parameters once we have that. Setting the initial quorum to ~1% for the first proposals would be my preference. Although that seems absurdly low, going higher than that poses a risk to the process (IMO). If there are regular high turnouts, the parameter can be reconsidered.

I was able to join a recent Gitcoin DAO call, and found out that they too forked the GovernorBravo contracts, and also have delegation. They mentioned that they may have issues with the ability to pass proposals given the current quorum parameters. Their quorum parameters are set to 1% threshold to propose, and 2.5% quorum. - Source

3 Likes
18

@Will with engagement friction, do you mean like loosing voters because it’s becoming too much? In general I think this is a risk, it depends a bit on the amount of proposals coming through.

I was thinking for the non-urgent proposals, that it may make sense to group them? For example there’s a voting timeframe every 2-weeks, or every month, where the proposals that passed the temperature check are up for voting.

This does loose some of the pace and ability to quickly adjust, but it does give some routine and could allow us to better promote.

On the 2nd point. To me it makes sense to reward people who come up with proper proposals that are implemented. It doesn’t need to be a lot, but some sort of incentive could stimulate active participation and improved efforts into proposals, that would help all. I’ll look around if there are examples where this is done.

Especially in the early phases, could be like a promotion. The DAO is also something that needs to mature and grow, and this could help to support that.

3 Likes
19

Agree on this. Difficult to gage this up front. Do you think it makes sense to have a relation between vote threshold and participation rate. Like low quorom / low partication rate requires higher % yes than proposals with higher participation rate?

20

By minimum engagement friction I mean setting up Threshold Network governance in a way that makes it easy for our existing community to navigate and for new community members to participate in the future. Quorum blocks make it much more difficult for our community to navigate the governance system. I agree there is a risk with lower quorum. However, community moderation and social gates via temperature check periods reduce the chance a bad proposal gets through.

I believe @jakelynch also mentioned the idea of a prioritization system for proposals during the community call. Do you two want to collab more on exactly what this look like? Could be helpful if done right.

For the most part I agree we should experiment with incentives on governance participation. However, I don’t want us to incentivize governance for the sake of governance. We definitely want to keep the quality of our discussions and proposals high. So, it needs to be for meaningful participation like your idea here for a successful proposal. Overall very interesting and super excited to see what you find here for examples.

3 Likes