For the past few months we’ve having regular discussions with some of the Gitcoin crew about ways we can collaborate. The first outcome of this is the new recipient metadata registry that was suggested by Gitcoin and built by Yuet and @Daodesigner from clrfund.

Another recent suggestion is for Gitcoin to run a Gitcoin branded instance of clrfund for the upcoming GR14 grants round, scheduled for some time in June/July. The proposed round would run in parallel with the normal centralized Gitcoin grants round, along with an instance of their new dgrants platform. Similar to how they ran GR12.

Kevin, and others from Gitcoin, have shown a desire to experiment with and embrace different funding mechanisms in parallel and to collaborate with clrfund on trying out MACI-powered QF in the context of Gitcoin grants rounds.

At face value, this seems a great opportunity to try clrfund out in a new context with a large userbase already familiar with web3 and QF. However, @Daodesigner raised some valid concerns around how running rounds in parallel like this might actually have a negative impact on the perception of QF using MACI. In large part due to the potential for it to turn into a head to head comparison between the “performance” of clrfund vs dgrants and/or cgrants, given their would likely be a strong bias towards the less frinctionful and more well established options.

I tend to be of the opinion that this is a good opportunity to add an option for private, collusion-resistant, QF to Gitcoin Grants rounds, and am hopeful that it would lead to more focus on privacy and collusion-resistance in QF and the web3 ecosystem more broadly. Longer-term, I would love for privacy to be the default behaviour of these systems, rather than just an option, or the current status-quo of none at all.

Anyway, this feels like a pretty pivotal decision for clrfund, so I’d love to hash it out here with the community.

What are your thoughts?

I agreed with @Daodesigner in that the experiment result may not provide meaningful insight in regards to MACI-backed or not because MACI is backend implementation.

The experiment result may show which platform has better UX, because that’s what visible to the users from the frontend.

I’m curious to know more about the concerns. Why would it have a negative impact on the perception of QF using MACI?

auryn

March 4, 2022, 6:22pm #4

There are at least a couple of compounding concern:

1. there are several UX challenges for rounds using MACI, as compared to Gitcoin’s current grants setup: donations can only be made on one chain, signup flow is necessarily frictionful for sybil resistance, you can only contribute once to the round (although you can update you allocations as many times as you like), etc.

2. MACI is private by design, it reveals very little about the way that users interact with the system. We have no insight into who allocated funds to who, all we see is the amount that each user contributes to the round and final output of the round (the distribution).

In concert, these two things make it very difficult to do comparisons between MACI and the existing mechanisms that go deeper than volume of users, volume funds contributed, and final distribution. Such a shallow comparison would almost certainly favour the more well established options with less friction for users. In short, it would not be an apples to apples comparison.

That said, I personally still think it’s worth running the round. We just need to be very deliberate about how we communicate the round. It should not be positioned as a head-to-head comparison of the performance of different mechanisms, at least not based on volume-based metrics. I do think it would be interesting and useful to compare the ratios of the distributions between mechanisms and to get qualitative feedback from users and recipients. But most importantly, I think it’s important for us to get more real-world experience coordinating MACI-based rounds and this feels like a great opportunity to do it in the context of a community that is already familiar with web3 and QF.

I would like to start by saying we are grateful to gitcoin for funding clrfund development, I hope this can be cleared up quickly and we can continue to collaborate and drive mainstream privacy/QF adoption. So my main concern here, and why I asked to move the conversation to the forum, is the framing of this by @owoki as “VS”.

On the call we had, this was brought up as “the search for the best QF mechanism” with the idea presented being we would run two rounds in parallel (both branded as gitcoin) and see which one users prefer. The framing was explained as “ [clrfund] MACI vs [gitcoin] pairwise” which I don’t agree with on principle. It’s not the first time the head to head mentality, or conversation about MACI/privacy not being a good fit for gitcoin, has been presented behind closed doors (was Scott’s suggestion last time) while posturing as collaborative in public. In my opinion the ‘experiment’ is flawed because the user doesn’t need to know that there is MACI under the hood, that’s the entire goal.

It could very well be that I’ve misunderstood the opportunity presented here, and would love to give gitcoin another chance to present the idea to our community and help them toward MACI adoption!

owocki

March 8, 2022, 5:22am #6

Hi from Gitcoin.

I regret that I’ve not had a chance to comment when this was first posted, and that most of the discussion on this post has focused on the discussion of “[clrfund] MACI vs [gitcoin] pairwise”.

Long term, I DO think it’d be meaningfully impactful to the ecosystem to speedrun some experiments to “the search for the best QF mechanism possible relative to our values”, but as people rightly pointed out above, we perhaps are nowhere near being able to run a real experiment on MACI & pairwise given the current setup. Perhaps it was naive to suggest this during our most recent CLRFund/Gitcoin brainstorm. Let me repeat back the reasons I heard from you all:

1. As auryn noted “there are several UX challenges for rounds using MACI, as compared to Gitcoin’s current grants setup”

2. as auryn noted “MACI is private by design, it reveals very little about the way that users interact with the system.” and “In concert, these two things make it very difficult to do comparisons between MAC”

3. as yuetloo noted “the experiment result may show which platform has better UX, because that’s what visible to the users from the frontend.”

4. as daodesigner noted it compares “[clrfund] MACI vs [gitcoin] pairwise” in a co-mingled way.

So lets take the (in hindisight, rather naive) idea to test pairwise & MACI off the table.

With that out of the way - I would ask to reorient the conversation to the reason to start with why. Why did we even start talking about doing this in the first place? Why do we care about interop between Gitcoin & CLRFund?

First, the designs that someone put together of Gitcoin Grants using CLRFund look deeply cool.

Second, In the proposal for GitcoinDAO to issue a 40k GTC Grant to CLRFund, the proposal listed the following reasons to engage:

1. Extend previous friendly contact between Kevin Owocki and Auryn MacMillian to formally affirm that Gitcoin & CLRFund are friendly projects built around similar missions.

2. Change the narrative created by other competitive projects working on the same domain. That is the misguided belief that we must have sharp elbows - boxing each other out from each other’s users and demonstrate loud social media clap-backs.

3. It is possible that the goodwill between the two projects could be extended into a formal integration or partnership one day - especially with the Decentralize Gitcoin workstream gaining speed.

4. By pushing new tech and solutions on top of QF (such as MACI), CLRFund can act as a testbed/testnet for future gitcoin features and visa-versa.

The proposal continued: It is our assertion that CLRFund’s implementation of Quadratic Funding is complementary to Gitcoin. Most notably, in the following ways.

• It is pushing forward MACI.

• It is pushing forward sybil resistance & collusion resistance.

• It is funding public goods in the Ethereum ecosystem.

• It is iterative and increasingly effectively proven itself, having run 7 rounds so far.

• Gitcoin Grants has funded CLRFund $33k in the past.

• The CLRFund has taken UI/design inspiration from Gitcoin Grants, and extended them to their decentralized QF protocol.

• Given that Gitcoin’s existing Grants product is centralized, and work to decentralize is ongoing, a partnership with CLRFund could be a fruitful way to accelerate the decentralization of Gitcoin Grants - and also to make Quadratic Funding in the Ethereum ecosystem more anti-fragile (similar to how there are many client implementations of ETH2).

<- end proposal text ->

I agree with the proposal author & I believe in the above statements.

The third & final “why do this?” from my POV: Our current our thinking has led us to an explicit embrace of Pluralism & Client Diversity in the public goods funding stack - both within the QF public goods funding space, but also through the embrace of Effective Altruism, NFT public goods, retro public goods & others. Our latest thinking on Gitcoin Grants 2.0 puts this pluralism into practice by proposing interoperability with other Grants/project registries.

So if we believe in the above “why”, then the next question to my mind is “what” and “how”.

With most projects we try to interopt with, we focus on

1. social interop

2. technology interop

3. token interop

After the above discussion, I’m not sure what next steps (if any) the CLRFund community would prefer, but I am open to discussing direction together. Do others agree with our “why”? Why or why not? If yes, then “what” do we do & “how”?

My personal take is that the designs that someone put together of Gitcoin Grants using CLRFund look deeply cool + I like the idea of doing a small round together to send a signal to the market that were in it for the same mission & finding ways to coordinate. I also have a deep admiration for MACI intellectually & think it’d be cool to learn some practical zk stuff. But if the time is not right, or our values are too different, I understand also.

All my best,
owocki

Flattery will get you everywhere . Thank you for clearing this up. I was the one that originally put the designs together to model what a Gitcoin Grants round using CLRFund tech stack might look like, this was done a few months ago, as part of an internal proposal to get gitcoin to run GR12 on our tech stack.

There is 100% room for collaboration, and our values are definitely aligned (no need to quote off the original grant proposal ). Would love to hear your thoughts on grant round details (number of projects, timeline, matching pool, etc).

Small design alpha with the rest of your branding:

owocki

March 8, 2022, 6:57pm #8

thanks for doing this - i didnt realize it was you or id have given you credit in the OP - your work is very beautiful, and i think conveys the gitcoin brand well aesthetically + also the potential of a combined co-branded experience.

Would love to hear your thoughts on grant round details (number of projects, timeline, matching pool, etc).

let me circulate this thread to ppl who plan gitcoin grants rounds + see what they think a good starting place would be.

annika

March 9, 2022, 9:46pm #9

Hey all! Jumping in here representing the Grants program from the Gitcoin DAO, to chat more about co-running a round. Been chatting with @owocki and figured I’d share some of my thinking here.

To start, I’m in agreement with @auryn & @owocki that there’s an opportunity here for co-experimentation here. In terms of round framing, strong +1 on the below comment; we should be clear that this is collaborative and not competitive.

Ideal timing on our end would be June 8-23, to coincide with when we are running GR14, our next quarterly grants round. The next round would be in September, if June ends up being too tight.

I would suggest we run this as an experimental ‘ecosystem round’, probably targeting a pretty small pool (maybe $25K to start?) in a specific domain (for example: in GR13 we are running rounds for Open Gaming, NFT Ecosystem… probably something net new, TBD, open to collabing on ideas here).

We are pretty busy at Gitcoin this week kicking off GR13 which starts today, but I’ll loop back with the team and we’ll have more to share in the coming week or two.

Excited by the prospect of working together!

auryn

March 18, 2022, 6:59pm #10

I agree. This seems like a great starting point for the Gitcoin community to kick the tires on clr.fund.
Do you have any suggestions on which domain might be best suited? Given the proposed scope of the round, I want to make sure it’s something where that amount of money can still be impactful. So I think “gaming” or “NFT ecosystem” might be too broad.

There are quite a few folks in the space who do community / governance facilitation across a whole bunch of different projects, perhaps this round could be targeted at individuals whose contributions are particularly valuable to the broader community? Austin Griffith, antiprosynthesis, and Chris Blec are three examples of individuals who have received funds via Gitcoin grants in the past for their contributions to the ecosystem.

Another option, along a similar line, could be funding for new and young developers in the space. Something akin to padawan DAO but in QF form. Essentially, each recipient should detail who they are, what they’re passionate about in and around web3, and how the money will help them push toward that passion.

I guess I like the idea of a round of this scale being targeted at individuals because it seems like it still have potential to be impactful in a way that it might not if it’s funding organisations.

That said, totally open to other suggestions as well.

annika

March 21, 2022, 3:44am #11

Yeah, I love this thought. Definitely agree with being intentional about it being impactful and keeping it smaller-scale in order to do so.

I really like both of these ideas - around community / gov facilitation, and new / young devs, and think either one could work - let’s jam further on these at our next Gitcoin <> clr.fund touchpoint!

GOOD ,Is surely worth a try。

yea it should be done as soon as possible.

For the past few months we’ve having regular discussions with some of the Gitcoin crew about ways we can collaborate. The first outcome of this is the new recipient metadata registry that was suggested by Gitcoin and built by Yuet and @Daodesigner from clrfund.

Another recent suggestion is for Gitcoin to run a Gitcoin branded instance of clrfund for the upcoming GR14 grants round, scheduled for some time in June/July. The proposed round would run in parallel with the normal centralized Gitcoin grants round, along with an instance of their new dgrants platform. Similar to how they ran GR12.

Kevin, and others from Gitcoin, have shown a desire to experiment with and embrace different funding mechanisms in parallel and to collaborate with clrfund on trying out MACI-powered QF in the context of Gitcoin grants rounds.

At face value, this seems a great opportunity to try clrfund out in a new context with a large userbase already familiar with web3 and QF. However, @Daodesigner raised some valid concerns around how running rounds in parallel like this might actually have a negative impact on the perception of QF using MACI. In large part due to the potential for it to turn into a head to head comparison between the “performance” of clrfund vs dgrants and/or cgrants, given their would likely be a strong bias towards the less frinctionful and more well established options.

I tend to be of the opinion that this is a good opportunity to add an option for private, collusion-resistant, QF to Gitcoin Grants rounds, and am hopeful that it would lead to more focus on privacy and collusion-resistance in QF and the web3 ecosystem more broadly. Longer-term, I would love for privacy to be the default behaviour of these systems, rather than just an option, or the current status-quo of none at all.

Anyway, this feels like a pretty pivotal decision for clrfund, so I’d love to hash it out here with the community.

What are your thoughts?

I agreed with @Daodesigner in that the experiment result may not provide meaningful insight in regards to MACI-backed or not because MACI is backend implementation.

The experiment result may show which platform has better UX, because that’s what visible to the users from the frontend.

I’m curious to know more about the concerns. Why would it have a negative impact on the perception of QF using MACI?

auryn

March 4, 2022, 6:22pm #4

There are at least a couple of compounding concern:

1. there are several UX challenges for rounds using MACI, as compared to Gitcoin’s current grants setup: donations can only be made on one chain, signup flow is necessarily frictionful for sybil resistance, you can only contribute once to the round (although you can update you allocations as many times as you like), etc.

2. MACI is private by design, it reveals very little about the way that users interact with the system. We have no insight into who allocated funds to who, all we see is the amount that each user contributes to the round and final output of the round (the distribution).

In concert, these two things make it very difficult to do comparisons between MACI and the existing mechanisms that go deeper than volume of users, volume funds contributed, and final distribution. Such a shallow comparison would almost certainly favour the more well established options with less friction for users. In short, it would not be an apples to apples comparison.

That said, I personally still think it’s worth running the round. We just need to be very deliberate about how we communicate the round. It should not be positioned as a head-to-head comparison of the performance of different mechanisms, at least not based on volume-based metrics. I do think it would be interesting and useful to compare the ratios of the distributions between mechanisms and to get qualitative feedback from users and recipients. But most importantly, I think it’s important for us to get more real-world experience coordinating MACI-based rounds and this feels like a great opportunity to do it in the context of a community that is already familiar with web3 and QF.

I would like to start by saying we are grateful to gitcoin for funding clrfund development, I hope this can be cleared up quickly and we can continue to collaborate and drive mainstream privacy/QF adoption. So my main concern here, and why I asked to move the conversation to the forum, is the framing of this by @owoki as “VS”.

On the call we had, this was brought up as “the search for the best QF mechanism” with the idea presented being we would run two rounds in parallel (both branded as gitcoin) and see which one users prefer. The framing was explained as “ [clrfund] MACI vs [gitcoin] pairwise” which I don’t agree with on principle. It’s not the first time the head to head mentality, or conversation about MACI/privacy not being a good fit for gitcoin, has been presented behind closed doors (was Scott’s suggestion last time) while posturing as collaborative in public. In my opinion the ‘experiment’ is flawed because the user doesn’t need to know that there is MACI under the hood, that’s the entire goal.

It could very well be that I’ve misunderstood the opportunity presented here, and would love to give gitcoin another chance to present the idea to our community and help them toward MACI adoption!

owocki

March 8, 2022, 5:22am #6

Hi from Gitcoin.

I regret that I’ve not had a chance to comment when this was first posted, and that most of the discussion on this post has focused on the discussion of “[clrfund] MACI vs [gitcoin] pairwise”.

Long term, I DO think it’d be meaningfully impactful to the ecosystem to speedrun some experiments to “the search for the best QF mechanism possible relative to our values”, but as people rightly pointed out above, we perhaps are nowhere near being able to run a real experiment on MACI & pairwise given the current setup. Perhaps it was naive to suggest this during our most recent CLRFund/Gitcoin brainstorm. Let me repeat back the reasons I heard from you all:

1. As auryn noted “there are several UX challenges for rounds using MACI, as compared to Gitcoin’s current grants setup”

2. as auryn noted “MACI is private by design, it reveals very little about the way that users interact with the system.” and “In concert, these two things make it very difficult to do comparisons between MAC”

3. as yuetloo noted “the experiment result may show which platform has better UX, because that’s what visible to the users from the frontend.”

4. as daodesigner noted it compares “[clrfund] MACI vs [gitcoin] pairwise” in a co-mingled way.

So lets take the (in hindisight, rather naive) idea to test pairwise & MACI off the table.

With that out of the way - I would ask to reorient the conversation to the reason to start with why. Why did we even start talking about doing this in the first place? Why do we care about interop between Gitcoin & CLRFund?

First, the designs that someone put together of Gitcoin Grants using CLRFund look deeply cool.

Second, In the proposal for GitcoinDAO to issue a 40k GTC Grant to CLRFund, the proposal listed the following reasons to engage:

1. Extend previous friendly contact between Kevin Owocki and Auryn MacMillian to formally affirm that Gitcoin & CLRFund are friendly projects built around similar missions.

2. Change the narrative created by other competitive projects working on the same domain. That is the misguided belief that we must have sharp elbows - boxing each other out from each other’s users and demonstrate loud social media clap-backs.

3. It is possible that the goodwill between the two projects could be extended into a formal integration or partnership one day - especially with the Decentralize Gitcoin workstream gaining speed.

4. By pushing new tech and solutions on top of QF (such as MACI), CLRFund can act as a testbed/testnet for future gitcoin features and visa-versa.

The proposal continued: It is our assertion that CLRFund’s implementation of Quadratic Funding is complementary to Gitcoin. Most notably, in the following ways.

• It is pushing forward MACI.

• It is pushing forward sybil resistance & collusion resistance.

• It is funding public goods in the Ethereum ecosystem.

• It is iterative and increasingly effectively proven itself, having run 7 rounds so far.

• Gitcoin Grants has funded CLRFund $33k in the past.

• The CLRFund has taken UI/design inspiration from Gitcoin Grants, and extended them to their decentralized QF protocol.

• Given that Gitcoin’s existing Grants product is centralized, and work to decentralize is ongoing, a partnership with CLRFund could be a fruitful way to accelerate the decentralization of Gitcoin Grants - and also to make Quadratic Funding in the Ethereum ecosystem more anti-fragile (similar to how there are many client implementations of ETH2).

<- end proposal text ->

I agree with the proposal author & I believe in the above statements.

The third & final “why do this?” from my POV: Our current our thinking has led us to an explicit embrace of Pluralism & Client Diversity in the public goods funding stack - both within the QF public goods funding space, but also through the embrace of Effective Altruism, NFT public goods, retro public goods & others. Our latest thinking on Gitcoin Grants 2.0 puts this pluralism into practice by proposing interoperability with other Grants/project registries.

So if we believe in the above “why”, then the next question to my mind is “what” and “how”.

With most projects we try to interopt with, we focus on

1. social interop

2. technology interop

3. token interop

After the above discussion, I’m not sure what next steps (if any) the CLRFund community would prefer, but I am open to discussing direction together. Do others agree with our “why”? Why or why not? If yes, then “what” do we do & “how”?

My personal take is that the designs that someone put together of Gitcoin Grants using CLRFund look deeply cool + I like the idea of doing a small round together to send a signal to the market that were in it for the same mission & finding ways to coordinate. I also have a deep admiration for MACI intellectually & think it’d be cool to learn some practical zk stuff. But if the time is not right, or our values are too different, I understand also.

All my best,
owocki

Flattery will get you everywhere . Thank you for clearing this up. I was the one that originally put the designs together to model what a Gitcoin Grants round using CLRFund tech stack might look like, this was done a few months ago, as part of an internal proposal to get gitcoin to run GR12 on our tech stack.

There is 100% room for collaboration, and our values are definitely aligned (no need to quote off the original grant proposal ). Would love to hear your thoughts on grant round details (number of projects, timeline, matching pool, etc).

Small design alpha with the rest of your branding:

owocki

March 8, 2022, 6:57pm #8

thanks for doing this - i didnt realize it was you or id have given you credit in the OP - your work is very beautiful, and i think conveys the gitcoin brand well aesthetically + also the potential of a combined co-branded experience.

Would love to hear your thoughts on grant round details (number of projects, timeline, matching pool, etc).

let me circulate this thread to ppl who plan gitcoin grants rounds + see what they think a good starting place would be.

annika

March 9, 2022, 9:46pm #9

Hey all! Jumping in here representing the Grants program from the Gitcoin DAO, to chat more about co-running a round. Been chatting with @owocki and figured I’d share some of my thinking here.

To start, I’m in agreement with @auryn & @owocki that there’s an opportunity here for co-experimentation here. In terms of round framing, strong +1 on the below comment; we should be clear that this is collaborative and not competitive.

Ideal timing on our end would be June 8-23, to coincide with when we are running GR14, our next quarterly grants round. The next round would be in September, if June ends up being too tight.

I would suggest we run this as an experimental ‘ecosystem round’, probably targeting a pretty small pool (maybe $25K to start?) in a specific domain (for example: in GR13 we are running rounds for Open Gaming, NFT Ecosystem… probably something net new, TBD, open to collabing on ideas here).

We are pretty busy at Gitcoin this week kicking off GR13 which starts today, but I’ll loop back with the team and we’ll have more to share in the coming week or two.

Excited by the prospect of working together!

auryn

March 18, 2022, 6:59pm #10

I agree. This seems like a great starting point for the Gitcoin community to kick the tires on clr.fund.
Do you have any suggestions on which domain might be best suited? Given the proposed scope of the round, I want to make sure it’s something where that amount of money can still be impactful. So I think “gaming” or “NFT ecosystem” might be too broad.

There are quite a few folks in the space who do community / governance facilitation across a whole bunch of different projects, perhaps this round could be targeted at individuals whose contributions are particularly valuable to the broader community? Austin Griffith, antiprosynthesis, and Chris Blec are three examples of individuals who have received funds via Gitcoin grants in the past for their contributions to the ecosystem.

Another option, along a similar line, could be funding for new and young developers in the space. Something akin to padawan DAO but in QF form. Essentially, each recipient should detail who they are, what they’re passionate about in and around web3, and how the money will help them push toward that passion.

I guess I like the idea of a round of this scale being targeted at individuals because it seems like it still have potential to be impactful in a way that it might not if it’s funding organisations.

That said, totally open to other suggestions as well.

annika

March 21, 2022, 3:44am #11

Yeah, I love this thought. Definitely agree with being intentional about it being impactful and keeping it smaller-scale in order to do so.

I really like both of these ideas - around community / gov facilitation, and new / young devs, and think either one could work - let’s jam further on these at our next Gitcoin <> clr.fund touchpoint!

GOOD ,Is surely worth a try。

yea it should be done as soon as possible.