ECC Opinion on the Dev Fund

Governance
1

I am hearing confusion about my and ECC’s opinion on whether or not there should be a new development fund. A few things are being conflated. I’ll try to pull them apart.

There are two primary questions:

  1. Should there be a new dev fund?
  2. If the community wishes to create a new dev fund, what should be its structure?

Should there be a dev fund?

ECC would welcome a new dev fund, but we are also ready to accept that the community might not want to create one

If the community wishes to create a new dev fund, what should be its structure?

Two structures have surfaced:

a. Embed organization’s addresses the protocol and allocate some % of block rewards to them.
b. Create a grants pool where anyone can apply to receive funding.

We believe that (b) is the superior option. The rationale is documented in our blog post. We believe in this so strongly that we have decided to refrain from receiving money directly from the chain in the long term. I suggested a possible grants-based model, but it must still be sufficiently vetted to write a formal ZIP. I’m still working on that, and if you support the idea, I would love to partner with one or more of you to complete that work.

If we wish to start a new dev fund this year, the community must make a clear decision within a couple of months.

Therefore, I propose that the community consider extending the current development fund by one year and turn our attention to developing a new grant-based structure to be launched in late 2025.

5 Likes
2

What do you think about sending all block rewards into the ZCG, and letting them continue to function as-is?

(Is the ZCG legally able to give grant funds to the ECC or ZF under a new block reward model, which doesn’t directly fund ECC or ZF via protocol coded addresses?)

Is your vision about a new grants based model being needed, an implication that ZCG isn’t capable/ able/ willing/ knowledgeable enough/ ecosystem-inclusive enough/ staffed-compensated enough/ etc to serve as a tolerable solution?

4 Likes
3

I don’t think “as-is” works. But I am not implying anything about the current ZCG team.

Under ZIP 1014, ZCG was originally intended to be a Major Grants Review Committee.

"40% for additional “Major Grants” for large-scale long-term projects (denoted MG slice)."

"This slice of the Dev Fund is intended to fund independent teams entering the Zcash ecosystem, to perform major ongoing development (or other work) for the public good of the Zcash ecosystem…"

"Priority SHOULD be given to Major Grants that bolster teams with substantial (current or prospective) continual existence, and set them up for long-term success. "

I think the original spirit of the MG structure fits, but I’m not sure it’s been operating this way over the course of its history, or necessarily should moving forward.

This provision will be an issue if it is a single dispenser of funds: “There should not be any single entity which is a single point of failure, i.e., whose capture or failure will effectively prevent effective use of the funds.”

I think we that is why, in part, the community needs a k/n multisig, with direct community involvement, and I respectfully submit that my proposal linked to above is a more robust and resilient option.

2 Likes
4

What about prefunding 90% of expected cost for critical major grant projects.

  1. Deprecated ZcashD
  2. ZSA -
  3. Stablecoins
  4. POS
  5. Programmability
  6. Maintenance of one single wallet-Zashi; the others are on their own until critical projects prefunded.

A rolling two year pipeline should always be prefunded. Then the excess (after prefunding) can be saved or have a little more flexibility; subject to board or voting. So the grant committee would not have much if any decision making ability with regard to major grants in the pipeline; and prefunding ensures the grant committee does not waste money and that the critical projects will be funded.

The grant committed should be more of a “project management” role. So highly skilled people who can call “bullshit” when the grantees are not performing as expected or ask for more money relative to what has been delivered.

Ultimately the community needs coin weighted voting to vote on a major grant pipeline.

1 Like
5

Thanks, and I agree with the general description/ proposal. (Didn’t mean to suggest anything personal of ZCG either, just the question of size/ scope/ and whatnot).

More grants, more voices in the process, more transparency about who, what, when, why, and more grant throughput can all help move the project ahead faster, and likely with better focus along the way.

2 Likes