The closest I’ve seen is @mistfpga’s idea to “extend” the supply curve rather than burn. I personally want to avoid donations to a centralized org or anything that could be seen as political, as I see this mechanism as “close to the chain” – if it were easy to accomplish on-chain without a bunch of consensus work, I’d prefer the allocation were made smaller rather than any entity burning or doing anything else with the proceeds.
Today’s noble cause is tomorrow’s villain, so we should avoid specifying outside orgs to receive donations at this level IMO.
I went in the opposite direction here, intentionally. I’d rather leave the Principal Dev the ability to hedge against future proceeds, etc, and give the ZF a “bad faith” ripcord to pull to end the Principal Developer’s allocation.
The sort of restrictions I’ve seen proposed can always be subverted, and seem to obstruct some responsible decisions the company might want to make. Better to avoid detailed overspecification and instead focus on the happy path, with a remedy for extraordinary situations.
I like this a lot. On the other hand my hope here was to make sure this seat was conflicted out in any discussions around the Principal Developer’s allocation or performance… is that still achievable?
I’m open to suggestions here. The research advisory board was an effort to have a place to “put” all of the technical advisory talent that’s working with the ZF, maintaining a formal relationship and an opportunity for governance participation. I left a lot as an exercise to the reader here. Thoughts on how we could achieve better first-class representation of research and technical interests on the board?
Heh, I should’ve mentioned that I expected a transition plan from the ZF in the proposal. Looking for a good spot to drop that.
I like your take after a couple reads – if we align on this proposal I think it could lightly formalized and included. In the meantime, I’ll try to make transition expectations more clear in the proposal, likely under “non-requirements”.
Thank you @mhluongo for your contribution (and for the shout out), it was a great read! I like it.
I’m going to comment via other’s comments first as some of my own initial sentiments have already been expressed.
Question, @mistfpga would this not reduce the value accrual of ZEC over time? Basic supply/demand economics, halving typically drives pricing upwards, if we put back ZEC and extend the next halving, wouldn’t that contribute to a slow growth?
I disagree, I think this is pretty feasible in the short term, conditional that ECC agrees to receive 1/3 of the remaining 20% dev fee (i.e 25% of the 75%)
and that ECC agrees to solely work on ZEC - two conditions which I glean have been a strong point of contention for ECC.
I’ll refer back to my proposal - I agree that this is a gap in @mhluongo’s proposal.
AUDITABLE METRICS
The Zcash , Zcash Foundation, and ECC must work together to develop and achieve consensus on auditable metrics that:
Show quantitative value to the ZEC economy
Track against the strategic roadmap
Can be measured and audited by anyone
Allows for flexibility in terms of failures, pivots, and adjustments
The Zcash Foundation will contract or hire[4] an individual(s) with the proper pre-requisites (background in blockchain, data, analytics, and design) who will solely be responsible for working with the Zcash Foundation, Electric Coin Company, and external developers to:
working with the community to define and communicate auditable metrics with product developers (i.e. ECC and external developers)
communicate with the Zcash community and host live votes
consolidate and publish voting results, feedback, and suggestions at a defined time interval
host Quarterly hangouts for discussions
The independent authority who will be responsible for ensuring the legitimacy and validity of reporting will be the Zcash community .
Moving along…
I also agree that there is another gap, @mhluongo, in terms of how to fix the existing grant funding mechanism.
I had a few ideas, but they did require more of a governance procedure/ application… @mistfpga on-chain governance was out of scope for @mhluongo proposal, which makes sense to me. It may be a phase II item: Priority #1 figure out how to allocate funds Priority #2 figure out how to manage fund disbursement and metrics Priority #3 figure out decentralized decision-making applications (both on-chain and off-chain)
With a dedicated team and active community, I’m hoping that a lot of ground on these three priority items can be covered in 1 year’s time.
@mistfpga you lost me here. Isn’t the point for the teams to 1. get funded and 2. build/ implement the ideas
On this, @mhluongo there’s a gap on entry-level participation for teams and/or individuals to begin to learn the code-base. Your 75% Dev Fund mirrors my Endowment Fund, but my ‘Zertilizer’ attempts to address flaws within the existing granting mechanism. Maybe there’s a blended approach that could be explored?
I think it’s a well-balanced meritocracy due to the inherent veto abilities of the network:
and the structure of the ZFND board, as proposed:
I am a little concerned about this:
@mhluongo could you explain to me why a team could receive Dev Fund money but also be justified in not working on ZEC?
Things I really liked with this proposal:
It’s well balanced between addressing short-term, immediate needs and nodding to longer-term governance
It proposes a roadmap to inclusion of external developers (despite not necessarily addressing the current issues with grants)
while also preserving stable funding for the principle developer (aka: the ECC)
It’s clear, actionable, and able to implement immediately.
It moves ZEC towards a Meritocratic and more decentralized governance structure
Things I would like to address:
It’s fully dependent on the 20% fee from miner’s rewards, I’d prefer a blended approach (like my endowment mechanism) to hedge against risk (aka: temporary reduction in ZEC value and/or hash rate.)
It does not address how metrics will be determined and by whom and how much weight they will carry in decision-making.
It proposes a Burn Rate
More on Burn Rate
Burn-rate seems like a misalignment of incentive. Metrics, roadmaps, and milestones should keep stakeholders financially responsible and accountable.
Using burn rate to ensure financial responsibility can be uninspiring and thus hamper motivation which can drive developers to other projects which do not cap their return on time/ effort/ capital investment.
If a burn rate is nonetheless decided upon, I’m against discarding the coin. I’m also against moving the halving, as suggested by @mistfpga. This is probably crazy, but I rather distribute the burned coin to all ZEC holders (yeah, even if it’s only fractions) and encourage the network to hold on to them.
And would like to eventually see ECC compete for Dev fund allocation like all other principal developers - something like my Equity fund proposal whereby a track-record of excellent work can make eligible an external team to apply for that 25% reserved for the principal developer.
However, I do disagree here:
I think the suggestion of eligibility around a CFO is fantastic and I would actually extend it to all applicants, with a caveat to make things less onerous, that the requirement of a CFO is only triggered at a certain level of funding.
There are a few comments/threads that I’m still working through- and that some of my questions/comments may have already been addressed- but I’ll continue to post along as I get through the rest of it.
@mhluongo, can you please clarify whether the Foundation would be allowed to use its 25% of the Dev Fund to conduct in-hourse R&D work, as it’s currently doing?
The phrasing above implies, by omission, that the answer is no. You seem to have confirmed that here, but then denied it here, and did not respond to my question here, so I’m confused…)
Also, can you clarify what is the intended difference between the two kinds of 3rd-party funding: “short-term development grants” coming from the Foundation’s 25% of the Dev Fund, versus the other 50% specified in the following?
(50% of the total), called the “outside development fee”, shall be distributed between at least two development teams, chosen semi-annually by the Foundation
(Recall that most Foundation grants are already on a time scale of half a year.)
Lastly, revising an earlier question:
ECC would need to cut down its expenditures from the current ~$700k/month to ~$200k/month, i.e., cease most activity.
There are a number of ways to address this. The ECC could split into two entities and net $400k / month, for example. It requires a little imagination, but using the ECC’s current burn as the sole number to optimize for here is putting the cart before the horse.
ECC’s current burn rate is the best factual indication we have, at present, for the amount of funding needed to do the corresponding work. This is not gospel, and you can cast doubts, but the onus is on you to argue with this factual information, because by default it is reasonable to assume that reducing funding from $700k to $200k/month will cause great harm.
If you doubt it, please make your case. Do you believe there are ways to do the same work as ECC more efficiently, or that some of ECC’s work is not needed, or that ECC can be broken up without harming its productivity? How?
Frankly, I find the attitude here to be dissonant. On one hand, we have plenty of factual data on ECC’s burn rate and work, but this is dismissed offhand (“requires a little imagination”). Conversely, without any factual information, the proposal allocates at least twice that amount to unknown new independent parties, that will be doing god-knows-what, with heaven-knows-what-teams, in faith that this money will be better utilized.
I’m all for decentralization, but not for cutting off limbs in hope that better ones will grow out.
I’m not sure I understand this. Could you please provide a little spreadsheet-style table showing how much USD-worth of coins the Principal Developer would get at various levels of the ZEC coin price?
Im a bit sick at the moment. So I will try to keep this brief.
agree. I think that the algo taking care of the distribution is best. there are several mechanisms I have thought of that don’t require much fiddling to get working, it is just picking which suits. I will post my burn thread in a bit, when I feel less sick.
No, I cannot see a reason why [I know nothing of economics]. burning coins effectively drives total issuance down and the emission supply down (and maybe the rate up, but that’s the same as total issuance down isn’t it? idk. I cant think properly)
I think taking coins out of circulation is a bad idea. extending the halving or tail emission is a simpler task, and makes sure ~21million are issued to spendable keys.
It only puts back the halving by the number of “burnt” coins. If the halving block number schedule is imperative then put it on the tail end of the emission, there are no rules for that, just it will end eventually. I will elaborate more in a separate thread.
This just seems like such a big chunk of money to take away from the ECC, can they realistically keep the lights on with that amount of funding? I do believe we need to transition to a model that allows the ECC to develop other revenue streams and bigger “full chain” or whatever its called, development teams to enter the space.
They either have to be replaced entirely buy… idk, I have yet to see a proposal from any company that says what they would do with the funds, just proposals that say funds should be allocated in a certain direction. (which is cool, but if the ECC is going to be replaced I would really like to see concrete development plans from these teams and be able to evaluate them myself before cutting out the ECC completely - The only people I can really see who are able to judge this is the zfnd. we have what has been promised and what got delivered, but these two things never match up - feature creep and unexpected things always make stuff changeable, so id love to hear how the ECC thinks they have done.)
The ECC’s lack of position on this topic is frustrating, but they have laid out a plan and a cost base. To be fair I cant really see them being able to stay open if the price stays this low. that makes me sad.
I will start a separate thread about this. Someone else asked me to do this too. I think it would be better in its own thread. as not to mess this one up.
No, this isn’t about teams for me. It is more trying to get the open source feel back in. I will expand on this in the new thread. but the essence of it is to allow “contractors” to work on the protocol. after they have done the work. I guess the best likeness is bounties, but no one asked for the bounty.
The issue I was trying to highlight is if xyz comes along to and says, “I think this is a great idea, I have already started to implement it, will you pay me?” the company could just say “no, we are already working on it” - when they were not. this pushes out people with the skillset to add to the community from tailoring it to zcash, their is little incentive.
That’s all I was trying to get across. If a big company can get paid, can they assure that individuals cant too?
Im going back to coughing.
if this seems a little odd, blame the bottle of cough syrup.
Confirmed, in-house R&D is fine. The balance I’d like to strike is this
Eventually, the ZF should hand primary maintenance of zebrad to another team, as there’s a soft veto power distorting this system- and spread development efforts across clients.
The ZF should take care to not discourage other dev fee recipients with their choice of work.
I’m not trying to stop R&D at the ZF, I am trying to focus it in support of a strategy chosen by the client teams.
Indeed. Dev fee funding is worthwhile for longer-term efforts, and is meant to attract longer-term talent. The funding isn’t less strictly scoped to deliverables, and is suitable for work like building and maintaining an entire Zcash client and other ongoing concern in the ecosystem. Recipients of this fee should be party to setting strategy for Zcash as well as execution.
To make this concrete, I’d like to see this funding mechanism draw a client team from Ethereum, Tezos, or another full-stack team of similar skill to make Zcash a priority.
Compare this to a grant, which has a scoped deliverable. If it helps, you could think of this as a “fellowship for dev teams”.
I’m struggling here. I’d personally rather focus on moving forward, but as someone quite familiar with software engineering, of course I believe we could get similar results more cheaply. At bare minimum, by focusing on the things that matter most, and doing less.
I appreciate that you’d like me to pitch an alternative to the ECC rather than a structure, but as I’ve said, I don’t believe comparing companies is appropriate at this phase. We’re talking about governing a cryptocurrency for the next 4 years, and bringing it back to “which company is better” is… well, it’s backwards and demonstrates the problem.
We need to build a robust, decentralized ecosystem. To me that’s a given – this is about values. If we disagree here, I’m not sure we can have a productive conversation.
Certainly. Split the ECC into research and execution components. Have the research component act as the Principal Developer. A separate entity can take on all engineering and marketing work currently done by the ECC, and maintain zcashd. Make the second entity a 25% recipient of the dev fee.
The entities now get $400k / month, under a strong accountability regime. If the execution-focused entity needs more funding, it can work outside Zcash. Outside developers can compete with the execution-focused entity, and the ZF can decide allocations periodically.
can be broken up without harming its productivity? How?
A decentralized governance system will be slower than a centralized one, but it will move forward with greater community interest, public buy-in, and public support.
You might want to check your priorities. A centralized privacy coin will eventually be challenged, and destroyed. I’d like to see Zcash survive long-term, against powerful antagonists, and this attitude won’t cut it.
Yes! If you’re at a point where the idea is so fleshed out that you’ve actually started implementing it, and it is indeed a great idea, then you’re in great position to apply for a Zcash Foundation grant!
And since the Foundation explicitly strives for diversity and decentralization (e.g., the “zebra” node), it’s fine if ECC works on similar things.
Absolutely! I was rigid here to help fight the monopoly we currently have, which I believe has some negative secondary consequences. I have no issue with eg the folks at the ECC splitting up and taking all of the dev fee, so long as they’re economically distinct entities.
Allowing competition means allowing competition to grow, and I think we need an active constraint against today’s “monoculture” to support that.
I agree with you, and I tried to leave a bunch of space for the ZF to introduce a transition plan or otherwise adjust their board structure (eg by binding the free seats to other community votes). They have that latitude today, so I see this as a starting point
Data point: when fellowships were discussed in the context of the prior grant program, there was a lot of resistance from community members and within the grant review committee to giving such carte blanche funding (even on a much smaller scale). Strong sentiments were expressed in favor of deliverable-oriented funding. Note that the committees did not have anyone employed by ECC or Zfnd, and did have people from other communities (Ethereum, Cosmos etc.). We did end up awarding some fairly open-ended grants, but only as a tiny fraction of the total budget.
The proposal at hand would go against that, by forcing at least two thirds of the funding to be carte blanche “fellowships”. Moreover, it would force such funding regardless of how the merit of those fellowship-seeking teams compares to that of worked-out, well-reasoned, deliverable-oriented proposals.
Split the ECC into research and execution components. Have the research component act as the Principal Developer. A separate entity can take on all engineering and marketing work currently done by the ECC, and maintain zcashd .
This is infeasible. The people doing research at ECC are the core cryptographic engineers that are also maintaining zcashd, protocol specifications and critical libraries. Similarly, the marketing and engineering are closely intertwined (e.g., outreach and hand-holding of ecosystem developers).
Most proposals on the table now fund the ECC the same way. All this proposal is doing is bringing multiple interested parties in to compete for the privilege of serving the chain and coin holders. I disagree with the “carte blanche” characterization, as it’s the role of the ZF in this proposal to do diligence and hold recipients accountable, but if you believe that characterization is correct, are you also against any proposals that fund the ECC without detailed grant-writing for all of their efforts?
There’s nothing to stop two separate entities from working closely together. I’d be interested in why you believe cross-entity collaboration is a non-starter
Excellent point. Indeed, I and others have said many times on this forum that ECC should explain its strategy and plans going forward. Several of the proposals explicitly include this element. I think it’s healthy to think of this as a “grant application”, to be judged either by the community as part of the Dev Fund decision, or by a higher-level governing body (in the proposals that have one).
As you already recognize, ECC does have a special role and track record, making flexibility and discretion easier to justify. Still, I would agree that many of its activities could have been funded by deliverable-oriented grants. The difficulty is: grants awarded by whom? The only body we have with the requisite structure and expertise is the Zcash Foundation, and for the sake of decentralization, we probably don’t want to put ECC’s funding completely at the discretion of the Zcash Foundation. And so we’re forced to compromise on this point, whether by giving ECC a carte blanche to execute its “grant proposal”, or by instating key-performance-metrics consensus mechanisms for incentivization (as in my idea, that got integrated into @acityinohio’s proposal).
Neither of these special circumstances arises for the hypothetical new teams, so ECC’s situation does not reflect on whether those should receive fellowship/carte-blanche funding.
It’s also worth mentioning – there’s no reason the ZF can’t have a much higher standard for anyone accepting a dev fee allocation than what I’ve outlined so far. This proposal isn’t meant to limit the rights of the ZF (except of course where it explicitly does), it’s meant to provide a structure that’s amenable to community participation, failover to a rougher crypto-native consensus in case of hostile intervention, and to encourage longer-term participation by professional development teams.
The board could certainly iterate on a legal accountability framework that’s consistent, but further reaching, than this proposal. In fact I’d hope it does.
EDIT: The only edge case I think this point calls into question is how to enforce a “use it or lose it” type structure on the 10% outside dev fee allocation.
@mhluongo, so the Foundation would be allowed to make those “50% outside devs” funds be deliverable-driven grants/contracts? Well that changes the calculus [1], and allays that concern of mine (and the past grant view committees…). But then, going back to my original question — it becomes unclear what’s the difference between the 25% grants and the 50% “outside devs” funding.
More importantly, I’m still struggling to see a satisfying answer to the following. Consider the following possible scenario:
ZEC stays around the current price, so about $600k/month (75%) are available to the “big” developers.
ECC gets just $200k/month and is starved, but cannot be broken up (yes, you think it can be; based on deep familiarity, I disagree).
Not enough good new teams show up with good proposals to use $400k/month (at a level of efficiency close to ECC).
Then what? Do we waste the Dev Fund on bad teams, or burn it, or save it for later? While ECC is forced to fire most of its employees and halt most development and outreach?
I’m especially worried about this scenario because it’s not a remote hypothetical; it’s the default if your proposal is implemented.
[1] Could you please clarify this point in your proposal? As well as adding “development” to the list of things the Foundation can do with its 25%?
(To be clear, I don’t mean to imply anything about your team. I have no idea what’s your team, and even assuming it’s wonderful, whether it can productively use $400k/month.)
Hello, that there really are no teams that can work for $ 400,000 per month? I think that you can do a lot more for this money than is done now, because the team’s work is not just getting wages but creating a product, the product is not ready as it was thought, what should I pay for?
A budget of 400 thousand a month or 4.8 million a year is a tremendous budget, which products you think can cost so much money while the product loses its price weekly, in this case the offer is correct, there are no teams for that kind of money, you need to find or create it, otherwise that now it’s just salaries (huge) in terms of efficiency.What is the effectiveness of ECC in your opinion? What cryptographic project does the same but for high salaries and continues its work (in your opinion)?
In my opinion, if you leave deductions from the block, then at the level of 3-5%, and the team should work for this money, there is not enough finance, try to develop the project with an increase in cost (yes I remember that price is not a priority, but because it’s simply not it makes sense that you can not pay attention to statements), this is how business works, and now that it’s just a repetition of history (we had money, we spent it, now there is no money and we won’t work). Leave them at 20%; there will not be enough of them either, there are no further plans, what is the point of not setting less and doing what they would do when 20% ceased to be enough.
I’m open to other solutions. The important component here is that the ZEC goes “elsewhere”, and that the “elsewhere” is widely and fairly distributed (rather than eg a donation).
probably not, looking at the spreadsheet response , it’s not only about enough but it’s also about price fluctuation and the ability to a team to focus despite market fluctuation- especially this market.
Burn coined could also contribute to an Endowment fund… I wonder if there’s little enthusiasm about this because it’s too traditional finance?? or because people don’t think it would work?? or I’m missing something??? but I’m really uncomfortable with all funding being based on ZEC miner’s reward…It’s high risk and offers no stability/ diversification
I think you make a great point on ECC’s quality / eligible replacements. You can’t have competition without competitors.
