[Proposal] Grants Policy Update: Projects with Tokens

📜 Proposals
1

Abstract

This post is intended to provide context on, and guide the community to a decision around, grant eligibility criteria as it pertains to projects with tokens.

This post is a Part III follow-up & summary of existing discussions outlined in these two recent governance posts: Novel Situation #1, and Proposed Revision to Grant Eligibility Criteria.

We acknowledge this is a net new policy evaluation happening in the middle of a grants round, seeking to bring near-term resolution to a policy ambiguity, which is not ideal. In doing this evaluation, we have identified the need to craft a longer-term, more deliberate & community-involved process for grants policy definition that spans across workstreams.

Context: Existing Policy

One of Gitcoin’s legacy eligibility criteria reads that, to be eligible for a grant on the Gitcoin platform, a project “should not have its own token or have raised over $500k in VC funding”.

This criteria was put into place in early 2021 before the DAO provided a strong governance model for Gitcoin Grants. The Web3 space has evolved substantially since then, and many early-stage projects now launch governance tokens at inception.

These tokens often have little-to-no economic value at the onset – and, as such, questions have been raised about whether this eligibility criteria should be revised to be more inclusive to these types of projects. Currently, FDD is declining all grant applications that have their own token of any sort.

This includes:

  • Projects which currently have a token
  • Projects which have any mention of an airdrop or sale on their grant page or any of the links on the grant page including their Twitter, Website, or github.

Bright ID Case

BrightID grant #191 was flagged by a user during GR12 as having a token. This dispute was escalated to the review team which determined that they are ineligible because they do have a token. After GR12, an appeal was raised by the BrightID team on this topic. This appeal relates to their existing grant, which has raised over $150K in Gitcoin Grants funding in prior rounds.

The email outlining the appeal, which can be read in full in this post, served as a catalyst for revisiting & re-evaluating this eligibility criteria, as well as for more clearly defining the FDD Appeals process as a whole (future post to come on this).

Proposed Policy Amendment

After extensive cross-workstream dialogue, as well as public discourse in the comments on the posts mentioned above, PGF & FDD propose revising the criteria as follows:

A project in the Main Round cannot:

  • Have a token with a fully-diluted market cap of greater than $20 million
  • Have raised over $500k in VC funding

We recognize that these criteria are somewhat arbitrary, but we believe creating an objective starting-point threshold from which we can iterate, rather than maintaining the status quo of nebulous criteria, is a) more scalable for the program long-term, and b) much clearer to current & prospective grantees.

Finally, the verbiage “in the Main Round” was specifically included to give us the flexibility to de-couple Ecosystem & Cause Rounds from this logic in the future. Today, all QF-eligible projects on the Gitcoin Grants platform are in the main round – so this applies to all grants for the immediate term – but we may de-couple ecosystem/cause rounds in the future, such that the funding partners of those rounds can make their own decisions around eligibility for their pools.

Grants Policy Definition Process (Longer-Term)

This discourse has led us to the realization that there is not clear accountability or process as to “who defines grants policy, and how?” – whether it’s PGF, FDD, the community-at-large, or a combination thereof, and how we collaborate and govern policy definition. We certainly want to make this a joint, community-heavy domain, and that is something we need to improve on as we continue to progressively decentralize the running of our grants programs.

As a next step, PGF & FDD will come back to the forum prior to Grants Round 14 with a proposed policy definition process for discussion.

Snapshot Vote

In the interim, on the ‘Projects with Tokens’ policy, we propose moving to a Snapshot Vote with two options:

1. Maintain “no token” status quo

This would mean that we continue with the ambiguous policy (“a grant should not have its own token”), and leave case-by-case decisions in the hands of FDD.

In this case, the Bright ID decision would be handled centrally by that group and would not continue further through governance.

2. Adopt new $20M market cap threshold

This would mean that we would adopt the new policy to be implemented for all grants as of GR13. Grants previously denied in GR13 for having a token would have an option to either submit a new grant (preferred) or appeal their old grant’s denial.

In this case, the Bright ID decision would be made by this criteria. Given that BrightID’s FD market cap is $7.6M at the time of writing, and they confirm to have not raised VC funding, they would continue on as a grantee eligible for QF in GR13.

Allowing projects with tokens to not be immediately disqualified does not mean that ALL projects with tokens having a market cap under $20 million will qualify. These grants must still pass all other platform eligibility criteria.

Wrap-Up

Given that this post is a “Part III” follow-on post and that community discussions on this topic started ten days ago, we plan to move this to a Snapshot vote on Tuesday, March 22nd. This will allow us to have the decision ratified prior to the end of the GR13 dispute period.

Thanks to @DisruptionJoe, @David_Dyor, @connor, @seanmac, @M0nkeyFl0wer for your collaboration & input.

12 Likes
2

Thank you for this post Annika.

Indeed the “have a token” criteria may have been way too arbitrary.

But the marketcap proposal sounds equally arbitrary, doesn’t it?

What if a developer team creates a token, gives all of it to the community and it has $100m marketcap? They would still have kept nothing for themselves, thus would have no funding at all from the token.

I would guess we would really have to do a case-by-case study, see how the token operates, how many tokens does the team have, and if it is the same team that requests the funding for the gitcoin grant.

Generally the idea is not to punish anybody here. It’s just to not let greedy people take money from projects that have otherwise very small sources of funding.

For BrightID’s case I have no idea how much they have raised from the token if there was a sale, how many tokens they kept etc. so I can’t really give an informed opinion.

1 Like
3

Lefteris,

I believe the “$20 million market cap” is a suggestion that puts some reasonable, though arbitrary guideline that helps us start fine tuning the logic. I also think it is important to say that we are setting precedent on how we want the Gitcoin ecosystem’s judicial system to work in the future.

The stewards could vote to switch this model in the future so I think both avenues are safe to try.

In practice, this vote will guide us on which judicial model the community prefers us to try first:

  • Option 1 - A separation of judicial and legislative branches where the judicial branch judges on a case by case basis setting precedents which the legislative branch can turn into policy in the future.
  • Option 2 - A system where the policy is continually fine tuned by the votes of the community. In this model FDD uses a letter of law approach and an appeals system guides us to refine and redefine policy as we see the letter of law interpretations diverging from the community’s interest.

Ideally, we would build out a system which would move the functions executed by FDD now, to be executed by the community in a distributed and fair way in the near future. For the time being, FDD would have to both supply judgements AND build the system for the community to supply judgements.

ANOTHER WAY TO FRAME THE VOTE

OPTION 1 - MAINTAIN “NO TOKEN” STATUS QUO

How it would play out for BrightID

BrightID appeal would most likely be upheld and they would be allowed to participate in GR13.

Unless there was significant objection, FDD is currently in favor of ruling to uphold their appeal for the following reasons.

FDD has already found through our Polis surveys that the community overwhelmingly wants us to fund public goods over following the letter of the law. In this case, BrightID is clearly building a public infrastructure needed for digital democracy. Their token was an opportunity to let the community drive it’s governance.

The token has not provided sufficient funding to allow BrightID to continue building.

How it would affect the Gitcoin Ecosystem moving forward

This would set a precedent for many other appeals to be judged case by case by FDD which would act as the judicial branch of the system.

Once a pattern was seen, then it would be appropriate for the legislative branch (Stewards) to create policy which would “hard code” the bottoms up norms created by the community.

I think it might help to say that option 1, letting FDD decide on a case by case basis is similar to English common law allowing the high courts to adjudicate on a case by case basis. The results of these cases comprise our legal canon which can all be used as relevant examples used to determine precedent.

FDD has continued to advance how decentralized and transparent our processes are. While not near perfect yet, we have come a long way from Kevin or Joe deciding. For GR13 & 14, FDD would be deciding most cases while building a system for the community to decide in the future.

In this scenario, I would push for FDD to create a tiered appeals system with the following characteristics

  • Creation of oversight mechanisms at “appellate court” level
  • Implementation of external appeals panel (Jury duty!)
  • High quality documentation of cases and processes to make FDD appeals process “forkable”

OPTION 2 - Adopt new $20m market cap threshold

How it would play out for BrightID

BrightID would be eligible for GR13 as they would not be in violation of any policy.

How it would affect the Gitcoin Ecosystem moving forward

Option 2 would fundamentally change how the policy for the Gitcoin platform (and currently the main ethereum round as well) is governed.

In this system, an appeal to the current policy not matching the intended desires of the community would trigger a quick research and writing process wherein FDD & PGF would draft a policy update to be voted on by stewards.

The FDD would then judge each grant application based on the letter of the law, removing an opportunity for bias. I believe this will actually help us build a scalable future.

FDD is working to build tools that help the community validate whether grants match a criteria. In this type of system, the community members themselves would participate in judging whether grants met a specific criteria. FDD’s role fundamentally changes from judge to builder of a trustless system which is less expensive to defend than attack.

In conclusion

My vote will be for option 2. I believe it is:

  • Less empowering (and stressful) to FDD
  • More scalable
  • Fixes some fundamental problems in the US legal system by being built on better communication and value rails.
6 Likes
4

I see you are trying to solve 2 different problems here in a misguided way.

Problem 1: BrightID not having sufficient funding from the token so they should still be eligible for gitcoin grants.

Problem 2: Figure out a way to judge which projects with tokens should be eligible for a gitcoin grant and which ones should not.

The proposed solution seems to try and address both which it should not. The 20m marketcap is arbitrary for the reason I explained above. It does not really address problem 2.

The argument that we can change it later to make more sense does not sound like a sufficient reason to go ahead with this change.

From what I understand there is a pressure of time (?) in order to make BrightID still eligible for GR13 before ratification? Then let’s just try to address Problem 1 and think on Problem 2 a bit longer.

The information we would need for this is how much funding does the brighID team itself has gotten from the token.

  1. Was there a token sale? If yes how much was sold and what was received.
  2. If it was just a token creation event how much of the token does the team own?

I think we all want the same thing in the end. Let’s just go towards it the right way without rushing to create new rules without thinking them through first.

3 Likes
5

I would just echo the above that Problem 2 is a quite complicated question involving the evolving nature of Gitcoin governance. It should be parked until after the round.

A decision on BrightId is clearly more pressing. It seems Problem 1 is already answered in that ‘the community overwhelmingly wants us to fund public goods over following the letter of the law.’ Since BrightId is ‘clearly building a public infrastructure needed for digital democracy’ then the surveys tell us the token issue is not the deciding factor here.

I don’t think this particular case then needs to be binding for all other cases.

Regarding Problem 2, I also wonder to what extent the community would be happy to see issues like this delegated to FDD. I’m not super closely involved in GitcoinDAO, just an observer from an academic perspective, but I actually think the degree of decentralisation currently present is quite a nice balance. While a desire to ever more decentralisation is commendable a quick survey on just how closely the community wants to be involved in refining policies around eligibility might be sensible.

1 Like
6

Sure, it’s equally arbitrary, but it at least begins to limit our scope to the subset of projects with tokens that actually need funding. If all projects with tokens are allowed, the aperture is super broad – projects with multi-billion dollar gov token treasuries are technically eligible.

If I were a new grantee to Gitcoin trying to determine if I fit the bill, I think I’d appreciate at least directional clarity.

This is an interesting corner case; I haven’t heard of any projects that have given 100% to community - but we should certainly have a process that accounts for and reviews situations like this.

IMO, in order for the grants program to be scalable, this should be an exceptions process – where projects like this one have the opportunity to raise their hand and make their case as to why they should be included, in spite of the $20M (or whatever dollar figure) cap – rather than a standard “FDD-reviews-the-issuance-details-of-every-single-token” process.

To give grantees proximate clarity, to have something to go off of – and then to intentionally build in a process for the “we-gave-away-all-our-tokens” type exceptions to make their case.

Blank slate case-by-case review for every grantee is not sustainable.

Yes, this is correct.

The BrightID decision needs to be finalized by the end of the GR13 disputes period, which I believe is March 28th.

My personal bias would be towards action and to try to come to community agreement on a more scalable starting policy that’s directionally right, such that BrightID can be evaluated in that framework, rather than as a complete one-off.

That said, I totally appreciate the concern around the timeline and I’m good with whatever the community decides.

3 Likes
7

Hi @annika

From my understanding, there should be 2 votes from this post:

  1. Update grants policy

    • maintain “no token” status quo
    • adopt new $20m market cap threshold
    • [my suggestion based on discussion] add a case-by-case option, not sure the name

  2. brightid case decision

    • eligible for GR13
    • not eligible for GR13

sorry I have a small brain, cannot deal with much info at the same time.
so for the topic one, I would support adopt new $20m market cap threshold

and also we should have a machinism to update the grant policy.

1 Like
8

+1 of splitting this into 2 separate proposals/posts.
The 20m cap while sounds better than a blanket ban on if the project has token does sound more appealing but I do think it would have to be more detailed to cover out corner cases like the one lefterisjp mentioned. (there may be more as well)

Moving onto bright ID → asking the team if they are open to sharing

  • Token sold
  • % Owned by the team

And using that information to decide if they can take part in GR13 / should step down to allow other projects to get more funds.

1 Like
9

I think the sense of being overwhelmed is what I was trying to get at.

Vote 2 should happen soon. Vote 1 should be deferred until after the round as it seems unwise to adopt such a change in the middle of a round or just after.

1 Like
10

Sounds good, thanks everyone for your feedback.

What I am hearing pretty universally is that we should expedite the BrightID decision as a one-off and hold off on broader policy definition.

@DisruptionJoe - in light of the community comments here, I don’t think we should move to a Snapshot vote tomorrow on the whole proposal, but rather move forward on BrightID alone.

Based on FDD’s current process, how will that decision be handled? Is done in isolation by the policy squad, without community input, or does it go to a full Snapshot vote of its own? I assume others may not have clarity here either so I want to have this discussion on next steps in public :slightly_smiling_face:

2 Likes
11

The FDD has not needed Snapshot yet and has been able to use discussion, emoji-signalling, and polls to make group decisions. I would guess this won’t change anytime soon.

I appreciate your statement to delay the snapshot vote pending further discussion because it is sensitive to obtaining full participation. But I am still in favor of voting on the change because I believe it is a positive change. It will help both reviewers and grantees absorb both the letter & spirit of Gitcoin laws (briefings/policies/documentation).

Joe and Annika have been foundational to getting this murky issue clarified. Thanks so much you two! I bias towards community-cohesion over independence. If the community feels we should discuss this more before taking action than so be it. I support the community vision…I just hope we can get quick results and not disappear into endless debates.

As a reminder, during the three part progression of this topic it became clear that the BrightID entity that created the grant actually doesn’t have a token. Thus a technicality would enable us to immediately reverse the BrightID grant denial. The entity that created and manages the $BRIGHT token is legally separate from BrightID Dao. This quickly resolves Q2 however it may not be the best way forward as even though the 2 bright organizations are not legally linked they are connected in theory through name and actions.

1 Like
12

I believe I outlined what I think will happen if we decide not to do a snapshot vote here:

I am ok with moving forward and having FDD make the call on the BrightID case without a snapshot vote. This is what has been done in the past.

The reason this case is different is because we built out an appeals process and found a legitimate case where the appeal serves as guidance to future policy. (as opposed to being a reviewer error or poor interpretation of current policy)

Because this situation is a “first” to make it this far in the appeals process FDD has built out to decentralize the decision making process, I do believe it is fair to judge both together. By saying we want FDD to make the decision or not, we establish a precedent which will be used for future appeals.

I don’t see how the decision here can not set a precedent, therefore there is no way to handle these separately.

However, because these types of calls (grant eligibility decisions) have always happened in FDD, the way forward that does not include a snapshot vote would be for FDD to make a call and write up the reasoning for it.

Then perhaps PGF could be responsible for updating policy in between rounds?

The token and funding info is all on the original post about the BrightID appeal: Novel Situation #1 - Project should not have a token or raised VC funding

1 Like
13

I have to comment here that 2 different entities is not a reason to automatically reverse decisions.

In BrighID’s case I don’t have all the facts so can’t speak from factual knowledge but my interactions with them have been very positive so I don’t think they would appeal without a reason and try to cheat Gitcoin.

BUT, if for example I(Lefteris) have 2 different entities, both of which I have major control of. Say Rotki Germany and “Opensource software Cayman Islands”, and the latter creates and sells a token, but the rotki Germany entity still wants to keep the grant matching … I hope you would challenge me there.

What I am trying to say is that it’s hard to have blanket rules and unfortunately I am afraid we would need case by case decisions after reviewing all the facts.

3 Likes
14

The token and funding info is all on the original post about the BrightID appeal: Novel Situation #1 - Project should not have a token or raised VC funding

I read that post and I still can’t find out how much has the DAO/team kept for itself. What is their treasury situation?

15

I am comfortable making the case by case decisions in FDD as has been done in the past, but would like the process to be explicit because this is the first appeal to get to this level.

Not deciding is a decision! We might call this OPTION 0 - Maintain the status quo and DO NOT explicitly agree to FDDs authority in this domain and set clear boundaries

If we maintain course, this is what the outcome might be:

  1. FDD source council makes a decision and writes it up on the gov forum.
  2. PGF & FDD Policy writes up policy recommendations based on the gov forum conversation
  3. FDD Grant Reviewers & Approver follows these policy recommendations for initial approval of new grants
  4. PGF writes up a policy update between rounds to be ratified (has the problem of bundling many policy decisions into one vote)

If we go with Option 1 or Option 2 via snapshot vote, then the decisions of FDD or the snapshot vote will have more legitimacy. (Option 1 & 2 as outlined here: [Proposal] Grants Policy Update: Projects with Tokens - #12 by DisruptionJoe)

I would like to see us start the appeals system in a legitimate way rather than leaving it as is.

A snapshot would need to start tomorrow or Wednesday by the latest to be able to pass in time for this round.

If we get positive approval from 5 stewards by Wednesday, I would advocate for us to put it up for a vote and not let our community be guided by inaction.

I’d also like to refrain from thinking we can find the BEST ANSWER and instead think “Is the recommendation of the people closest to the work SAFE TO TRY”

The complexity of the situation is high, therefore a sensing and responding methodology is practical.

2 Likes
16

I also agree with your sentiment here, Lefteris. @David_Dyor is making sure the entire surface area of the problem is in view, but it seems to me that his interpretation is that he agrees with you that we should do a case by case analysis and is informing of the DOWNSIDE to pushing for a letter of the law interpretation. (Which you aren’t pushing for, but some might)

17

@castall can you share the info @lefterisjp and @bobjiang requested here?

1 Like
18

If we’re talking about changing to rules to this,

Then, yes, BrightID would fit within those rules.

If we’re thinking of including other rules about the value of tokens sold, or the value of tokens given to the team, and we want to look at BrightID as an example, no tokens were sold and no tokens were given to the team. I think this is unusual for community token launches. I normally see around 15% reserved for the team.

Unfortunately, BrightID’s token model is not likely to be used by other projects, so the decision isn’t likely to be of much help. I didn’t think about this when we agreed to be a test case for a new appeal process in December.

19

I generally agree with the sentiment that many of these situations will be unique cases and it’s hard to put a blanket policy down. I also feel that setting a policy like this going forward should take time and deliberation, and not be rushed for GR13 or to close a specific case (like BrightID). But I do feel the urgency to make a call on BrightID and I think I’d encourage FDD to make the final call for now.

Regarding the $20m threshold - I think we should focus on a project’s treasury and not the market cap - what if the token is 100% owned by community members? This is naturally hard to measure and verify, so it’s maybe not the best metric, but I struggle to think of something better.

It seems like these unique 1 off cases will continue to be raised, and it’s likely not possible to set a policy across the board that is fair to all, but it’s also not possible to scale governance votes for each and every dispute. So given that, I’d like to throw out the idea of setting a “loose” policy on funding/tokens for grants between GR13 and 14, with plenty of time to debate. And then maybe using governance to elect a “board” of decision-makers who have the final say, independent of FDD. Governance can then vote to tweak the general policy or board members in the future when they see fit.

2 Likes
20

This is so well stated. :raised_hands: I agree that we are conflating a few problems together and love that we are starting to tease them apart. Thank you Lefteris!

This makes me a bit weary. I will trust the intention of this comment, but for policy making, bringing these items to the community and not just leveraging emoji reactions would likely be more credible. Once again, I dont have the context here, just would caution making any larger decisions on this mechanism (ie, who is invited to emote, how much information and time do they have to decide, etc.)

As Lefteris mentioned, this just isn’t true in spirit and I don’t feel like this would stand up in any real evaluation.

I am really surprised to hear this. I assume the team participated in the fair launch? Eligibility criteria here would likely favor the team doing development (rightfully so!). It feels dishonest to say the team was given no tokens though :thinking:

This may be the pessimist in me, but I feel like a token was launched, and was optimistically positioned as a way to fund development. Now that the markets have cooled and that is not sustainable as once hoped the question becomes, should BrightID be allowed to receive matching funds again.

Interested in seeing the vote options as they come up :slight_smile:

1 Like