[Proposal] GR14 Round Structure & Grants Eligibility Update


This proposal looks to finalize round structure & matching pool allocations for Grants Round 14.

In addition, we’re proposing a policy change to platform-level eligibility for grantees, following the many discussions on this topic in GR13.


  • GR14 will look similar structurally to GR13, as we hone our innovation focus in on Grants 2.0 and launching the protocol

  • We are standing up a dedicated ETH Infra round in order to more intentionally support Ethereum protocol development

  • We are proposing removing the “grants should not have a token” criteria from platform eligibility

Round Structure

GR13 Recap

Main Round

In GR13, we continued on with the no-category approach & the 2.5% main pool matching cap that we had successfully tested in GR12.

As background, prior to GR12, the main pool was divided into categories that assigned pre-set percentages of the pool to grants in specific disciplines or geographies (“categories”).

Since then, we have done away with that category-based main pool approach, and instead have been scaling thematic matching pools outwardly with Ecosystem & Cause Rounds, which are dedicated QF pools for specific projects & domains. See the GR13 & GR12 posts for more context.

Based on community feedback, the no-category approach and 2.5% matching cap continued to satisfy their intent and people are excited by the benefits that cap continues to bring to the longer-tail of grantees (funding many grants vs. letting the top few take the lion’s share of the pool).

Ecosystem Rounds

Based on ecosystem partner feedback, Ecosystem Rounds – rather than main pool categories – are an offering that there is a clear market need for us to continue with & build upon.

We’ve grown Ecosystem Rounds substantially – from 2 in GR11, to 5 in GR12, to 9 in GR13 – and are seeing demand in GR14 from ecosystems that are new to working with Gitcoin, a testament to product-market fit of that offering in spite of market turmoil. We ran retrospectives with several partners after GR13 to get their input as we build these out further.

As we work towards giving ecosystems more agency over their own rounds, we are seeing some awesome community-led innovation take shape. A few examples to note from GR13:

  • Collaborative ecosystem rounds, like ZK Tech & Open Gaming

  • Novel funding mechanisms, like Radicle’s Drips

  • Ecosystem round matching caps: In GR13, we offered the option for these rounds to set their own individual matching caps. All nine rounds took us up on this offer, selecting caps ranging from 10-20%, allowing ecosystems themselves to test QF based on their own needs

As we look towards Grants 2.0, a world wherein anyone will be able to stand up their own grants program, we want to continue to enable ecosystems to successfully run & innovate on their own rounds on top of Gitcoin, rather than Gitcoin doing this work in a centralized way.

Cause Rounds

Cause Rounds are rounds funded by external sponsors for clear sets of global public goods, and represent Gitcoin moving beyond just Web3 & Digital Public Goods, and into Public Goods more broadly speaking. These rounds expand the user base & TAM of Gitcoin Grants, and have successfully brought in funding interest from major Web2 philanthropists.

In GR13, in addition to continuing with the Climate & Longevity rounds from GR12, we added a ‘Support for Ukraine’ round. This round was successful by all accounts, raising $700K in matching funds in the span of just a couple weeks to provide humanitarian aid given the crisis in Ukraine.

All this said, we continued to learn acutely in GR13 that Cause Rounds represent a lot of operational overhead for Gitcoin – since there isn’t usually an external lead driving these rounds forward like we have with Ecosystem Rounds, a substantial lift falls on the PGF workstream for these rounds.

As a result, until we have the Grants 2.0 protocol which will enable anyone, anywhere to stand up their own Cause Round, we plan to grow these rounds vertically, rather than horizontally (i.e., doubling down on just a few key rounds and scaling funding within those rounds). We don’t have the resources to run many small Cause Rounds in parallel.

GR14 Proposal

We propose GR14 look a lot like GR13 – partly because the community feedback we have received on the direction of the last couple rounds is positive, and partly because we are honing our innovation focus in on Grants 2.0 and launching the protocol.

Context: Grants 2.0 & Maintenance Mode

To be explicit about the second point above: Grants 1.0, the centralized platform on which our program currently runs, is now in maintenance mode. The product team will fix any bugs and continue to maintain the platform as we build Grants 2.0 in parallel, but no product resources are prioritized to innovate on the current platform.

This limits how much we can play with the grants program in the near-term, but is the right long-term direction given the vision we are working towards.

Given the above context, we do not plan to make substantial changes to the grants program structure or do any substantial innovation on QF over the next few rounds, with an eye to this longer-term big play we are marching towards.

Proposed Round Structure

As a result, the Public Goods Funding workstream proposes that the structure of the round remains the same for GR14 at a high-level.

In summary, the structure of the round will remain:

  • A Main Pool (of up to $1M)
  • Ecosystem Rounds
  • Cause Rounds

Main Pool

The GR14 main pool will be a single matching pool fund/distribution of up to $1M in matching for the round. As in GR13, no individual grant’s matching contribution amount shall exceed 2.5% of the overall matching pool fund.

We are specifically requesting “up to $1M”, rather than a specific amount.

This “up to $X” is something we’ve been discussing for a bit – while historically we’ve requested a specific amount, we actually don’t think it makes sense for governance to ratify a specific amount prior to the round. Doing so prematurely and setting too high an amount can cause us to unnecessarily pull funds from the multisig – since when these posts are created, we are still fundraising for the main round. This is especially timely right now given the down market, and the fact that we have seen some funders rescind commitments due to that.

Ecosystem Rounds

In GR14, we plan to run roughly ten Ecosystem Rounds. As in previous rounds, these are pass-through funds that are not drawn from the existing multisig balance, and once again we have a mix of new & returning ecosystem partners funding these rounds.

Within the ecosystem rounds we plan to run in GR14, we are particularly excited to announce a new Ecosystem Round we are being intentional about standing up: an ETH Infra round focused on protocol devs in the Ethereum ecosystem.

This round was spun up in response to the discussion here – and as we expand Gitcoin Grants beyond just open-source in the Ethereum ecosystem, we believe this is an important round to prioritize in order to ensure we are continuing to have a dedicated funding pool for protocol development.

Cause Rounds

In GR14, we plan to run three Cause Rounds: a Climate Round, a Blockchain Advocacy round, and a new DEI Round. As with Ecosystem Rounds, these are pass-through funds that are not drawn from the existing multisig balance.

Grants Eligibility Update

We are proposing an expansion to grants eligibility in GR14, based on (1) the direction we are headed with Grants 2.0, and (2) the BrightID appeal which brought into question the existing eligibility criteria.


Since its inception, Gitcoin has been focused on funding public goods. In the early days of the grants program, there were no eligibility criteria highlighting ‘what’s in’ and ‘what’s out’ – anyone could get approved for a Gitcoin Grant. At one point, it was brought to Gitcoin’s attention that there were grants on the platform that did not meet the ethos of ‘public good’, and the following norms were established for grants eligibility:

  • A grant should not have raised over $500K in VC funding

  • A grant should not have a token

Today, FDD declines grant applications that meet these criteria. In addition, community members have the ability to ‘flag’ a grant they see on the platform that they believe should not be deemed a public good, which then sends that grant to FDD’s dispute process. Denied grants are offered a chance to request an appeal which are vetted by the FDD. The ideal process by which appeals might trigger policy revisions (and vice versa) have not yet been established. FDD has consultations with LexDAO Impact Clinic planned.

Where we are today

As outlined in this post, the landscape has evolved and many early-stage projects, like BrightID, that the community would deem eligible for grants do have small token experiments.

In GR13, as we pursued the BrightID appeal, we explored the idea of allowing tokens under a certain market cap. We realized quickly that there is a ton of complexity associated with this – token reporting is non-standard, and setting a market cap would be too arbitrary a criteria that would likely continue to require much manual review.


PGF & FDD are recommending that we remove the ‘a grant should not have a token’ criteria from our eligibility.

As per the existing rules, the removal of this criteria does not mean that airdrops and quid pro quo offers will get through, only that the existence of a token doesn’t automatically disqualify a project. QPQ also applies to/includes non-monetary rewards.

As with the BrightID appeal, we want to move in the direction of putting the definition of a public good into the community’s hands, rather than having this be something Gitcoin prescribes centrally. As the result of that specific appeal makes evident, the ‘has a token’ criteria is not a good barometer of what the community considers a public good – and so we propose broadening the aperture, and triaging appeals on a case-by-case basis.

In addition, we will work with the product team to determine what changes we might make in assessing whether a project is a public good at application stage (e.g., requiring projects with a token to submit a brief writeup on why they should be eligible).

Grants previously turned down for having tokens will need to re-apply and will not automatically be re-reviewed with this change.

Voting Options

We will ask the stewards to vote on three options:

Option 1: FOR GR14 Structure & FOR New Eligibility

You approve the GR14 structure as is, and are in favour of us removing the “no token” eligibility requirement.

Option 2: FOR GR14 Structure & AGAINST New Eligibility

You approve the GR14 structure as is, but are NOT in favour of us removing the “no token” eligibility requirement. If this option prevails, GR14 eligibility will remains as-is.

Option 3: AGAINST GR14 Structure

You do not approve of the GR14 structure, and will be submitting an alternate proposal for consideration.

Once we have feedback on both this and any other proposals, the Public Goods Funding workstream will gather all formal proposals and submit a Snapshot vote to decide which to move forward with.

Please do not submit a snapshot vote for your proposal specifically! This just adds confusion and makes it harder for the community’s voice to be heard effectively.


Hey Anika,

Thanks a lot for the post and for explaining where gitcoin grants 1.0 stands right now.

About this I am really torn. I really think neither FDD nor anybody has the ability “triage on a case by case basis”. This is why rules like no token, or less than $X in VC funding are helpful. They make it easy to weed out applications.

It’s very easy to cheat if we triage on a case by case basis. If nothing else simply DOS the people who triage. Claim that token is not owned by the entity applying, claim it was a fair launch and nobody in the team kept any tokens and other things that are impossible to verify with certainty.

Handling token projects

I understand this is not an easy problem to solve and it has no good solution but there is multiple approaches to take.

As before

As we did before. So set out rules that help guide and set the spirit of how gitcoin grants should work. This makes it manageable by whoever goes through the applications. Especially considering that gitcoin grants 1.0 is in maintenance mode. People can still appeal and explain why their token project is an exception. (these would be a minority).

Drop the no token requirement

Say we accept everything and tokens and all is okay but have to make decisions for every project on a case by case basis. This is not manageable in my opinion and also sends the wrong message about what kind of projects gitcoin should fund.

The vast majority of token projects follow a certain formula. Which is to keep a certain % of the supply for themselves in their treasury which gives them a big pot of money to work with. Funding such projects further through gitcoin grants sounds ridiculous to me.

For the token projects that may be an exception to this rule I would say ask them to appeal on a case by case basis, based on a document that we should create specifying what kind of tokens are acceptable.

So make it possible to appeal, but still keep the no token rule, which would both:

  1. Save us time and effort
  2. Send a clear message on what kind of projects should be funded by gitcoin

My recommendation

So at this point I believe I would vote for and ask other stewards to vote for Option 2.

Option 2: FOR GR14 Structure & AGAINST New Eligibility

You approve the GR14 structure as is, but are NOT in favour of us removing the “no token” eligibility requirement. If this option prevails, GR14 eligibility will remains as-is.


I couldn’t agree more. I will be voting for option 2.

If projects that have raised money via token sales are permitted to participate, GitCoin will devolve into a marketing campaign.

I’m not sure I understand what the justification would be to allow token projects, other than perhaps it’s a recognition of the impossibility of the task of identifying them – I understand that, but I don’t think turning away from the challenge is the solution.

One of the things that makes the task of identifying misbehaviour is the speed of the rounds and the fact that the donations are delivered directly upon receipt. In GitCoin 2.0, if every grant recipient was forced to be a smart contract, there could be a three-month escrow of the distribution for both the match and the actual donations. This would leave more time for human evaluations which would make it more effective. Perhaps this would make it less likely that people would try to cheat.


Similar to the above comments about not funding projects that have their own tokens as reserves (100% agree), I also feel strongly that the lobbying groups (eg Blockchain Association and Coin Center) should also be excluded from matching. These groups have exorbitant funding from corporates, venture capital, and very deep pocketed individuals. In GR12, CC and BA combined received ~$440k in matching. I’ve been to several parties these guys threw during this period, and you can safely assume a good chunk of this change went not to furthering public goods, but wining and dining Capitol Hill staffers and officials. Allocating matching capital to them that could else wise go to furthering open source / public goods is not in line with Gitcoin’s stated mission. This ship has probably sailed, but just wanted to make the point.


Great work @annika
I am just curious what does DEI mean in this context?


Oooof did not know they are still getting funded by Gitcoin. Strong + 1
Especially if your allegations on exorbitant spending are true.

1 Like

Just my 2 cents: this is an important part of effective lobbying, it’s not just having meetings with legislators and educating them, unfortunately. A group that wines and dines people versus just sitting down with them over a powerpoint presentation is more likely to get support, that’s just human nature, especially for people that work in DC.

I would personally consider donating to both those organizations probably, if they were in GR14. Political risk to web3 is huge and can’t be ignored, and impacts any and all public goods built on top of it! :slightly_smiling_face:

Just want to give a different perspective on that point! I wouldn’t want to see all the funding stay with companies for orgs with such influence on fiat law, and Gitcoin seems like an ideal avenue to address that!

1 Like

Just my 2 cents: this is an important part of effective lobbying, it’s not just having meetings with legislators and educating them, unfortunately.

Yep, this indeed how our world works and I don’t disagree. I just don’t think matching pool should be used to fund it, especially given (1) CC and BA’s goals aren’t to further public goods / open source, (2) they have ready access to capital, and (3) it takes away from smaller projects that rely on Gitcoin.


I think this is a very fair take. I’m not extremely aware of how funds are spent by these lobbying organizations (and I generally hate the idea of lobbying altogether, but I get why it needs to be done).

I understand both sides of why funding advocacy is essential (especially right now), but also that these orgs may already be well capitalized.

I do just want to note though, when you said:

The reason why their matching was so high in GR12 is because the donations from matching funders specifically for the Advocacy round was $900k (?) while there are so few grants in that category. Perhaps the corporates, VCs, deep pockets you mention that fund these groups anyway were a primary driver for funding that matching pool. So optimistically, it’s money that would have went into their pockets anyway, only now the general public gets a more democratic say in how it’s distributed

You’re correct these grants still take some funds from the main pool, but the max cap was 2.5%, so $25k. I don’t want people thinking CC and BA took $440k from the main pool funds that would have gone to smaller projects, it was more like ~$30k. But yeah I think there is a case to be made that we should decouple some cause, and ecosystem rounds from the main pool, and I’ve made this case internally. We just need to better define what the main pool should include.

See results from GR12 broken down by round here:


I’m also on the fence with token requirements, I think it’s very hard to define.

NFTs are tokens. There are *actual valueless governance tokens. There are non-transferable tokens. There are groups tokenizing carbon credits. There are tokens that were airdropped with 100% to the community. There are projects with tokens with no treasury or founder-owned allocation. There are projects doing purely charitable work or UBI with tokens.

There are projects doing work with for a larger org that may have a token but the project owners don’t manage it (all the bankless grants). Work on EIP-1559 I believe got some early funding via Gitcoin Grants, but Ethereum has a token :wink:

Where do you draw the line? I think tokens are going to be a core part of lots of different areas of web3 (more than we even see now), and many can be public goods but still have a token.

I definitely agree with you here, and maybe the rules should be no tokens sales, or no token sales that raised >$500k (or whatever the VC threshold is).

Rather than an arbitrary measure of market cap (like $20m), I think it should be more of a consideration of whether their work can be / is funded by their token, and whether the project is a public good. But of course that’s impossible to define and will require manual reviews.


As stated in my post the easiest way which would end up with less work imo is to keep a simple requirement and if a token project, like BrightID, feels they should be an exception apply and explain why.


It’s worth considering that the centralised “no token” policy excludes:

  • any hyperstructures (which is a huge space to explore for sustainable public goods, and arguably the future of sustainable FOSS)
  • any public good project using a token for governance
  • any public good using token-gating with communication
  • any project that even looks like it’s building on defi mechanics (eg. just saying you’re inspired by Uniswap/Maker)

So the current policy just cuts out good public goods projects on the first pass, not even giving them a chance to participate on their own merit in the community match-funding.

We’re starting to conflate has token with funded by token in this debate, and so does the current policy, which is the problem being addressed by the suggestion to begin with.

I think the proposing teams could help inform this discussion by sharing some of the specifics to illustrate why they came to this suggestion. As a grant applicant, I saw a high load of appeals on Discord, and also noted appeals finding their way through backchannels, so I don’t think this was a few isolated cases like BrightID.

I also looked through the Notion tables showing the applications and approval pipeline – something I’d suggest delegates could do if they want to get more specific situational awareness.


I would like to vote AGAINST token, and agree with @lefterisjp and @tjayrush .

Reason 1: we need to keep consistent with the rules without token.
Reason 2: Most token is delivered by token sales (and the project team had capability to feed themselves)
Reason 3: Some token projects are not public goods.
Reason 4: I don’t know the reasons (and discussions) for allowing token for the grant. Maybe there are more contexts in FDD and PGF, and would you share more? @annika

For token projects, we could review them case by case.


The vast majority of token projects are funded by their token in one way or another.

The exceptions can appeal.


Are you stating that generally, or based on the Gitcoin applications?

1 Like

Generally. Which would open the floodgates for everyone and their grandma’s chicken to apply for extra funding from gitcoin grants since suddenly token projects would be fine.


I share the same sentiment with @bobjiang on voting against token. Nevertheless, the exceptions can appeal as @lefterisjp rightly said. The good example is in the case of Bright ID.

Above all, the most important thing to look out is whether the project is a public good that need to be funded.

1 Like

This is conversation has been on-going since a while in the FDD over the grants eligibility criteria…
I have to mention a few points here:

  • Governance token have no values… (We need to make a distinction in-between governance token, monetized token and experimental tokens…)
  • Side rounds thematic should be clear or depending on the funding partner, they could have the opportunity to debate/decide to allow a grant who has a token in place, or plan to have a token in the near-by-future which has been seen many times over many grants (Most of them has been denied) But BrightID is a strong example.

In my view, we should keep the main eligibility criteria, under 500k in VC funding or external funding and no quid pro quo as the 2 main standards.

Grants that has been denied in the past or currently, can always re-apply, or they can appeal the decision (This can take days and they might not be up for the current funding round)

I agree

Based on this, I am voting for Option No.1

1 Like

Oh but they very much do

We can call them “useless governance tokens” as much as we want but it does not change the reality of the situation, which is they very much have value, and are a funding mechanism.

I don’t believe that I need to write this … but Gitcoin itself is the proof.


I think we should be able to make a clear distinction over Governance Token (There is 2 side on that medal) Monetized Token and Experimental Token at this point…