Fund Alternative: A Grants Model Proposal

Grants Model Proposal

This proposal is an alternative to the existing community fund models proposed in the current discussions in the #community_fund keybase chat and governance meetings.

Below is a rough outline, not necessarily a comprehensive or formal proposal.

Overview

Community decentralization is challenging, especially when it comes to decision making processes, and even more so when those decisions involve funding. Building a decentralized community makes building a decentralized cryptocurrency network look easy.

The Grin development donation fund currently has an amount of capital to deploy to achieve the ambitious and long-term goals that the community set out to fulfill. This fund has grown to a point where alternative strategies need to be considered to support a more efficient deployment of the resources. This is a good problem, and can mean that Grin development should be able to continue well into the future to fully realize our collective visions.

The motivating factor for proposing this change is to reduce centralization around the current funding decision making process to best serve the needs of the ecosystem by more efficiently deploying capital through a grants platform with a more diverse decision making body than exists today.

Current proposals suggest splitting the fund up into smaller groups or teams that would then manage their own chunks of the fund. This can be problematic for a few reasons:

  1. They donā€™t make it meaningfully easier for developers to make proposals and receive funding than it is today (it actually complicates the process with multiple competing paths)

  2. They incentivize more tribalism and less cooperation as each recipient/group will always continue to press for more funding and more influence, promoting an ā€œus vs themā€ attitude

  3. Grin is still tiny relative to the rest of the space, further fractioning may only weaken opportunities to capture more mind-share from both a developer perspective and a market perspective

Instead, this proposal encourages unity over division by creating a unified grants platform modeled from https://grants.zfnd.org and by providing the opportunity for trusted community members to give their voices a direct influence over funding decisions.

This proposal remains sensitive to the fact that not every developer needs to be stripped down publicly by the entire community every 3 months to pay their bills- we can trust our more established teams that have been contributing for years now to make wise decisions with how they run their team.

Finally, this proposal provides the Grin ecosystem with an opportunity for a robust grants program that the community can be proud of and that will bring new community members in and existing community members together, working toward the same goal, of making the Grin ecosystem as strong as we can.

Benefits

  • Streamlined and robust process to more efficiently fund proposals that improve the Grin ecosystem

  • More diverse and inclusive decision making process compared to the existing and proposed funding models

  • Provides insulation for the existing established teams in the ecosystem to request funding to manage themselves

  • Does not fracture the community into smaller, competing groups

Required Components for a Grants-based Funding Model

The below components would need to be complete for a minimally-viable grant funding model for Grin.

Grant Funding Decision Making Body: Council++

  • All funding decisions pass through the grants platform, with final decisions made by Council++

  • Fund multisig keys are still held by original council (and so do not change) but decision making is expanded to include rotating community chairs

  • 6 fixed legacy council seats: antiochp, jaspervdm, lehnberg, quentinlesceller, tromp, yeastplume (since I am proposing this, I will abstain from inclusion)

  • 5 rotating community seats: dburkett, dtavarez, mcmmike, hendi, phyro (just possible suggestions to start)

  • The 11 seats make up Council++, where 6/11 votes are required to achieve funding consensus (alternatively we can move to 5/9, removing both a legacy council and community seat if we cannot find enough suitable volunteers)

  • In the event that the multisig key holders do not honor a 6/11 consensus agreement for a payout, it would invalidate the spirit of the program and be a great harm to the Grin ecosystem- there are no guarantees here, but it is still arguably less centralized than the current model and does not fracture the community

Grin Grant Funding Web Platform

  • Web platform modeled from https://grants.zfnd.org

  • Clear and easy to understand UX for proposal applicants

  • Transparency (in the right places) for all

Community Outreach/Awareness

  • Market the grants platform to the greater community to encourage new contributors

  • Sustained efforts to bring developer awareness to the opportunities available on the Grin grants platform

Administrative Overhead

  • Full-time administrative support would be required to consistently and sustainably support a healthy grants platform

  • I am willing to bootstrap this myself for free for 3-6 months or until we find someone suitable, whichever comes first

Implementation Steps

  1. Specify deliverables for Grinā€™s grant funding web platform, find a willing developer/firm with reputation and propose a funding request from council to fund it + hosting + maintenance (I can volunteer for working on this proposal)

    • https://grant.io/ (built zcashā€™s grants platform) might be a good starting point
  2. Assemble Council++ decision making body with rotating community seats from trusted community volunteers

  3. Bring grants platform online

  4. Grin++ and Rust teams apply for the initial amount of BTC they think is needed to continue development in their respective ways without interference

  5. Market the grants platform to the greater crypto and open source communities

  6. Replace me with a suitable administrator

Other Thoughts/Open Questions

  • How does the community seat rotation work? Swap one member out each quarter? Swap whole team out each year? How are new additions decided?

  • How are legacy council seats replaced if one of the six leaves? Does council++ or legacy council decide? Or is the seat given to community rotation?

  • Does this achieve intended effect of deploying the existing fund capital as efficiently as possible?

  • Is this more efficient than splitting the existing fund up into multiple funds with different processes?

  • Is the structure meaningfully different than other proposals?

  • Does this feel more inclusive to existing community members?

  • Will this make it more likely for high quality proposals and developers to join the Grin ecosystem?

Future Possibilities

  • Once a robust grants platform is established and the Grin ecosystem has grown, new decision making groups can participate on the platform (like https://zcashomg.org/)

Final Thoughts

Admittedly, this is not the easiest path and would require quite a bit of effort and time investment to execute properly, not to mention the extra decision-making complexity. However, the payoff could potentially make a big impact for the long-term sustainability, capability and adoption for the Grin ecosystem.

Any thoughts/critiques are welcome.

I hope this can continue to move us forward in the direction we all want: sustainability and growth for Grin.

Opinions above are my own and do not reflect anyone elseā€™s opinions.

9 Likes

i like the idea but instead of 6 fixed legacy council & 5 rotating community seats, i think that having good balance between is better especially when core team already have its own fund and community needs at least the same number of voices

5 fixed legacy membres & 5 rotating community seats

community members needs to be the most active members on keybase and the forum participating in various discussions like @phyro

1 Like

To me, the latter is the simplest way to achieve the former.

On one hand, streamlining the funding request process is great. I really like the idea.
On the other hand, this might be more suitable for projects not as small as we are, itā€™s a hefty operation. Also, splitting the fund into two separate ones which require full transparency but no wide community approval, does solve some problems of people (cryptographers for e.g.) not being willing to publicly request funding.

Nevertheless, this should be seriously discussed. Not sure which approach I personally prefer.

edit: (good points from @joltz on keybase)

I realize the appeal of just wanting to do a clean split and hoping the problems go away but Iā€™m not convinced they will and Iā€™m concerned that splitting into smaller competing groups will be worse for the ecosystem as a whole. I also think it will also make it more convoluted to new outside contributors to get funding. Just my 2 grin

1 Like

I am not sure yet if I prefer this new model over the old one, although I see a lot potential if applied properly. :thinking:
In general I think we need both

  1. More autonomy for making small decisions, e.g. funding of community projects
  2. More structure as well as more protection of core programmers who are now publicly scrutinized. E.g. by using templates for applications and a second pair of eyes before submission.

Personally I think we can keep the MultiSig the way it is. In other word, the decision body does not automatically means having the keys to the Grin fund. Requiring 6/11 or 5/9 for a multisig sounds like a hassle and would slow down payments.

What I like about the new platform idea is that applications become more streamlined and structured, something that is now often missing or hampering progression from ideas to grand applications. The trick will be to find a balance between having a new structure with more formal templates for grand applications while at the same time keeping things minimal and simple. Hence, I would not change the MultiSig, only expand the decision body giving formal rights to community members. In all the time that I was part of the project I never felt even once that funding request were unfairly judged (only sometimes communication mistakes were made), but for the community having more "formal authority ", think will help. At the same time, those community members can help ā€˜encourageā€™ proposals from the community to be entered in the grand system and to be brought up for a vote. Since basically a larger network is involved in the decisions, this might help reach more qualified programmers and cryptographers out there, at least that is my hope.

1 Like

While splitting into smaller groups may be the simplest way for a more diverse decision making body, it adds complexity from the outside perspective of a new developer to Grin with a proposal who wants to apply for funding. The simplest approach imo would be a unified grants platform that they can use to see if there are any similar proposals in one easy to find place, as well all of the requirements and process necessary to succeed.

It is also possible to have both, a unified platform, different categories in which different parts of the larger body do the first scrutinization and improvements of the proposal and help bring it to the council ++ board. So both unified as well as allowing smaller groups to progress the decision making process.

In any case, how we will proceed with the current situation we really should give this idea a chance to develop.

As I also did comment on the original message from @joltz on keybase:

The idea would be to create a focused and well-supported channel with a solid grants program based on zcashā€™s model (as best as we can) to make it more straightforward for people to get funding, while simultaneously adding new voices to the existing funding decision making process with rotating seats held by members of the community.

It might be a more efficient way to spend the money as there would be a well-defined, well-supported and more diverse decision making process. I think over time it would mean the money is spent on higher quality proposals with a better funnel to bring higher quality proposals into the Grin ecosystem, as opposed to just fracturing the existing model into smaller pieces.

Source: keybase://chat/grincoin#community_fund/570


my answer Quote:

I had a similar idea , also the grants.zfnd.org has some kind of a legal entity around it.

We are internally discussing and evaluating, if we could take grinnode.live under the umbrella of one of our open-source development companies, as a research and development branch.

This would provide a more stable and reliable starting point for legally hireling (paying taxes, I know :() freelancer and fund more projects to come.

At the same time, it would become very or frankly said 100% centralized around a few people who are running the company. But this could be circumvented when , similar to grants.zfnd.org define a few people as ā€œproject leadsā€ with a set of code of conduct and playbooks to work in the open-source community, with a certain amount of funding for a project.

We are , and I am personally working on different, non crypto-related , but open-source projects. Applying these kind of rules already and trying to improve the project.
We are working with current open-source developer as a team , including a few freelancerā€™s of mine around the world and other community members.

source: keybase://chat/grincoin#community_fund/592

I am currently going though the documents of Zcash-Foundation to get a better understanding how they are operating. Also I am going though the financial documents of Zcash-Foundation in order to get a rough estimate on the capex and opex costs to setup something similar.

One of the key points we need to think about are:

  • location
    ā€“ in which jurisdiction we want to open a (non)-profit crypto foundation.

  • legal structure
    ā€“ Can we structure the non-profit foundation, based on blockchain-shares ? [1]

  • funding
    ā€“ after going though the documentes of the zcash-foundation, and talking to some professionals, I could come up with a rough-estimation.

  • and all the open questions @joltz mentioned above. :point_up_2:

[1] ( posisble, as we are currently in the process of it for my other companies)

Lets not add yeastplume at all. He did great things in the past, but he last post made me worry about his his state of mind. When he mentioned the bill and melinda foundation. I instantly knew he should not be involved in any financial aspect(s) before you know it he will ask people to vote for a certain group and arguments that the other side is evil.

1 Like

Where can I find the source of this?

@Chronos

yeastplume: Or give it all to bill and melinda gates and they can do some actual good with it.

That was clearly a joke and should not be blown out of proportion.

3 Likes

Love this idea, I already started to make content and promotion for Grin, if it will be some intensification for this process , it will be really cool. Grants its ideal form!

its also cool to use TIPs , little rewards for little contributions
Such a system successfully works in polkadot ecosystem Polkadot/Substrate Portal

Also very important point :
All PAYMENTS and COUNTINGS MUST BE IN GRIN! CHANGE BTC TO GRIN THAN REWARD THE PARTICIPANTS. IF YOU ARE FAN GET GRIN!

1 Like

In the context of recent discussions about the community council I am bumping this (pre-CC?) thread as I was thinking the same.

For certain projects like Grin++ maintenance I think a grant model might work better than the current funding periods.

If a longer term funding of like 1 year were provided to maybe two signers for a project then they would be more able to rely on it and go focus on their work.

It would also provide a better review period for the community at renewal. In any given monthly or quarterly period it is hard to judge progress, bug fixes can just as likely be a true report of a significant amount of work or a catch all excuse for inaction. Whereas over the course of a year itā€™s much easier to see if the project is actually making real progress.

It adds the risk of someone running off of course, which is why it could only be appropriate for recipients who already have a history of consistent activity that is longer than the funding period.

Iā€™ve re-read the thread now though and I see this was part of the decision making process that lead to the CC. No need to rehash a debate thatā€™s already been had. Up to the CC to sort it out.

1 Like