Ecological Analogies to an Evolutionary Framework in GG24

🧙 🧙‍♀️ Ideas and Open Discussion
1

:seedling: An Evolutionary Lens for GG24 Allocation

Note: this text does not come from an expert in game theory or on-chain economics. I am one of the many builders who believe in Gitcoin and the public goods funding ecosystem. The idea here is simply to plant a seed, drawing on diverse inspirations, and see if it grows. Suggestions and corrections are very welcome.

Ecological Inspiration: My Research on Density-Dependence

About ten years ago, I conducted a research project titled:
“Density-dependent mortality at different developmental stages of two tropical tree species, one abundant and one rare."

We studied two tree species in a Brazilian rainforest fragment:

  • Abundant species (Mollinedia schottiana) → showed negative density dependence. The more individuals crowded together, the higher their mortality, due to competition and natural enemies.
  • Rare species (Faramea picinguabae) → surprisingly showed positive density effects once past seedling stage. Survival actually improved when a small cluster formed (an Allee effect).

:point_right: In short: abundance triggered diminishing returns, while rarity sometimes created resilience.

This is one of many ecosystem mechanisms that maintain diversity in nature: abundant species are regulated, rare ones are supported once they reach critical mass.

Linking to Gitcoin Funding Dynamics

Looking at GG24’s structure and the five proposed domains, I wondered:

What if funding domains behave like species in an ecosystem?

  • Abundant domains (lots of grants, lots of capital) → may experience diminishing marginal returns, like the abundant tree species. Each extra grant yields less incremental impact.
  • Rare domains (few grants, little capital) → may actually need a boost, like rare species that only thrive once a small cluster emerges.

This suggests adding a regulatory layer to Gitcoin’s metrics:

  • Apply negative feedbacks for over-saturated domains.
  • Apply positive boosts for rare/underfunded domains.

Not to replace existing tools, but to complement them.

I was especially inspired by the discussion in the Condorcet voting proposal.

In that thread, @clesaege gave a detailed example of how we can simulate Condorcet preferences across domain allocations. That comment made me revisit my old ecological research.

Just like Condorcet can run in parallel with mean/weighted voting to reduce “peanut butter spread,” we could run this evolutionary heuristic in parallel with TVF:

  • Use TVF and votings to establish a baseline.
  • In parallel, run an evolutionary model that looks at past Gitcoin data, estimates “density effects” per domain, and suggests adjustments.
  • Compare outcomes. If they align, that’s strong validation. If they diverge, it opens new discussions.

Both experiments reduce blind spots: Condorcet against strategic voting, evolutionary heuristics against over-/under domain saturation.

Translating Frequency and Density into GG24

The Total Value Flowed (TVF) metric gives us a concrete base — it tracks how much value moves through the ecosystem. But TVF alone is new, untested, and reductionist. Optimized in isolation, it risks Goodhart’s Law.

So we propose: keep TVF as a base metric, but enrich it with a regulation Score inspired by population ecological modeling.

The idea is to treat each funding domain as if it were a “strategy” in a population and calculate a score that can signalize if the allocation strategy will be effective before it happens.

In practice, that means:

score1.png

  • Density factor (D): decrease weight as a domain nears “carrying capacity” (too many grants splitting the pool).
    densidade.png

  • Frequency factor (F): increase weight for domains underrepresented in past rounds (rare species effect).
    Denominador-de-frequencia.png

Three main steps define this mechanism:

  1. Estimate the carrying capacity (Ki) for each domain.

    • Use the $1.3M minimum commitment and past rounds as reference. For example, central domains like Developer Tooling or Security & Privacy could start with ~$250–300k, while emerging domains like Interoperability or Localism might start at ~$150–200k.
    • These values serve as carrying capacities — allocations per domain should not exceed 𝐾𝑖.
    • The distribution can be adjusted according to gitcoin current priorities and funding availability.

  2. Calculate domain specific fi and overall frequencies ∑fj.

  • Count how often each domain appears, in past rounds, reports and discussions. Developer Tooling, for example, is mentioned in both the official post and the sensemaking report, so it gets a higher counter; others appear only in sensemaking.
  • Then apply a rarity factor 𝛽 representing how much we want to boost rare domains.
    • If we choose 𝛽 = 0.5, less mentioned domains get a small bonus.
    • This follows the logic of frequency-dependent mechanisms: rare strategies can have an advantage because they bring diversity.
  1. Incorporate density - Di (saturation).
  • Track how much is already allocated in each domain (Ai).
  • When Ai is far below Ki, Di ≅ 1. As the domain approaches capacity, Di decreases, discouraging further allocations and distributing resources toward less saturated niches.

This idea of carrying capacity comes from the density games literature: strategies with higher payoff are less impacted by crowding (PMC), but total abundance is still limited.

Finally, combine the two factors with the base allocation metric (e.g., TVF) to create a product of historical data analysis × current observation for each domain i.

scorefunc.png

Final adjusted score and definitions

Considering that 𝑖 = 1,2,…,𝑛 indexes the funding domains (e.g. Developer Tooling, Privacy, Interop, Target Education, Academic Research), we have a function that incorporates density and frequency effects on the different funding domains.

scoreadjusted.png

1. TVFᵢ (Total Value Flowed)

  • What it is: The baseline Gitcoin metric that tracks value flowing through a domain.
  • Where it comes from: On-chain transactions + past matching pool allocations + donations

Data challenges:

  • Attribution: correctly mapping flows to the right domain.
  • Consistency: different rounds sometimes grouped categories differently.
  • Freshness: TVF updates “after the fact” — less useful for real-time signals.

2. Aᵢ (Allocated)

  • What it is: The amount allocated to a domain in the current round.
  • Source: Snapshot voting results or matching pool configuration.

Data challenges:

  • Early estimates vs. final allocations may diverge.
  • Timing matters — do we take Aᵢ as the “committed allocation” at voting or the “realized allocation” at payout?

3. Kᵢ (Carrying Capacity)

  • What it is: The inferred “saturation threshold” for a domain.
  • Source: Derived from historical rounds (regressions, PCA, etc.).

Data challenges:

  • Needs enough historical points per domain to estimate reliably.
  • Sensitive to shocks (e.g., one huge grant could distort the regression).
  • Likely has to be recalibrated after each round.

4. fᵢ (Relative Frequency)

  • What it is: A proxy for how “common” or “rare” a domain is.
  • Possible considerations:
    • Number of grants submitted per domain.
    • Number of mentions in ecosystem-sensemaking threads.
    • Donor participation counts per domain.

Data challenges:

  • Choice of proxy strongly affects interpretation.
  • Risk of noise if using textual mentions (NLP classification errors).
  • Could overweight domains that are trendy in discussion but not in funding.

5. β (Rarity Sensitivity)

  • What it is: A governance parameter, not raw data.
  • Source: Set collectively (e.g. via forum debate or parameter voting).

Data challenges:

  • Needs to be interpretable to non-technical community members.
  • Could be dynamic (adjusted per round) or fixed for longer periods.

In this way, a project in a rare, under-saturated domain gets a higher multiplier; one in a crowded domain gets a lower one. Which can be used signal for future strategic funding decisions.

mermaid-diagram-2025-08-24-215425.png

Why This Matters

  • Resilience through diversity: Avoids monocultures of funding.
  • Simple & testable: Can run alongside Condorcet and TVF without disruption.
  • Grounded in nature: Ecology offers heuristics that have regulated diversity for millions of years.

What’s Next?

This is just a conceptual prototype. It is not a definitive solution. Still needed:

  • Validate the capacities Ki with real past data and community input.
  • Test different β values for the rarity factor (is a stronger or weaker bonus better?).
  • Integrate other quality signals (e.g., reputation, continuous participation) if we want to refine the index.
  • Understand how this approach fits operationally with GG24 flows, especially when interacting with Allo and the TVF index.

By sharing this sketch, I hope others can co-create an evolutionary allocation mechanism that starts simple, respects priorities from sensemaking, and leaves room for diversity. Feedback, critiques, and improvements are more than welcome!

Invitation

I’d love to hear from the community:

  • Does the analogy between ecological density-dependence and funding resonate?
  • Which GG24 domains look “abundant” vs. “rare”?
  • How might we set the first parameters using past Gitcoin data?

References

1 Like