Decentralizing the Dev Fee

Community Collaborations protocol
12

Excellent disclaimers!

Double-checking that I have a link to back this up. I’d thought James’ post on the dev fee covered it, but wanted to avoid linking because I think a lot of it is besides the point… will find another one or see if he’d like to jump in here to make that an open conversation.

Whoops, good catch! I LaTeX-ified this from a Python snippet and missed a coefficient- it should read

MaxBenefit(RewardDollarAmount) = Max(500000, 500000 * \sqrt{\frac{RewardDollarAmount/500000}})

I’ll get that in the PR :blush:

There are a couple ideas here.

For both, limiting the upside per-month should incentivize captial-efficiency and saving ZEC now to get better upside down the road.

For the ZF, that to me should keep it from becoming a huge fund without direction and an opsec nightmare – I’m skeptical that the ZF would ever be making many millions per month and deploying that productively, versus “giving back” to the holders with a burn.

For the principal developer, the idea is that an appointment that’s 4 years by default, including a say in governance, can limit some month-to-month upside to favor saving for the long term. Not only is it pro financial discipline, it’s good for holders in the case of extraordinary price growth.

In the case of significant price growth for other dev fee recipients, there’s a periodic adjustment that happens every network upgrade. Other recipients are taking a larger risk than the principal developer, as they don’t know how long they’ll receive an allocation, and can’t, for example, borrow against future ZEC earnings in case of a rainy day.

Finally, the whole mechanism means that at some price point, the dev fee is “reduced” relative to issuance.

  1. “First among equals” implies a deference and natural leadership position, enabling a greater voice in setting cadence and direction amongst dev teams.
  2. The governance participation underscores that greater voice. Obviously that seat would be conflicted out of discussions around the principal developer.
  3. I believe there’s a place for an exclusive, longer-term allocation with more freedom from oversight. Principal developer would more easily be able to focus on research a year out, for example, versus other recipients which would need to justify their progress semi-annually.
  4. And finally, I don’t believe we can attract a diverse set of skilled crypto teams whilst requiring them all to be exclusive on Zcash. Many of the candidates that come to mind (us, Parity, etc) work in complementary ecosystems. I don’t think that’s wrong, as long as they’re held accountable and aren’t working against Zcash’s interests.

I hope that covers most of your questions - I’m going to revisit this with fresh eyes in the morning.

1 Like