CC Fund: expenses, responsibilities, spending guidelines and follow-up processes

Governance
53

First of all, thank you for writing this very nice and clear summary of financial status. I really appreciate all the work and efforts you put into it.

Since I have the chance to have my voice heard on this, I will repeat what I have already communicated at least once during various meetings.

I am a strong advocate of bounties, but I don’t believe in the bounties system we currently use. The “apply for funding” model is not an effective way of funding projects for ツ community.

Before I dive into solution I advocate, few words about my experience with grants both as receiver and elector. In 2021 I received a grant from MINA Foundation for participation in their zkApps builders program Meet the zkApp Builder — Marek Narozniak | Mina Protocol, later in 2022 I built client-side zero-knowledge a smart contract generator application called “MAC!” mac.sqrtxx.com on behalf of the “zkIgnite Cohort 0” grants program and finally, in early 2023 I was working as an elector, helping to distribute grants for zkIgnite Cohort 1. I distributed around 16K US$ worth of vallue among various smart contract projects.

Given the above experience, here are my thoughts on how we could improve how funding works for ツ projects.

The biggest and most significant problems are:

  1. Reviewing grant applications,
  2. Estimating if those are reasonable,
  3. Mentoring / reviewing the work done, keeping track of it, managing it,

Currently, the Community Council is using the regular funding scheme, under which one applies for funding, describes the project, council votes, locks funds, then work is done and funds get disbursed.

Solution 1: Retroactive grants

This is an alternative way of funding, it is more resource efficient and suitable for all the small projects. It is also practiced at MINA Foundation and works more or less as follows:

  1. Someone does something, could be even very small like write a blog post, make a meme or fix a bug in the wallet.
  2. A grant period gets opened, could be yearly, quaterly, monthly, weekly… Users who found something cool that was done can nominate the receiver for a grant. Someone could also nominate him/herself.
  3. At the end of the period all the nominations get reviewed, adequate amount of funds gets locked for the grantees.
  4. The grantees have certain amount of time to pick their prize.

Why is it more efficient? There is no point (3), no mentoring, no managing. Work is already done, it is easier to estimate the resources that have been spent rather than estimate resources that need to be spent (if regular grants are used instead of retroactive grants).

Solution 2: Hire community electors and mentors

This is more resource costly and also difficult, but suitable for funding bigger projects such as potential ツ-based start-up company. Full disclaimer, I also “steal” this idea from MINA Foundation as myself I was hired as an elector for zkIgnite Cohort 1 incubator program.

The role of electors is voting on grants distribution. The role of mentors is reviewing the distributed grants if they are spent according to the plan.

It works as follows:

  1. Grant period gets announced.
  2. Sufficient amount of time in advance job offers for electors and mentors are announced. Preferably to community members who have adequate background to serve in such a role.
  3. Grant applications are submitted by the deadline. Electors review it.
  4. There are multiple rounds of voting, each elector has certain sum to distribute. The last voting is final. Between the voting rounds meetings are organised to discuss the proposal, in a similar way as ツ CC meetings are arranged.
  5. The funded proposals get publicly announced.
  6. Teams that have been awarded are beginning their work. They have regular meetings with mentors who review their progress and write reports on that. Based on those reports the grants are distributed, either later, either during the work (for example to cover expenses such as server infrastructure costs etc).
  7. At the end the program final work is being reviewed and locked funds are disbursed.

The process described above has a potential to become decentralised.

My experience with ツ bounties

I would also like to share how our process affected myself. I personally applied for a bounty regarding the Telegram bot.

I nearly completed my work, I was already at the stage of running a prototype trying deposits and withdrawals, but due to bug in the core wallet API Owner API finalize_tx responds with Fee: Missing fee fields error · Issue #635 · mimblewimble/grin-wallet · GitHub I could not complete my bounty, not without redesigning most of it from scratch and dropping some of the features.

If this was a retroactive grant we wouldn’t have locked funds and blocked because of something that can’t be completed.

If this was a grant program reviewed by electors they probably would catch the proposed design can’t be implemented due to limitations of core wallet owner’s API.

16 Likes