TEMP CHECK – How Many Domains Should GG24 Include?

TEMP CHECK – How Many Domains Should GG24 Include?

As we move toward GG24, one of the central design questions is: How many domains should we run?
The program strategy doc currently points to 4–6 domains, while sensemaking has surfaced 2 dozen+ credible proposals. I want to open this conversation transparently and hear the community’s views. I come into this with an open mind.


The Case for Fewer Domains (4–6)

  • Clarity & Focus – Launching a major structural shift (multi-mechanism, multi-domain) is already a lot for the community to process. A smaller set of domains makes the change easier to explain, market, and coordinate.
  • Information Bandwidth – The average participant cannot meaningfully track 8+ new domains at once. Fewer domains means deeper engagement and less cognitive overload.
  • Quality Over Quantity – Limiting scope could raise the bar for proposals and ensure higher execution quality per domain.
  • Operational Efficiency – Gitcoin program ops and marketing resources are finite. Concentrating them on a smaller set of domains increases the chance of success.
  • Precedent – Other orgs (e.g. ARIA in the UK) focus attention on a few “opportunity spaces” at a time, making the prioritization legible without diminishing the importance of other areas.

The Case for More Domains (8–12+)

  • Innovation Surface Area – Ethereum has many urgent problems (AI, privacy, open data, DeFi transparency, etc.). Running more domains means more experimentation and more shots on goal.
  • Inclusivity & Legitimacy – Restricting to 4–6 could create disillusionment among operators whose proposals are set aside. More domains broadens participation and builds legitimacy.
  • Network Effects – Each domain brings in its own funders, operators, and communities. More domains = more total capital, partnerships, and talent in the Gitcoin ecosystem.
  • Flexible Funding – Even if Gitcoin commits $1.3M, domains can bring their own co-funding. With operator hustle, 10–12 domains could still be meaningfully resourced. Especially if we are lucky/good at bringing in outside funding.
  • Decentralization – Letting GTC stewards decide which domains to fund (without an artificial cap) better reflects our goal of moving toward a network-driven allocation model.

Where Do We Land?

This is the tradeoff:

  • Fewer domains = more clarity, focus, and controlled rollout.
  • More domains = more innovation, inclusivity, and legitimacy.

I don’t have a fixed view here, my view has been evolving over time. My ask: let’s surface arguments, tradeoffs, and data points now so stewards can make an informed call before the Snapshot vote.


Discussion Questions

  1. Should Gitcoin constrain the number of domains to 4–6, or let the stewards decide based on proposal quality?
  2. How should we weigh clarity/marketing vs. inclusivity/innovation?
  3. Could merged/clustered domains give us the best of both worlds?

Looking forward to the conversation.

4 Likes

Does Gitcoin have any ambition or intention to scale this project to another dimension?

I haven’t seen this in your main area of interest or within this included roadmap, however, if we plan to largely introduce concepts to improve content and quality, I’d like to see this move to the Eastern market, or Asian area and not as a digital presence, but as a hybrid approach where we “should” and even we “must” scale out this with both scenario; Digital and physical landscape (The arena)

The North American market is in a stagnation stance while the eastern region are swiftly operating and distributing their footprint worldwide, with exactly the feature we should use, where they can also bring speed and affordability (in conjunction with quality), and so the reach in that area is immense since the population might be 10X even 100X more. We are circling around using only a small fraction of the cake (as the surface of the area to explore)…

I believe if we want to reach the next level, we have to use different approach. And so expansion and scalability should be a top priority to sustain this project.

Have a wonderful day!

If we see domains as ‘infrastructural’ then fewer would be better. (I have some catching up to do on the DDA discussion, happy to be corrected).

It’s a new idea, so I’d vote for a minimal approach with rigorous testing.

By ‘testing’ I mean demonstrating the cross-cutting value-additions of each domain we support.

Over time, these tests can evolve through empirical data (e.g. ‘domain A added X value, domain B added Y value in the given period’).

If this happens, we’ll have a replicable method for adding new domains and purging unproductive ones.

2 Likes