Youtube Video of this pitch // Deck
TEMP CHECK - Gitcoin 3.3 (3,3): An Evolutionary Arena for Capital Allocation
Here is my vision for Gitcoin 3.3. I’d love to have a discussion/temp check on whether this is something we should pursue or not. Please vote FOR/AGAINST/ABSTAIN!
Three goals for Gitcoin 3.3:
- Fund/Solves Ethereums biggest problems.
- Evolves great capital allocation software.
- Achieves (3,3,3,3) between its stakeholders (ethereum ecosystem, builders, funders, GTC holders).
From Grants Program to Coordination Infrastructure
Gitcoin is evolving beyond quadratic funding into a modular ecosystem for capital allocation. Gitcoin (3,3) is our next chapter: an open arena for testing, evolving, and scaling capital allocation software that solves Ethereum’s biggest coordination challenges—at the speed of crypto and AI.
While Gitcoin was once the builder, it is now an arena—providing a distribution container that accelerates the next generation of builders who are developing domain-specific mechanisms for grants, retro funding, deep governance, and more.
The Vision
We aim to build a virtuous cycle where:
- Builders of capital allocation mechanisms gain distribution, legitimacy, and funding.
- Gitcoin gains exposure to successful experiments, and upside in their impact.
- The Ethereum ecosystem benefits from faster, more intelligent capital allocation.
This is the Gitcoin (3,3): a win-win-win between builders, Gitcoin, and the community.
The Evolutionary Arena
Inspired by BitTensor’s Proof of Intelligence, Gitcoin becomes an evolutionary substrate for funding infrastructure:
- Domains (like subnets) compete to build the best tools for allocating capital.
- Each domain has a defined goal (e.g. onboarding developers, growing wallet adoption).
- Software is evaluated on real-world outcomes—distribution, traction, and impact.
Over time, Gitcoin helps evolve “proof of allocation intelligence”—rewarding the most effective approaches with funding, distribution, and visibility.
Allo.Capital’s Role
Allo.Capital—an R&D studio focused on post-AI capital allocation—is helping to design Gitcoin 3.x. Think of us as the McKinsey of onchain funding design. We support ecosystem partners (Gitcoin, Big Green DAO, others…) in building regenerative, pluralistic, AI-informed capital allocation systems that effectively solve their ecosystem needs.
Milestones
- Gitcoin 3.0: Decentralize capital allocation software development into specialized domains.
- Gitcoin 3.1: Introduce tokenizable, extractable value (TEV) from successful funding experiments.
- Gitcoin 3.2: Build into Bittensor-Inspired Evolutionary Arena
- Gitcoin 3.3: Realize a compounding flywheel of capital allocators, signal evaluators, and ecosystems—all benefiting from collective intelligence.
Join the Arena
- If you’re building capital allocators or impact evaluators → apply to Gitcoin Grants 24.
- If you want to help shape the arena itself → collaborate with us on the evolution.
Vote: Should Gitcoin pursue the 3.3 vision?
Please cast your vote:
FOR — Adopt the Gitcoin (3,3) vision and begin evolving the arena
AGAINST — Reject the direction; continue with the current approach
ABSTAIN — I am neutral or need more information
Gitcoin (3,3) is about evolving faster, funding smarter, and coordinating better—together.
—
Appendix A Feedback so Far
Steelman: For & Against this view
Arguments For Gitcoin (3,3)
- Evolutionary speed > static design: The arena enables rapid iteration on funding mechanisms.
- Builder-aligned incentives: Solves the distribution problem for early-stage funding infra projects.
- Modular pluralism: Different capital allocation mechanisms (QF, retro, deep gov) can coexist and co-evolve.
- DAO-aligned: Decentralizes Gitcoin’s roadmap and makes it more resilient, participatory, and scalable.
- Bridge to new ecosystems: Offers a framework others (Celo, Protocol Labs, Arbitrum) can use.
Arguments Against
- Evaluation is hard: Impact measurement is domain-specific, noisy, and hard to make comparable across mechanisms.
- Apples vs. Oranges vs. Tanks: Comparing retroactive, quadratic, and governance funding (or impact funding focused on OSS vs irl vs other stuff) can be a category error.
- Human judgment required: Unlike pure ML or AI models, capital allocation involves values, ethics, and politics.
- Premature abstraction: Trying to evolve “proof of allocation intelligence” before maturity could lead to misaligned incentives or low-quality signal.
Feedback from an ecosystem luminary
(not name dropping who they are tho.)
-
Emphasized the need for a strong, clear vision and business model: Success depends on building composable, high-quality capital allocation primitives and a platform that can capture enough value to fund ongoing R&D.
-
Cautioned that previous teams (including Gitcoin) failed to capture enough cash flow to sustain the high cost of quality software development.
-
Stressed that the product must allow customers to flexibly adapt grant structures to their needs—Gitcoin’s past product limitations led to missed opportunities.
-
Warned that without a major product-market fit breakthrough, Gitcoin risks becoming a “zombie” project—surviving but not thriving, which can trap teams for years.
-
Suggested that if Gitcoin can’t reinvent itself and deliver on its original vision, it may need to pivot or accept a different, more limited role.
-
Sees potential in the “arena” model—creating a competitive environment for capital allocation mechanism builders, where Gitcoin provides distribution and takes upside in successful ventures.
-
Compared the vision to BitTensor: a pluralistic, evolutionary marketplace for intelligent allocation, but noted the challenge of comparing impact across domains and mechanisms.
-
Stressed the need for an abstraction layer to enable apples-to-apples competition within specific domains, acknowledging this is a complex but solvable problem.
-
Warned that the market for “impact mechanism competitions” is likely small and that most ecosystems care about real impact (including profit), not mechanisms per se.
-
Pointed out that for the arena model to work, the network (not just subnets/providers) must capture the majority of revenue; otherwise, successful providers will eventually leave the network.
-
Expressed skepticism that most module builders in this space would become successful standalone ventures—most will be valuable as components, not as independent networks or tokens.
-
Overall, he saw merit in the vision but highlighted the need for careful business model design, focus on real customer needs, and patience given the slow, challenging market dynamics.
Summary of Feedback from another ecosystem luminary
High-Level Alignment
- Shared Goal: Both parties want to build capital allocation mechanisms that are:
- High-quality in outcomes
- Simple in design
- Decentralized (minimize reliance on central decision-makers)
- Resistant to harmful social dynamics/games
- REDACTED is framing this as a way to embed funding mechanisms directly into L2s/DeFi protocols.
- You framed it as an evolutionary container to breed and select better mechanisms—he agrees the direction is similar.
Key Feedback Points
- Start with what’s missing, not market demand:
REDACTED argues that with limited capital, it’s inefficient to be unopinionated or overly responsive to current market needs. Instead, focus on high-leverage primitives the world doesn’t yet have. - Deep Funding > Metrics:
REDACTED prefers deep funding over retro metrics-based funding, because it avoids Goodhart’s Law (the corruption of metrics once they become targets). Deep funding encourages constant evolution of how “impact” is measured. - Indirection is key:
Both deep funding and metric-based retro funding use indirection (voting on metrics or mechanisms instead of directly on projects), which reduces the surface area for manipulation or social games.
Your Synthesis
- We recognize deep funding as a good example of Vitaliks confusion/diffusion framework.
- We acknowledge the need to integrate this thinking more deeply into Gitcoin 3.0, especially the idea of indirect, evolutionary design rather than fixed metric targets.