Oh, it would be a long term project to actually implement after year 8. I would expect the process of agreeing on and implementing a voting system to be hard, and not a differentiator at least in the short term.
I just think it is a good idea to try to try to agree now about how we will allocate a dev fund in the future, since it will only get harder to come to a consensus in the future.
@tromer thank you for this proposal. I think it provides additional clarity, it compliments (for the most part) @mhluongo’s proposal, and moves us significantly closer to a decision.
Initial Thoughts
1. Endowment Fund/ Interest-Earning Mechanism
To review:
Take, for example, a nonprofit with an annual budget of $1-million that hoped to create an endowment that would generate at least $100,000 a year in annual income. That organization would need an endowment of at least $2-million to generate that much annual income, based on a 5-percent payout.
This can be incorporated here, instead of a volatility reserve or as a percentage of each member’s volatility reserves. Ultimately you’ll have to balance returns expectations with risk acceptability.
Fund Benefits 1.) ability to generate capital from external sources 2.) ability to have equity in more mature (not-grant-appropriate) crypto projects that earn a return and/or strengthen the ZEC ecosystem (unless explicitly stated that the fund shall not invest in crypto-related projects, despite their maturity.) 3.) ability to earn money on unused funds.
Shortcomings 1.) to invest in traditional markets ZEC would have to be converted to USD, which may have ramifications in cases of less liquidity, something I didn’t think of prior to; though I’m hoping won’t ever be a problem for ZEC 2.) It will require the hiring of a fund manager and some legal work to set up 3.) Alternative interest-earning accounts like Blockfi or Celcius Network may offer higher returns with less operational logistics and less risk than an endowment fund.
2. Coaching, Nurturing, and Scaling
Noting this:
You might want to have more skin in the game, i.e:
(low-end) commitment to mentorship, coaching, technical resources, touch-points with entrepreneurs, opening up of network/ contact, etc.
(high-end) some sort of revenue-share agreement (however, I get the sentiment that these projects don’t generate profit of their own from @tromer comments on the Dev call
…I’m not sure and this is outside my scope… maybe @tromer you might be able to take the concept and make it applicable to this space:
The idea is instead of giving out grants, an entity will distribute loans that are repayable (with interest) based on a percentage of profits made from the business over a generous time-horizon, and because this structure aligns incentives, the loaner will make available coaching and resources for the project’s success (hence above suggestion on skin in the game).
This just may not be applicable for this space, which is fine. But if the intention is to nurture teams, I would suggest a more formality around what that means; this in itself can act a greater value-add for high-quality applications than the grant money itself.
3. There is no discussion of metrics, milestones, or governance implementation goals.
This may be out of scope due to time constraints, but I would like to see ZFND incorporate some of the sentiments that have been raised in terms of defining metrics, building for decentralization (on-chain governance and voting), and better defining “furthering financial privacy” (ZFND) and “furthering the Zcash cryptocurrency and its ecosystem” (ZFND-MG & ECC) into decision making for Major Grants. It’s a short-term investment that will undoubtedly service the community over the long-term.
Thanks for the shoutout I made a comment below.
I don’t know enough about endowments and such to really comment on that (why I didn’t comment on your proposal before) but I will say that this is why I support the trust fund model, it is already a legally recognized entity with supporting regulations and in that way, I feel, is less ambiguous about intentions, thats all.
@ttmariemia, thank you for the close reading and thoughtful suggestions!
I agree with the ideal of creating an sustainable endowment, and sustaining work using its earnings (or better yet: its real earnings, adjusting for inflation).
The problem lies in the numbers. At the current coin value, a 20% Dev Fund can barely sustain the current expense rate if consumed as soon as it’s accrued.
Another way to look at it: even if we completely stopped funding development for several years and saved everything into interest-bearing investments, the Dev Fund monthly stream would need to be an order of magnitude larger than discussed, in order to build up enough principal, for the interest on that principal to sustain renewed operations.
That said, if the coin price jumps (as it has in the past), than the Volatility Reserve could accumulate much faster, and then the interest on that reserve could become a significant revenue source. Indeed inspired by your proposal, I said that “The Volatility Reserve may be kept as ZEC, or sold and held as fiat currency or low-risk liquid investments”. Edit: The Funding Target will let the reserve builds up as fast as feasible, and prevent it from being spent unless necessary, which I think is consistent with your outlook.
I admit that “low-risk liquid investments” is succinct and maybe too narrow; would you change this to something else?
commitment to mentorship, coaching, technical resources, touch-points with entrepreneurs, opening up of network/ contact, etc.
Good ideas! I’ll add something in this spirit.
revenue-share agreement (however, I get the sentiment that these projects don’t generate profit of their own from @tromer comments on the Dev call
The way we’ve been thinking of this so far is to split the timeline, not the revenue. Support projects before they’re profitable. The grant-sponsored R&D, released as open source, is a public good that Zfnd can comfortable support. The hope is that the recipient will eventually find a way to monetize things, cast aside their grant training wills, and become a self-sustaining part of the ecosystem.
That said, the “long-term loans instead of grants” is a very interesting direction. I don’t have any experience with it. @acityinohio, do you think it’s feasible?
3. There is no discussion of metrics, milestones, or governance implementation goals .
I agree that it would be great to include these. I made some attempts at it, earlier. But no easy answers here; I think the community isn’t ready yet to define metrics etc. crisply enough to be formally enshrined in a meaningful way. Especially when they need to stay sensible for many years, but need to be decided in a few days… So for now, by necessity it is left to ECC and Zfnd to make their own judgments on this, and the best we can do is put in place the general governance, transparency and accountability mechanisms that will encourage them to do the right thing.
Some personal opinions/suggestions (also posted under @mhluongo proposal):
Wouldn’t it be desirable to put everyone on equal footing in terms of having to apply for funding? In other words, a single pool with no guaranteed pre-allocations but still allowing for long-term funding in case of recurring applications from credible teams with a proven track record.
How about a universal 25% cap per team per funding cycle + some reasonable $ cap in case of considerable price appreciation? Again, same rules for everyone. The most concentrated allocation possible in each cycle would be a four-way split between ZF, ECC, and two other teams.
In case of price appreciation, instead of burning extra coins, I think accumulating them into a dev fund reserve for future use is much more reasonable.
I like the idea of reforming the ZF board and authorizing it to make funding decisions, preferably with a requirement to abstain from voting in case of direct conflicts of interest.
Here’s one way to achieve some balance of power between the board, Advisory Panel, and coinholders: initial membership voted in by the Advisory Panel; subsequently, regular open elections in which 1 seat is voted in directly by coinholders (building the required technical solution could be rewarded in the first couple of funding cycles) and the other four by existing board members; at any given time, the coinholders should be able to signal dissatisfaction and if that hits a certain threshold, the Advisory Panel would have to vote in a new full membership. That’s just one idea but the point would be to empower ZEC holders and establish some basic checks and balances.
@mlphresearch, thanks for these great questions and suggestions!
I think everybody agrees with this ideal, but no one knows how to reach it…
The problem is, what is the body which receives and decides these applications? Any single body would be a point of failure, and indeed Zfnd (which is only suitable body that actually exists) does not want to control all the funding, since it would create centralization with all of its regulatory and execution and capture risks.
So all the (realistic) proposals on the table try to approximate the ideal in various ways. Mine and @mhluongo’s specifically, by giving Zfnd discretion on some of the fund (enough to also assign to Major Grants / outside developers), but keeping enough funds outside of Zfnd’s control and thus outside the unified process.
Now, one of my goals in my proposal was to move a bit closer to your ideal, by at least putting all the neither-ECC-nor-Zfnd work under the same unified system of grants (explicitly bolstered to support major external developers). I think this is better than @mhluongo’s proposal of having separate systems (Zfnd grants to outsiders, vs. “outside development” which is also decided by Zfnd), whose difference I still can’t understand.
How about a universal 25% cap per team per funding cycle + some reasonable $ cap in case of considerable price appreciation? Again, same rules for everyone. The most concentrated allocation possible in each cycle would be a four-way split between ZF, ECC, and two other teams.
In the long term, I’d love this. My worry is that in the short term, and by default, it can turn out extremely harmful. I’ve seen no evidence that there exist two big new teams with attractive plans and clear capabilities. Conversely, we know that (at the current coin price) ECC will be starved by 25%. It would require ECC to drop expenses from ~$700k/month to ~$200k/month, and you know what that implies.
So simple question: suppose no good use is found for most of those %50, and meanwhile ECC is starved by its 25%. What’s the right thing to do?
Hard cap implies: “then let Zcash wither away”. Not a good outcome.
So I want a fallback. And thus my proposal says: if after giving preference to external teams we still haven’t used all of the Major Grants slice, then the Zfnd board may choose to assign it to ECC, for a well-specified grant proposal. This will be revisited half a year later.
@mhluongo answers it differently: he says ECC should split itself up to get more of the other slices. Based on deep familiarity with ECC’s technical work, I think the splitting that @mhluongo suggests cannot work.
Here’s one way to achieve some balance of power between the board, Advisory Panel, and coinholders: initial membership voted in by the Advisory Panel; subsequently, regular open elections in which 1 seat is voted in directly by coinholders (building the required technical solution could be rewarded in the first couple of funding cycles) and the other four by existing board members; at any given time, the coinholders should be able to signal dissatisfaction and if that hits a certain threshold, the Advisory Panel would have to vote in a new full membership. That’s just one idea but the point would be to empower ZEC holders and establish some basic checks and balances.
I need to digest this, but gut reaction: what problem is this trying to solve?
Our current system is self-perpetuating board (as in most non-profits) with advisory mechanisms. It seems to have worked well so far: we have extremely well-qualified and well-meaning people serving.
The one concern I’ve heard is that some members are ECC shareholders, and that’s a narrow issue that can be solved by a clear rule if people are really worried about it.
So, are you sure that giving ultimate control over Zfnd to wealth-weighted vote plus a loosely-defined panel (many of whose members are pseudonymous and thus not really accountable) would be any better?
The only part I’m uncomfortable with is the ‘Advisory Panel’ - it could become a point of capture, or leveraged somehow.
I would much rather see community involvement, that already looks off to a good start & could evolve into something powerful.
Mush confess my opinion has been coloured by whats going on in Chile - a nation shaped by a powerful few & managed by a small group of experts (shudder).
Brief aside to this discussion: regardless of which proposal is adopted, I expect that the ZF board will tackle this head-on to remove the conflict in a more permanent manner in the future.
I would actually prefer decision-making to be held in one concrete body that is accountable to other stakeholders in the community (checks and balances). That’s why I intuitively like both the strategic council and reformed ZF board proposals combined with Advisory Panel and coinholder input. It would increase fairness and accountability. It may not be ideal but pre-allocating funding is at least as problematic.
I think it makes a lot of sense to have fallback options in terms of applying the cap, decision-making in special situations, etc. Your proposal ticks a lot of important boxes in this regard.
My final point was an attempt to address the key problem that all proposals are trying to solve. It’s the type of solution that has stood the test of time in other contexts: introducing checks and balances to avoid any single stakeholder having full control of all decision-making. I see three points of control moving forward: ZF board (open elections), Advisory Panel (broader community, can/should be enlarged as the community grows), coinholders (permissionless access, skin in the game). Just to reiterate, with regards to dev fund governance: Advisory Panel would vote in the initial membership of the board which should be able to operate autonomously under normal circumstances (simple majority); in subsequent open elections, four seats would be voted in by existing board members, one directly by coinholders; at any given time, critical mass of coinholders could trigger the replacement of all members via an Advisory Panel vote. No one has full and final power but everyone has some. That’s what I came up with when trying to think about creating a balance of power. Not a proposal, just some food for thought
These are valid concerns. But all entities are subject to capture - ZF board, Advisory Panel, even coins. That’s just life. On paper, I can’t think of a body more representative of the “Zcash community” than the Advisory Panel, especially if it is allowed to grow over time. So it feels like some sort of a counterbalance to ZF, leading dev teams, and coinholders.
I agree, at current ZEC prices we’re not looking at generating profit/interest, however, I do believe that the discussion of capping/burning/ etc. was based off the assumption (and the history) that the price has jumped and as a result provided too much funding in once instance.
The endowment fund is a vehicle by which excess funds are not destroyed but act as a monetary value add, and also an ecosystem-building value add (as mentioned before, depending on the investment parameters for the fund).
Generally, you want double your annual budget to be allocated to your endowment fund and determine a percentage of that as principle v.s. investment liquidity.
Awesome, I must have overlooked this.
I wouldn’t specify low-risk this early on; adding a clause for low-risk without having defined the parameters of your fund may be jumping the gun. I would prefer something like this: a breakdown between low to high-risk investments;
A revenue-share agreement does just that! The caveat is that before being awarded a loan, the team/company must have a viable business plan around their innovation.
Ideally, the lender will work with the team/company to review, revise, improve, and ideally help implement the monetization/go-to-market strategy when the time is right. This is where the whole support/mentorship thing really becomes meaningful.
In other words a revenue-share agreement first awards money, second and only once the ‘business’ / ‘innovation’ has launched (so very flexible timeline) then collects money based on the loanee’s revenue hence revenue-share agreement.
Does that make sense? It’s essentially a more friendly and flexible Venture model that does not take equity (sometimes) > some models can take equity… which later on can become a tertiary source of funding for the Dev fund…but having a non-profit status might complicate things when it comes to equity.)
I respectfully agree and disagree. No one (or very few people) like to sit down for hours and define strategy/metrics. It arduous, takes time, and there are always more pressing issues, always.
An organization, a community, a company, has to be intentional about doing this or it will inevitably get pushed to the side, or be done quickly and uselessly.
An early-stage startup should not spend months strategizing, however, I think ZEC is at a stage now where the time invested will help all stakeholders save a bunch of money, make better decision, learn more from failed projects, and ultimately act as a value prop that builds trust and strengthens the ZEC community like no other.
However, I do agree that a few days is not enough… I reckon it will take at least 2-3 more Google Hangouts and someone working behind the scenes (either from ECC or from ZFND or an external but trusted party (governance board) to pull it all together.)
Over the course of the next 4 years, I’d say the investment it worth it. I’d lean on ECC to get us started. (I am sure ECC - or maybe even ZFND has something like a mission, vision, OKR’s (Objectives and Key Results) that could act as a launchpad).
Maybe it’s not a before Dev Fund decision is made item, but a right after dev fund decision is made before allocating and major funding to anyone…? 
With that sort of incentive, maybe we can hash it out in 2 weeks!
@tromer By the way, I personally think it’s particularly problematic to pre-allocate funds to concrete organizations in a situation where the default is for mining fee based funding to continue in perpetuity. I see less of a problem with the latter if everyone has to apply on equal terms.
Equal terms would make it a generic solution & more likely to be relevant years from now - ECC has a strong track record & abilities so shouldn’t be an issue for them either.
After the new 2019 Advisory Panel list was just released i took the time to went through the list:
2018 Panel: 74 members
2019 Panel: 61 members
2019 Panel: 26 new members
2018 to 2019 Panel: 37 old members are not in the new 2019 panel
2019 Panel: People closely affilated with the ZF, ECC or founders: 21 members (incl. 2 Bolt-Lab Members)
2019 Panel: out of the 26 new members 8 are new members from either affilated with the ZF, ECC and 2 from Bolt-Labs.
I did not include the people from tendermint, cosmos, Monero, Ethereum (foundation), Horizen, other dev teams and previous ZF grant benefitaries and such into any affilated to category.
Not sure if this sounds like “counter balalance”, i leave this to everybodys own discretion.
Yes, it does serve as a counterbalance, especially if it is allowed to grow over time within reason. Other ways to become a Panel member besides invitation can be introduced to ensure easier access. But it should still be restricted to people with proven interest in and track record in supporting Zcash. Coinholder signaling/votes is the place for permissionless access. Again, the way I see it:
ZF board or strategic council (open elections; day-to-day governance)
Advisory Panel (broader community; semi-restricted access; important one-off decisions)
Coinholders (permissionless access; skin in the game; ongoing polling/signalling)
Power can be balanced between the three. In my initial suggestion, coinholders can directly determine one of the board/council seats and trigger the Advisory Panel; Advisory Panel can replace the whole board and serve as the decision-making body in emergencies and one-off situations; board/council can deal with day-to-day governance, incl. dev fund. Anyway, that’s my best shot after reading all proposals and forum discussions. If it doesn’t make sense, it doesn’t make sense.
Just in case: these are all my personal opinions and written down as potential add-ons to proposals by @mhluongo and @tromer which I otherwise like.
Thanks for the proposal Eran. I appreciate the pragmatism of this approach. A couple of questions / thoughts:
Based on the ECC call yesterday, the current ECC monthly burn rate is about $750k. I was curious if the $700k in this proposal was intentional or if you’d be open to adjusting the monthly cap to $750k for all entities.
I’ve been thinking about expense growth for the ECC, Zfnd and other developers. I’d like to pose this question to the ECC in another setting, however I have to imagine that some growth for the ECC (and Zfnd / other devs) is desirable and inevitable after Year 1 of this ZIP. For example, increases in employee related expenses (health care premiums, COLA, etc.) for a static number of employees would likely push the monthly burn beyond the monthly cap. Given that an increase in the Funding Target appears to require a coin holder vote (which may not technically be feasible for some time), I’m wondering if a built-in modest annual increase (e.g. 5%) in the Funding Target might be desirable. I don’t have a strong opinion on the amount (input from the ECC and Zfnd would be great) but I’d like to avoid needlessly slowing progress at either organization for something fairly predictable. It’d be great to hear other people’s ideas on this.
I’m a bit concerned about the management of Volatility Reserve account and especially skeptical of any strategy that involves the large scale selling of ZEC for other assets for investment purposes (specifically in the Volatility Reserve). My fear is that we’re opening Pandora’s Box by having an actively managed Reserve. Perhaps a simpler approach would be to allow the principal developer (ECC) and Zfnd to use excess funds to build a 6 or 12 month cash reserve to cover 6 or 12 months of operating expenses should unforeseen circumstances occur. In the future, additional developers focused solely on Zcash could also be eligible for a reserve based on the same approval process as increasing the Funding Target. Excess funds would then sit in ZEC in the Volatility Reserve.
As an aside, I’ve come to believe that we should avoid development funding designs that effectively require development funding to continue into perpetuity. My dream scenario is that Zcash’s development needs are well funded and we have such a huge reserve that additional funding from block rewards become unnecessary for the foreseeable future. This scenario is probably a low probability outcome and totally dependent on the market and success of Zcash. Call me crazy but if Zcash becomes the de facto private digital store of value, it is plausible that the Volatility Reserve could be 9 figures+ USD. I’d also hope at that time we have sufficient decentralized governance mechanisms to prudently manage this Reserve. While this may be a low probability outcome, I’d suggest that we avoid development funding designs that prevent this outcome altogether. The burning of excess coins or donation to unrelated causes seem to guarantee that perpetual block reward funding will be required. Stated differently, it appears desirable to give the Zfnd, ECC and future funding recipients exposure to ZEC. In the event that ZEC is wildly successful, we may be able to avoid permanent block reward funding (or significantly reduce the rate of funding). If we keep funding at the bare minimum (without a Volatility Reserve or similar mechanism), we’re guaranteeing that we’ll need to keep funding development, likely via block rewards, into perpetuity.
@hameed, thanks for these great questions!
This is a very reasonable point. But increase in operating expenses is difficult to predict (inflation now is just ~2%, but who knows how cryptographic engineer salaries will change over the next few years?..). And we do have a mechanism to increase the Funding Target down the road, if really needed. So I’d rather keep things simple for now.
if the $700k in this proposal was intentional or if you’d be open to adjusting the monthly cap to $750k for all entities
ECC’s expenses have fluctuated around $700k/month, sometimes dropping below it. Some people have called for “streamlining”. Conversely, ECC has made attractive plans that would call for $1.1m/month by its estimates. So this is really hard to calibrate… I’m picking $700k/month as the number floated around most commonly in ECC’s communications and community discussions, and leave it to the adjustment mechanism to increase it if needed.
I’m a bit concerned about the management of Volatility Reserve account and especially skeptical of any strategy that involves the large scale selling of ZEC for other assets for investment purposes (specifically in the Volatility Reserve).
Perhaps a simpler approach would be to allow the principal developer (ECC) and Zfnd to use excess funds to build a 6 or 12 month cash reserve to cover 6 or 12 months of operating expenses should unforeseen circumstances occur.
We learned, the hard way, the importance of hedging the enormous volatility of cryptocurrency markets. ECC has been pursuing essentially a minimalist selling strategy akin to what you recommend, and consequentially mostly missed out on the huge price spike of early 2018. Had it sold more ZEC then to build a larger USD reserve, maybe we would not have needed the extra Dev Fund now.
So I definitely want ECC’s and Zfnd’s financial experts to have the flexibility to prudently plan for the long term, and — if feasible — ensure a long operating runway or even (as @ttmariemia pointed out) attain a sustainable endowments whose investment income funds operations.
Following great discussions with @mhluongo, @ttmariemia, @mlphresearch, @mistfpga, @Autotunafish, @acityinohio and others, and in light of the above ad-hoc polls, I made several changes to my proposal (above and in Git).
Most significantly:
And also:
If you’ve made some other suggestion to me, and I haven’t explained why I don’t follow it, then I probably dropped it accidentally and please remind me!