No. They shouldnât. It may not be enforceable, but youâall could require that grants disclose that the multiple projects are affiliated and, if later, itâs found out that people did not disclose this, they could be disqualified.
5 Likes
Heavy +1s to @lefterisjp and @tjayrush on their further comments on the multiple-entries per project question. Well said on both counts 
And I would go so far as to question whether many members of our community were even aware that this was happening or was habitually attempted⊠glad weâre getting it cleared up now.
Re: Well-capitalized projects
I appreciate this. And while it can get a bit murky- Iâm optimistic on a transparent way forward.
To add clarity in terms of the way we can start to assess grantee reputation as a community - letâs specify that opening a funding round of any size wherein the project/company/DAO in question sold off shares or promised dividends in a formal agreement with investors will show up on a financial audit. As we happily have grantees from all over the world, some countries may document this in differing ways, and bylaws of investment cycles vary, but in any case where publicity exists announcing ongoing funding raises, we will want to consider this criteria for non-inclusion. I think this should feel like âgraduationâ more than a penalty 
should you have been so lucky as to catch the eye of the traditional investment world.
So - I advocate this criteria in the spirit of prioritizing pre-pre-seed projects, but also out of respect for our stalwart projects who have disdained formal funding due to concerns of competing priorities that would sacrifice their open source mission or the integrity of their solution.
In future rounds, we can get more specific about on-chain inflow/outflow expectations to qualify a fair playing ground amongst projects of different maturity levels - again- using always public data and signals to perform any checks and balances.
I agree that this is a significant change which might surprise some folks if we were to implement after a quick forum discussionâŠ
What we can do is improve the availability of real (and on-chain audited!) grant award totals so that we (Gitcoin) and our partners (anyone running their own round), our grantees and their supporters can see the true amount of funding achieved through Gitcoin Grants Program over time. As we start making these numbers more widely available, I hope the discussion will continue to evolve. Perhaps we see supporters prioritize the lesser funded grants of their own accord, or perhaps we start cohorting projects so that those more mature are in their own camp to compete for matching funds, and those newcomers have a distinct matching pool to draw from⊠I imagine some grants program partners may have their own ideas about a cap or cut-off for previous grant funding - so allowing them to make their own criteria seems crucial to me.
Thanks to everyone for all these excellent thoughts and considerations! Thanks to @koday for ensuring these conversations happen in public!!
4 Likes
Thank you for opening this discussion.
As an active contributor in the Web3 Education and community category, I really appreciate this being a separate category in the beta round. I suggest adding these requirements:
- Projects should add data on itâs viewership such as demographics, age, onchain history etc in order to better gauge groups being targeted via content being developed
- Sorting projects who have verifiably created onchain activity via itâs viewers or subscribers. Further choosing top âxâ projects via this method.
- For projects which produce multi-lingual content, add a third party verification of translation or original content in the criteria. This third party can be trusted members within the community who speak/read/write the language.
- Allow projects which proliferate web3 culture or create cultural artefacts
5 Likes
Thank you all for the amazing suggestions and open discussion here!
Quick update - weâre planning on leaving this post open for discussion but will likely lock in the eligibility requirements by the end of the week (March 31st). I plan to make a revised post and clearly label what has been added or changed since this draft.
At that point, we may begin to share the requirements with past grantees and/or publically on our social channels as we start to generate interest in the Beta Round. Grant applications are tentatively scheduled to open on April 11th.
Iâd also like to add some input on the suggestions weâve got floating around here:
I completely agree Shawn - as mentioned above I plan to make a revised gov post at the end of the week that highlights the changes made to this criteria. However, the way we choose what to change or add is unclear. Iâd like to strike a balance between the two ends of the spectrum - i.e. one person making that decision and going to snapshot vote for every rule change. For this round I was thinking we could host a call with the PGF team and open it to all DAO core contributors, and do smaller-scale live voting on some of the proposed changes. Iâm curious to hear what your thoughts are around this topic.
I agree that an org should not be able to have multiple grants/subprojects that roll up into their org and I think any orgs that try to do this should be considered for a ban from future grants rounds.
I also like TJâs suggestion as a way to enforce this policy considering it may not be explicitly clear to round operators.
After reflecting on this, I actually do think a single grant should be able to qualify for multiple core rounds. With the current architecture the donations in each round would count separately for matching, and if they meet the eligibility criteria of more than one round I donât see why they shouldnât be able to pull funding from those sources. Otherwise, we are essentially asking them to conduct some game theory-esque analysis on which round is the most beneficial for them to join and that may never be a clear-cut answer.
Also, this functionality was present in most, if not all, cGrants rounds, so changing this policy to â1 grant, 1 roundâ seems like a much bigger change than letting this continue. The only difference now is that they need separate donations in each round to count for matching instead of allocating multiple sources of matching funds from 1 larger set of donations.
Iâll leave it at that for now to keep this comment at a reasonable length but will be adding more responses to other points in the coming days 
5 Likes
+1 this is a growing need. Especially felt for web3 education, but also for every project audit to be available in native language (as well as financial audits for public records and funding announcements).
We will be tracking the need for language audits closely in this round and I agree that right now, our community can definitely help fill in gaps- for the future, we may have to think of ways to compensate and source more global grantee reviewers to fill this needâŠ
@jengajojo would love to talk with you more if you have further ideas on how this could look for the future! (ale.k#2565 on discord.)
The issue here becomes our party-line on matching caps. For example, this absurdity:
We would like to give out as much money as possible to as many promising projects. To maximize the number of projects who receive funding, we put in a 5% matching cap on each round.
So we have Project #1 who participates in Round A. Meanwhile Project #2 participates in 3 rounds; A, B, and C.
Project #1 which participates in 1 round hits the matching cap and receives 5% of the pool for that round. They received 5x the unique votes as the next most popular project - but 4/5ths of their supporters donât get matched since they hit the matching cap. Project #2 meanwhile also hits the matching cap, even though they only had 1/5th of the support of Project #1.
That all is okay and is how weâve done matching caps historically ^ However now, weâre saying that because Project #2 fit within 3 categories- they now get to exceed the matching cap for Round A, in practice. Maybe they hit that cap for B and C too (but just barely) and so now we have penalized projects which had more supporters via the matching cap, but privileged a project whose supporters split their support across multiple rounds. (Spoiler: this is a big sybil/airdropper technique and is generally executed via script against our contracts). So Project #2 has now bagged 3x as much of the reward as we intended to âcapâ a single project from receiving; 15% of any single matching pool if we assume equal distribution and equal cap across all our rounds.
This seems in bad faith to me, and so matching caps per round feel mutually exclusive with projects participating in more than one round simultaneously⊠Recognizing that at the end of the day this is Gitcoinâs matching pool split into 5 buckets- same pool, same funder.
That said, if Iâm a partner and I want to encourage projects who are located in a certain geographical region, this is independent of whatever funding those projects may receive from Gitcoin. I want to give them a âbonusâ essentially for building in the region-- so they get their funds from Gitcoinâs grant pool and then a bonus from my grant pool. This is a new bucket of money- so I feel that partners controlling their own eligibility criteria feels perfectly fine, here.
Would love to hear community sentiment- as again, this is something that may not have been widely acknowledged in previous rounds. Would be great to have it worked out for Gitcoinâs own case.
6 Likes
First off, Iâm very excited about the Beta Round being just around the corner. Congrats!
Iâd like to see eligibility criteria become more transparent and independently verifiable. Some of the things I would advocate for:
-
A consistent wallet address for receiving donations. Iâd like to see projects receive donations via a wallet (ideally multisig) that resolves to a project ENS and has name tags on Etherscan. Anyone can verify these things in one click â and get a good sense for how much money the project has flowing through it. I think Rotki is exemplary in this regard.
-
Active OSS / Github repo. Iâm glad that @koday is proposing that Github activity continue to be a requirement for OSS projects. Iâd like this criterion extended for any other projects that are building software.
-
One-click proof of work / impact. For education, community, media, climate-related public goods (ie, basically anything that isnât OSS), Iâd like there to be a âproof of workâ thatâs accessible in one click. Ideally, itâs dated and has some basic metric for reach / engagement. A newsletter, podcast feed, Discourse forum, project dashboard all serve this function. Make it easy to prove that you or your project is doing something that matters to people.
-
Snapshot / voting history for DAOs. If youâre a DAO, prove you have a community. Snapshot is one of several good tools for signaling you are more than one person and capable of managing a budget.
Iâd like to move away from arbitrary requirements like ânot have prior external funding of over $500k USDâ. Per @tjayrushâs comment, there are incredible projects that have multiple people working full-time for multiple years on them. This criterion feels arbitrary, hard to enforce without insider info or âhonor codeâ, and unfair to long-standing projects.
Iâd like to see the projects within a round empowered and given tools to self-police against quid pro quos, advertising, Sybil attacks and other practices intended to manipulate the QF. Iâm not sure how best to orchestrate this but want to see QF rounds among projects embody the Ultimate Frisbee style âspirit of the gameâ. This is especially important given the sunsetting of FDD, the part of the DAO that was most vigilant in rooting out such behavior.
Regarding round dynamics, I also have the following thoughts:
-
Rounds shouldnât be too big. Generally, Iâd like to see a ratio of at least $10K in matching funding per project within a round. So a matching pool of at least $200K for a round with 20 projects in it.
-
One project:round only. Projects (and teams) should not be able to participate in more than one round. The recommendation about having a consistent wallet address can mitigate this.
-
Projects should be established. I agree with @kodayâs proposal of at least a 3 month track record. I would extend that by giving the grants more of a retrospective bent: the descriptions should focus on what the projects have accomplished in the recent pass (eg, between grants rounds), not what they plan to do with more money. I donât want grants to have prospective âdeliverablesâ but I do want them to have proof of work/impact.
Finally, itâs in bear market conditions like we face today that Gitcoinâs mission is most important. Iâd like to see every marginal dollar go towards teams that are buidling through the bear â and setting clear, consistent eligibility requirements is one of the best ways we can do that!
7 Likes
I absolutely agree with all of this. Especially two things.
Consistent wallet address (and if not that, then at least keep a history of the changes to a projectâs wallet from inception). I think itâs important to one day be able to go back in time and figure out whatâs been happening on chain. Forensic evidence as it were.
One grant, one project, per team. This is equally important to me. If GitCoin doesnât do this, then my only recourse is to make TrueBlocks ten projects which I donât want to do.
7 Likes
Probably best if grantees are only in one round for the Beta rounds just given it would be confusing for donors to see the same grant in different rounds and have to donate more than once if they want to support a project. Ideally in the not too distant future we implement âjet fuel QFâ which enables people to donate to a project in more than one round at the same time. This would make it a better experience for grantees and donors in future rounds.
This question is a bit more complicated. Personally I think each project should stand on its own based on the eligibility criteria. We shouldnât punish individuals for being part of more than one project nor should we create incentives for individuals to hide themselves from view if they are part of more than one project. And as you pointed out its hard to be clear about who is involved in a project in an anon space.
This also ties into the discussion of the same organization having more than one proposal for their different initiatives. To me this really comes down to if these individual initiatives are real and how the funds are actually allocated. We shouldnât punish a DAO or other organizations or individuals for doing more than one thing. We also shouldnât create incentives that force organizations to splinter or split up in order to qualify for funding. The missing piece here IMO is having improved reporting, updating and verification. Iâm hopeful that a community of impact certificates and attestation providers will grow in the year ahead and this will dramatically increase transparency and accountability.
My two cents on this one is that we shouldnât allow grantees to promise anything in return for donations in their proposal or elsewhere in their community outreach. This may get complicated as people provide retroactive air drops or other things to their community members but it would be best if these sort of thing was genuinely retroactive. Its great when Gitcoin is a community organizing tool and a way for grantees to find their community and continue to engage with them. The goal needs to be to ensure donations are not coming in to receive a reward and to protect the voting with your wallet component of QF, people shouldnât be selling votes.
The key part of this question to me is the word sale. Gitcoin grants rounds shouldnât be used to promote an NFT drop or some other form of a sale. That being said NFTs are a broad category of web3 tools used as impact certificates, attestations, carbon offset and renewable energy certificates etc. The distinction should be if the NFT is being used as a utility or as part of the community engagement strategy for a project with goals related to the round they are applying for vs if the NFT is the whole project in and of itself. A portion of funding from an NFT sale should not be considered as adequate to be seen as being tied to the the objectives of the round.
Matching caps are critical to distribution of funds to a wider spectrum of grantees. Perhaps there should be some guidelines for matching caps based on the size of the round. A lower cap the larger the round. We have done this somewhat organically but it could be a bit more structured moving forward to provide some suggestions to round operators. I would also potentially support a maximum match for projects across the whole program quarterly for projects if a project is allowed to be in multiple rounds.
I think the answer to this question very much depends on the goals of the individual round. In general I think we should be very careful about not allowing sybil attacks or scams into the rounds but the question of âqualityâ is pretty subjective and in a sense is why we are harnessing the âwisdom of the crowdâ. Whatâs important is that the eligibility criteria is very clear and continues to be refined for each round as edge cases come forward. As a general rule I usually suggest to round operators that when considering a potential grantee we ask ourselves how we would feel if they raised the most money in the round. If that would seem problematic then it should tell us something about how to refine the eligibility criteria and why.
I would love to see more community members getting involved in the Grant Round Operators Guild (the GR OGs) and weighing in on the decisions for the rounds eligibility. Many of these decisions are hard to capture in broad strokes policies and requires talking about the specifics of a project in detail with a group. I believe that having a healthy community of grants round operators will be critical for the growth and impact of our grants programs as well as independent rounds run on the Grants Stack.
Love seeing this conversations happening in public with so much community input.
Big should out to the OâDays @connor and @koday and all the other Gitizenâs from the community for all the thought and time you have put into this discussion.
5 Likes
This is a really interesting idea @ccerv1! Ideally the website link that is provided would serve as this form of proof but of course not all website adequately provide this sort of information or context. Perhaps a form with a set of leading questions that was included as part of the application process could help with this. Would be great to talk more about this idea and what it could look like in practice.
2 Likes
This makes sense to me. One thing I would add is that we should distinguish between which rules would apply to any round in the quarterly grants program including featured rounds and which would be specific to only some sub set of rounds. One of the great things about the program now being decentralized is we can have different criteria for different rounds. We for sure want to have some general rules that apply across the board in the program, for example rules around sybil or hate speech but some other rules may not make sense for every different round.
I agree with the reasoning behind this but worry about the implementation during the Beta and what that experience will be like for donors and grantees. Really to me this makes the case for prioritizing jet fuel QF.
2 Likes
This looks great! Love the updates and thank you for making all the information clear and concise. Happy to be here and thank you for all the support and everything thatâs gone into making this happen.
3 Likes
I like the eligibility, just wondering how it may apply to existing projects just now making their way to web3. As an example: As part of my âImpact Onboardingâ strategies, Iâm working to onboard NGOs that have a proven track record, so they can adopt the tech to gamify their efforts and report impact transparently. Does this mean they would have to be in web3 for 3 months or am I misunderstanding that?
We should try to make the reporting easy by offering a wireframe for this. Something like âlist 5 impactful projects you used funding for since the last round.â
4 Likes
Hi there Pedro Marques here from RMTerra and first time here on Gitcoin , we are very interested to know more how to be elegible for a grant too. Can anyone explain me how to participate and what the steps need it?
Thank you very much, really appreciate your help!
1 Like
There is a challenge around DEI here. It is caught in a scarcity trap. We donât prioritise it and so we continue to miss the benefits of diversity in the ecosystem. How might we shift our values enough to recognize the opportunity cost we continue to incur in the absence of more diverse participation?
4 Likes
This is a good opportunity for DEI projects and their communities to become more active in the forums. I donât think itâs easy for most people who arenât personally affected by DEI challenges to actively work to improve this situation. Itâs also not easy feeling underrepresented and taking the initiative to be one of the first to advocate for yourself and your community. A good solution could be to encourage a few of the more vocal leaders nudging others to express their opinions/ concerns in between rounds, even starting now for the next round instead of waiting until itâs too late. Iâve been pushing the LatAm community to do this, but havenât seen much participation so I have to push harder.
3 Likes
In our case, directed.dev leads to a rabbit hole of information for the visitor who is interested (eg Public Notion page, then progress updates/newsletter, or whitepaper). Thereâs also plenty on our Twitter and, most importantly, the vlog series that I started to document the work behind the scenes, e.g. us trying the onboarding to crypto in our pilot school in Kenya. I canât include links but if you search for âLaunching a Web3 Charity #10, Kagumo High School!â then youâll see
2 Likes
Hey all! Make sure you see the follow up post here:
and feel free to still drop feedback and thoughts in that thread
3 Likes
Unfortunately, I would have to disagree with this statement.
I definitely understand that it makes sense in the context of Rotki.
However, personally, I collaborate loosely with multiple teams and on multiple projects. Its just so happens that its much easier to have one github org than multiple. Your proposal would take a lot more time on red-tapping and unnecessary line toeing. Honestly, sounds a bit self-righteous.
1 Like
The easiest way is not always the best way. Thanks for sharing your opinion. We will agree to disagree here.
1 Like
Ok so this was my first time applying for the beta round for one ! My project got rejected probably I wasnât able to explain my idea properly but I would like to emphasise it would be great if some sort of feedback is provided at the time of rejection. We donât know why the projected was rejected even before the round even after putting so much effort in to it
4 Likes