Specify that we wouldn’t accept a USD cap? We’ve done a lot of research, thinking and discussing this topic. Also, the idea of a USD cap only came into play recently.
2 Likes
A long way indeed, but in our nutty crypto world anything is possible (plus I’m an optimist).
I get your point on ZEC denominated packages being sexy & attractive, but we live in a fiat denominated world & that’s not going to change in the next few years.
1 Like
Ian, Josh is speaking for me and for the entire leadership team of the ECC. We believe that these three points are true and are important. You may disagree with us, but please do us the respect of assuming that we mean what we say.
5 Likes
There was a fiat-denominated cap in an early version of [what became] Matt Luongo’s ZIP 1011. I replied on the thread about that, saying that I wasn’t sure ECC would be able to serve effectively in that role: Decentralizing the Dev Fee - #83 by zooko
Matt subsequently removed that provision from his ZIP before the community sentiment collection. At the time of the community sentiment collection, [the proposal that became] ZIP 1011 no longer included a fiat-denominated cap:
[Edited by @daira to correct the ZIP number.]
3 Likes
Sure. I’m an optimist too.
It’s not just about a nice compensation package. A person would come into a job and know that, based on longevity (vesting window) and contribution, they will receive X ZEC per month for as long as they are with the company and contributing well. They are a coin holder as soon as they receive the ZEC, but also this achieves ongoing and long-term alignment with other ZEC coin holders due to the anticipation of future ZEC that they haven’t yet received.
3 Likes
Thanks for sharing Zooko!
I support this approach. Retaining and growing talent in the Zcash ecosystem is a top priority from my perspective. A “Major Grants” mechanism in the final proposal could alleviate concerns of the ECC receiving excessive compensation if the price of Zcash dramatically increases. For example, I’d initially expect the ECC may receive some of the Major Grant funding, assuming that the ECC needs the funding. As the price of ZEC increases, the ECC could be weaned off the Major Grant funding to rely solely on the base ECC allocation in the proposal. If the ECC’s allocation ends up being much more than anticipated, this should be factored in future conversations about protocol funding (assuming in 4 years this will be revisited).
We should be thoughtful of how we allocate development funds to new entrants. Given the limited funding, I’m wary of initially allocating a fixed percentage of the development funding to new entrants. I’d prefer a combination of USD with a ZEC kicker for incentive purposes. A shift to a fixed percentage feels more appropriate after teams have delivered results and shown longevity in the Zcash ecosystem (even a year would make me more comfortable).
I know this has been a painful process for some but we seem to be reaching a solution that could work for the ECC, Zfnd, new entrants, and the wider Zcash community. Hang in there everyone!
7 Likes
Logically, to have any possibility of fixed-ZEC-amount grants, the USD cap (or more precisely, the USD-denominated mandatory Volatility Reserve mechanism) must be removed.
With that done, the grant review committee can be given the discretion on how to denominate its grants, taking into consideration proposers’ preferences, proposers’ track records, available reserves, etc.
Edit: My claim above is incorrect. Constant-coins-per-month is possible, with some planning and within some range of parameters, as @acityinohio points out below. The idea is to create a “treasury” of coins (both ECC and ZF already have some reserves, and they may be able to grow it even within the Funding Target), and then commit to future disbursement of coins that are already within that “treasury”. As the USD value of the commitment grows, so does the USD value of the treasury, so it all works out.
6 Likes
You might just have something there… not just for new entrants but for all recipients. A mix of USD & ZEC denominated value.
Proposed compromise, in the spirit of @hameed’s post:
Keep the Volatility Reserve mechanism, but change it as follows.
Each Dev Fund slice has a Funding Target, initially US $700,000 for each slice. At the end of each calendar month, the fair market value of the Dev Fund ZEC received during that month will be computed, and half the excess over the Funding Target will be put into a dedicated Volatility Reserve account by the funds’ recipient.
(I added just the “half”, and the precise fraction can be tweaked.)
And clarify that the grant review committee has the discretion on how to denominate its grants (ZEC or otherwise), taking into consideration proposers’ preferences, proposers’ track records, available reserves, etc.
On one hand, this gives plenty of ZECUSD “upside” exposure and incentive alignment for ECC employees, grantees, and ZF employees (hey don’t forget those!).
On the other hand, in case of ZECUSD increase, it still captures a lot of the upside into a Volatility Reserve (for a rainy day, an extended runway, or an interest-bearing “endowment”).
@joshs @zooko, does this satisfice your concerns? It would let you give employees up to half their compensation as fixed ZEC amounts, which by analogy, is much more than what’s commonly given as employee stock options.
@mhluongo @prestwich, would this satisfice your company’s needs, as prospective Major Grant proposers?
@acityinohio , is this compatible with ZF’s obligations and outlook?
@ttmariemia @mlphresearch, is this reduced Volatility Reserve compatible with your outlook on volatility cushioning and interest-bearing endowments?
3 Likes
Would there be any legal problem with the ECC or the ZF lending ZCASH through DEFI? Smart contracts can be insured. And with a large reserve like that it could provide a significant source of income.
There must be a way of hedging the ZEC in some way to a tolerable level of volatility…
Those numbers seem a little strange.
I am pretty sure that 4500 zec are mined a day. Your numbers add up to 109374 per month shouldn’t it be between 126000 and 139500 a month?
idk. my numbers a probably wrong.
I don’t know that I understand it. It feels like a lot of moving parts. I believe if there is a USD cap, it inherently doesn’t align as we couldn’t commit to X ZEC per month over a vesting schedule without risk of going underwater. But maybe I’m missing something.
1 Like
Do your numbers include the halvening?
1 Like
You’re right, but in my compromise above there’s no hard USD cap.
A mathematically-equivalent way to think about that compromise is:
Half your slice is straight ZEC, uncapped.
The other half is capped at $350k/month (ignoring the first half) and the excess goes into your Volatility Reserve.
2 Likes
No they are 6.25 zec at current block speed. the halvening would make it half, 65520 - 72540 per month. (which also isn’t 109374. - sorry if I am being thick.)
No worries. These numbers are important. The current monthly allocation, give or take is 218,750 - so roughly 109,375 post halvening.
3 Likes
Eran - yes, all three allocations would need to be on a ZEC % basis. The major risk I see with this approach is that each entity (ECC, Zfnd, Grant Committee to the extent this differs from the Zfnd) will need to do treasury management. At a minimum, each entity should have a public policy for managing treasury, maintaining reserves, etc. I understand that the Volatility Reserve is meant to address this risk.
Thinking through this approach, can you clarify if each entity has it’s own Volatility Reserve account or if it is a shared Reserve account? Apologies if you’ve previously answered this, I wasn’t 100% certain from the ZIP.
1 Like
ECC and ZF manage their own Volatility Reserves (ZF manage two, for its General Use and for the Major Grants). The grantees don’t, that’s already taken care of by ZF.
1 Like
I don’t think that it’s reasonable for the protocol to be designed around a company’s compensation policies. Treasury management strategies change much faster than the protocol. Unlimited-upside comp for individuals is not sustainable anyway. Changing the Dev Fund structure to support would be socializing private costs of misaligned compensation.
My company’s needs are fair compensation for work, and the ability to participate in upside if we want to. So whether this suits our needs depends on who is allocating grant funds and whether we can negotiate a reasonable deal. As far as delivering work goes, the grant process matters to me a lot more than the treasury management.
That said, we would be less likely to hold ZEC if the Dev Fund guarantees fixed-ZEC payouts to any entity, or is shaped to support fixed-ZEC payouts to individuals.
8 Likes