I don’t see a proposal on the Snapshot - is there a date in mind for opening the proposal, and also what kind of voting period would there be?
I think having good commms on a proposal like this is important too - this isn’t a criticism of anything specific, but I’ve noticed that people tend to miss important proposals and then feel like they got ninja-passed or the like. (There is a core dev who has contributed to EIPs that everyone has heard of who missed the London Hard Fork until after it happened, and made a comment about it being rushed without anyone knowing about it. I suppose he missed the bat crowd on Twitter, or, more likely, doesn’t hang out on Twitter at all.) How can we make sure there is maximum transparency on this?
Hey @wschwab in general the snapshot vote happens at least after 1 week of deliberation on a proposal in the forums.
The approach we try to take on governance is laid out in this post.
The way to get more eyes on something is to keep tweeting about it and mentioning it in discord I guess, so that more and more people participate.
Regarding the proposal there was also a small convo in Twitter between @androolloyd, @auryn and myself where there was a request of CLR fund to also contribute to the Decentralize gitcoin workstream. The discussion can be seen here.
I’d definitely love to see some concrete plans @auryn & clr fund would have with the funds? It’s then easier to maybe setup some milestones or identify concrete benefits deriving from this disbursement of funds
Agreed. I think that the things that were discussed in Twitter as per my post above can and should be formulated more formally in a post in this topic.
I don’t think this will bring any help to the community. No matter what cooperation you say in the future, there is no promise. The funds of the treasury cannot be misused in this way. Unless CLR makes a commitment in specific cooperation and giving back to the community
I’ll start by acknowledging my obvious bias in this vote. Given that bias, I’ll abstain from casting a vote. Anyone that wants to vote on this and has delegated to me should delegate to someone else for this proposal.
My understanding of this proposal is that it is less about specific future deliverables and more an acknowledgement of past work pushing the Quadratic Funding and Ethereum Public goods space forward. So I’d be inclined to view it in the same spirit of the Retroactive Public Goods funding post that Optimism recently published. In other words, this would be the Gitcoin DAO explicitly saying “we value the contributions you have made to the QF space and want to align our future efforts towards funding Ethereum’s public goods”.
That said, I do think there are specific deliverables that we are already planned and would be beneficial to the Gitcoin DAO, that could be much more easily achieved given this extra funding.
Specifically, we are:
Building a production ready decentralized QF protocol, with baked in Sybil and collusion resistance, that can scale to billions of users.
Making it easy for anyone to deploy their own instance of the clrfund to fund whatever public goods they want, including both the contracts and the app.
Building in a modular and extensible way so that instances of clrfund can choose the governance, Sybil resistance, and recipient registry solutions that best suit their community and use-case.
This funding would allow some of our contributors to focus on this full-time, along with bringing new talent in (likely from the Gitcoin community via bounties).
One important thing for the Gitcoin DAO to consider is if/how this fits with the decentralize grants workstream.
Clr.Fund , desde sus inicios a estado ayudando a proyectos con muy poco volumen 500 usd 100 usd sucede que en algunos paises es mas importante comer que tener financiamiento.
Sin duda apoyaria esta alternativa demostrando que realiza un trabajo etico para la comunidad , si la comunidad se guia por lo que ve y no le gusta la financiacion bajen los fondos a 35K pero sin duda son grupos que no hay que dejarlos solos por un click de distancia.
(2) is answered in the OP and by Auryn in his reply.
For (1) I think it’s a good question. Auryn went into a bit more detail in his response but perhaps a more official breakdown of costs and a timeline could help alleviate some of the people’s concerns here as the amount is indeed rather big.
In more concrete terms, at the current GTC value, this would give us the capacity to hire ~2 full-time developers and a full-time product manager for the next year, which would radically increase the rate that we can ship the features mentioned above. The other place that some small portion of the funding may be used is to cover infrastructure costs for running the coordinator, since computing the ZKPs can be pretty demanding.
There is some variability to how far this funding will get us, since we would obviously not intend to cash it out immediately. Ideal case, we could find folks who want to be paid in GTC so there is no need to convert it at all. Otherwise, we would need to convert some portion of periodically (say monthly or quarterly) to cover dev costs.
Are people satisfied with the answers provided by Auryn and the CLR.fund team? Is there any more things that need to be discussed before we move onto a snapshot vote?
thank you for detailing this + the even more specific answer re hiring. It would be fantastic if we could identify people wanting to work on GTC payout bounties to further CLR.Fund mission.
I’d also really love to maybe see a collective report on QF co-authored by Gitcoin and CLR Fund that essentially details the huge progress made in the space since QF became a “thing”. This could also really further people’s understanding of the concept AND the uptake in setting up/funding grants for future rounds in both projects…
Yeah, I think this would be a really valuable piece of content. Although, at least from clr.fund’s side, we’d probably want to wait until after we’ve run at least one production scale round before authoring a report like this.
Retroactive funding for the win. I would absolutely support this proposal.
CLR.fund has made huge contributions to the QF space and supporting basically the only “competitor” is exactly the right vibe.
We are all allies in the public goods space.
I will vote for this without any reservations.
That said, I think it would be in the best interest of GTC to see some vesting requirements in basically all of these large grants… I don’t think they have to be even on chain… just a friendly understanding that the holdings would only be liquidated at a certain rate… And definitely would not be “diversified” upon receipt.
Honestly, with this team I don’t even think it would need to be said, they are crypto savvy, understand token economics, and have a culture of making win-win deals… I assume they will hodl the GTC unless they need it. That said… it would prob be cool to be explicit about that in all big grants that don’t have any milestones.
Yeah, I have no qualms with this at all. Perhaps some vesting schedule with a clawback option for the Gitcoin DAO would be a good way to put people’s mind at ease. Above I mentioned that, at the current value, this could cover one year of costs for two devs and a PM, plus some misc. expenses. So perhaps vesting it continuously over the course of a year, or in four discrete tranches, would make sense.
As much as I’m confident that we could be trusted to do it on a handshake, we have a variety of great tools available to us to eliminate the need for trust, so we may as well make use of them.
Hi. I am overall supportive of the effort clr.fund is doing but I do wonder why we need a separate proposal to acknowledge the past effort. The normal Gitcoin round should fulfil that purpose.
If we pass a proposal without set goals, targets, and deliverables, it may be very difficult to assess the effectiveness of the value delivered. I do suggest changing the format to the “Budget proposal” type.
I love this idea, specifically the thought that collaboration and the sharing of ideas can flow between teams. CLR.fund is further ahead in MACI and thinking through nested matching pools while Gitcoin is further ahead in scale.
Could we set the expectation that each team connect every two weeks to share current work and brainstorm on learnings and roadmaps a bit? The DOT and KSM analogy sounds wonderful given how tightly those groups collaborate.
@auryn - Would you be open to a sync every two weeks (or whoever is doing the building) to ensure both teams can learn from experiences of the others? When Gitcoin launches the dGrants protocol, the learning will be invaluable from the CLR.fund side to make sure we are offering complimentary experiences.
I’m more than happy to sync up regularly to share learning. Bi-weekly might be a little frequent, given the pace we’re moving at currently. But that could change quickly if/when this grant is approved.
