# 🌱 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*).

👉 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](https://gov.gitcoin.co/t/gg24-structure-strategy-and-timeline/22878) and the [five proposed domains](https://gov.gitcoin.co/t/gg24-from-ecosystem-sensemaking-to-domain-proposals/23021), 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](https://gov.gitcoin.co/t/proposal-try-out-condorcet-voting-for-gg24-domains/23188).

In that thread, [@clesaege](https://gov.gitcoin.co/u/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:

[](https://postimg.cc/87gvbn00)

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**.

- **Frequency factor (F):** increase weight for domains underrepresented in past rounds (rare species effect).
[](https://postimg.cc/5XrW5xZ1)
- 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](https://en.wikipedia.org/wiki/Frequency-dependent_selection): rare strategies can have an advantage because they bring diversity.

3. Incorporate density - **Di** (saturation).
Track how much is already allocated in each domain (**Ai**). Use a logistic-style factor:
- **Density factor (D):** decrease weight as a domain nears “carrying capacity” (too many grants splitting the pool).
[](https://postimg.cc/SnnKCQg7)

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)](https://pmc.ncbi.nlm.nih.gov/articles/PMC3753514/), 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*.

[](https://postimg.cc/s1Jbztpp)

---
### Final adjusted score and definitions

Considering that 𝑖 = 1,2,…,𝑛 indexes the funding domains (e.g. Developer Tooling, Privacy, Interop, Education, Research). This is the regulating function that incorporates density and frequency effects.

[](https://postimg.cc/4KZ3YDSX)

#### 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.

[](https://mermaid.live/edit#pako:eNptU9uO0zAQ_RXLT5Btlt7SbSKBFG2UggpC6q72gYaHwXFaaxO72A4Qqn3nlV_hQ_gIvoSJk-6miChyfDlzfObM5EiZyjmNaFGqr2wP2pK3m0wSfG7v0u2tslCSOyhrTlJE8JwcuCa5qkBI4hPPQ5TwvI9dyGbreb9_eR6ebEAL2xDDpRFWfGnnTEljQdoeHCM4Fg6cdHzXtdZcWhKXpWJghZI9dI3Q9TkUtG6E3OHkAAzZe2SByOIMeXPgTBSCkVTzzzWXrCEXqPvPj589DphWxhAoyz4v03MdwNjtajVZ-qvVdDbYJL5PYmPEThIObH-yAwg7qWK9KvJs_ZwUWlUEM7fCWMHQT5BQNkYY339F1ue0b3I0QBQNKow_1TJHu06qUCzIHA_QWj7YbFmKTL5GdqVbfj8HC267Zc2kuyHZJq4UDUmBIdAVLxHkJZn4sXixfiwi5jrftsPTshV2g9G8gvs2u5a6a5KNm6ddDun2yeLBJX1_dJgbpjTHGrkvXt62D_FI0g6DRnrsQMfvwMODbmyl-ac6m4t3YNke5fkp-mZcYPxkLgLfSx87HAvl_DkVwQETJV2__ZcFZfQd22H7nhwuiqEPyb-iz7KgI7rTIqeR1TUf0YprlI9LemzBGbV7XvGMRjjNQd9nNJMPGHMA-UGp6hSmVb3b06iA0uCqPmBKPBGw01A97uK_lHN9rWppaTRfLAPHQqMj_Uaj6fQynI6Dq8ViMg_C-Ww-og2NwqvLWRAGE3xny3AxDR9G9Lu7dny5DJazq_FsPJ-MMSoIH_4Cf35Hrw)

---

## 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.

---

## Invitation

This is just a beginning. 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?

If Condorcet voting is about making preference aggregation more robust, maybe an evolutionary lens can make *resource allocation* more adaptive. Let’s test both in parallel and see what emerges. 🌍

---

### References

- [My research](https://docs.google.com/document/d/1yVJ-18pn-gpinrI4lvoB20gSJ8n-HCdi-B3fxurCnCQ/edit?usp=drivesdk): TOMAZ, C. M., 2017. *Density-dependent mortality at different developmental stages of two tropical tree species, one abundant and one rare*. UFSCar - CCA).
- [GG24 Structure, Strategy and Timeline](https://gov.gitcoin.co/t/gg24-structure-strategy-and-timeline/22878)
- [GG24: From Ecosystem Sensemaking to Domain Proposals](https://gov.gitcoin.co/t/gg24-from-ecosystem-sensemaking-to-domain-proposals/23021)
- [Proposal: Try out Condorcet Voting for GG24 Domains](https://gov.gitcoin.co/t/proposal-try-out-condorcet-voting-for-gg24-domains/23188)
- [Gitcoin Grants Round 19 Recap](https://www.gitcoin.co/blog/gg19-results-and-recap)
- [Evolutionary Game Theory – Frequency-Dependent Selection](https://en.wikipedia.org/wiki/Frequency-dependent_selection)
- [Density Games – Carrying Capacity Effects](https://pmc.ncbi.nlm.nih.gov/articles/PMC3753514/)