- The Beta Round General Eligibility Policy has been finalized.
- The Core Round-Specific Eligibility Policies have been finalized.
- This is a follow-up to this gov post which discussed the general platform and round-specific eligibility requirements for the upcoming Beta Round.
- There was a lot of good discussion in the comments, and some of the main talking points will be summarized below.
- What has changed or been added since the last gov post is clearly labeled
- These requirements are locked in for the Beta Round. However - this will be an iterative process and the discussion will remain open over the coming quarters as we continue to evolve our grants program.
General Platform Eligibility
**Note: Please refer to this document to see the full list of general platform eligibility requirements in one place.
Most of the discussion on the previous forum post was centered around the general eligibility requirements. Some of the most debated topics include:
Quid Pro Quo - Gitcoin has a long-standing rule that grantees cannot promise any financial compensation to their donors. However, questions have been raised about whether or not non-financial privileges should qualify as quid pro quo behavior. This could include giving out POAPs or discord moderator roles in return for supporting a project. While this rule did not change for the Beta Round and still only encompasses financial compensation, we feel this discussion should continue as we define what makes an acceptable and healthy grantee <-> donor relationship.
Multiple projects per person/org - This rule has been added to the general platform eligibility requirements. It was not specifically called out before, but now we will be enforcing the policy that a single person cannot apply to one or more core rounds with more than one grant. Additionally, organizations cannot create multiple grants that roll up into the same org/entity.
Multiple rounds/matching pools per grant - This policy has been added and will mimic the Alpha Round: a single grant can only qualify for matching from one pool during the Core Beta Rounds. This choice was made to both simplify the round operations as we are still in a testing phase and prevent the biggest projects from soaking up funding across multiple matching pools.
It’s important to note that this is a different policy than GR1-15 which ran on cGrants, and is still up for debate as we may enable grants to qualify for multiple matching pools in a given round in the future. However, the big difference here compared to cGrants is that donations only count for matching from the round they were donated in - there is no overlap in counting donations for matching between rounds as we are using on-chain data as the source-of-truth.
Another interesting discussion is around Gitcoin’s requirement that grants must not have prior external funding over $500k. There are arguments that this is too hard to track accurately for projects, that some projects are still public goods and strapped for cash despite raising over $500k in the past, that they may have raised money previously but transitioned to 100% community-owned, etc. Ideally, we want to strike a balance between allowing projects that are “too big” but still supporting the larger grants that are public goods and truly do need the funding despite their previous raises. Although this policy is not changing for the Beta Round, this will certainly be an interesting debate to continue as we move forward.
Round Specific Eligibility
Note: Please refer to this document to see the full list of Beta Core Rounds Eligibility Briefs in one place.
There was significantly less discussion focused on the eligibility of the individual core rounds, and as a result, not much has changed.
The only round that is technically brand new is the Web3 Community & Education Round. Since this is likely the broadest category of all the core rounds, it has been a challenge to settle on clear and objective eligibility criteria. The proposed criteria in the previous gov post were rather simple and will be supplemented with the following rules:
- Projects must be older than 3 months
- Projects must have a proven track record in the Web3 space and list their long-term goals and recent milestones.
Other than the Web3 Community & Education Round, there will not be any changes to the round-specific eligibility criteria at this time. However, continuing to discuss and evolve these criteria as we run multiple iterations of each round on the new Grants Stack is going to be crucial for attracting and providing funding for the highest quality grantees possible.
Round Structure Questions
There are a few other topics related to round structure that are up for debate but aren’t directly related to eligibility criteria. This includes:
- Matching caps - How should these be set for Gitcoin Program Rounds? Should it be constant across the board or should it come from a formula that depends on matching pool size, number of grantees, or something else?
- Universal matching cap - If we allow projects to qualify for multiple rounds in the future (after the Beta Round) should we implement a ‘universal matching cap’ that ensures a project cannot take too much money from multiple pools? If so, what would the structure of this look like?
Gitcoin’s intentions are to crowdsource knowledge and opinions both internally and externally in order to set the eligibility requirements that allow us to run the best grants program we possibly can. This is one of many strides we are making in our efforts to decentralize and evolve the Gitcoin Grants Program, and we encourage all stakeholders and community members to weigh in on these requirements if they would like to see something changed or added on. Thanks for reading!