[Discussion & Feedback Request] Gitcoin Program Beta Round Eligibility

đŸŒ± Gitcoin Grants
, , ,
1

Introduction

The Gitcoin Program Beta Round is the second set of Gitcoin Program QF rounds that will run on the new decentralized Grants Stack. The planned dates for this round are April 25th to May 9th and there will be 5 Core Rounds each with a distinct matching pool:

  • Climate Solutions
  • Ethereum Infrastructure
  • Web3 Community & Education
  • Web3 Open Source Software
  • ZK Tech

As we continue our efforts to decentralize and shape the new Gitcoin Grants Program, these rounds were chosen from a larger pool by the community through a Snapshot vote.

340×649 62.5 KB

Note: There will also be a number of externally operated Featured Rounds that run in this same 2-week window; the details of which are still being determined.

The purpose of this post is to outline the general eligibility policy that ALL grants must meet in order to qualify for acceptance into any of the 5 core rounds. In addition to the general eligibility, grants must meet the extra criteria for the round they are applying for. The description of each specific round’s eligibility criteria is listed after the general eligibility policy.

The PGF team is asking DAO contributors, stewards, and community members to carefully read these eligibility requirements and provide feedback or engage in an open discussion where needed. The requirements are subject to change but will be locked in before the application window opens.

Gitcoin Program General Eligibility Policy

This policy is set and enforced by the FDD & PGF workstreams of the GitcoinDAO and is ratified by the GitcoinDAO stewards. The following are not permitted in Gitcoin-operated rounds:

  • Hateful Content - No racist, sexist, or otherwise hateful speech, no discrimination
  • Deceiving Users - Malicious content that could cause harm or unintended consequences to users
  • Falsification - Any type of hacking to falsify a contribution is prohibited. No encouraging or enabling Sybil attacks or other forms of malicious manipulation of the grants platform or the Gitcoin community
  • Fraud & Impersonation - Claiming to be a brand or person you are not. The Grant owner must be directly affiliated with the project, the funds must go to the project, and be used for the purposes stated in the Grant’s details
  • Quid Pro Quo & Bribery - The Grant may not have any form of quid pro quo that has financial value (a scenario in which a user gets some additional unique benefit/award in return for their donation)
  • Advertising - Using grants to showcase something you are selling like a token sale or NFT drop
  • Well-capitalized projects - Not have prior external funding of over $500k USD via venture capital, token launches, or NFT sales
  • Grantees cannot be subject to sanctions, and funding cannot be used in violation of any applicable law, rules, or regulations (for example those addressing sanctions, financing of terrorism, and anti-money-laundering)
  • Grantees can be eliminated from consideration in the round if they are found to be encouraging or enabling Sybil attacks or other forms of malicious manipulation of the grants platform or the Gitcoin community.

Additional criteria that projects must meet:

  • Project Update - If you are a returning grantee, you must provide an update on what work has been accomplished since the last grant round your project received funding from
  • Verified Github (if applicable) and/or Twitter account

Web3 OSS Round Eligibility

To qualify for the Web3 OSS round, in addition to meeting the criteria outlined in the program policy above, grants must:

  • Be an open-source project with meaningful Github activity in the prior 3 months that has demonstrated work completed towards the project’s mission
  • Primarily focused on developing on top of or advancing the broader Ethereum and/or Web3 industry

Ethereum Infrastructure Eligibility

  • The Grant must be in support of, or directly advancing the Ethereum ecosystem. This includes areas like:
    • Core client devs (e.g., geth / nethermind; prysm / lighthouse)
    • Tooling providers (e.g., hardhat / ethers.js)
    • Those showcasing the power of critical ecosystem ideas (e.g., dark forest with zero-knowledge proofs)
    • Those doing the hard work of educating developers (e.g., Austin (Gitcoin) / Nader (DeveloperDAO))
  • The Grant must be open source (if software-related)

Climate Solutions Round Eligibility

  • Projects must be at least 3 months old. Newer projects should establish themselves and submit to the next round.

  • The Grant must be primarily focused on climate solutions (the group may do other work but the grant proposal should be directly related to climate solutions). The proposal should explicitly outline how this project will help reduce GHGs or is an important core infrastructure for web3 climate solutions.

  • Grantees who received funding in previous rounds should report on project progress since GR15 or the Alpha round. We understand that some projects may have less progress given the timing of Alpha round disbursements. This will ensure accountability to supporters and also help encourage contributors by showing what you’ve been accomplishing.

  • All returning grantees are expected to update their proposal, in addition to project updates the proposal should include lessons learned from previous work and how they will use the additional funding from the upcoming round. The updated proposal should indicate how additional funding will help the project meet its goals, and include a rough timeline for the project overall.

  • There is a general expectation that projects are within the “realm of viability”.

    • Even if a project may be at a very early stage, it still must seem credible to the average person with an understanding of web3 technology and climate solutions.
    • Grantee founders must genuinely intend to build the project, and the project must not broadly be considered an impossibility.

Web3 Community & Education Round Eligibility

The Web3 Community & Education Round is a new category that has not been a Gitcoin Program round in the past; however there have been similar ecosystem rounds called ‘Media’ and ‘Community’.

Reflecting on the Alpha Rounds and all the legacy “Main Round” grants, there were many great projects that couldn’t join OSS due to specific “active OSS repo” requirements. In GR12 and before we had mutually exclusive categories like “infrastructure” “dapps” and “community” - and this would be like the old community category, which included podcasts, newsletters, educational projects, journalists, and more.

As we’ve now split open-source software into its own round, we will run this Web3 Community & Education Round to focus on non-software related projects that are helping to push the Web3 space forward.

The requirements to be accepted in this round are outlined below*:

  • The project must be focused on improving the Web3 ecosystem.
  • Examples of projects which may fit are those that are:
    • Growing new communities
    • Providing educational resources
    • Creating content (youtube tutorials, newsletters, blog posts, podcasts, etc)
    • Protecting users by investigating bad actors
    • DAOs focused on socialization
    • Onboarding new users
    • Working on inclusion/diversity/advocacy

*Note: As this is a new Core Round category, we’d love to have the community weigh in and narrow the scope or suggest more objective criteria.

ZK Tech Round Eligibility

  • The Grant must be in support of, or directly advancing the ZK tools, libraries, community, or protocols.

  • The Grant may not have any form of quid pro quo that has financial value (a scenario in which a user gets some additional unique benefit/award in return for their donation)

  • The Grant owner must be directly affiliated with the project and the funds must go to the project.

  • The Grant should be focused on accomplishing the following for ZK:

    • Usability - improving the user experience of zero-knowledge tools/libraries, not zero-knowledge rollups. This could also be technical education and documentation.
    • Tooling - improving the developer experience or making it easier to develop applications utilizing zero-knowledge proofs or technology.
    • Applications - technical implementations of zero-knowledge proofs and circuits, not simply applications built on top of zero-knowledge roll-ups.

  • The project should not have its own token or have raised VC funding (let’s keep the funds for the aspiring projects!)

  • The project must have been active in the last 3 months - social media and GitHub.

  • The project should have demonstrated either concrete progress, or evidence of a substantive technical roadmap that clarifies how ZK technology will be used and advanced.

  • The Grant deliverables should be open source.

Conclusion

These eligibility requirements are designed to ensure we capture and provide funding to the highest quality projects in each category. As a reminder, the requirements are not yet set in stone and we are highly encouraging the community to discuss what makes sense and what could be changed. Thanks for reading this far and stay tuned for more updates!

28 Likes
2

Really great to be discussing this topic! Two questions:

  1. For the general eligibility criteria that reads: “Well-capitalized projects - Not have prior external funding of over $500k USD via venture capital, token launches, or NFT sales.” Does this include having received over $500k USD in funding from grants including the sum of past Gitcoin grants rounds?
  2. Can a grantee apply & participate in more than one round if they meet the criteria of each? Related to this: Can a grantee apply/participate in a Core Round and a Featured Round?
16 Likes
3

I love these questions! Thanks for posting them. I was wondering a similar question on multiple rounds.

FWIW, I think the way the tech works, donors would need to contribute to the grant in each round. ie, contributing to the grant in a core round would not automatically enable matching in a featured round (as currently built).

9 Likes
4

Thanks for putting this together so quickly @koday! Glad we’re getting ahead of this and also glad we’re working to crowdsource opinions. I’m not sure we can really do a formal snapshot vote on the many various criteria and limitations, however, it would be INCREDIBLY helpful to get more input from the community: Stewards, grantees, donors, etc.

Some topics I’d love others to weigh in on, not all mentioned in the main post:

Multiple entries - Should one single grant be allowed in multiple rounds? Multiple core rounds (ie. OSS and Eth Infra)? A core and a featured round (ie. OSS and DeSci)? Can/should we as Gitcoin even moderate featured round reviews and approvals?

And on a similar wavelength - should a single person be allowed to have multiple different grants in the same round? Should they be allowed to have multiple different grants in different rounds? Is this really enforceable in an “anon-friendly” platform?

Quid Pro Quo - We’ve always had issues drawing the line here. Does a POAP count as QPQ? Does a Discord role count as QPQ? We’ve tried to draw the line at “monetary value”, but we’ve also seen things like POAPs act as incentives even without “value” - and of course, we get into potential airdrop speculation/farming territory.

NFT “sales” or drops have also been a bit of a gray area - would love to hear what others think about this.

Matching caps - are they good? Should they be higher? Lower? Removed altogether?

And in general, should we aim to be more strict on approvals to better curate quality projects, or be more lenient and trust the “wisdom of the crowd”? Should brand new projects with little history be allowed in, or should we aim to check and verify past work and some level of prior progress? The issue is we don’t want to discourage new ideas and prevent funding from getting into the hands of very early creators, however, we’ve also had many issues with “grant emulations”, or essentially, projects that look “legit enough” but in reality were just totally made up for the sake of farming donations.

I’ve found the community often has tons of opinions on criteria after a round is over, but ideally, we can start fixing these issues proactively :slight_smile:

13 Likes
5

Hey Connor - I love how we are working on codify the criteria. As we continue to grow, it would make sense to clarify how round eligibility changes over time (how and by whom). This clarification will help us avoid future disagreements.

I think that with the community input that @koday is seeking here, once the comments are integrated, it would not be a hard step to formalize an update process. I am adding this question to our D-RACI chart (to be shared shortly) as work to be done, which I am happy to help work through.

6 Likes
6

Hey Connor! An aspect of Gitcoin that I find especially fascinating is the support for very very early stage projects. I’ve been working on science for 40 years+ and support of early ideas is something we must fix in TradSci to advance the human knowledge. I do believe this is an area that Gitcoin excels. Regarding ‘grant emulations’, we might be able to use some tools like Passport or Holonym in order for people to have the matching funds? Projects’ owners would still be allowed to apply :grinning:

9 Likes
7

Thank you Connor!
Cheers
Maria

3 Likes
8

Multiple entries – think it’s very fair for projects to fall under multiple categories, but think we should have an application process to be able to get funds from any additional round, or max cap to avoid people trying to abuse the system. Maybe in the future we can even weight it, so like the 1st pool a grantee is in has the most matching potential, and it halves in any additional round they get approved for, to give the most relevant grantees priority.

For multiple grants, I’m with you on the enforceable aspect lol. We could “strongly suggest” focusing on one grant per season. But someone can realistically have varying levels of responsibility in different projects, & seems hard to make a judgement call. For me, the potential for fraud outweighs this multi-grant scenario. IMO at least for Beta, we should place a limit of 1 per grantee (to the best of our control).

POAPs seem ok-ish to me if they’re not openly offered upfront, Discord roles feel a little weirder. Are we evaluating this just based on what grantees say in their applications, or are we/the public also auditing them during/after the process?

Don’t like Gitcoin funding NFT drops, but can imagine exceptions with less typical use cases–e.g. such as using grant funding to teach an underrepresented population like how to empower themselves creatively, releasing an NFT collection to further this cause. Giving NFT’s a soft no for Core Beta Rounds, just due to optics and abuse potential.

Matching caps = good :slight_smile: Keep for sure! No opinion on higher/lower

In general: my vote is to be more strict to curate quality projects. Know that our whole schtick is being decentralized af, but grants programs literally anywhere else on this planet are way more stringent, with good reason
 free money lol. As we narrow our public goods funding focus by reducing to 5 Core Rounds (which the community gets to decide) while branching out to wider cases with featured rounds, more eyes (and attacks) are going to be on us. Our teams are leaner now, & we literally don’t have as much manpower to identify donation farmers once they’re thru.

If my responses seem conservative, it’s because Partnerships works hard on a tight schedule to secure grant round support every single quarter :face_with_spiral_eyes: & it is really not easy in this market, so let’s do what we can to ensure it’s only going to the right places–would rather not work to line the pockets of scammers, even just a little bit lol :pensive:

Love that we’re fine-tuning the eligibility with these questions before the round happens! Thanks for kicking this off @koday :raised_hands:

8 Likes
9

Hi all!

From my perspective one project should be only on one core round, while there should be no limit related to Featured rounds.

3 Likes
10

A couple ideas to aid grantees in knowing who is eligible and how best to position themselves for the round–

Web3 OSS Round Eligibility

  • I get the sense that this has been unclear, and different grantees have provided different levels of detail in their updates.
  • Per request of many community members and supporters: quantitative updates are much appreciated. We would love to see the measurable impact you’ve had, via the metrics of success you use to guide your product. Example: “Shipped new code,” does not help us. Better: “Shipped 2 new features and gained an average of +20% new discord members month over month since product launch.”

Ethereum Infrastructure Eligibility

  • I would advocate that this round be subject to the same criteria as OSS: the project must have been in operation for 3+ months prior to submission for the grant. Any less time than 1 quarter means it’s very difficult for our communities to judge the legitimacy of the public good contribution offered

  • I would also specify/clarify that we will want an update of material progress for those grantees who are returning. Again- we <3 a good quantitative metric


Excited for this new category! I know we’ve excluded a ton of amazing work in this space for difficulty in determining which communities are “public goods” and we’ll be excited to let this get decided democratically!

As far as eligibility goes, I would suggest that we ask grantees for this particular round to include any and all social channels that they use to reach their audience, along with audience size. Bigger != better with nascent projects in this space, but this for me is similar to our github requirement: we want to see that you are building. This also gives us an opportunity to share your channels with supporters who can discover you when the grant round opens!

Another thought as we grow into our protocol-led future: for ZK Tech Round Eligibility it would be amazing to take a couple community volunteers who are familiar with ZK to perform technical audits. If you’re interested- please reply here to post your desire to help with this!

And a final point in response to @connor’s post above:

Since we are moving to on-chain protocol underwriting for every piece of the grants process, our protocol must treat individual project wallets for the sake of measuring support for matching eligibility. This is not only the auditable, technically sound solution, but also simply more fair.

In the spirit of giving a platform & giving pre-pre-seed funds to as many new and upcoming projects as possible, it is my belief that we should allow only 1 project per team. Thank you @GoretiFreitas for lovely summary here and +100 to our amazing ability to find and support the super, super early folks!

While we can see you on-chain :eyes: shifting your money through multi-sigs (and we will use more and more on-chain signals to establish grantee reputation), I think we want to trust here that projects not abuse this space to present the same project as if it were actually several public goods contributions, when it is in fact the same project in new clothes
 While you are building amazing open source software that we’d love to fund, your blog talking about that software is not a public good :sweat_smile:, nor is your discord server, nor is your merch shop
 in my humble opinion
 Let’s keep it classy out here, folks.

It is my suggestion that for the beta round, each project is able to join 1 and only 1 of these 5 core rounds; but can be considered automatically for inclusion in any of our amazing partner-matching featured rounds.

I’d love, love us to explore a dynamic process like the one @juanna suggests for the future!

6 Likes
11

Hey thanks for this.

So lots of thoughts and questions in here.

Multiple projects per round

By this we mean I guess, an org having multiple grants for multiple of their subprojects in as many different rounds as possile. This should not be allowed. The organization behind the grant should be identified and if the same, then disallowed to have multiple grants in different rounds to maximize return.

Otherwise we are all incentivized to split our grants into smaller subprojects. I for example could split a part of rotki that deals with infra of the ethereum network and put it in infra and the rest of the opensource app in opensource. And double dip.

Others can do the same. Then it becomes a mess.

Quid pro quo

I really dislike even POAPS and discord roles for donations. Why? Because it’s neither about POAPs, neither roles. It’s about the expectations of future airdrops.

Through the years we have been using gitcoin at rotki people are constantly coming and asking for a discord role because they donated. I explain to them this is not possible, due to quid pro quo rule and also that a discord role would not mean anything.

As the conversation with the user progresses, it always, without fail ends up in one thing. They want the role/POAP as a way to count eligiblity for the future token drop they are sure we will do.

Funding

  • Well-capitalized projects - Not have prior external funding of over $500k USD via venture capital, token launches, or NFT sales

I am one of the people who talk about well funded projects not being eligible. But this sounds a bit too broad. It depends on a lot right? So when did they raise the money? What if they raised a small seed in 2018 and it’s all spent now and they are 100% community based and open now? What’s their burn rate? What’s the team size? etc.

It can get really, really complex really fast. I am afraid I don’t have a good answer as to how a proper rule should look like. It’s more like, every time a well capitalized project tries to use gitcoin, it’s obvious to all and there is community pushback. But don’t know how to codify that in a fair way that won’t exclude projects. Have had talks with many projects like Umbra, dappnode and more about fairness here and it’s very hard to codify it.

7 Likes
12

Thanks @koday for this. And to all for the good input. To your request about further defining Web3 Education - * Providing educational resources:

Do workshop series / a book doing a deep dive into one subject or discipline or one community demographic meet the definition for inclusion?

2 Likes
13

I would argue “no” for this. Disclaimer: As a long time grantee, I do not meet this criteria, but others may. If true, this is a change to the current way things work, and deserves more discussion.

3 Likes
14

I would argue very strongly against this. Not only that, I would add an item to the general requirements so that a single group of people (physical human beings) not present more than one project.

In the past, some groups have presented five or six separate projects for the same exact people. This does not seem fair to me.

One might argue that they are cannibalizing their own potential, but I think more likely people do it to unfairly increase their grant income, particularly if they don’t disclose that the projects are affiliated. If not banning this outright, then perhaps there should be a requirement that they disclose it’s an affiliated project. (With a proviso that if found later to be affiliated, they are disqualified.)

3 Likes
15

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
16

Heavy +1s to @lefterisjp and @tjayrush on their further comments on the multiple-entries per project question. Well said on both counts :clap: 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 :upside_down_face: 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
17

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
18

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 :slightly_smiling_face:

5 Likes
19

+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
20

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