Community Sentiment Polling Results (NU4) and draft ZIP 1014

Community Collaborations protocol
5

Kudos to @Josh and ZF’s board for this important step in converging towards a decision, and the diligent sentiment gathering (formal and informal) that lead to it.

I’m honored that my proposed ZIP 1012, building on @mhluongo’s ZIP 1011, was recommended as the basis for forthcoming discussion. I support revising ZIP 1012 to accomodate clear community sentiments. The obvious caveats are ensuring that the results remains executable, and being careful about interactions since there are many interdependent governance, accountability and incentivization mechanisms.

I would like to offer some initial comments on the planned revisions, and also make some process commentary. Please excuse the length of this post; it mostly summarizes things said elsewhere, but collects them in one place.

Trustees

  • Add ZIP 1010’s accountability requirements, either through a legal trust or some other means.

I support implementing the strongest form of accountability that’s feasible. The reason I did not integrate the legal trust approach is that I’m apprehensive about finding a trustee willing to undertake this duty, given the technical, legal and regulatory complexities. This introduces costs in time and fees, and a risk that the idea will prove infeasible.

I suggest to integate the Trust mechanism, but also specify that if this proves infeasible (as judged by consensus of ECC and ZF after their best efforts), then as fallback the existing accountability mechanism of ZIP 1012 will be used. Copied here for convenience:

Enforcement
For grant recipients, these conditions should be included in their contract with ZF, such that substantial violation, not promptly remedied, will cause forfeiture of their grant funds and their return to ZF.
ECC and ZF will contractually commit to each other to fulfill these conditions, and the prescribed use of funds, such that substantial violation, not promptly remedied, will permit the other party to issue a modified version of Zcash node software that removes the violating party’s Dev Fund slice, and use the Zcash trademark for this modified version. The slice’s funds will be reassigned to ZF-MG (whose integrity is legally protected by the Restricted Fund treatment).

Another difference is that the reporting requirements of ZIP 1012 are more rigorous and explicit than those of ZIP 1010’s. I suggest to keep the rigorous reporting requirements, but there is flexibility here.

USD Cap

  • A major difference between ZIP 1012 and ZIP 1013 is the presence of a dollar-denominated cap in ZIP 1012. We’re in favor of this cap for the Foundation, but we don’t think such a cap is necessary for the ECC if we add ZIP 1010’s strict accountability requirements.

This planned revision strikes me as weird and undesirable, for several reasons.

First: ZF, being a 501(​c)3, is subject to strict regulatory constraints on its use of funds. These regulations don’t apply to ECC. So it seems upside-down to place a cap on ZF but not on ECC.

Second: my impression was that USD cap is widely supported, based on sentiments expressed in many community discussions.

Third: Recall ZIP 1012 (unlike some other proposals with a USD cap) does provide an upside to the Dev Fund recipients, even if the USD price exceeds the monthly USD cap (Funding Target). If that happens, the excess coins are not burnt or redirected, but rather deposited into the Volatility Reserve of that same recipient. They can then be withdrawn from the Volatility Reserve whenever it’s needed in order to top-up the income to the Funding Target. Thus, in effect, the excess ZEC go towards extending the runway instead of increasing the burn rate. Moreover, there’s a mechanism for increasing the Funding Target.

For all of those reasons, I suggest applying the Volatility Reserve mechanism to all parties, though there’s certainly room for relaxing it (e.g., increase the default Funding Target, or change the Funding Target update mechanism to make it easier to increase; @mlphresearch’s analysis made a similar point).

Grant Review Committee

  • The inclusion of the Grant Review Committee as specified in ZIP 1010 to determine Major Grant disbursement rather than the ZF board, with explicit authority to disperse these restricted funds added to the ZF bylaws.

In principle, I would love to have an independent Grant Review Committee. However, I am apprehensive about decentralized means to appoint it.

In particular, there are major issues with the committee composition that ZIP 1010 prescribes:

The ZF Grant Review Committee would be compromised of five members, voted on in the following manner:*

  • 1 seat for the ECC. Though the appointed member may change, they retain power to choose the seat for 4 years.
  • 1 seat for the Zcash Foundation. Though the appointed member may change, they retain power to choose the seat for 4 years.
  • 2 seats voted on by ZEC holders directly, elected every year. There would be open elections held by the Foundation similar to the 2018 advisory process which resulted in Ian and Amber’s election, except using a ZEC coin-staked vote directly.
  • 1 seat held by a technical member, elected every year. This member would be selected by the combined group (2 coin-staked seats + ZF seat + ECC seat) with an express focus on ability to evaluate technical proposals.

To summarize the forum discussions:

Half of the committee is controlled by “ZEC holders directly”. Such coin-weighted voting has severe problems. If these are two seats captured, then the others two seats don’t suffice to mitigate the damage (and there would be a deadlock on electing the 5th, technical member). That’s creates a very bad risk of capture, for a committee that controls the disbursement of many tens of millions of dollars. References:

More generally, I fear that the problem of conjuring an independent grant committee is basically the general “decentralized governance” problem in disguise, and we’re not going to solve it here either.

Another problem is the presence of an ECC member on the Grants Review Committe. This causes an unacceptable conflict of interests when awarding grants to ECC, and also for all other grants because they compete with ECC for funding.

(Recall that, in the rationale and design of ZIP 1012, it is crucial that ECC can compete for Major Grants, in order to sustain its operations until concrete opportunities arise to create even greater value for the Zcash ecosystem. If ECC is not allowed to compete for Major Grants, then its dedicated slice needs to be much larger.)

Thus, unless and until a better solution to this governance problem is found, I reluctantly suggest to keep the weak language (“ZF shall strive to create an independent grant committee”) of ZIP 1012, or similar. Or be more specific and prescribe, as @mlphresearch suggested, to compose an independent grant committee by a sentiment collection process, followed by final decision by the ZF board.

Board composition

  • With the addition of the explicitly specified Grant Review Committee, changing the ZF board election requirements to be advisory, but retaining the requirement for ZF board members to divest themselves of ECC equity. […]

Indeed. The phrasing in ZIP 1012 is meant to be flexible enough to accommodate whatever is the state of the art, but it’s indeed fine to clarify that board voting may remain advisory.

Dev Fund ZIP revision process

Lastly, I would like to raise a process issue.

ZF should proceed very cautiously in modifying ZIPs, and recognize that the more it changes the ZIPs that were voted on in the sentiment collection, the further it strays from established consensus into the territory of centralized discretion.

The ZIP authors (myself included) have no special standing in forming the consensus on revisions, and even if I happen to personally approve of changes to my proposed ZIP, this is no way indicates that the modified ZIP retains or improves its original widepsread approval. Perhaps my tastes happened to diverge from the community on these specific changes?

Furthermore, the narrative of “merging” ZIPs is alluring but misleading. We have good signals on monolithic ZIPs, but not on which components people approved or disapproved of. When merging ZIPs, we run the risk of removing the elements that many people did like, and choosing elements that are widely disliked. A merged ZIP may look fine to the authors of the original ZIPs, but may be judged by the community as worse than either of the original ZIPs. Worse yet, if it’s hurried through because it’s “merely a merge” then the community may not put in the time and effort to notice the problems in time.

I thus urge ZF to use all the means at its disposal to gather community sentiments about all the changes it’s making, including clearly explaining what changes were made and why; explicitly calling for specific feedback and focused ad-hoc polls; and if the changes are major, repeating the structured sentiment collection on the forum and Community Governance Panel.

9 Likes