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
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 
2 Likes
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
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
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
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?
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:
- FDD source council makes a decision and writes it up on the gov forum.
- PGF & FDD Policy writes up policy recommendations based on the gov forum conversation
- FDD Grant Reviewers & Approver follows these policy recommendations for initial approval of new grants
- 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
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)
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.
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
This is so well stated. 
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 
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 
1 Like
Hi @castall
From what you said, I can get following info (please correct me if I am wrong):
- Brightid team reserved about 15% token.
- 0 token sold from the team
so would you share the team multi-sig address? (not sure if it is sensitive to be public, if yes, please find a proper channel to share in Gitcoin discord).
1 Like
I agree it is a weak argument and I explained why in my post. I am simply trying to pull all information into this discussion and ensure nothing gets ignored.
Yeah daos have a funny way of making me weary too. Full empathy with you on this! In all seriousness, I see the FDD decision making as a feature not a bug. We are learning which types of decisions require various methods and info preservation. The ability of the fdd to rapidly signal on simple matters has helped us adapt and pivot along the way. And this is not the topic of this post. We are discussing projects with tokens and somebody asked how the fdd would likely make the next decision. My response was specifically to answer her question, not table fdd decision-making for inspection and critique.
At risk of irritating y’all, I want to point out that it can be difficult and time-consuming to achieve Dao consensus. We are so close to actually making a beneficial policy change derived from an appropriate process it would be sad and counter-productive to cancel it, in the hopes that maybe in some hypothetical future we will sit down to address the issue again.
Procrastination is the enemy and we have a great simple modification here that had been created by a PG/FDD co-lead process which involved ample public discussion. Do we really think more pages of debate will create changes to the proposed changes? I suggest it is unlikely and we move ahead with the suggested changes. However, I will support the community majority position.
1 Like
This needs to either go to a vote tomorrow or be left as is… which is a vote for option 0.
Do we currently have comments from 5 or more stewards @Pop? What is the process for us moving this forward in the most legitimate way?
Moving Forward with Input from this Thread
Based on the feedback from the community, and given we did not receive at least 5 steward comments in favor of moving this motion to a snapshot vote, FDD is moving forward with Option 0 for the BrightID appeal.
FDD Judgement of BrightID Appeal
After judging this case, FDD made the decision to uphold BrightID’s appeal, for two primary reasons:
- The changing nature of how web 3 is using tokens such as governance tokens creates a divergence between the intentions of the community and the policy as written today. “Cannot have a token”
- BrightID clearly fits the definition of a public good as infrastructure which supports digital democracy. Our Polis report which received 138 responses from the community overwhelmingly shows that the community wants us to “fund public goods” before worrying about the semantics of policy. While their launch of a token hoped (and still does) hope to give them a sustainable funding model, they have not achieved this status yet.
As a result of this decision, the BrightID grant will be included in GR13 and eligible for matching funds in the round.
As discussed above, policy will be re-evaluated post-round, and we welcome input on that process.
Thank you to @annika @David_Dyor, the stewards & community members who took their time to weigh in, and @castall and the BrightID team for going through the experience of being the first appeal to go through the full Gitcoin appeals process.
Situational Context
1 - FDD source council voted as the “appellate court” to decide if the appeal had merit to be heard.
2 - FDD put it to the community on the governance forum saying “we would like this to be a vote to determine precedent on how we deal with appeals at this level because it is the first case to get to this level.”
3 - Because it did not get enough positive steward attention to put it to a snapshot vote, Option 0 has been selected.
4 - This post serves as communication of FDD’s justification for it’s decision to uphold BrightID’s appeal, include them in GR13, and informs the community on potential next steps.
5 Likes
I never get tired of watching you tie-together seemingly disparate concepts and individuals/groups. Thank you Joe for bringing closure to this incredible 3 part process in a way that clearly describes what has happened as well as what is happening next in the world of grant appeals. I am optimistic the lessons taken from running this actual appeal will make future appeals leaner and faster. And thanks to all who contributed to these talks. i think it is worth noting we came very close to moving to steward vote. It is a bit murky but I think I saw at least 3 supportive steward comments maybe 4.
4 Likes
Sorry that’s not correct. I was just pointing out 15% as an example of a typical amount.
There is no team multisig. The team didn’t receive any tokens.
This isn’t the right narrative. $Bright token is performing much better than we ever expected, but we never expected it to cover BrightID core development. If one day it could cover the costs, great, but we never anticipated that. That would be very optimistic indeed.
Whether there is a possibility of a token or DAO treasury being used to fund core development at some future time (I hope it can, but we need other options, like Gitcoin grants) is different than saying the core team received tokens, which they didn’t.
I’m not trying to paint us in a more positive light, I’m trying to dispel misinformation, so that if there’s any use for this token launch to set a precedent, it can be done so accurately.
I think @lefterisjp was making the point that the same people can control multiple entities and pretend to not be related. Very true, but not the case here. United in purpose, but not the same people. The $Bright token airdrop was meant to be much more spread out to avoid being just the same people. The link you shared has the right information.
10 million $Bright went to the DAO treasury. That treasury could certainly be used to fund BrightID core, but it hasn’t yet, and we need Gitcoin and other grants.
Most projects do take some tokens for the core team or dev team, so I’m sorry we can’t be of more help setting a precedent for that with regard to Gitcoin grants. My personal feeling is that should be OK if a project does that.
I don’t know if these will factor in at all to the updating the token guidelines, but in case you all don’t know there’s another token (actually two tokens) that BrightID has had since before it first applied to Gitcoin Grants in round four. These have been used to raise funds almost exclusively for the core team. Should a grants project be allowed to charge a fee for its services and sell rights to those services?–because that’s what we’ve done. You can read about Sponsorships tokens and Subscriptions tokens. Gitcoin has purchased sponsorships tokens to use in the trust bonus.
sorry sir, I misunderstand you ;(