Decentralizing the Dev Fee

[ttmariemia]

Thank you @mhluongo for your contribution (and for the shout out), it was a great read! I like it.

I’m going to comment via other’s comments first as some of my own initial sentiments have already been expressed.

@mistfpga

Why? When you go to burn the coins, don’t. put them back via extending the next halving by x number of blocks.

Question, @mistfpga would this not reduce the value accrual of ZEC over time? Basic supply/demand economics, halving typically drives pricing upwards, if we put back ZEC and extend the next halving, wouldn’t that contribute to a slow growth?

@mistfpga

Personally I would be happier with this being a NU5/6 proposal.

I disagree, I think this is pretty feasible in the short term, conditional that ECC agrees to receive 1/3 of the remaining 20% dev fee (i.e 25% of the 75%)
and that ECC agrees to solely work on ZEC - two conditions which I glean have been a strong point of contention for ECC.

@mhluongo

Dev fee recipients are chosen semi-annually by the Foundation based on their
ability to move Zcash forward.

I’ll refer back to my proposal - I agree that this is a gap in @mhluongo’s proposal.

AUDITABLE METRICS

The Zcash , Zcash Foundation, and ECC must work together to develop and achieve consensus on auditable metrics that:

• Show quantitative value to the ZEC economy
• Track against the strategic roadmap
• Can be measured and audited by anyone
• Allows for flexibility in terms of failures, pivots, and adjustments

The Zcash Foundation will contract or hire[4] an individual(s) with the proper pre-requisites (background in blockchain, data, analytics, and design) who will solely be responsible for working with the Zcash Foundation, Electric Coin Company, and external developers to:

• working with the community to define and communicate auditable metrics with product developers (i.e. ECC and external developers)
• communicate with the Zcash community and host live votes
• consolidate and publish voting results, feedback, and suggestions at a defined time interval
• host Quarterly hangouts for discussions

The independent authority who will be responsible for ensuring the legitimacy and validity of reporting will be the Zcash community .

Moving along…

@mistfpga

So what happens to the current grant program, is this trying to fix that? because this seems to stop people like myself from getting involved. (And it is already hard enough)

I also agree that there is another gap, @mhluongo, in terms of how to fix the existing grant funding mechanism.

I had a few ideas, but they did require more of a governance procedure/ application… @mistfpga on-chain governance was out of scope for @mhluongo proposal, which makes sense to me. It may be a phase II item: Priority #1 figure out how to allocate funds
Priority #2 figure out how to manage fund disbursement and metrics
Priority #3 figure out decentralized decision-making applications (both on-chain and off-chain)
With a dedicated team and active community, I’m hoping that a lot of ground on these three priority items can be covered in 1 year’s time.

@mistfpga

Can you please define what you mean by the community, and how you are envisaging the partnership with the community working?

@mhluongo curious to know what you think about my Vesting idea. Decentralized Participatory Voting through VESTING

@mistfpga

I think you really need to encourage developers like radix. - How does this help individuals get involved? wont the dev free recipients just take and implement the ideas themselves?

@mistfpga you lost me here. Isn’t the point for the teams to 1. get funded and 2. build/ implement the ideas

@mistfpga

I would like to hear what @ttmariemia thinks.

It seems the zcash tech should help enable startups, she knows a lot more about start ups than me.

On this, @mhluongo there’s a gap on entry-level participation for teams and/or individuals to begin to learn the code-base. Your 75% Dev Fund mirrors my Endowment Fund, but my ‘Zertilizer’ attempts to address flaws within the existing granting mechanism. Maybe there’s a blended approach that could be explored?

@mistfpga in response to this:

@mhluongo

While dev fee recipients are not required to work exclusively on Zcash,
considering the nature of their work, recipients must guarantee they aren’t
obliged to the interests of competing projects.

I think it’s a well-balanced meritocracy due to the inherent veto abilities of the network:

@mhluongo

• Miners can veto activating a new fork by refusing to build off blocks using
  new network rules, orphaning a minority effort. They can also attack any fork
  attempt that doesn’t change
• Users can veto a fork by refusing to update their full nodes, rejecting
  blocks as invalid – as demonstrated in the UASF fiasco resulting from the
  SegWit2x attempt to force a Bitcoin hardfork. Users can also vote with their
  dollars, acting as a fork resolution of last resort via market pressure.
• Developers can refuse to update client codebases to follow a fork. While this
  might not seem like a strong veto, in practice that means any fork will need
  at least one additional development team, or the agreement of existing client
  software developers.

and the structure of the ZFND board, as proposed:

@mhluongo

To manage the dev fee and fulfill its community and diligence duties, the
Foundation shall maintain a board of 5 independent members. Rather than the
structure in the current bylaws, the board will consist of

• 1 seat voted on by ZEC holders directly.
• 1 seat representing a newly created research advisory board, whose primary
  role will be technical diligence of potential recipients of the dev fee.
• 1 seat for the “principal developer”, a privileged recipient of the Zcash
  dev fee acting as “first among equals” amongst a variety of dev fee recipients
  building on Zcash.
• 2 seats elected by the board, as the board is currently selected according to
  the bylaws. The board’s discretion here means these could be selected via a
  community election, or via the remaining 3 seats’ direct vote.

I am a little concerned about this:

@mhluongo

While dev fee recipients are not required to work exclusively on Zcash,
considering the nature of their work, recipients must guarantee they aren’t
obliged to the interests of competing projects.

@mhluongo could you explain to me why a team could receive Dev Fund money but also be justified in not working on ZEC?

Things I really liked with this proposal:

• It’s well balanced between addressing short-term, immediate needs and nodding to longer-term governance
• It proposes a roadmap to inclusion of external developers (despite not necessarily addressing the current issues with grants)
• while also preserving stable funding for the principle developer (aka: the ECC)
• It’s clear, actionable, and able to implement immediately.
• It moves ZEC towards a Meritocratic and more decentralized governance structure

Things I would like to address:

• It’s fully dependent on the 20% fee from miner’s rewards, I’d prefer a blended approach (like my endowment mechanism) to hedge against risk (aka: temporary reduction in ZEC value and/or hash rate.)
• It does not address how metrics will be determined and by whom and how much weight they will carry in decision-making.
• It proposes a Burn Rate

More on Burn Rate
Burn-rate seems like a misalignment of incentive. Metrics, roadmaps, and milestones should keep stakeholders financially responsible and accountable.

Using burn rate to ensure financial responsibility can be uninspiring and thus hamper motivation which can drive developers to other projects which do not cap their return on time/ effort/ capital investment.

If a burn rate is nonetheless decided upon, I’m against discarding the coin. I’m also against moving the halving, as suggested by @mistfpga. This is probably crazy, but I rather distribute the burned coin to all ZEC holders (yeah, even if it’s only fractions) and encourage the network to hold on to them.

Finally, I agree with @avichal here:

@avichal

1/ I worry that having a principal developer is too much centralization and we should be striving for multiple such developers who are able to focus primarily on Zcash and drive progress

And would like to eventually see ECC compete for Dev fund allocation like all other principal developers - something like my Equity fund proposal whereby a track-record of excellent work can make eligible an external team to apply for that 25% reserved for the principal developer.

However, I do disagree here:

@avichal

3/ Minor point but I think we should drop some of the constraints for fund recipients around having a CFO.

I think the suggestion of eligibility around a CFO is fantastic and I would actually extend it to all applicants, with a caveat to make things less onerous, that the requirement of a CFO is only triggered at a certain level of funding.

There are a few comments/threads that I’m still working through- and that some of my questions/comments may have already been addressed- but I’ll continue to post along as I get through the rest of it.