Proposal for a Zcash Governance Bloc (“zBloc”)

Governance
1

In recent polls about the future of Zcash development funding, the community signaled a strong preference for a non-direct funding model. It also decided on a temporary one-year continuation of a development fund where ZCG would continue to be funded and the remaining placed in a temporary “lock box,” while the community determines next steps. In this proposal, I outline how non-direct funding might work in more detail, for consideration by the Zcash community.

Thank you to @peacemonger, @nuttycom, @daira, and @adjychris for the reviews, feedback, questions, and suggestions needed to make this a strong proposal.

Proposal for a Zcash Governance Bloc (“zBloc”).

Zcash governance must be set free.

It must be unbridled from individuals who, despite their best intentions, are flawed and prone to temptations to control and coerce. It must represent voices from all over the world, who need digital cash for their security, and for their dignity. It must withstand the fire of chaos and attempted capture of all forms.

zBloc is a governance blueprint for a thriving Zcash.

It is built for decentralization and accountability, to include more voices and ensure results from those who receive funding by block rewards.

It is built to be dynamic, recognizing the risk that any one group may become captured or ineffective while allowing new innovative and positive voices to rise up and carry our flag forward.

It is built for clarity, illuminating the path to how decisions are made.

This proposal for a successor is intended to modify and clarify the Funding Bloc proposal I posted in March based on our current state and community feedback. I’ve renamed it the Zcash Governance Bloc (“zBloc”), as it would serve as a governance and funding decision mechanism. I’ve renamed the Development Fund to the Zcash Community Fund to indicate that funds may be allocated to non-software development-related activities such as community support and education.

Bloc Membership

The zBloc would distribute decision-making authority for both Zcash governance and funding decisions, potentially to any number of constituencies.

A constituency is a group representing a trusted subsection of the Zcash community.

The Initial Structure section below proposes a set of initial constituencies, but the model allows for changes over time, enabling the zBloc to evolve.

  • New zBloc constituencies may be added as they gain trust and removed if they are no longer operating or trust is eroded. The means for this is described in the Governance Decisions section below.

  • zBloc constituencies may be granted different levels of authority, receiving less or more say over time. This is done by allocating or removing signing keys to reflect the amount of voting power allocated to each constituency. For example, if the community wishes to increase the weight of coin holder voice over time, it could increase the number of signing keys allocated to coin-holder representatives, which would dilute the power of other constituencies.

Each independent constituent makes a governance or funding decision by signing a transaction. The transaction construction may be completed off chain and asynchronously before it is submitted but the specific implementation details can be determined later. A decision is ratified when a threshold of signatures is met.

The constituent chooses how to make their decision (polling, majority vote, coin-holder signaling, technical feasibility, mission alignment, etc.). If the constituent is impacted by an outcome such as funding or authority, they must abstain. If a conflicted constituent does not abstain from signing, other constituents may challenge the decision and reverse support through another signature.

To be considered a constituent, each must pre-commit to an internal governance mechanism for decision-making that all other constituents approve of (i.e. greater than one decision maker, means of assessing community sentiment, etc.). If the constituent changes its governance mechanism, it must be approved by a super majority of the other constituents.

I propose that the initial group of constituents be (if they are willing and approved by the others): coin-holders, ECC, Shielded Labs, Zcash Community Grants, Zcash Core Engineers, Zcash Foundation, and ZecHub. Each constituent would receive one signing key.

1107×596 20.9 KB

While the mechanism for coin holder approval is not yet clear, I propose that the other zBloc members elect a representative responsible for establishing a clear process and mechanism for gathering coin holder sentiment. Once a sufficient mechanism is established, coin holders could be allocated more than one signing keys.

Relentless decentralization is zBloc’s core value and mission. It’s the unifying ethos that will keep zBloc’s doors open to new contributors. This continuous expansion is in the best interests of the growing Zcash community. Thus, initial zBloc members have the responsibility to facilitate this growth and encourage, nurture, and welcome emerging groups of constituents.

Governance Decisions

A supermajority must approve any governance decision. To signal clear community consensus, I propose a 75% threshold.

This includes:

  • Changes to Zcash consensus rules, where an activation height is only set once a supermajority has approved the activation.
  • Adding or removing constituencies to the zBloc.
  • Increasing or decreasing the voting power of zBloc constituencies by granting additional or retiring signing keys.
  • Increasing or decreasing the number of Funding Pools, the rules that govern them, and the amounts allocated.

Final ratification occurs when node operators adopt the software.

Funding Decisions

I propose we continue with an 80/20 funding model in perpetuity, in which 80% of the block rewards are given to miners and 20% to the Zcash Community Fund. The 12% allocated to the lockbox activated in NU6 would be used to seed this fund.

This proposal includes two Funding Pools, with different rules for each. These are the Large Grant Fund and Minor Grant Fund. Over time, it is worthwhile to consider other specialized pools. This might include novel ideas, such as the speculative funding pools suggested by @nuttycom or others, such as a retroactive fund, speculative fund, and maintenance fund.

Who may apply for grants is not restricted. It is highly encouraged for all participating organizations to seek outside funding and not solely rely on the Zcash Community Fund.

The Large Grant Fund will include 80% of the Zcash Community Fund.

  • The Large Grant Fund is used for grants at or above $100k, based on the current ZEC price (a Governance Decision can change this threshold).
  • An absolute majority (>50% of the constituencies) of the zBloc makes funding decisions and disbursements.
  • Proposals are submitted to the Zcash forum, and each zBloc constituency must monitor and engage with participants and either sign or explain why they are not supporting the grant.
  • Disbursements are made when the recipient successfully demonstrates completion of a milestone to the satisfaction of a majority of zBloc members.

The Small Grant Fund will include 20% of the Zcash Community Fund.

  • The Small Grant Fund is used for grants under $100k (a Governance Decision can change this threshold).
  • A designated organization, or perhaps different organizations with areas of specialization (engineering, marketing, etc.) will administer decisions and disbursements in exchange for an annual fee.
  • The organization(s) will be elected by the zBloc, and can be changed or removed through a Governance Decision.
  • The fee will be proposed by the organization and approved by the zBloc.
  • The organization will self-govern and manage the process for grant submissions, approvals, and disbursements.
  • ZCG could be a candidate for this role initially.
  • The role is open to competition. For example, rather than ZCG splitting off as an independent organization, perhaps this function could be rolled under the Financial Privacy Foundation or third parties that may be interested in managing the fund in exchange for a fee.

I believe that this model, or something similar, will:

  • Increase transparency and accountability for all participants
  • Increase the voice of the community through direct participation
  • Further decentralize Zcash governance and provide clarity on how decisions are made
  • Continue funding Zcash development efforts
  • Create a structure that can easily evolve over time

I welcome your thoughts.

18 Likes
2

This process should start now. It is possible that by the time this structure is ready to be implemented, new groups of constituents will emerge. This could be LATAM communities, user groups, Zcash developers, etc. Each group can be assigned any number of signing keys, like electoral votes. The number of keys per group can be determined once all of the initial zBloc candidates are confirmed.

Decentralization within each constituency is just as important as decentralization at zBloc membership level. Signing keys should never be controlled by just one person within an organization. Org leaders should be required to align with a number of other constituents in their org (e.g. board members, team leaders within the org, etc). At the very least, this requirement will facilitate internal dialogue.

7 Likes
3

The Small Grant Fund should be split evenly between technology-focused projects (50%) and marketing/community/business development initiatives (50%).

4 Likes
4

I think that if we use the same groups of people to seed the new governance entity we will end up with the same results, aka fruits of the poisoned tree of some sort.

I suggest we elect new representatives in charge of the various roles (engineering, logistics, marketing, etc) via coin voting with the ability to delegate.

10 Likes
5

My thoughts:

  1. I’m against making the dev fund last into perpetuity. I’m open to making it last for a very long time, like 20 years, but if Zcash becomes fossilized like Bitcoin it could be hard to remove it once Zcash is mature and doesn’t need it anymore. It’s kind of like changing the constitution of a country, and we could be stuck with a system that funds vanity projects. In the real world at least it seems to be much harder to remove things from the government than to add it.

  2. It’s important that the coin holder voting mechanism isn’t a winner-takes-all system. If the coin holders are close to unanimous against a decision (>90%) I think they should be able to veto any decision, but if they’re more evenly split the trusted entities should be able tilt the balance. The coin holders voting power should also scale together with what % of circulating supply is participating in the vote.

  3. Not sure how I feel about dividing into different funding pools. Not necessarily against it, but not sure yet.

3 Likes
7

In this proposal each of the constituencies have one signing key.

@Dodger mentioned Nested FROST a few weeks ago.

Is it possible to have such an arrangement in place for some or all of the voting groups instead?

1 Like
8

We are looking into this! We’re probably going to do a proof of concept soon.

9 Likes
9

Threshold signatures are one of the best/only tools we have now. I think the drawback is that there has to be social coordination and somewhat synchronous, manual execution of the mechanism. I don’t think it can scale to dozens or 100s or 1000s of constituents. A single small threshold signature may be good for an early iteration. But, with ZSAs in the future, would it be possible to design a signalling mechanism with a governance token or some sort of badges where the mechanism can be massively scalable and more programmatic without relying so much on off-chain coordination and manual human action? Are there any ideas floating around for how ZSAs could be utilized for governance and voting? Should Zcash governance be one of the first target problems for ZSAs to solve?

2 Likes
11

I do think it’s a super interesting problem and I think solutions and proposals can have really cool downstream effects. So, I have fun thinking about it. But, I’m also very fond of simplicity and KISS. Do you have a simple answer? I might have missed your exact idea/PoV in the noise. Do you have a simple but detailed potential solution to consider?

2 Likes
12

Can you flush this idea out a bit more?

How would this work in practice? Who are the perspective representatives?
How does this idea protect against capture and self-dealing?

2 Likes
14

More coinholder voting practice, improvement, convenience would be welcome and awesome.

Your example of taddrs might answer contentious questions but does not define a mechanism for disbursement of funds to implement the changes. Or could it? Eg “Give ECC and ZF XX,XXX ZEC from lockbox to deprecate and remove taddrs?” There would still be a question of who holds the keys and how the disbursement is finalized.

1 Like
17

There is no need to be upset. It’s just one proposal. :wink:

I appreciate that you voiced your opinion. I look forward to seeing other proposals and perhaps there will be one that satisfies your concerns.

3 Likes
18

I think it’s an interesting proposal!

I have a question: in the constituencies: can there be people who belong to several constituencies?

I ask the question because we currently have ZCAP members, who are also ZecHub members, and also ZAC members, who vote in the various polls that have been held.

Should we prevent one person from belonging to several constituencies, and how does one prevent a possible Sybil attack, should the identities of all constituency members be known?

Regarding what some mentioned about “coinholders needing”, I think it should be mentioned that Zcash is not only for coinholders, but also Zcash targets, and I want to believe this, the user who uses Zcash in their payments and micropayments. Does this mean that those common “or small” users of Zcash would have no decision making power in anything because they are not “coinholders”?

Folks, let’s think about something: there are many types of Zcash users: those who just store it, those who are big investors (whales), and those who will just use it as a quick way to trade in their businesses. Let’s even think about the activists who see Zcash as a way to oppose the status quo!

Thinking about it will make us find the best mechanism that includes them all.

By the way, I loved this comment: :heart:

3 Likes
19

You have a small elected team in charge of governance, with a representative or expert in its own field, such as engineering, marketing, education, etc. + 1 president to break ties. It’s the same as in every corporate structure. They don’t have any signing key.
The key holders have to ratify their decision. This should be a formality unless there is a clear breach of trust. In that case, anyone from the community can start a recall vote (coin vote with super majority) to have them kicked out.
The same happens when they want to make a major policy change. The community can veto (i.e. Brexit).

The key points:

  • Not every decision will be put to a vote.
  • Small number of people in charge with experts otherwise, no decision will be made,
  • But they are accountable to the community. Bad decisions or leadership can be replaced quickly.
  • They don’t have the signing keys
1 Like
20

So a committee, something like ZCG but with specialities and only the ability to recommend things? What about all the small grants? Is this their full-time job?

Is this for all governance or funding decisions?

Who holds the keys?

Where do coin holders fit in?

I’m still not clear on capture / self-dealing with coin holder votes in this context. Suppose I have a bunch of ZEC (yes, I am a zodler), plus I’m the CEO of ECC which has more ZEC, plus I’m friends with DCG who have a ton of coins and may wish to delegate to me. What keeps me from capturing governance and funding?

3 Likes
21

If you manage to get the majority of coins to vote then you kinda successfully carried a 51% attack on governance. This is like Zuck essentially being the boss of Meta. However, if you do that it will crash the zec value and your coins will be worth little.
Not every decision needs a coin vote. You would be on the leadership board (as I think you should if you have that many ZEC at stake). The community elected you and should not question everyone of your decisions.
Coin votes are after reserved to large decisions (like ZSA, or ZM) and vetos.

Honestly, it is very similar to a democratic republic, or typical publicly traded company.

3 Likes
23

Coin holders are a group, with the potential to have increased authority over time by assigning additional keys. This allows for a transition.

25

This matches your thoughts on a different thread about democracy not working. Are you suggesting all voting is “captured” ? Interesting.

27

What is stopping intelligence services from buying ZEC, rn, at bottom prices? Same problem if they control most of the supply. Nation states can print money so perhaps that isn’t an issue for them.

29

Today the LCWG discussed some topics around FROST and NDFM use case was brought up.

While some argued that it was too soon to propose tools, and moreover that it wouldn’t be suitable because of some requirements: signature attribution and robustness, I think otherwise

The following represent my views and not LCWG’s.

I think that any NDFM that has a k-of-n kind of disbursement mechanism already outlines a threshold and FROST should be used before proposing any other signature mechanisms.

Given that a NDFM requires a k of n approval to disburse funds there are some important aspects to consider.

Requirements and open questions:

  • Attribution: do we want to know who voted for what? Is that important or is it just tabloid magazine material?
  • robustness: is FROST optimistic protocol not robust enough for a k-of-n with small k and n’s?
  • synchronicity: what’s the timeframe to vote?
  • privacy: what privacy properties do we want?
  • chain activity, yes or no: do we want the NDFM v1 be on chain? or is it off chain ok? what has to be on chain? all of it? or just the final k-of-n signature?

A case for FROST:

  • attribution: according to @conradoplg Verifying Shares can be made public to actually have signature attribution
  • Robustness: FROST provides a single round protocol by participants sending commitments to the coordinator beforehand.
  • synchronicity: what’s the timeframe to vote? I believe that deliberation of the different parties should be async but disbursement approval shall be done asynchronous within a human compatible timeframe.The world is round and crypto is decentralized. This is hard because of timezones.
  • privacy: do we want recipients to be private and shielded? or shall these transactions be shielded but viewable by a viewing key? can a grant recipient in an oppressive regime be put in danger by this?
  • chain activity, yes or no: NDFM v1 should be as simple as it can be. It will already be better than direct funding. There’s an improvement from scratch. NDFM v1.1, 1.2, etc should iteratively be improving on its robustness and incorporate feedback from experience iteratively and regularly until there’s a very stable version of NDFM.
  • Reputation: It will hurt Zcash a lot if we don’t use our own tools. We developed FROST for the world to use but it’s not “good enough for us”? that does not look well.
5 Likes