I believe Thesis was one of the contenders but @mhluongo has been silent recently
Yep, we’d like to start work as a major dev team — I’ve suggested our priorities and vision for the work in another post on the forum.
We very much still want the position, it just hasn’t been clear how best to engage with the Zcash community while the MGRC bootstraps.
In fact… here’s the proposal from nearly a year ago. If the community is ready for us to re-engage, we are!
great to see you back on the forum @mhluongo. I think it would be beneficial for the community to compare & contrast the above Thesis proposal with ECC + ZF roadmaps/capabilities in order to gauge how Thesis can be complimentary to the ECC & ZF work.
Some first thoughts for community to consider:
-is something like tZEC valuable in contrast to wZEC that has centralized custody?
-does the community want/need a GO implementation?
-can the ECC/ZF push forward user defined assets on Zcash themselves?
-is 25% of dev fee too large of a slice for the proposed work
also I feel that even if ECC/ZF can implement items in the Thesis proposal, the community needs to consider the value in having Thesis do those in order to take said items off their plate to focus on other items in the roadmap.
I like incentives used in a competition.
I like the idea, on a theoretical level.
If there is a consensus for this new team, I would prefer to have them focus on a second algorithm so that each team can verify the same transactions and the miners can choose which chain they support, taking the most decentralized approach to development as possible so developers did not have a platform to argue, just a platform to compete, side by side, block by block.
I would be opposed to 2 teams working on the same road map, but I would not be opposed to 2 teams making a unified road map to scale a competitive environment for cross chain interoperability between 2 blockchains that both exclusive mine Zcash.
I’ve done some thinking today about what you’ve said, @mistfpga, and spent today reviewing the history, and rather than continue on with my objection that you understand, if youre interested, I’m curious what you think of a perhaps half baked solution. My contention is that power in the network is too heavily entrenched with the ECC, and the ZF has proven not necessarily a conduit for appropriate decentralization. If you’ll permit me to ask you to accept the conclusion that the MGRC team is not sticking to the ZIP, and that the MRGC and ZF does have the autonomy to be creative with its role, how about setting a large portion of the MRGC allocation to the creation of a company to compete with the ECC. I think rather than ragtag grantees that have siloed projects, we create a structure to house developers who can work more constructively towards projects and create cohesion and a home for them in zcash for the long term. This equally will perhaps have the benefit of wrestling away the keys of developer control over the project. Thoughts? (is it possible to just buyout gitcoin – partially kidding)
If by “compete with the ECC” you mean doing valuable things that ECC hasn’t done, or doing specific things better than ECC, then yes, of course:
If a suitable team gathered and made a well-reasoned proposal in this spirit, then I expect the MGRC to consider it favorably.
Do you have specific directions/suggestions in mind, for such a proposal?
@tromer, if i remember correctly, you’re the godfather of the current governance and allocation scheme, so your voice here is far more important than mine. i’m mainly just concerned about what could happen 4 years from now if the power structure stays the same.
i assume that the current people who are best experienced with the source code are bar none ECC but then those who have been issued grants or have done per diem work. should there be an interest in joining together those people, they would probably be the first place to look.
I am happy to discuss this and your other points, but this isnt the best thread. if you start a new thread I will post in it.
How are we left to wonder? It says right at the beginning of ZIP 1014:
This proposal describes a structure for the Zcash Development Fund, to be enacted in Network Upgrade 4 and last for 4 years. This Dev Fund would consist of 20% of the block subsidies, split into 3 slices:
- 35% for the Electric Coin Company;
- 25% for Zcash Foundation (for internal work and grants);
- 40% for additional “Major Grants” for large-scale long-term projects (administered by the Zcash Foundation, with extra community input and scrutiny).
Governance and accountability are based on existing entities and legal mechanisms, and increasingly decentralized governance is encouraged.
This is the text of the document that was ratified through more than a year of conversations, plenty of which are on this forum. I have not seen any deviation from this ZIP in the execution of MGRC with ZF’s support. Can you point out any specific deviation?
Which part of ZIP 1014 or the conversation around it is not being adhered to?
First, how is your proposal different than what the MGRC is already slated to do as per ZIP 1014?
I’m not a lawyer, but I don’t see why a grant recipient couldn’t be a pre-existing company, or establish a company to carry out a grant application.
Second, what do you mean by “compete”?
MGRC and ECC have separate funds, and in fact that provides direct incentive alignment. There could be competition or divergence of vision, and the more discussion around those alternatives, the better for Zcash, IMO.
There could be MGRC grant recipients who aim to do A, while ECC aims to do B where it’s impossible to do both A and B. I expect for most plausible scenarios, though, there will be plans for X and Y and it’s possible to do both, producing more value for Zcash.
For example, the Thesis proposal involves making the Zcash network a privacy hub for other assets like BTC & ETH, while ECC is focused on scalability & light wallet improvements.
So as far as I can tell, MGRC is already capable of doing what you’ve proposed, and is also following ZIP 1014. So far I have yet to see any substantive claim that there’s any deviation from the ZIP.
at first it looked like a good idea
in second thought its better to have many small teams doing specific projects