[Proposal] GR14 Round Structure & Grants Eligibility Update

📜 Proposals
42

It actually seems like the two points of view here are not that different:

Option 1: No token policy stays, but projects that want to can apply for an exception and can be approved after a review (case by case basis)

Option 2: Token policy is updated with some general guidelines and thresholds, but projects still are applying anyway when opening a grant and are always subject to review and approval (case by case basis)

I don’t think anyone is really trying to change the policy to “all projects with tokens are allowed no matter what”, but maybe that wasn’t explicitly clear in the initial proposal. I also don’t think anyone is really arguing for a “no token projects allowed no matter what” either.

It doesn’t look like we’ll come to a resolution to make a change before GR14, and that’s ok. But IMO these two options are essentially the same thing in practice. So I suppose the question is, which one is more work for the DAO, and which one is fairer for grants.

I’d argue even if we went for option 1, we’d still want to provide some guidance and criteria about what types of projects/tokens are likely eligible for an exception (so we don’t get as many applications to review that are obvious declines, and so our reasoning is public/decisions are justifiable and applied equally). This makes it even closer to option 2, essentially the same thing.

I think in the long term it will be less work for the DAO and fairer to grantees if we provide general guidelines for what kinds of token projects could be approved, and provide some examples, even if the metrics are not strict values.

So before making a decision here, I think the details to nail down are 1. What is the review/appeal process (I don’t think a BrightID situation with a big forum debate and governance vote is scalable, FDD will likely have to make decisions, all the more reason to set public guidelines), and 2. What those rough guidelines should be (market cap? treasury? funding/runway? type or mechanism of token? etc)

Again, doubt this can happen before GR14, but just wanted to state that I really think most people in this thread are in agreement that certain types of projects with tokens should be allowed, but simply disagree on the best policy to communicate and enforce that.

12 Likes
43

Yes.

As stated above exactly because of this I think we should not change the rule at all now, but instead properly define what token projects are okay.

5 Likes
44

Well said. Totally agree. I think we are all saying similar things here.

+1

3 Likes
45

This conversation has evolved since this post, but I feel the need to clarify the following exchange:

Regarding the vision for Grants 2, it is not our vision to change the way Gitcoin runs its rounds.

It is our vision to enable grant programs outside of Gitcoin to come to their own policy decisions with their communities and to tailor their programs to their needs. These will and should differ from the set of choices the Gitcoin community has made to run our grant rounds.

Let’s not conflate the choices we make for the running of our rounds at Gitcoin, with the choices other communities may make when using the Grants 2 protocol.

The community decided policies for Gitcoin grants will still hold when Gitcoin runs its rounds on top of Grants 2. :handshake:

8 Likes
46

Thanks everyone for the thoughtful dialogue here - eligibility is definitely a nuanced topic, and it is great to see so many people engaging so passionately.

The proposal is now up on Snapshot for voting.

4 Likes
47

Thank you for the clarification. I forgot to specify that the main round will not align. It’s also a very good idea to let the communities decide.

You/we could inform them and brief the round owners on how we suggest they should run their round and what are the biggest issues/vulnerabilities and no-no’s :smiley: (that we encountered)

2 Likes
48

There has been a lot of debate here, I want to mention I really appreciate the discussion. It’s opened my eyes to a number of use cases I hadn’t considered, and the broader implications of us denying a grant.

I still feel that those with a token should apply, get denied, and then appeal. I know this creates friction for us, but to me it send the “right” message that token launches (which fund a project) are a big deal, and exclude you for funding from the community match pool.

Like it was pointed out, we want to offer more granularity to those ecosystems who are okay with having a token, but we dont have that ability yet. so… for GR14, I would say we keep the rules the same and then evaluate once we have Grants 2.0 ready.

1 Like
49

Agree here and should those allegations be true it is 100% not conducive to levelling out the playing field in terms of access to resource

1 Like
50

A protocol should always be un-opinionated and specific communities should come with their own rules. A best practices can be shared based on Gitcoin experience but again, each community will be able to take what they need and leave the rest

2 Likes
51

Can we apply a matrix here as I am trying to do in the governance flow so that an easily digestible and usable format is in place for people to be able to self determine eligibility? Almost a “are you aligned enough to ride” dynamic where we have a set of attributes that must be met for an eligibility score?

Very much pulling from the engagement score we’re been working on with Steward Cards and creating a pattern of self evaluation and accountability vs pages of text…

3 Likes
52

There is a side-effect to making the eligibility change. A likely big increase in approved grants.

I think this will have beneficial PR optics in a time of decreasing momentum and bear markets. In season 13 we had our first decrease in numbers…this doesn’t paint a nice picture. How much better would it look if we were able to announce big increases to approved grant numbers?

This might help extend our Overton window…

Also, I want to re-state my view that

If a project is a true public good it really doesn’t matter whether they have NFTs or other tokens.

If only we could quickly hold community polls about the projects of questionable public good benefit we could ignore the entire token/nft debate. If a project is deemed a true public good or public-good-benefit by the majority of our community the fundraising methods become irrelevant (unless illegal or unethical). The more fundraising such a project achieves the more benefits accrue to public goods. Even if by an NFT sale.

2 Likes
53

We will always be here for consultancy. I was talking from a POV in which it would be a waist of resources to not share with them what we believe is of crucial importance for their success. :slight_smile:

2 Likes
54

@David_Dyor - we discussed the last round the eligibility for multiple grants proposals from one DAO/organization, so I just wanted to check if multiple-proposal from one community is still not an option.

to recap on the specific topic:

  • Bankless has 23 000 members, and they are working in self-organized groups, called guilds and projects.
  • Some of the projects may/may not be a public good (Bankless Academy, Bounty Board, DAO dash, Ultrasound merch, and many more)
  • As of now, a few tried to apply but have been declined based on the one DAO one proposal rule

My question is if this rule still applies for GR14 or not

And my second question is, does this rule apply only for the main matching round or overall.

55

It surprises me sometimes how far we’ve gotten away from the original intent of the Quadratic Funding paper. The ‘curator’, at least in my reading of that paper, was supposed to be the community itself.

I feel that what’s happened is that “GitCoinDAO” the organization has taken over “Curation” task and as a direct result any hope of the community building that skillset themselves will disappear. The obvious, logical conclusion of the path we’re on is human-in-the-loop, centralized KYC.

The discussion should not be about whether or not a centralized workstream should allow or disallow projects to participate with or without tokens. It should be about how we can enable, teach, train, and foster an environment where the community builds the skillset themselves.

Having said that – we shouldn’t allow projects that are already funded with tokens to receive matching funds.

56

Right now the vast majority of projects that have tokens also receive some funding benefit from them (e.g. holding in treasury, selling to investors, etc) upon launch or sometime in the future when tokens become transferable. In these cases, I don’t think it makes sense for them to get matching funds on Gitcoin so we can prioritize public goods that don’t have a clear funding mechanism.

I lean towards the process of token projects that aren’t using them for funding (e.g. team/treasury didn’t retain any tokens, etc) can apply for an exception. I also believe we can adjust the eligibility later on if we’re seeing way more tokens unrelated to funding.

2 Likes
57

Agree. So I hope the FDD team can share these refined guidelines.
For now I will abstain from voting because it is unclear to me if a yes vote would lead to rushed implementation. I do not think this will be the case but would love in any case to see the draft of these eligibility criteria first and hear if they will already be used in GR14.

58

Although I voted for, if “against” wins, we will need to rapidly update the appeal process to execute in a day or two for most cases. This is doable for GR14. Thanks @annika for getting ahead of this so we can prepare based on the results of the vote!

2 Likes
59

Since the criteria published in gr13 (and historically) is “A project should not have a token” we do not need to create an exception/exemption process imo. FDD reviewers can already recommend approval of projects with tokens based on their judgement & discretion.

The FDD put forth their recommended changes to token-policy in GR13 which did not proceed to Steward vote.

Since then there has been intermittent coordination between PGF and FDD to try and come up with a suitable suggestion that might reach and pass Steward vote. Unfortunately there seems to be a diverse range of opinions on how best to deal with the token issue which doesn’t appear headed for fast resolution. The matter is bigger than the FDD alone imo. This is why the FDD attempt during GR13 did not reach the voting stage. People wanted to contribute to the discussion and did not want the FDD deciding unilaterally.

Feels like we are drifting from the topic of GR14 structure but since the appeal process was brought up I can give a brief summary:

  1. All appeals requests are started via a Google form (posted on the Grant Eligibility Notion page).

  2. FDD assesses all requests for merit. Any with merit (usually based on simple mistakes) get processed internally by the FDD unless they are based on a Novel Situation (NS), which is the most complex case, as we saw with BrightID

  3. The google form states that NS appeals will get 3 days of Gov forum discussion followed by 3 days for Snapshot vote. The 3 & 3 timeline, suggested by FDD last season, has never been used (or approved by Stewards). (imo we need to eliminate Steward voting from the Appeal process for true efficiency).

  4. FDD is engaging LexDAO to help refine the process, especially for NS. This part of the process is an experimental work-in-progress that has not been ratified by Stewards. Instead of clinging to historical procedures designed before the Dao existed the FDD is now considering the challenge from a blank-slate perspective, now with LexDAO.

Notes:
-Most appeals other than NS can be dealt with quickly (<48 hours).
-The plan is to replace the FDD assessment stages with assessment by a decentralized group.

What does this mean for GR14? The FDD is prepared to deal with the majority of appeal requests quickly. Should any NS Appeal get requested we should expect dao-wide lengthy vigorous debates.

2 Likes
60

From my perspective, as someone who has been with Gitcoin Holdings for over 3 years, what we see happening with the GitcoinDAO and FDD/PGF workstreams is exactly what you describe, community curation. 2 years ago approvals and eligibility were solely handled by people within Gitcoin Holdings, with no governance or public debate.

FDD’s evolution IS the community building that curation skillset, why would that hope disappear? Anyone can join the DAO and volunteer to curate, we’re having these open debates in a public forum on policies/appeals, governance votes are open. Sure we could have the community more involved using a governance vote on every grant application but that would be a bit messy…

These aren’t mutually exclusive, we need a platform-wide general policy that the community agrees to, and we also need to enable + train the community to curate (FDD). The reality is grant reviewing, curating, and approving, is time intensive and not the most fun work. No one is going to do it for free just to build a skillset, we need to compensate those putting in the time and effort, hence, a workstream is created.

I don’t think this is obvious or logical, we’re on the opposite path, this is where we started, and we’ve been progressively moving away from it.

But yes I do think we could build out a more decentralized dispute and arbitration system, maybe with staking, voting, incentives, etc. But we’d still need a general platform-wide policy.

I also want to say that this is all specific to GitcoinDAO operated rounds - ideally with Grants 2.0, anyone will be able to run their own custom round whenever they’d like, and choose how they curate (via a centralized team or decentralized community).

5 Likes
61

I think you missed my point. The point I’m making is that in the original paper, the curation function was supposed to be handled by the individual donations from the community. That was the mechanism that was meant to curate “good” projects from “bad.”

There was an acknowledgement in that paper that there was a Sybil problem, but there was no mention of a gatekeeper (that I remember). I’m talking about the gatekeeping function.

There are well-established methods to do gatekeeping in a non-smart-contract (i.e. human-in-the-loop) world. Those methods are called KYC.