What? This is entirely backwards. ZIP 1014 defines a fairly narrow role for the MGRC (quoted above by @dontbeevil ). That was what people voted for, and there’s no reason to believe they voted as if the ZIP said something else.
That is also my interpretation. (As @Shawn points out, ZF can invest its share, subject to its 501(c)(3) requirements. The role of the MGRC, on the other hand, is purely to decide how Major Grants are disbursed. Recall that we had a big discussion about whether the MGRC should have more autonomy as its own organisation; that was voted on and the conclusion was no.)
There’s nothing in ZIP 1014 requiring awards to kick in with network upgrades. You might be confused by the wording that allows direct payment of grants to recipients as funding streams (without changing the overall amount of the MG slice). That’s entirely optional; the recipients can instead be paid from the MG funding stream (and until NU5 at the earliest, they would have to be).
You were pretty clearly talking about investments other than grants. That is not within the scope of the role that ZIP 1014 gives to the MGRC. It’s in the name as well as being implied by the text of the ZIP: the MGRC is a grant review committee, that’s all.
i want to see MGRC operate as an aggressive proactive organization that invests in teams/companies. we should have 2-3 ECCs, we won’t get there if we just sit back and wait to evaluate random proposals like ZF does, imo. there’s nothing i see in ZIP that disallows MGRC to operate in a proactive fashion. do believe steve/dontbeevil were talking about stewardship over MGRC investments. that’s valid, and should to be discussed further.
nothing in that ZIP prevents MGRC from operating in a proactive manner.
don’t vote for me if you want to see MGRC built into redundant bureaucracy that accomplishes little. only vote for me if you want to see MGRC operate as an aggressive proactive organization that takes zcash to the next level.
you think it would be a good idea for MGRC to operate as a redundant bureaucracy (do the exact same thing as ZF)? future of zcash will sit on MGRC’s shoulders. should the future of ZEC ecosystem be decided by hoping for a great proposal to be offered? what if no interesting proposals are offered for months on end… should MGRC sit on their hands, and hope for better days? have doubts the community really wants that.
respectfully, it is not redundant or a bureaucracy, it is a democratic check on the foundation by community members who are presumably appreciable zcash holders. it gives the notion of a “community” politicial legitimacy.
My understanding is that “grants” can, and very often do, carry terms and conditions. As a random example, ZIP 1014 does specify the constraint that:
All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license
It’s fine if the grant terms also include things like profit-sharing, regardless of whether this starts overlapping with the concept of “investments”. And it’s fine if the review committee weights this in their decision. This is why ZIP 1012 used the same “grant” terminology but also explicitly allowed investment-like grants. Unfortunately, ZIP 1014 removed that clarification and left us here to interpret an ambiguous concept…
Also, to the extent that the phrasing is ambiguous, we could look at the community’s expressed intent. I recall a lot of support for the idea of allowing investment-like grants, and no expressed objections other than “quantitatively it’s not likely to be a lot of money, so let’s not rely on it”.
No not at all. I am not too sure what lead you to think otherwise. The ECC plays a vital role in the zcash ecosystem. The idea of the zip is to get new companies involved so zcash in not reliant on the ECC.
Currently the tech hurdle is the biggest barrier to entry for teams that want to start working on zcash. The principle of the zip is to find these teams and get them to benefit zcash, now and in the future. The ECC doesnt just do development. They have been key in every part of zcash. It is unlikely to find one team that can do the whole thing, but a few teams, sure. It is very possible.
I also think there is room for improvement on some of the ECC’s efforts - certainly in an area such as outreach a specialised company or two could go a very long way to helping improve things.
Am in full agreement that the MGRC should expand beyond grants to include bounties, prizes and investments. Thus far in crypto, we have seen many bounty and prize programs work better than outright grant programs. Claiming that we can’t do this because we chose a poor name to begin in “MGRC” is short-sighted and attempting to ossify too quickly.
We need to manage and grow this pool of capital so that it can help Zcash over the coming decades, not 4 years, and partially using some of the capital as investments, where the returns flow back to the capital pool, is the way to do that. As @alchemydc points out, it’s commonplace for non-profits to invest to be able to continue allocating capital for years and decades to come.
Investing prudently while earning a reasonable ROI with one’s own money is difficult enough. I’m not sure it’s a wise idea (for the moment) to have the MGRC given the option of making investments which can help or hurt the Zcash ecosystem.
To add to this, there are indeed non profits in crypto that have an investment arm dedicated at projects that will help build that cryptocurrency’s ecosystem. The best example that comes to mind is the Interchain Foundation. As you can see here, they have various funding types. From what we know about past funding at the ZFND, there are definitely projects that can go into a service agreement (e.g. ZEC Wallet) and grants. Investments should be made, however, I believe they should be rare. If a company/project gets $100K+ in funding, considering an investment option doesn’t seem bad. That amount of money is usually what VCs would give during a pre-seed/seed round and I suspect that MGRC will serve as the pre-seed round for many companies/projects eyeing the Zcash ecosystem.