GG24: Structure, Strategy and Timeline

đŸŒ± Gitcoin Grants
2

i personally would be more comfortable if the team within gitcoin that wants to run the domain had to go through the same proposal & approval process as everyone else. It (1) dogfoods the process (2) provides a more level playing field & (3) provides an opportunity for gov forum participants to provide feedback on the draft plan for the OSS round.

i feel that the “hybrid model” is not the right framing as we move to a more network driven funding program. as we’re making a big shift from 2.0 era to 3.0, and allocating resources to make that change, we should not be thinking in half measures and hedges, we should be decisively moving towards a structure that works across all domains.

i think the team within gitcoin that wants to run the domain had to go through the same proposal & approval process as everyone else.

2 Likes
3

Thank you for the update Mathilda, I understand that, shifting from “QF-only” to multi-mechanism doesn’t mean that QF would be “abolished :rofl:” in GG24, it just means that it won’t be the only funding mechanism, do let me know if I’m right on the money.

I do have another question: if I suggest a domain, does that mean I have to build it? Can I suggest a domain without having to build it?

1 Like
4

Great to see some progress in the sense-making as GG24 quickly comes up. One question I have is how are the top 3 community rounds from GG23 being incorporated into GG24? As an operator on 2 of the rounds and advisor on one there’s been no communication or clarity on the rounds involvement for GG24.

1 Like
5

Yes, correct! We plan to still run with QF in OSS. As we did in GG23, we are inviting a multi-mechanism approach where any mechanism is welcome.

Yes of course you can. This is part of sensemaking. But for a domain to run in GG24, it would need a domain allocator (operators) managing and running it.

1 Like
6

This looks great. Very interested in seeing how GG24 plays out.

1 Like
7

I’m in the opposite position. I would like to operate a community domain that’s been through the sense-making process, but I don’t want to suggest the domain. I just want to operate it using the Updraft mechanism. How are we going to match domain allocators and funding mechanisms to domains?

2 Likes
8

Nice, I think this is one of those occasions where we see 2 perfect scenarios in the comments :rofl:I’ll drop my domain suggestion in 2 bits.

2 Likes
9

Thanks a lot for clarifying, would get to it.

10

This reads like Gitcoin’s trying to spin “we’re cutting scope and consolidating control” as “we’re evolving”. The hybrid model pitch is nice on paper, but operationally it means Gitcoin keeps the crown jewel OSS domain and leaves the rest as a half-dozen sandbox fiefdoms for the community to manage. That’s not decentralization, that’s selective franchising now, isn’t it? The “minimum $1.3M” commitment is impressive at first glance, but when the bulk is already earmarked for Gitcoin-run domains, the community slices start looking like consolation prizes, especially when funding is “flexible” at Gitcoin’s discretion.

The governance flow is also tilted. Sensemaking reports go in, Gitcoin filters them, and only the pre-approved shortlist hits Snapshot. By the time GTC holders vote, the real decisions are already made in-house. That’s not participatory governance now, is it? That’s more like curating the menu before anyone sits down to order. If you’re going to sell this as community-driven, the gatekeeping needs to be transparent and criteria published before the fact, not wrapped up in “quality standards” that can be invoked to kill proposals on vague terms.

Finally, the messaging is heavy on “focus” and “impact” but light on accountability. Smaller number of domains? Fine. But if the goal is higher quality, then where’s the published track record of what “good” looks like from GG23 and earlier rounds? Without hard evidence of impact per dollar, this shift feels more like cost control than strategic refinement.

Harsh, I know, but someone has to say it


11

Totally understand where you’re coming from, and maybe the “Hybrid Model” is just a poor choice of words. My reasoning behind proposing that Gitcoin continues to host and manage OSS, is because that’s where our deep expertise lie and we already have an extremely legitimate program. I’m open to shifting it, for sure, and would love others to weigh in on this too. What I would suggest, then, is that Gitcoin proposes the OSS domains we wish to run, and GTC holders vote on the top X of those that will be approved into GG24, alongside community-operated domains.

And to be clear, everything (including funding for each domain) will have to be ratified through governance first, including Gitcoin-managed domains - that hasn’t changed!

1 Like
12

I’m not sure I understand this. This is merely us making sure that all domains that go into the vote meets our eligibility and standards. This remains our program and our matching funds, so it’s up to us to set the eligibility of the program to ensure high impact and in line with our mission. It is absolutely up to us on checking which reports are eligible to head into a Snapshot vote or not. We listed eligibility for community rounds (and excluded rounds for vote that weren’t eligible in previous GG rounds), as well as domains for GG24. That hasn’t and won’t change.

This is the first time we’re running with this domain model, so we don’t have anything to compare it with yet! FF to look at the retrospective for GG23, where we break down the first time that we ran multi-mechanism.

3 Likes
13

[UPDATE]: In response to @owocki’s comments, I’ve updated this to clearly outline that Gitcoin will propose the OSS domain(s) in the hybrid model, still including community involvement and expertise oversight from the Gitcoin team, while ensuring the decision-making clearly lies with GTC holders.

7 Likes
14

Thanks for the question, @Oba-One!

So, unfortunately, because of the new structure under domains and the fact that we’re not continuing with using Grant Ships in the same way, this won’t possible to apply to GG24. I’m planning on making an announcement about this this week!

4 Likes
15

[UPDATE]: Due to the large number of domain proposals received for GG24, we are extending the ‘aggregation’ period by one week before we kick off the vote. This will allow us and the community to complete the following before heading into the vote:

  • All eligible domains will have domain allocators assigned
  • Clear strategy outline for each domain
  • Gives everyone more time to adjust RE: feedback given by stewards
16

i am not onboard with this direction.

we should open as many domains as GTC stewards vote for

  1. so as to artificially constrain the innovation of the ethereum network (we got about 2 dozen proposals, i could see funding about 1/2 of them)
  2. the program ops team does not have the authority to unilaterally decide how many domains will go live.
1 Like
17

Shouldn’t a decision like this have a community discussion/call and go through governance?

How can I as a builder and operator have any confidence going forward that any decisions made in GG24 will be honored going forward?

1 Like
18

I absolutely hear where you’re coming from, and it’s our accountability that we didn’t speak up about this earlier! Because we’ve designed a whole new structure (which went through governance), and that we’ve voting on domains, it’s going to be a very difficult process to include it in the same way as before. That’s all I’m saying! But what we are of course doing in our decision-making as we’re voting on domains is ensuring we take into account past community rounds (and those operators) that have run in previous rounds – those successes will be taken into account, so what we can do is ensure the teams that were the top voted in Grant Ships get a boost in this round when it comes to voting.

19

My thinking is the following:

  1. gitcoin only has so much funding and the rounds we fund need to be meaningful (I’d say around $50k - $100k per round and there could be multiple rounds within each domain)
  2. we need to see domains able to raise their own funding too
  3. it requires operational and marketing support to some extent from gitcoin and those resources are limited so we need to make sure we consider this in how we scale the # of domains. the Gitcoin team also has other projects on their plate!
  4. Because there could be multiple rounds within each domain, it does increase the lift and scope a bit!

The initial thinking when this strategy was set by the team was that we would start smaller and simpler for GG24, ensuring quality while we’re still building. But if you think we should go a different path, I encourage you to draft a proposal where you outline your thinking of running 12 domains instead and how we may fund or resource those. Would love the community to weigh in on it too!

2 Likes
20
  1. gitcoin only has so much funding and the rounds we fund need to be meaningful (I’d say around $50k - $100k per round and there could be multiple rounds within each domain)
  2. we need to see domains able to raise their own funding too

i’m glad were able to have a conversation on merits, out in the open, about the distribution of the funding. neither of us has the authority to make the decision unilaterally, so out in the open is the way it should be.

my view is that if gitcoin distributes $1.4m, it should do $700k to oss and that leaves 700k (plus whatever outside funding) across 10-12 other domains. assuming the domain operators can bring in $700k in extra funding, that is $2.1m across 11-13 domains, or roughly $190k/domain.

/f you consider OSS a sacred cow and give that $1m, and divide the funding equally across the other rounds, that leaves roughly $100k/domain. which in my view is plenty.

it is possible well see some of the domain proposals combined (eg the oss/devex proposals) combine into multiple rounds within the same domains. i think that will further close the gap.

  1. it requires operational and marketing support to some extent from gitcoin and those resources are limited so we need to make sure we consider this in how we scale the # of domains. the Gitcoin team also has other projects on their plate!

assuming youre talking about the “program ops” team, as Gitcoin to me means the entire project in the broadest sense to me.

what is the marketing/operational support being provided by Gitcoin program ops team? what do the domain operators need from Gitcoin? Have we surveyed them to see what they need? what is being provided and in what form? how will we measure how satisfactory they find the support? an NPS score?

do we have to provide uniform support for each domain? would it be possible to provide tier A support to a small batch and a lesser level of support to others?

the Gitcoin team also has other projects on their plate!

assuming youre talking about the “program ops” team, as Gitcoin to me means the entire project in the broadest sense to me.

my view is that the program team should be focused on the program.

how much of the program ops team is going into supporting the domain allocators vs other projects (like the OSS funding round)?

  • OSS - If we were to breakdown the OSS domain at $700k-$1m using fair fees we would be allocating roughly $31k to the OSS domain ops/overhead - is the program ops team spending more or less than that on administering OSS round?
  • what other projects are we talking about?

my view is that the program team should be primarily focused on the program, and the activities of supporting the domain operators that are the heart of the program.

likewise - If you want to constrain the domains to only 4-5 you should draft a proposal to do so.

until a proposal is passed limiting the number domains, the decision remains up to the stewards during the upcoming vote on distribution of funding. that is where the authority to make this decision lies.

3 Likes
21

TLDR: Public goods funding should be treated like living ecosystems, adaptive, resilient, yet dependent on constant support. Gitcoin can improve inclusion and adaptability by creating customizable allocation mechanisms, leveraging on-chain reputation, milestone-based streams, and AI-assisted historical analysis. Future funding could move beyond rounds, using neural network driven incentives and utility mechanisms for GTC tokens to foster participation and stronger consensus.

Take a look at nature: the fittest of the fit survive, adapt, and thrive (just like Gitcoin and Ethereum). If you want to see the fundamentals, most complex systems are found in nature (you’ve explored that before: Mycofi).

We need to build proper and genuine incentives with customizable allocation mechanisms, involving different stakeholders and curated by “experts” in guilds or fields of expertise, as gitcoin has done in the past.

We need an L2beat-style index for Gitcoin public goods projects to implement evolutionary Mycofi neural networks with on-chain reputation and infinite streams (like Superfluid streams) that vary according to milestones and shipping. With this approach, there will be more inclusion and adaptability in allocation, in my opinion. You could even create utility mechanisms for the GTC token with this, gaining more traction and activity. The stream could distribute fractions of GTC per milestone or per shipping apart of the pools per round. I imagined that there would be no rounds in upcoming gitcoin seasons.

I love the key changes, @MathildaDV :slight_smile:

We also need a historical perspective of Gitcoin milestones on socials. For example, an AI agent could identify practices and past experiences to determine the best potential next steps using indicators such as metrics of participation and divulgation, and then assist in creating stronger consensus among the players of the game.

We need to start viewing allocation mechanisms in public goods funding as living organisms or ecosystems. They are complex living systems, like mycelium or rhizomes. They must constantly adapt, grow, and survive, yet they are inherently fragile. If they die, it is part of evolution, but they cannot thrive without a constant stream or pulse of energy or funding. They are both resilient and dependent, self-organizing yet reliant, and they evolve only as long as they are sustained.

Some documents of interest @owocki :

  1. Evolutionary game theory: cells as players
  2. Why Darwin would have loved evolutionary game theory
  3. Evolutionary game theory and human social structures
  4. Evolutionary games for cooperation in open data management
  5. Evolutionary game dynamics for higher-order interactions
  6. Evolutionary game-theoretical approaches for long-term strategic bidding among diverse stakeholders in large-scale and local power markets: Basic concept, modelling review, and future vision
1 Like