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.
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?
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?
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 -
Thanks !
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?
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.
We could split the on-chain process into two parts:
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.
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?
@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.
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 
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
@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.
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?
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.
I like @Naxsun’s ideas of something to at least commemorate those who make successful proposals (a simple NFT could be fun), as well as the cadence of a vote every 2 weeks (better than monthly, I think) - as this could help set the expectation for engagement and give people a reason to check in regularly.
Hello everyone,I want to know about what kind of merger? Now that the new website has not come out, is it until December 2021
Hello @mack. I do not mean to avoid your question but we usually stay away from hard dates. However, the merge is already underway and we build in public. That means you can follow our progress. For example 
I followed the Twitter of two tokens。
These two accounts are not very active. Although there are tens of thousands of followers on Twitter, there are very few active accounts. Does this mean that very few people pay attention to the development of the project?
Is there a weekly or daily report on the progress of our merger project? If so, where do they post it。
Finally, I think the person who proposed the merger of the two projects is a very clever person
Hi Mack,
在 Discord (Keep) 和 Github (KEEP/NU <> T token transition mechanics · Issue #1 · threshold-network/solidity-contracts · GitHub) 上发布的更新
Hi! You could also check out the dev updates made by Evandro, refer to the latest edition below.