Thanks for linking me on this @sonya. In case anyone is interested in how the Zcash Foundation currently deals with conflicts, I suggest reading this thread from the last time @boxalex brought it up. Quoting myself there:
Re: Board Members, no one on the Board is currently employed at the ECC, though you are right to be concerned about conflicts. In the case where the Board believes there is conflict, they need to exclude themselves from votes (see this amendment to the bylaws of the Foundation: https://www.zfnd.org/about/incorporation-docs/bylaws_amendment_2/ ).
Later in the thread:
…in the case where ECC’s interests are conflicted with the Foundation [then Board members who are ECC shareholders] are conflicted out of Board votes. This has not happened yet, but if it does it will be reflected in the minutes per the bylaws.
In any event, I would strongly oppose removing this policy, and everything I’ve seen about this proposal suggests it would reduce the likelihood of conflicts by broadening the board composition (though I have some concerns on that, more on that below) and requiring that “no board members have an ongoing commercial interest in any recipient of the dev fee.” (which is a great restriction!)
Anyway,
I’m going to refocus on proposal feedback. In general, there’s really a lot to like here @mhluongo, and I think you’ve done a better job synthesizing than (my now less aptly named!) attempt at a synthesis ZIP. A few caveats to anyone reading:
- This is my personal opinion and not anything official from the Foundation
- Matt talked to me about his in-process ideas at Devcon5 and I provided some limited feedback
- I’m biased because I’m currently employed by the Foundation (and thus the Foundation’s current board)
In broad strokes, here’s what I like:
- The goals and amount of funds to disburse makes sense to me, as does the idea behind a max cap for the ZF/principal developer disbursements (though like @mistfpga I’d really prefer not burning funds, more on that in a minute)
- As I’ve mentioned before I agree that rather than a new, untested body, any entity controlling disbursement should either be a Zcash Foundation with new restrictions or a minimalist trust, and I’m glad to see that here
- I like the intent behind the board changes to the Foundation to broaden stakeholder input, but like @tromer I have some concerns about the transition and maintaining consistency in current Foundation efforts
- I suspect it would greatly broaden external developer contribution, which is a Very Good Thing™ for Zcash
- Creating an opportunity for (accountable) continuity through a Principal Developer is a good idea
- It’s well thought out and incorporates good ideas from many other proposals on the table
Some areas where there are open questions/concerns for me:
To Burn or Not to Burn
This is a less critical issue for me than my other open questions, but I have a mild preference for not burning coins — are there any other palatable options here? How about the coins above that amount are required donated to a an orthogonal but mission-aligned nonprofit that accepts Zcash (Tails, Tor, Open Privacy, etc.) at the board’s discretion? Then it wouldn’t affect supply while benefiting the broader aims of the Zcash ecosystem.
Incentivizing shielded adoption
My favorite part of my proposal was the idea of linking payout percentages to shielded adoption, which was something @tromer had brought up in the forums some time ago. I think there’s still room for that here but perhaps it can be enshrined in the criteria used by the new board to judge future dev fund recipients.
Accountability details and Foundation + Principal Developer requirements
My second favorite part of my proposal is the requirements surrounding disbursement for obligatory recipients of a fund described here. I’d love to see some of these integrated here…maybe not all of them, but focusing on reducing the risk that a Principal Developer may buy out or guarantee some flow of the dev fund to pre-dev fund/non-employee shareholders is really important IMHO.
On the principal developer’s board seat
A board member with any financial interest in the principal developer is a potentially existential risk, due to concerns around inurements in US-based nonprofits. An easy way to fix this is simply remove “outside the seat for the principal developer” — they can still choose a friendly representative outside the organization/principal developer shareholders, but we’d avoid the self-dealing risk. (Note that this hasn’t been an issue today even with the Foundation board having three ECC shareholders; the Foundation has never retained the ECC for any work or directly funded their efforts)
On the research seat
It’s not clear to me how the “research advisory board” would be created or how those members are selected…which is a smaller version of my issues with the other strategic council approaches. I think we could simply make this a “technical member” of the board with the same goal but dispense with requiring the creation of another board-like entity and leave it to the rest of the new board created by this proposal.
Board details and Foundation continuity
My biggest concerns are here. I’m not opposed to fundamentally re-imagining how the Foundation board is selected — but this proposal suggests a rather rapid shift. It’s understandable given the new scale of the Foundation’s duties, but it’s also very risky to do all at once and immediately after the dev fund is established. If this board structure were to be required immediately after activation, it’s conceivable that the board is completely refreshed (e.g. 3 new board members join, vote off the 2 remaining board members and select 2 of their own based on the way the bylaws currently work). Given that this proposal selects the Foundation for this body because it’s already established and has been working for the Zcash ecosystem for many years with reputation and trust, the possibility of a complete board shift worries me. It’s also not clear to me how frequent these elections are supposed to happen.
This is not an insurmountable issue, but it’s a critical one. Here’s my suggestion on how to fix it through board composition and election frequency:
- 1 seat voted on by ZEC holders directly, elected every year (or sooner if the member resigns. In any case, this seat must be elected by ZEC holders through a coin-staked vote). 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 for the “Principal Developer” with the non-shareholding restriction above. This seat stays for 4 years. (if they resign, the Principal Developer and only the Principal Developer can elect a new representative)
- 1 seat held by a technical member for doing due diligence on dev teams. Initially this member will be selected by the Foundation’s legacy board, then every year they will be elected by the other members of the board. (their vote does not count!)
- 2 at-large seats elected by the board, as the board is currently selected according to the bylaws, with a modification to make it a 2 (instead of the current 3) year term. Initially these two members will be selected by the Foundation’s legacy board.
Here’s how these modifications enable a smoother transition to a broader board:
- At beginning of year 1 (e.g. October 2020 to October 2021) there is guaranteed to be a slight board majority supplied by the legacy Foundation board. (3 members elected by Foundation Board) This grants the Foundation an opportunity to transition into a new board structure while acclimating to its expanded role.
- At beginning of year 2 (e.g. October 2021 to October 2022) the 2 non-legacy members (ZEC-voted seat, which may or may not have a new member, and the Principal Developer seat) and 2 legacy members would have to elect (or re-elect) the technical member. In this case it’s possible it will transition to a board where there are 3 new members and 2 legacy-selected members.
- By beginning of year 3 it’s possible that the entire board has changed its makeup (as four seats will be up for election then).
This ensures a smoother transition but ultimately leads to a board that will eventually be much more influenced by the Principal Developer and the rotating ZEC holder and technical seat. There are some intricacies on the timing of elections here but I do think it’s preferable to do something like this (even when trying to remove my admittedly extremely high bias for Foundation stability).
On combining proposals
Great work Matt! If my concerns are addressed above, I’d actually feel more comfortable supporting your proposal over mine — or modifying mine to fit yours.