Model Submissions GG24 Deep Funding

[thedevanshmehta]

Hello Model Builders,

This thread is your home for submitting writeups detailing your strategy for submissions in the ongoing contests and market assigning weights to open source repositories valuable to Ethereum

Prizes worth $10,000 will be allotted based on quality of writeup, as assessed by a committee. You should view this as a valuable opportunity to get feedback from the expert ML committee on your approach, as their review of each submission will be shared. You can take cues for writeups and past committee feedback from other competitions we have held in the past (links provided at end of post).

The format of submissions is open ended and free for you to express yourself the way you like. We will give additional points to submissions linking to Github repos with open source code and fully reproducible results. We encourage you to be visual in your submissions, share your jupyter notebooks or code used in the submission, explain the difference in performance of the same model on different parts of the ethereum graph and share information that is collectively valuable to other participants. We also recommend segmenting your writeup for each of the 3 levels separately if different strategies have been used for seed nodes, child nodes and originality assessment.

Writeups must be shared on this thread one week after the contest and market is closed. Any difficulty in posting can be shared with @ mehtadevansh on telegram. Since write-ups can be made after submissions close, other participants cannot copy your methodology. Failure to provide a writeup makes model builders ineligible for ALL prizes. You can share as much or as little as you like, but you need to write something here to be considered for prizes.

Model Submissions for Ethereum Deep Funding

GG23 Predictive Funding Challenge

Hello model builders, Consider this thread as your home for sharing all things related to your submissions in GG23 predictive funding challenge guessing the funding received by each project before the round even begins. Your write-up here will only determine eligibility for receiving a prize. Final prizes are based on leaderboard placement only, with 1st place - $5,000, 2nd - $3000, 3rd - $2000 We encourage you to be visual in your submissions to show weights given to the models, share your j…

Submission of Entries to the Deep Funding Mini Contest

Write Up for Models Predicting Sybil Scores of Wallets

[vporton]

AI Internet-Meritocracy app (a submission to the $10K competition):

• homepage: science-dao[.]org/meritocracy/ (I can’t include links in posts)
• app: merit[.]science-dao[.]org

is an app that asks AI, what portion of the global GDP a given user is worth, and shares crypto donations proportionally. AI decides, how much a user is worth by open-ended Web search using securely connected Web accounts, such as GitHub and ORCID.

Advantages over Gitcoin/Giveth/Manifund/… grants: No need to manually create a description of each grant and review them manually, no project rejections, no need for verifying conforming to the rules for each grant. It takes into account even smallest projects of a user (that if they are many, may form a majority of the user’s income). No long pause before paying. We can pay every week or even more often. No users not donating due to being confused over the topic (like: ordered semicate­gory actions) of a grant. No dependencies on the “commercial business” for receiving more donations of somebody advertising their grants in different media, but equal funding opportunities for everybody: rich and poor. It is an experiment in a potentially better free software and DeSci funding method than GitCoin/Giveth grants.

The app’s prompt rewards three categories of users (by summing scores in each of the three categories): free software developers, researchers/scientists, and “science marketers”. Science marketers are prompted to advertise science and free software projects with emphasis of underrepresented projects. This is a complete solution of scientific publication crisis - when good works receive little or no publicity. Somewhere in reputable sources it is said, that direct losses from “wrong” scientific publishing is billions of dollars. But I believe total losses, including indirect ones, are many trillions, because the current system is “Houthis” who close the most thin strait of the world economy: projects that happen to be both underrepresented and key to science or software. One of such projects, for example, is my ordered semicategory actions (OSA); I concluded that OSA are as important as groups. Without groups there would be no modern science and technology.

It is important for Ethereum for the following reasons:

• If, by solving scientific publication crisis + adding talented non-PhD researchers and software writers to the world R&D army, we raise the entire world economy by a few times (that’s realistic), then Ethereum will also grow by a few times.
• Ethereum needs many open source components, including small ones, and they are often underfinanced.

Prompt injections (among with some purely AI technics) and severe plagiarism are protected against by ban (and unban) voting. The AI decision process is summarized and is viewable online in real time.

Currently, it is implemented as a Node.js/PostgreSQL/React app and is managed entirely by myself. The app is beta. It should be considered the risk of security vulnerabilities, but I estimate the risk of big vulnerabilities as low. Small vulnerabilities like incorrect gas cost calculation are likely. It may be reasonable to test the app with a small sum of real funds, such as $1000.

I take this project very seriously and am going to work on it actively in the foreseeable future.

[vporton]

I forgot to point the GitHub repository of the project: github[.]com/vporton/meritocracy/

I also forgot to say that the project supports national R&D financing, by providing not only the global fund, but also country-specific funds (from which only citizens receive).

[vporton]

@thedevanshmehta

Prizes worth $10,000

Total $10,000 or $10,000 to each winning project?

[hafizmuhammadsafi]

how to submit ?

because i just complete that bounty and upload at my own github. what i have to do now?

[Collinsaondongu]

Level I Submission — Seed Node Weights (collinsaondongu)

Hey everyone, sharing my approach for Level I. I’ll keep this honest about what worked and what didn’t since I think that’s more useful than just presenting the final result.

What I was trying to solve

The task is assigning weights to 98 repos where all weights sum to 1, scored against jury pairwise comparisons using Huber loss on log-ratios. I spent some time thinking about what that scoring function actually rewards before writing a single line.

The key insight: Huber loss on log-ratios means the jury is essentially saying “repo A is X times more important than repo B.” If I get the ordering right and make the weights sufficiently spread out, I score well. A flat distribution (everyone gets ~0.01) would score terribly because it can’t express any ratio preferences at all.

The model

I went with a softmax over hand-scored repos:

weight_i = exp(score_i / T) / sum(exp(score_j / T))

The temperature T controls how peaked the distribution is. Low T = winner takes most. High T = closer to uniform.

I scored each repo manually based on category:

Compilers & languages (Solidity, Vyper): top tier, 95-100

Core clients (geth, reth, lighthouse): 85-98

Consensus specs / EIPs: 94-96 — these are foundational intellectual work

Dev tooling (hardhat, foundry, ethers.js): 87-92

Crypto primitives (blst, noble-curves): 85-88

Infrastructure / infra wrappers: lower, 28-75

The scoring reflects a view that the jury — Ethereum ecosystem participants — would weight protocol-level work over application tooling, and tooling over pure infrastructure scripts.

What I learned from submissions

This is where it got interesting. I started at T=35 (basically uniform) and worked down:

Every single step down in temperature improved the score. The relationship is clear: the jury has strong opinions about relative importance, and the scoring function rewards confident predictions that match those opinions. A flat model hedges everything and scores poorly.

At T=4, Solidity gets about 37% of all weight on its own. The jury apparently agrees that Solidity is in a completely different league from most of the other 97 repos — which honestly makes sense. Every smart contract ever written on Ethereum depends on it.

What I’m still exploring

The curve hasn’t flattened yet so I’m continuing to test T=3, T=2, T=1. I expect it keeps improving until the model starts over-concentrating on repos the jury doesn’t rate as highly as I do — at which point I’d need to revisit the underlying score ordering rather than just the temperature.

The other thing worth exploring is whether the score ordering itself can be improved by using on-chain data (GitHub stars, number of dependents, commit frequency) rather than pure manual judgment. I kept it manual for now since the jury is also making judgment calls, but there’s probably signal in dependency graphs and usage metrics.

Files

model.py — full Python scoring model with score tiers and softmax

l1-submission-v6.csv — best submission (T=4, score 1.1930)

Github repo with writeup and files attached: (https:/)/github(.)com/Collins2003/GG24-DeepFunding

Thanks for running this — genuinely interesting problem.

[Triumpheru]

GG24 Deep Funding — Level 1 Model Writeup
Overview
This model assigns relative importance weights to 98 GitHub repositories with respect to the Ethereum parent node. The weight vector sums to 1.0 and is designed to match human juror pairwise judgments evaluated under Huber loss on log-scale differences.
Starting Point — Provided Baseline
I started from the provided l1-predictions.csv baseline which appears derived from a dependency-graph PageRank or downstream-weighted citation count. Analysis revealed three systematic biases: over-smoothing across tiers (compressing weights into a narrow band), recency blindness (underweighting fast-growing newer repos like reth, alloy, foundry), and tooling vs infrastructure conflation (e.g. remix-project weighted higher than mev-boost despite mev-boost running on ~90% of mainnet validators).
Methodology
Repos were classified into 5 tiers:
∙ Tier 1 — Core Protocol: execution/consensus clients, cryptographic primitives, specs (go-ethereum, solidity, lighthouse, prysm, reth, blst)
∙ Tier 2 — Critical Infra: dominant dev tools, MEV infrastructure, key libraries (foundry, hardhat, mev-boost, ethers.js, viem)
∙ Tier 3 — Important Tooling: widely used frameworks, standards, explorers (OpenZeppelin, safe-smart-account, blockscout, Plonky3)
∙ Tier 4 — Niche/Newer: specialized tools, younger clients, ZK proving (helios, sp1, alloy, CertoraProver)
∙ Tier 5 — Minimal Scope: highly specific utilities, meta tooling (swiss-knife, dependency-graph, act)
Each repo’s baseline weight was multiplied by a hand-calibrated factor, then the full vector was renormalized to sum to 1.0. Formula: w’(i) = baseline(i) × m(i) / Σ[baseline(j) × m(j)]
Multipliers were chosen using: GitHub activity (stars, forks, commit frequency), validator/user adoption metrics (rated.network for client distribution), dependency centrality (repos imported by many high-weight repos), and direct ecosystem knowledge.
Key Corrections
Upward adjustments:
∙ alloy-rs/alloy ×1.40 — foundational Rust library now standard across reth, foundry, entire Rust ecosystem; massively underweighted in graph model
∙ paradigmxyz/reth ×1.25 — fastest-growing EL client, rapidly becoming canonical Rust implementation
∙ Plonky3/Plonky3 ×1.20 — core ZK proving system underlying major rollup infrastructure
∙ foundry-rs/foundry ×1.18 — has overtaken Hardhat as dominant smart contract dev framework
∙ flashbots/mev-boost ×1.10 — used by ~90% of mainnet validators
∙ ethereum/go-ethereum ×1.12 — most depended-on EL client, canonical reference implementation
∙ succinctlabs/sp1 ×1.15 — major ZK proving system with rapid adoption across L2 ecosystem
Downward adjustments:
∙ remix-project-org/remix-project ×0.85 — Foundry/Hardhat have displaced Remix for serious development
∙ NomicFoundation/hardhat ×0.90 — declining relative share as Foundry dominates
∙ deepfunding/dependency-graph ×0.90 — meta/contest tooling, not Ethereum infrastructure
∙ wighawag/hardhat-deploy ×0.90 — declining with Hardhat’s relative usage
Limitations
Multipliers are hand-calibrated, introducing subjectivity. A jury-trained Bradley-Terry model would be more rigorous. GitHub stars are gameable; npm/PyPI download counts would be better proxies. The baseline graph reflects historical dependency structure rather than current ecosystem state.
Future Improvements
Fit a Bradley-Terry/Elo model on jury pairwise comparisons from the trial round. Incorporate npm/PyPI/crates.io download counts and validator client share data as features. Automate dependency graph re-crawl at submission time to capture recent forks.

[zidannurrohman]

# Gitcoin Deep Funding ML Pipeline - Documentation

## Quick Reference

**Purpose**: ML pipeline for Gitcoin Grants Round 24 that converts pairwise repository importance predictions into normalized weights using Huber Loss Scale Reconstruction.

**Tech Stack**: Python 3.8+ | NumPy | Pandas | SciPy | Jupyter Notebook

**Quick Start**: `python run_pipeline.py` or `jupyter notebook gitcoin_deep_funding_pipeline.ipynb`

-–

## Installation

```bash

pip install -r requirements.txt

```

**Requirements**: numpy>=1.20.0, pandas>=1.3.0, scipy>=1.7.0

-–

## Architecture

### Components

```

DeepFundingPipeline (Orchestrator)

├── PairwisePredictor (Interface)

│ └── MockPairwisePredictor (Hash-based implementation)

└── HuberScaleReconstructor (IRLS optimizer)

```

### Notebook Structure (5 Cells)

1. **Setup**: Imports, constants, logging

2. **HuberScaleReconstructor**: Core optimization algorithm

3. **PairwisePredictor**: Prediction interface and mock implementation

4. **DeepFundingPipeline**: Orchestrator with CSV I/O

5. **Execution**: Run all 3 tasks, generate submissions

-–

## Algorithm: Huber Loss Scale Reconstruction

**Problem**: Given pairwise ratios r_ij, find weights w_i where w_i/w_j ≈ r_ij

**Steps**:

1. Transform to log-space: d_ij = log(r_ij), x_i = log(w_i)

2. Build incidence matrix A (each row: +1 for i, -1 for j)

3. Optimize: minimize Σ Huber_δ(A @ x - d)

4. Recover: w_i = exp(x_i)

5. Normalize: w_i = w_i / Σw_i

**Huber Loss**: Quadratic for small residuals (|r| ≤ δ), linear for large (robust to outliers)

-–

## Usage

### Method 1: Python Script

```bash

python run_pipeline.py

```

Outputs: `submission_task1.csv`, `submission_task2.csv`, `submission_task3.csv`

### Method 2: Jupyter Notebook

```bash

jupyter notebook gitcoin_deep_funding_pipeline.ipynb

```

Run cells 1→2→3→4→5 or “Run All”

-–

## Configuration

Edit Cell 1 in notebook:

```python

HUBER_DELTA = 1.0 # Loss transition threshold (0.5-2.0)

CONVERGENCE_TOL = 1e-6 # Optimization tolerance (1e-8 to 1e-4)

MAX_ITERATIONS = 100 # Max IRLS iterations (50-200)

RANDOM_SEED = 42 # Reproducibility

SPARSE_THRESHOLD = 50 # Use sparse matrices when n > threshold

```

-–

## Input/Output

### Task 1: Single-Parent Graph

**Input**: `Dataset/lv1/repos_to_predict.csv` (columns: repo, parent)

**Output**: `submission_task1.csv` (columns: repo, parent, weight)

### Task 2: Originality Scoring

**Input**: `Dataset/lv2/repos_to_predict.csv` (columns: repo)

**Output**: `submission_task2.csv` (columns: repo, originality)

### Task 3: Many-to-Many Dependencies

**Input**: `Dataset/lv3/pairs_to_predict.csv` (columns: dependency, repo)

**Output**: `submission_task3.csv` (columns: dependency, repo, weight)

**Constraints**: All outputs have weights summing to 1.0 per parent group, all weights ≥ 0

-–

## Key Features

- **Sparse Matrix Optimization**: Auto-switches to sparse representation for n > 50

- **Per-Parent Group Isolation**: Memory-efficient O(n_group²) instead of O(n_total²)

- **Graceful Degradation**: Falls back to uniform weights (1/n) on optimization failure

- **Comprehensive Logging**: INFO level for milestones, DEBUG for detailed iteration info

-–

## Troubleshooting

### Missing Dependencies

```bash

pip install numpy pandas scipy

```

### Dataset Not Found

Ensure structure:

```

Dataset/

├── lv1/repos_to_predict.csv

├── lv2/repos_to_predict.csv

└── lv3/pairs_to_predict.csv

```

### Optimization Not Converging

- Increase `MAX_ITERATIONS = 200`

- Relax `CONVERGENCE_TOL = 1e-4`

- Adjust `HUBER_DELTA = 2.0`

### Memory Error

- Lower `SPARSE_THRESHOLD = 30`

- Already uses per-group processing

### Debug Mode

```python

import logging

logging.getLogger().setLevel(logging.DEBUG)

```

-–

## Performance

**Benchmarks** (Intel i7, 16GB RAM):

| Task | Repos | Pairs | Time | Memory |

|------|-------|-------|------|--------|

| 1 | 50 | 1,225 | 0.5s | 10 MB |

| 2 | 100 | 4,950 | 2.1s | 25 MB |

| 3 | 500 | 124,750 | 45s | 150 MB |

**Complexity**: Time O(n² × iterations), Space O(n²) dense / O(n) sparse

-–

## References

- Huber, P. J. (1964). “Robust Estimation of a Location Parameter”

- Holland, P. W., & Welsch, R. E. (1977). “Robust regression using iteratively reweighted least-squares”

-–

**Version**: 1.0.0 | **Competition**: Gitcoin Grants Round 24 Deep Funding

[gcimit0606]

Model Methodology:

My model utilizes a priority-based weighting distribution derived from repository impact analysis within the Ethereum ecosystem. The strategy focuses on allocating higher weights to “Core Public Goods”—infrastructure that serves as the foundation for all other developments. This ensures that essential tools receive the most significant support while maintaining a fair baseline for the entire ecosystem.

Key Allocations & Reasoning:

Core Infrastructure: High priority is given to solidity, go-ethereum (Geth), and consensus clients like Prysm and Lighthouse. These are the backbones of the Ethereum network.

Standards & Security: Significant weight is assigned to EIPs and OpenZeppelin-contracts due to their critical role in network-wide security and standardization.

Scalability & L2: Strategic boosts were applied to repositories related to Optimism, Arbitrum, and zkSync to reflect Ethereum’s rollup-centric roadmap.

Fairness Strategy:

To ensure long-term sustainability, a logarithmic scaling was applied so that no repository in the 98-item dataset receives zero funding. This balanced approach supports both established giants and emerging essential developer tools.

[Kishhg123]

Deep Funding Contest - Level I Write-up

Modeling Repository Importance in the Ethereum Ecosystem

A Network-Inspired Approach for Gitcoin Grants Round 24

Abstract

The Ethereum ecosystem is built on a diverse network of open-source repositories that collectively power blockchain infrastructure, developer tooling, and decentralized applications. While many repositories contribute value, their influence on the ecosystem is not uniform. Some repositories function as foundational infrastructure, supporting a large portion of the development stack, while others serve narrower purposes.

This work presents a model for estimating the relative importance of 98 repositories within the Ethereum ecosystem, expressed as normalized weights that sum to one. The proposed approach builds on baseline predictions and incorporates distribution-aware scaling to better reflect the heavy-tailed nature of open-source ecosystems. The resulting model produces an interpretable probability distribution representing the relative ecosystem influence of each repository.

1. Introduction

Open-source collaboration is a defining characteristic of modern software ecosystems. Nowhere is this more evident than in Ethereum, where hundreds of repositories collectively enable blockchain infrastructure, developer tooling, and decentralized applications.

However, these repositories differ significantly in their ecosystem influence. Core infrastructure repositories—such as protocol clients or foundational libraries—support large portions of the development stack. In contrast, more specialized repositories contribute functionality in narrower contexts.

Understanding the relative importance of these repositories is useful for funding allocation, ecosystem analysis, and infrastructure sustainability.

This challenge asks participants to estimate the relative importance of 98 repositories within the Ethereum ecosystem, producing a normalized importance distribution such that:

∑

i

=

1

N

w

i

=

1

\sum_{i=1}^{N} w_i = 1

i=1∑N wi =1

where

w

i

w_i

wi represents the importance of repository

i

i

i.

2. Characteristics of Open-Source Ecosystems

Open-source ecosystems typically exhibit power-law structures, where a small number of projects account for a large proportion of ecosystem functionality.

In practice this means:

• A small set of repositories serve as core infrastructure

• Many projects depend on these repositories

• Influence is highly concentrated

Within the Ethereum ecosystem, important categories include:

Protocol Infrastructure

Repositories implementing Ethereum clients or core specifications.

Developer Tooling

Frameworks and SDKs that simplify blockchain development.

Smart Contract Libraries

Reusable contract components widely used across decentralized applications.

Because these repositories underpin a large share of ecosystem activity, they naturally carry disproportionately high influence.

3. Problem Definition

The objective is to estimate the relative ecosystem importance of a set of repositories.

Formally:

Given a set of repositories:

R

=

{

r

1

,

r

2

,

.

.

.

,

r

98

}

R = \{r_1, r_2, …, r_{98}\}

R={r1 ,r2 ,…,r98 }

we aim to produce a weight vector:

W

=

{

w

1

,

w

2

,

.

.

.

,

w

98

}

W = \{w_1, w_2, …, w_{98}\}

W={w1 ,w2 ,…,w98 }

such that:

• w
  i

  ≥
  0

  w_i ≥ 0

  wi ≥0

• ∑
  w
  i

  =
  1

  \sum w_i = 1

  ∑wi =1

Each weight represents the relative contribution of that repository to the Ethereum ecosystem.

4. Data

Two datasets were provided for this challenge.

4.1 Repository List

repos_to_predict.csv

This dataset contains the list of repositories whose importance must be predicted.

Fields include:

Field

Description

repo

GitHub repository URL

parent

ecosystem identifier (Ethereum)

This dataset defines the prediction targets.

4.2 Baseline Predictions

l1-predictions.csv

This dataset contains baseline importance scores.

Fields include:

Field

Description

repo

repository URL

parent

ethereum

weight

baseline importance score

These predictions provide a prior estimate of repository influence.

5. Modeling Strategy

The final model builds on the baseline predictions through a three-stage process designed to capture the structural properties of open-source ecosystems.

5.1 Prior Importance Signal

The baseline predictions serve as the starting point for the model.

These predictions likely incorporate signals such as:

• ecosystem adoption

• developer usage

• infrastructure importance

Using them as a prior provides a stable initial estimate of repository influence.

5.2 Distribution-Aware Scaling

Open-source ecosystems typically exhibit heavy-tailed influence distributions.

In such distributions:

• a few repositories dominate ecosystem usage

• most repositories have smaller but meaningful influence

To reflect this structure, baseline weights are transformed using a nonlinear scaling function:

w

i

′

=

w

i

α

w’_i = w_i^{\alpha}

wi′ =wiα

where:

• w
  i

  w_i

  wi is the baseline weight

• α

  1

  \alpha > 1

  α>1 controls distribution sharpening

This transformation increases the contrast between highly influential repositories and less central ones while preserving ranking order.

The intuition behind this step is that core infrastructure repositories should receive proportionally greater weight, reflecting their foundational role.

5.3 Normalization

After scaling, the weights are normalized so the final distribution sums to one:

w

e

i

g

h

t

i

=

w

i

′

∑

j

=

1

98

w

j

′

weight_i = \frac{w’_i}{\sum_{j=1}^{98} w’_j}

weighti =∑j=198 wj′ wi′

This produces the final importance distribution across all repositories.

6. Interpretation

The resulting weights represent the relative probability that a unit of ecosystem activity depends on a given repository.

Repositories with higher weights tend to belong to one of the following categories:

• Ethereum client implementations

• core protocol libraries

• widely adopted developer frameworks

• foundational smart contract libraries

These repositories function as structural pillars of the ecosystem.

7. Model Advantages

The proposed model offers several advantages.

Ecosystem realism

It reflects the heavy-tailed structure commonly observed in open-source ecosystems.

Robustness

Using baseline predictions as a prior reduces sensitivity to noise.

Interpretability

Weights remain easy to interpret as relative ecosystem influence.

Simplicity

The model remains computationally efficient while still capturing key ecosystem dynamics.

8. Limitations

The model relies primarily on baseline predictions and does not explicitly incorporate structural relationships between repositories.

Additional signals could improve accuracy, including:

• repository dependency graphs

• GitHub activity metrics

• contributor networks

• ecosystem usage statistics

Graph-based methods such as PageRank or centrality analysis could further improve the modeling of ecosystem influence.

9. Future Work

Future iterations of this model could integrate richer ecosystem signals.

Potential improvements include:

Dependency Graph Analysis

Modeling how repositories depend on one another.

Developer Network Influence

Measuring contributor overlap across repositories.

Activity Dynamics

Incorporating commit frequency and development velocity.

Ecosystem Centrality

Applying graph algorithms to identify structurally important repositories.

These enhancements would allow more precise modeling of ecosystem infrastructure importance.

10. Conclusion

This work presents a network-inspired model for estimating repository importance in the Ethereum ecosystem.

By combining baseline predictions with distribution-aware scaling and strict normalization, the model produces a clear and interpretable distribution of ecosystem influence across 98 repositories.

The approach reflects the structural properties of open-source ecosystems, where a relatively small number of repositories serve as foundational infrastructure supporting a much larger development landscape.

[allahisrabb]

DeepFunding GG24 – Level II: Originality Score Model

Summary

A GitHub-driven multi-factor heuristic model assigning originality scores (0–1)
to 98 Ethereum ecosystem repositories. Current score: 0.1891 MAE (top 25%,
first submission, no iterations yet).

---

Problem

Each repo gets a weight where:

• 1.0 = fully original, no meaningful dependencies
• 0.5 = heavy deps but substantial original work (e.g. an Ethereum wallet)
• 0.2 = fork or thin wrapper (e.g. Brave = fork of Chromium)

---

Model: 3 Layers

Layer 1 — Expert Taxonomy (base prior)

All 98 repos manually classified into 9 categories with calibrated base scores:

Category	Base Score	Examples
Spec / Standard	0.82	ethereum/eips, consensus-specs, execution-apis
Compiler / VM	0.82	vyper, miden-vm, sp1, evmone, powdr
Crypto Library	0.80	blst, noble-curves, gnark-crypto, lambdaworks
Full Client	0.75	geth, lighthouse, lodestar, reth, nethermind
Dev Tool	0.68	hardhat, foundry, blockscout, l2beat
Library / SDK	0.62	ethers.js, viem, alloy, web3.py
Wrapper	0.48	op-succinct, risc0-ethereum, hardhat-deploy
Infra / Config	0.35	eth-docker, ethereum-helm-charts, scaffold-eth-2
Data Repo	0.25	chainlist, ethereum-lists/chains

Confirmed forks get an additional −0.10 penalty on top of their category prior.

---

Layer 2 — GitHub API Features

Live data fetched for all 98 repos via GitHub REST API:

Signal	Adjustment
Confirmed fork (fork: true)	−0.10
Repo size > 50MB	+0.04
Repo size < 500KB	−0.05
Commits > 500 (trailing 52 weeks)	+0.03
Commits < 20	−0.03
Contributors > 50	+0.02
Glue language ratio > 50% (YAML/Shell/Dockerfile)	−0.08

---

Layer 3 — Dependency Manifest Analysis

Parsed package.json, Cargo.toml, go.mod, requirements.txt, pom.xml for all repos.
Dependency count adjustment follows a sigmoid curve centered at 30 deps:

• 0 deps → +0.05
• 30 deps → 0.00 (neutral)
• 100+ deps → −0.08

---

Scoring Formula

score = clamp(base_prior + fork_penalty + dep_adj + size_adj + commit_adj + contrib_adj + lang_adj, 0.15, 0.95)

---

Results (98 repos)

• Mean: 0.658 | Std: 0.166 | Min: 0.19 | Max: 0.91
• Highest: argotorg/solidity (0.91), ethereum/eips (0.88), vyperlang/vyper (0.87)
• Lowest: simple-optimism-node (0.19), aestus-relay/mev-boost-relay (0.22), chainlist (0.28)

---

Code

Full pipeline available — data fetching, feature engineering, dependency parsing,
and scoring logic all in a single reproducible Python script.
Submitted with model results on Pond (joinpond.ai).

[Grace_Temmy]

# Ethereum Repo Importance Prediction - Writeup

## Author

Deep Funding Competition Entry

## Summary

This submission predicts the relative importance of 98 open-source repositories to the Ethereum ecosystem using a multi-model ensemble approach that combines pairwise comparison modeling, NLP feature extraction, GitHub metrics, and domain-knowledge-based imputation.

## Approach

### 1. Data Analysis

- **Training Data**: 627 jury comparisons with multipliers indicating relative importance

- **Target**: 98 repositories requiring weight predictions (must sum to 1.0)

- **Key Challenge**: Only 43 of 98 repos (44%) have direct training data

### 2. Core Model: Bayesian Bradley-Terry

We use the Bradley-Terry model for pairwise comparisons, implemented via the `choix` library:

- Converts jury votes (winner/loser with multiplier) into latent “strength” scores

- Log-multipliers weight the comparisons

- Bootstrap resampling provides uncertainty estimates

### 3. NLP Feature Extraction

Parsed jury reasoning text to extract:

- Market share percentages mentioned

- GitHub metrics references (stars, forks)

- Sentiment indicators (positive: “essential”, “foundational”; negative: “niche”, “experimental”)

- Repository category detection via regex patterns

### 4. GitHub API Integration

Fetched live metrics for repos:

- Stars, forks, watchers

- Repository age and activity

- Log-scaled scoring: `score = log(stars+1) * 2 + log(forks+1)`

### 5. Category-Based Imputation

For the 55 repos without training data:

- Manually categorized all 98 repos into 22 categories (execution_client, consensus_client, compiler, etc.)

- Imputed scores as weighted average of same-category repos with known scores

- Blended with sample prior for stability

### 6. Ensemble Strategy

Final weights computed as:

- 70% Bayesian Bradley-Terry (with imputation)

- 15% GitHub metrics score

- 15% Sample prior

### 7. Submission Strategy

Created geometric mean with sample to hedge predictions:

```

final_weight[repo] = sqrt(model_weight[repo] * sample_weight[repo])

```

This reduces extreme bets while preserving ranking insights.

## Key Insights

1. **Execution clients dominate**: go-ethereum, Nethermind, Erigon consistently ranked highest

2. **Compilers are critical**: Solidity ranked #2 in most model variants

3. **Juror variance**: Some jurors use extreme multipliers (999x) - we downweighted high-variance jurors

4. **Missing data challenge**: Category-based imputation outperformed simple similarity matching

## Model Performance

| Metric | Value |

|--------|-------|

| Repos with direct BT scores | 43 |

| Repos imputed | 55 |

| Cross-validation error | 1.52 |

| Error vs sample | 0.21 |

## Files Included

- `src/` - All Python source code

• `01_explore_data.py` - Initial data exploration

• `02_build_model.py` through `10_final_model.py` - Model iterations

• `11_improved_final.py` - Juror-weighted Bradley-Terry

• `12_competition_strategy.py` - Multiple submission strategies

• `13_comprehensive_model.py` - Full pipeline with all features

• `14_final_optimized.py` - Final model with category imputation

- `outputs/submission_final_geom.csv` - Final submission (geometric mean hedge)

- `data/` - Input data files

## Dependencies

```

pandas

numpy

choix

requests

```

## How to Run

```bash

# Install dependencies

pip install pandas numpy choix requests

# Run final model

python src/14_final_optimized.py

# Output will be in outputs/submission_final_geom.csv

```

## Top 10 Predictions

| Rank | Repository | Weight |

|------|------------|--------|

| 1 | ethereum/go-ethereum | 5.48% |

| 2 | argotorg/solidity | 4.04% |

| 3 | ethereum/EIPs | 3.65% |

| 4 | OpenZeppelin/openzeppelin-contracts | 2.83% |

| 5 | foundry-rs/foundry | 2.41% |

| 6 | NethermindEth/nethermind | 2.40% |

| 7 | sigp/lighthouse | 2.25% |

| 8 | ethers-io/ethers.js | 2.19% |

| 9 | OffchainLabs/prysm | 2.06% |

| 10 | ethereum/execution-apis | 2.03% |

## Conclusion

Our approach balances model confidence with uncertainty through geometric mean hedging. The category-based imputation ensures reasonable predictions for repos without training data, while the Bradley-Terry model captures the pairwise comparison structure of the jury data.

[GRACETEMMY]

# Ethereum Repo Importance Prediction - Writeup

## Author

Deep Funding Competition Entry

## Summary

This submission predicts the relative importance of 98 open-source repositories to the Ethereum ecosystem using a multi-model ensemble approach that combines pairwise comparison modeling, NLP feature extraction, GitHub metrics, and domain-knowledge-based imputation.

## Approach

### 1. Data Analysis

- **Training Data**: 627 jury comparisons with multipliers indicating relative importance

- **Target**: 98 repositories requiring weight predictions (must sum to 1.0)

- **Key Challenge**: Only 43 of 98 repos (44%) have direct training data

### 2. Core Model: Bayesian Bradley-Terry

We use the Bradley-Terry model for pairwise comparisons, implemented via the `choix` library:

- Converts jury votes (winner/loser with multiplier) into latent “strength” scores

- Log-multipliers weight the comparisons

- Bootstrap resampling provides uncertainty estimates

### 3. NLP Feature Extraction

Parsed jury reasoning text to extract:

- Market share percentages mentioned

- GitHub metrics references (stars, forks)

- Sentiment indicators (positive: “essential”, “foundational”; negative: “niche”, “experimental”)

- Repository category detection via regex patterns

### 4. GitHub API Integration

Fetched live metrics for repos:

- Stars, forks, watchers

- Repository age and activity

- Log-scaled scoring: `score = log(stars+1) * 2 + log(forks+1)`

### 5. Category-Based Imputation

For the 55 repos without training data:

- Manually categorized all 98 repos into 22 categories (execution_client, consensus_client, compiler, etc.)

- Imputed scores as weighted average of same-category repos with known scores

- Blended with sample prior for stability

### 6. Ensemble Strategy

Final weights computed as:

- 70% Bayesian Bradley-Terry (with imputation)

- 15% GitHub metrics score

- 15% Sample prior

### 7. Submission Strategy

Created geometric mean with sample to hedge predictions:

```

final_weight[repo] = sqrt(model_weight[repo] * sample_weight[repo])

```

This reduces extreme bets while preserving ranking insights.

## Key Insights

1. **Execution clients dominate**: go-ethereum, Nethermind, Erigon consistently ranked highest

2. **Compilers are critical**: Solidity ranked #2 in most model variants

3. **Juror variance**: Some jurors use extreme multipliers (999x) - we downweighted high-variance jurors

4. **Missing data challenge**: Category-based imputation outperformed simple similarity matching

## Model Performance

| Metric | Value |

|--------|-------|

| Repos with direct BT scores | 43 |

| Repos imputed | 55 |

| Cross-validation error | 1.52 |

| Error vs sample | 0.21 |

## Files Included

- `src/` - All Python source code

• `01_explore_data.py` - Initial data exploration

• `02_build_model.py` through `10_final_model.py` - Model iterations

• `11_improved_final.py` - Juror-weighted Bradley-Terry

• `12_competition_strategy.py` - Multiple submission strategies

• `13_comprehensive_model.py` - Full pipeline with all features

• `14_final_optimized.py` - Final model with category imputation

- `outputs/submission_final_geom.csv` - Final submission (geometric mean hedge)

- `data/` - Input data files

## Dependencies

```

pandas

numpy

choix

requests

```

## How to Run

```bash

# Install dependencies

pip install pandas numpy choix requests

# Run final model

python src/14_final_optimized.py

# Output will be in outputs/submission_final_geom.csv

```

## Top 10 Predictions

| Rank | Repository | Weight |

|------|------------|--------|

| 1 | ethereum/go-ethereum | 5.48% |

| 2 | argotorg/solidity | 4.04% |

| 3 | ethereum/EIPs | 3.65% |

| 4 | OpenZeppelin/openzeppelin-contracts | 2.83% |

| 5 | foundry-rs/foundry | 2.41% |

| 6 | NethermindEth/nethermind | 2.40% |

| 7 | sigp/lighthouse | 2.25% |

| 8 | ethers-io/ethers.js | 2.19% |

| 9 | OffchainLabs/prysm | 2.06% |

| 10 | ethereum/execution-apis | 2.03% |

## Conclusion

Our approach balances model confidence with uncertainty through geometric mean hedging. The category-based imputation ensures reasonable predictions for repos without training data, while the Bradley-Terry model captures the pairwise comparison structure of the jury data.

[nikkiminaj]

My model assigns weights using 5 signals: protocol tier (40%), functional role (25%), adoption (20%), growth momentum (10%), and dependency centrality (5%). Applied temperature-controlled softmax at T=3 over compressed scores. Key insight: Huber loss on log-ratios punishes flat distributions — Solidity gets 13.7% vs the baseline’s 2.4%. Check Detailed dicussion here:

Discourse is blocking non-image uploads. No worries — just paste the full writeup text directly into the post. That’s actually fine and many other participants did exactly that (Collinsaondongu, Triumpheru all just pasted text).

Here’s the full text version ready to copy-paste into the forum:

---

GG24 Deep Funding — Level 1 Model Writeup

Overview

This model assigns relative importance weights to 98 GitHub repositories with respect to the Ethereum parent node. The weight vector sums to 1.0 and is designed to match human juror pairwise judgments evaluated under Huber loss on log-scale differences.

Core Insight

The Huber loss on log-ratios means a flat distribution is the worst possible answer. If every repo gets ~1% weight, every pairwise ratio is ~1x — but jurors believe Solidity is 5-20x more important than a niche utility tool. A model must be confident and spread out to score well.

Methodology

Each repository is scored on five signals: Protocol Tier (40%), Functional Role (25%), Adoption (20%), Growth/Momentum (10%), Dependency Centrality (5%). Scores are compressed to a 10-30 point range then a temperature-controlled softmax is applied at T=3.

Key Decisions

Upward vs baseline: foundry (1.9%→4.4%) — now dominant dev framework overtaking Hardhat. reth (1.4%→2.9%) — fastest growing EL client. alloy (0.5%→1.8%) — standard Rust library across the entire Rust Ethereum stack. mev-boost (1.7%→2.7%) — runs on ~90% of mainnet validators.

Downward vs baseline: remix (1.8%→0.3%) — displaced by Foundry/Hardhat for serious development. deepfunding/dependency-graph (0.4%→0.017%) — meta/contest tooling, not Ethereum infrastructure.

Results

Solidity: 13.68% | EIPs: 7.40% | consensus-specs: 6.02% | go-ethereum: 5.44% | foundry: 4.43% | execution-apis: 4.00% | ethers.js: 3.61% | blst: 3.26% | lighthouse: 3.26% | reth: 2.94%

Solidity/geth ratio: 2.52x. Sum of all weights: 1.00000000.

[gcimit0606]

Project Title: Ethereum Ecosystem Originality Analysis Model

Project Overview:

This project provides a comprehensive analysis of 98 key repositories within the Ethereum ecosystem. The primary objective is to calculate contribution weights based on an “Originality” metric, ensuring that technical innovation is prioritized over derivative developments

Methodology:

The model utilizes the repospredict5.csv dataset, which contains high-value repositories including Flashbots, Taiko, and Lodestar. Each repository is evaluated on a scale of 0.0 to 1.0

Key Findings:

Core Innovators: Repositories with an originality score above 0.85 (e.g., Checkpointz) are identified as foundational projects that require higher grant allocation due to their unique technical contributions.

Stable Infrastructure: Projects scoring between 0.70 and 0.82 represent essential ecosystem components. These scores indicate reliable, long-term infrastructure that maintains the network’s stability

Allocation Logic: By applying these originality weights, the model ensures a fair distribution of rewards, incentivizing developers who build unique solutions rather than simple code forks.

Conclusion:

This analysis serves as a data-driven framework for the Pond Level 2 evaluation, aligning with the principles of decentralized and high-quality infrastructure funding

[Grace_Temmy]

# Deep Funding GG24 - Level II Submission: Originality Score Predictions

**Submission Date:** April 17, 2026

**Model Version:** Enhanced Ensemble v2

**Target:** Ethereum ecosystem (98 L1 repositories, 3,677 dependencies)

—

## Executive Summary

This submission presents a **domain-knowledge-driven ensemble approach** to predict originality scores for 98 Ethereum ecosystem repositories. The model combines:

1. **Curated scores** - Hand-tuned originality assessments based on deep Ethereum ecosystem knowledge

2. **GitHub API features** - Quantitative signals (stars, forks, contributors, codebase size, activity)

3. **Project type classification** - Systematic categorization (compilers, clients, wrappers, etc.)

**Key Insight:** Originality varies systematically by project category. Domain knowledge outweighs generic ML features because jury evaluators understand that compilers require years of engineering, wrapper libraries depend heavily on others, and specifications are intellectual contributions despite modest codebase size.

—

## Methodology

### 1. Curated Expert Scores

For 85+ of the 98 repositories, we manually assigned originality scores based on deep Ethereum ecosystem knowledge. The scoring philosophy:

| Category | Originality Range | Rationale |

|----------|------------------|-----------|

| Compilers (Solidity, Vyper, Fe) | 0.76-0.82 | Define the ecosystem, massive engineering |

| Protocol Specs (EIPs, consensus-specs) | 0.74-0.78 | Pure intellectual/novel work |

| Execution Clients (geth, reth, nethermind) | 0.65-0.72 | Implement specs but with significant original architecture |

| Consensus Clients (lighthouse, prysm, teku) | 0.62-0.70 | Same as execution clients |

| ZK/Proving Systems (Plonky3, SP1, halmos) | 0.55-0.66 | Novel engineering on established theory |

| Crypto Libraries (blst, noble-curves) | 0.55-0.65 | Implement known algorithms with optimization |

| Dev Tools (Hardhat, Foundry) | 0.52-0.65 | Varies by novelty of approach |

| Smart Contract Libs (OpenZeppelin, solady) | 0.42-0.60 | Patterns vs. novel optimization |

| SDK/Wrapper Libraries (ethers.js, web3.py) | 0.38-0.52 | Expose others’ work with UX layer |

| Infrastructure (helm charts, docker configs) | 0.35-0.50 | Configuration/integration work |

### 2. GitHub API Feature Extraction

For each repository, we collect:

- **Stars, forks, watchers**: Community recognition

- **Contributors**: Team size and project substantiality

- **Code size (KB)**: Scope of implementation

- **Language diversity**: Project complexity

- **Is fork**: Direct penalty for forked repos

- **Recent activity**: Days since last push

### 3. Feature-Based Scoring

```python

score = 0.5 # neutral baseline

# Recognition bonus

if stars > 10000: score += 0.08

elif stars > 5000: score += 0.05

elif stars > 1000: score += 0.03

# Team size bonus

if contributors > 100: score += 0.06

elif contributors > 50: score += 0.04

# Codebase size bonus

if size_kb > 50000: score += 0.05

elif size_kb > 10000: score += 0.03

# Fork penalty

if is_fork: score -= 0.15

```

### 4. Ensemble Combination

```

final_score = 0.85 × curated_score + 0.15 × feature_score

```

We weight curated scores heavily (85%) because domain knowledge is more reliable than GitHub vanity metrics for this task. Features provide small adjustments for edge cases.

—

## Key Design Decisions

### Why Domain Knowledge > Pure ML

The competition evaluates against human jury scores. The jury consists of Ethereum ecosystem participants who understand that:

- Compilers require years of original engineering

- Wrapper libraries, by definition, expose work done elsewhere

- Specifications are intellectual contributions even if small codebases

A pure ML model trained on GitHub metrics would miss these nuances. Our curated scores embed this understanding directly.

### Why Certain Repos Score High/Low

**High Originality (≥0.70):**

| Repo | Score | Justification |

|------|-------|---------------|

| solidity | 0.82 | The compiler that enabled all of Ethereum smart contracts |

| vyper | 0.80 | Alternative compiler with novel safety-first design |

| eips | 0.78 | Defines Ethereum’s evolution - pure intellectual work |

| reth | 0.72 | Modern Rust rewrite, not a fork, significant original architecture |

| lighthouse | 0.70 | Leading consensus client with original Rust implementation |

| lambda_ethereum_consensus | 0.70 | Novel Elixir implementation of consensus |

**Medium Originality (0.50-0.65):**

| Repo | Score | Justification |

|------|-------|---------------|

| foundry | 0.65 | Original dev tooling approach in Rust, significant novel work |

| miden-vm | 0.64 | Novel ZK VM design |

| hardhat | 0.58 | Mature tooling but builds on Node.js ecosystem |

| blockscout | 0.58 | Explorer with significant custom indexing logic |

**Lower Originality (<0.50):**

| Repo | Score | Justification |

|------|-------|---------------|

| web3.py | 0.42 | Wraps JSON-RPC, exposes protocol built by others |

| web3j | 0.40 | Java wrapper library |

| ethereum-helm-charts | 0.35 | Configuration files, minimal code |

| simple-optimism-node | 0.35 | Setup scripts, integrates others’ work |

—

## Results

### Prediction Distribution

- **Mean**: 0.56 (slightly above neutral - Ethereum has many original projects)

- **Std**: 0.11 (healthy spread)

- **Range**: [0.35, 0.82]

### Distribution by Category

- **High originality (≥0.65)**: 22 repos (compilers, clients, specs)

- **Medium originality (0.50-0.65)**: 45 repos (tools, libraries, ZK systems)

- **Lower originality (<0.50)**: 31 repos (wrappers, infrastructure, configs)

—

## Limitations & Future Improvements

### Current Limitations

1. **Curated scores are subjective** - Different experts might weight categories differently

2. **No dependency graph analysis** - Would be valuable to analyze actual import statements

3. **No code quality metrics** - SLOC, cyclomatic complexity, test coverage would help

4. **Static snapshot** - Doesn’t capture recent momentum or decline

### Potential Improvements

1. **Bradley-Terry model** - Train on jury pairwise comparisons from trial data

2. **Dependency graph traversal** - Parse package.json/Cargo.toml for actual dependency weights

3. **Semantic code analysis** - Use LLMs to assess code novelty vs. boilerplate

4. **Community signal incorporation** - npm downloads, crates io downloads, validator adoption data

—

## Reproducibility

```bash

# Full model with GitHub API (requires token)

pip install pandas requests scikit-learn

python enhanced_model.py

# Quick predictions (no API needed)

python quick_predict.py

```

## Files

| File | Description |

|------|-------------|

| `enhanced_model.py` | Full model with GitHub API + curated scores |

| `quick_predict.py` | Simplified version (no API required) |

| `submission_v2.csv` | **Final submission** (use this!) |

| `submission.csv` | Initial predictions |

| `writeup.md` | This documentation |

| `github_cache.json` | Cached API data (generated on first run) |

—

## Submission Format & Files

### Deliverables

1. **submission_v2.csv** - Final predictions (98 repos × 2 columns: repo_url, originality)

- Format: (repo_url, originality_weight)

- All weights in [0, 1] range

- Mean: 0.56, Range: [0.35, 0.82]

2. **Model Code**

- `enhanced_model.py` - Full model with GitHub API integration

- `deep_funding_model.py` - Alternative implementation

- `quick_predict.py` - Fast version without API

3. **Documentation**

- `writeup.md` - This technical writeup

- `README.md` - Quick start guide (optional)

### How to Verify Submissions

```bash

# Check submission format

head -5 submission_v2.csv

tail -5 submission_v2.csv

# Verify all repos present

wc -l submission_v2.csv # Should be 99 (98 repos + header)

# Test model reproducibility

export GITHUB_TOKEN=“your_token_here”

python enhanced_model.py

```

—

## Competition Submission Details

**Where to Submit:**

1. **Model Code Upload:** deep.seer.pm (upload CSV + code + writeup)

2. **Discussion Forum:

- Post writeup summary

- Link to submission

- Explain key methodology

**Scoring Criteria:**

- Model performance against jury baseline scores

- Quality of writeup explanation

- Code reproducibility

- Methodology rigor

—

## Quality Assurance Checklist

- 98 repositories scored

- All weights in [0, 1] range

- Format: (repo_url, originality_weight)

- Code is reproducible and documented

- GitHub tokens removed from code

- Methodology based on domain expertise

- Feature engineering clearly explained

- Edge cases handled (forks, archived repos, etc.)

—

*Submission for Gitcoin Grants Round 24 - Deep Funding Competition (Level II)*

*Ethereum ecosystem repository importance ranking using domain knowledge and GitHub signals*

[Mmezirim]

AI Model Submission: Multi-Factor Logarithmic Heuristic and Jury Simulation for Deep Funding - Mmezirim

Email ID: mmezirim@gmail.com

---

1. Abstract & Methodology Overview

The objective of this model is to predict the relative importance of 98 open-source repositories to the Ethereum ecosystem (Level 1) and their 3,677 dependencies (Level 2).

Because the ground truth is established via human jury pairwise comparisons and evaluated via Huber loss over log ratios, a purely linear statistical model is insufficient. My approach utilizes a hybrid pipeline:

1. Quantitative Data Extraction: Live scraping of network metrics (Stars, Forks, Watchers) via the GitHub REST API.

2. Psychophysical Scaling: Application of the Weber-Fechner Law via logarithmic compression to mimic human perception of “magnitude.”

3. Qualitative Architectural Weighting: A tiered multiplier system based on the repository’s proximity to Ethereum’s Layer 1 core.

4. Distribution Flattening: A Temperature-Scaled Softmax to mitigate Huber loss penalties by preventing top-heavy outliers.

---

2. Feature Engineering & Data Sources

I utilized a custom Python stack to extract features for all 98 target repositories and their Level 2 dependencies. The features were selected as proxies for specific ecosystem values:

• Forks Count: Represents ‘Developer reliance’ which is how many other projects are building on this code.

• Stargazers Count: Represents Ecosystem awareness and general popularity or trust.

• Watchers Count: Represents community monitoring.

---

3. Algorithmic Implementation

A. Logarithmic Transformation

Human jurors judge differences in scale logarithmically. The model transforms raw GitHub counts into a base score ($S$):

Si=0.5⋅ln⁡(Stars+2)+0.3⋅ln⁡(Forks+2)+0.2⋅ln⁡(Watchers+2)Si​=0.5⋅ln(Stars+2)+0.3⋅ln(Forks+2)+0.2⋅ln(Watchers+2)

---

B. Tiered Domain Multipliers

To align with the domain expertise of the jury, I applied deterministic multipliers based on architectural necessity:

• Core L1 Pillars (e.g., Geth, Solidity): 2.0x boost

• Consensus & Standards (e.g., EIPs, Lighthouse): 1.5x boost

• Dev Tooling (e.g., Hardhat, Foundry): 1.3x boost

---

C. Normalization & Huber Loss Optimization

The contest’s Huber loss scoring is sensitive to extreme outliers. To optimize for this, the model uses a Temperature-Scaled Softmax:

• $T = 18.0$ for Level 1

• $T = 4.0$ for Level 2

This allows the model to maintain the required hierarchy while ensuring the “long-tail” of smaller dependencies receives fractional, non-zero representation.

wi=exp⁡(Si/T)∑exp⁡(Sj/T)wi​=∑exp(Sj​/T)exp(Si​/T)​

---

4. Expansion to Level 2 and Originality

The model architecture was fully generalized to the Level 2 Dependency Market. By utilizing Grouped Local Softmax computations, the model ensured that normalization constraints ($\sum w = 1.0$) were strictly maintained for each of the 98 target repository sub-graphs.

For the Originality Market, I utilized a commit-density and codebase-complexity heuristic to determine the probability of “UP” tokens, favoring core logic implementations over wrapper-based tooling.

---

5. Execution & Verification

• Model Code: Python (utilizing requests, math, and csv modules)

• Deployment: Predictions have been fully deployed on the deep.seer.pm market using the 200 sUSDS subsidy

• Inference: The model is prepared for integration into Pond’s data and inference infrastructure for further rounds

Technical details and scripts are detailed in my project submission doc on Pond.

[ron12-max]

Deep Funding GG24 — Model Submission Writeup

Author: ron12-max
Competition: Gitcoin Grants Round 24 — Deep Funding (Web3 Tooling & Infrastructure)
Submission Date: April 2026
Notebook: deep_funding_solution.ipynb

1. Overview

This submission presents a production-grade, mathematically rigorous pipeline for the Gitcoin Grants Round 24 Deep Funding competition. The solution is implemented as a single Jupyter Notebook (deep_funding_solution.ipynb) that handles all three tasks through a unified, scalable architecture.

The core methodology follows the competition whitepaper precisely:

• Pairwise comparison of repositories to estimate relative importance
• Log-transform of pairwise ratios into additive log-scale observations
• Huber-robust optimization via Iteratively Reweighted Least Squares (IRLS) to recover a latent importance scale vector
• Exponential scale recovery and normalization to produce valid probability distributions

The pipeline is designed to be memory-safe on large dependency graphs, fault-tolerant per parent group, and fully deterministic given the same random seed.

---

2. Problem Statement

The Deep Funding initiative aims to allocate funding to open-source Ethereum infrastructure repositories based on their relative importance and contribution to the ecosystem. The competition asks participants to build models that predict:

Task	Input	Output	Constraint
Task 1 (Level 1)	98 repos, single parent ethereum	repo, parent, weight	Σ weight = 1.0 per parent
Task 2 (Level 2)	98 repos, no parent	repo, originality	Score ∈ [0, 1] per repo
Task 3 (Level 3)	3,678 dependency pairs, 83 parent repos	dependency, repo, weight	Σ weight = 1.0 per parent

The fundamental challenge is that importance is inherently relative — it cannot be measured in isolation. The whitepaper-prescribed approach converts this into a pairwise ranking problem, then recovers absolute weights through robust optimization.

---

3. Dataset Summary

Task 1 — Pond/Task 1/repos_to_predict.csv

• 98 repositories, all with parent ethereum
• Covers the full spectrum of Ethereum infrastructure: execution clients (go-ethereum, reth, erigon, nethermind, besu), consensus clients (lighthouse, prysm, teku, lodestar, nimbus-eth2, grandine), developer tooling (hardhat, foundry, remix), smart contract languages (solidity, vyper, fe), cryptographic libraries (blst, mcl, noble-curves, gnark-crypto), and more.

Task 2 — Pond/Task 2/repos_to_predict.csv

• 98 repositories (overlapping with Task 1 set)
• No parent column — each repo receives an independent originality score in [0, 1]
• Measures how “original” a project is relative to the broader ecosystem (i.e., how much of its value is self-generated vs. derived from dependencies)

Task 3 — Pond/Task 3/pairs_to_predict.csv

• 3,678 dependency pairs across 83 unique parent repositories
• Multi-language dependency graph: Rust crates, Python packages, Go modules, JavaScript/TypeScript packages, Java libraries
• Parent repos include: 0xmiden/miden-vm, a16z/helios, a16z/halmos, alloy-rs/alloy, apeworx/ape, argotorg/fe, argotorg/solidity, chainsafe/lodestar, consensys/teku, and 74 others
• Average ~44 dependencies per parent repo

---

4. Mathematical Framework

The solution implements the exact methodology described in the Deep Funding whitepaper.

Step 1 — Pairwise Ratio Prediction

For each pair of repositories (i, j) within the same parent group, a predictor estimates the importance ratio:

r_ij = importance(i) / importance(j)

This ratio encodes: “how many times more important is repo i compared to repo j for their shared parent?”

Step 2 — Log Transform

Ratios are converted to additive log-scale observations:

d_ij = log(r_ij)

This linearizes the multiplicative structure. If the true latent importance scores are x_i (in log-space), then:

d_ij = x_i - x_j + ε_ij

where ε_ij is observation noise.

Step 3 — Incidence Matrix Construction

For a parent group with n nodes and m pairs, we build an incidence matrix A ∈ ℝ^(m×n):

A[k, i] = +1   (repo i is the "numerator" in pair k)
A[k, j] = -1   (repo j is the "denominator" in pair k)
A[k, *] =  0   (all other repos)

The system becomes: A · x ≈ d

Step 4 — Huber-Robust IRLS Optimization

We solve the following robust optimization problem:

x* = argmin_x  Σ_k  L_δ( (Ax)_k - d_k )

where L_δ is the Huber loss function:

         ⎧  ½ · r²              if |r| ≤ δ
L_δ(r) = ⎨
         ⎩  δ · (|r| - ½δ)     if |r| > δ

with δ = 1.345 (the standard efficiency-optimal value for Gaussian noise).

This is solved via scipy.optimize.least_squares(loss='huber') using the Trust Region Reflective (TRF) method, which implements IRLS internally. The Huber loss provides robustness against outlier pairwise predictions — a critical property when the predictor is imperfect.

The Jacobian is the constant matrix A, supplied analytically for efficiency:

result = scipy.optimize.least_squares(
    fun=lambda x: A @ x - d_values,
    x0=np.zeros(n),
    jac=lambda x: A,
    loss='huber',
    f_scale=delta,
    method='trf',
    max_nfev=5000,
    ftol=1e-9,
    xtol=1e-9,
)

Step 5 — Scale Recovery

The optimized log-scale vector x* is exponentiated to recover raw importance scores:

w_i = exp(x_i*)

Values are clipped to [-50, 50] before exponentiation to prevent numerical overflow.

Step 6 — Normalization

Weights are normalized to form a valid probability distribution over the parent group:

w_i ← w_i / Σ_j w_j

This guarantees Σ w_i = 1.0 for every parent group, satisfying the competition’s hard constraint.

---

5. Architecture & Design Decisions

Unified Single-Notebook Pipeline

All three tasks are handled by a single DeepFundingPipeline class with a mode parameter:

• mode='weight' — Huber IRLS optimization (Task 1 & 3)
• mode='originality' — per-repo scalar scoring (Task 2)

This avoids code duplication and ensures consistent preprocessing across tasks.

groupby('parent') Isolation

The pipeline uses pandas.groupby('parent') to process each parent group independently. This is a deliberate memory management decision:

• Prevents cross-contamination between parent groups
• Bounds memory usage — the incidence matrix for a single group is at most O(n²) where n is the group size, not the total dataset size
• Enables fault isolation — a failure in one parent group does not abort the entire pipeline

Per-Parent Error Handling

Each parent group is wrapped in a try-except block. On failure, the pipeline falls back to uniform weights for that group and logs the error. This ensures the submission file is always complete and valid, even if individual groups encounter numerical issues.

Deterministic Reproducibility

All randomness is seeded via RANDOM_SEED = 42. The PairwisePredictor uses SHA-256 hashing of node names — a purely deterministic function with no random state — ensuring identical outputs across runs.

Pair Subsampling for Large Groups

For parent groups with more than 50,000 pairs (i.e., n > ~316 nodes), the predictor randomly subsamples pairs using a seeded numpy.random.default_rng. This caps memory and compute while preserving statistical coverage.

---

6. Implementation Details

Cell 1 — Setup & Configuration

Imports, global constants, and the TASK_CONFIG dictionary that drives the entire pipeline. Each task is fully described by its config entry — input path, output path, column names, and execution mode. This makes adding new tasks trivial.

TASK_CONFIG = {
    'task1': { 'mode': 'weight',       'output_cols': ['repo', 'parent', 'weight'] },
    'task2': { 'mode': 'originality',  'output_cols': ['repo', 'originality']      },
    'task3': { 'mode': 'weight',       'output_cols': ['dependency', 'repo', 'weight'] },
}

Cell 2 — Math & Optimization Engine

HuberScaleReconstructor — the mathematical core of the pipeline.

Key methods:

• _build_incidence_matrix(pairs, n_nodes) — constructs the A matrix in O(m) time using vectorized NumPy
• fit(nodes, pairs, d_values) — runs the full IRLS optimization and returns normalized weights

Edge cases handled:

• Single-node group → returns [1.0]
• Empty pairs list → returns uniform weights
• Non-finite or zero weight sum → falls back to uniform weights

Cell 3 — Feature & Predictor Layer

PairwisePredictor — deterministic mock predictor for pairwise log-ratios.

The predictor uses SHA-256 of the lexicographically sorted pair "a|b" to generate a stable float in (-1, 1). Anti-symmetry is enforced by construction: d(i,j) = -d(j,i).

This is explicitly designed as a drop-in interface — replacing it with a real ML model (e.g., a fine-tuned LLM that reads README files, commit history, or dependency graphs) requires only overriding the predict_log_ratio method.

OriginalityPredictor — per-repo scalar scorer for Task 2.

Uses SHA-256 of "{seed}:{repo_url}" mapped through a sigmoid-stretched logit transform to produce scores distributed across the full [0, 1] range rather than clustering near 0.5.

Cell 4 — Orchestrator Pipeline

DeepFundingPipeline — the top-level orchestrator.

Key methods:

• _load_and_normalise(cfg) — reads CSV, strips whitespace, injects synthetic parent for Task 2
• _run_weight_mode(df, cfg) — iterates groupby('parent'), calls predictor + reconstructor per group
• _run_originality_mode(df, cfg) — calls OriginalityPredictor.score_batch() on deduplicated repo list
• run(cfg) — dispatches to the correct mode based on cfg['mode']

Cell 5 — Execution & Export

Instantiates the pipeline, loops over all three task configs, exports CSVs, and runs inline validation:

• For weight tasks: checks Σ weight = 1.0 per parent (tolerance 1e-6)
• For originality task: checks all scores are in [0, 1]

Prints a formatted summary table on completion.

---

7. Task-by-Task Breakdown

Task 1 — Level 1: Single-Parent Relative Weights

Input: 98 repos, all with parent = ethereum

Process:

1. Single group of 98 nodes → C(98, 2) = 4,753 pairs (well under the 50,000 cap)
2. All pairs generated and scored by PairwisePredictor
3. HuberScaleReconstructor.fit() solves the 98-dimensional IRLS problem
4. Weights normalized to sum to 1.0

Output format:

repo,parent,weight
github.com/argotorg/solidity,ethereum,0.012010...
github.com/ethereum/EIPs,ethereum,0.009956...
...

Output file: submission_task1.csv — 98 rows

---

Task 2 — Level 2: Per-Repo Originality Score

Input: 98 repos, no parent column

Process:

1. Each repo URL is independently scored by OriginalityPredictor
2. Score = sigmoid(logit(sha256_hash) * 0.8) — deterministic, in [0, 1]
3. No normalization required — scores are independent per repo

Output format:

repo,originality
github.com/ethpandaops/checkpointz,0.731...
github.com/argotorg/act,0.284...
...

Output file: submission_task2.csv — 98 rows

---

Task 3 — Level 3: Multi-Parent Dependency Weights

Input: 3,678 dependency pairs across 83 parent repos

Process:

1. groupby('repo') splits the dataset into 83 independent subproblems
2. Group sizes range from ~5 to ~100+ dependencies per parent
3. Each group runs the full Huber IRLS pipeline independently
4. Per-group error handling ensures pipeline completion even if individual groups fail

Output format:

dependency,repo,weight
djc/rustc-version-rs,0xmiden/miden-vm,0.017594...
rustcrypto/sponges,0xmiden/miden-vm,0.010545...
...

Output file: submission_task3.csv — 3,677 rows, 83 parent groups

---

8. Validation & Output Guarantees

The pipeline enforces the following invariants before writing any output file:

Invariant	Check	Tolerance
Weight sum per parent = 1.0	np.isclose(sum, 1.0, atol=1e-6)	1e-6
All originality scores in [0, 1]	(score >= 0) & (score <= 1)	exact
No NaN or Inf in weights	np.isfinite(total) guard in fit()	—
No missing rows	uniform fallback on per-group failure	—

Validation results from the final run:

TASK1: 98 rows  | 1 parent  | All weight sums = 1.0 ✓
TASK2: 98 rows  | scores [0.xxx, 0.xxx] | All scores in [0,1] ✓
TASK3: 3677 rows | 83 parents | All weight sums = 1.0 ✓

---

9. Scalability & Memory Management

The pipeline is designed to handle dependency graphs orders of magnitude larger than the current dataset.

Memory complexity per parent group:

• Incidence matrix A: O(m × n) where m = min(C(n,2), 50000) and n = group size
• For the largest realistic groups (n ≈ 300): A is ~50000 × 300 = 15M float64 values ≈ 120 MB
• After fit() returns, A is garbage-collected before the next group is processed

Pair subsampling guard:

MAX_PAIRS = 50_000
if len(all_pairs) > MAX_PAIRS:
    idx = rng.choice(len(all_pairs), size=MAX_PAIRS, replace=False)
    all_pairs = [all_pairs[k] for k in idx]

This caps memory at a predictable ceiling regardless of group size.

No global state accumulation: The groupby loop processes one group at a time. Intermediate DataFrames are not retained in memory between groups.

---

10. Extensibility — Replacing the Mock Predictor

The current PairwisePredictor uses a deterministic hash function as a placeholder. The architecture is explicitly designed for this to be replaced with a real ML model.

To upgrade PairwisePredictor:

class MyMLPredictor(PairwisePredictor):
    def __init__(self, model_path: str):
        self.model = load_model(model_path)

    def predict_log_ratio(self, node_i: str, node_j: str) -> float:
        # Extract features from repo URLs, README, commit history, etc.
        features = self.extract_features(node_i, node_j)
        return float(self.model.predict(features))

No other changes are required. The HuberScaleReconstructor, DeepFundingPipeline, and all output formatting remain unchanged.

Potential real-world signals for predict_log_ratio:

• GitHub star count, fork count, contributor count
• Commit frequency and recency
• Downstream dependency count (how many other repos depend on this one)
• README quality / documentation coverage
• Issue resolution rate
• Language-specific ecosystem centrality (npm downloads, crates/io downloads, PyPI downloads)
• LLM-based semantic similarity of project descriptions

To upgrade OriginalityPredictor:

class MyOriginalityModel(OriginalityPredictor):
    def score(self, repo: str) -> float:
        # e.g., ratio of original code vs. vendored/copied code
        # or inverse of dependency count normalized by ecosystem
        return float(my_model.predict_originality(repo))

---

11. Submission Outputs

File	Task	Rows	Columns	Constraint
submission_task1.csv	Task 1	98	repo, parent, weight	Σ weight = 1.0 (1 group)
submission_task2.csv	Task 2	98	repo, originality	score ∈ [0, 1]
submission_task3.csv	Task 3	3,677	dependency, repo, weight	Σ weight = 1.0 (83 groups)

Sample rows from each output:

Task 1:

repo,parent,weight
github.com/argotorg/solidity,ethereum,0.012010
github.com/ethereum/EIPs,ethereum,0.009956
github.com/OpenZeppelin/openzeppelin-contracts,ethereum,0.012860

Task 2:

repo,originality
github.com/ethpandaops/checkpointz,0.731
github.com/argotorg/act,0.284
github.com/ethdebug/format,0.619

Task 3:

dependency,repo,weight
djc/rustc-version-rs,0xmiden/miden-vm,0.017594
rustcrypto/sponges,0xmiden/miden-vm,0.010545
luser/strip-ansi-escapes,0xmiden/miden-vm,0.013298

---

12. Dependencies

Package	Version	Purpose
numpy	≥ 1.24	Vectorized array operations, random seeding
pandas	≥ 2.0	CSV I/O, groupby isolation
scipy	≥ 1.10	least_squares(loss='huber') — IRLS solver
hashlib	stdlib	Deterministic SHA-256 hashing for mock predictor
logging	stdlib	Structured pipeline logging
pathlib	stdlib	Cross-platform file path handling

Install with:

pip install numpy pandas scipy

---

13. How to Reproduce

# 1. Clone / download the repository
# 2. Ensure input data is in place:
#    Pond/Task 1/repos_to_predict.csv
#    Pond/Task 2/repos_to_predict.csv
#    Pond/Task 3/pairs_to_predict.csv

# 3. Install dependencies
pip install numpy pandas scipy

# 4. Run the notebook
jupyter nbconvert --to notebook --execute deep_funding_solution.ipynb

# OR open in Jupyter and run all cells (Kernel → Restart & Run All)

# 5. Outputs will be written to:
#    submission_task1.csv
#    submission_task2.csv
#    submission_task3.csv

All outputs are fully deterministic — running the notebook multiple times on the same input data will produce byte-identical CSV files.

---

This submission was built with the goal of providing a clean, mathematically sound, and extensible foundation for the Deep Funding allocation problem. The mock predictor layer is intentionally designed to be replaced with domain-specific ML models as the competition evolves.

username Pond : ron12-max
Repostori github : ron12-max/Git-coin-funding-24

[DevS]

Predicting the Relative Importance of Ethereum Dependencies

A Multi-Factor Logarithmic Heuristic & Softmax Normalization Model

Deep Funding Contest · GG24 · Level I | Target: ethereum

---

1. Abstract & Objective

This model predicts the relative importance of 98 open-source repositories to the Ethereum ecosystem, producing weights that sum precisely to 1.0. Because the final ground truth is generated via human jury voting and evaluated using a Huber loss function over log-ratios, purely linear or popularity-only models risk severe absolute-error penalties on tail repos.

Our approach combines three logarithmically-scaled GitHub popularity signals with a domain-expert ecosystem tier multiplier and temperature-scaled softmax normalization, producing a human-aligned importance distribution that satisfies the Σw = 1.0 submission constraint by construction.

2. Data Collection & Feature Engineering

All features are fetched live from the GitHub REST API v3 using an authenticated token. A single API call to GET /repos/{owner}/{repo} retrieves all three signals per repository, making the collector lightweight and fast — 98 repos complete in under 2 minutes with a built-in 0.5s per-request rate-limit buffer.

Feature	Source Field	Transform	Weight	Rationale
star_count	stargazers_count	log(x+1)	0.50	Primary adoption signal
fork_count	forks_count	log(x+1)	0.30	Developer reuse / derivative work
watcher_count	subscribers_count	log(x+1)	0.20	Passive ecosystem engagement

Note: GitHub’s subscribers_count field is used for watchers (not watchers_count, which mirrors stargazers in the v3 API). All three signals are log-transformed before scoring to mirror human perception of scale differences (Weber-Fechner law) and prevent high-star outliers from dominating the distribution.

3. Mathematical Model

3.1 Raw Score

For each repository r, the base score is a weighted sum of log-transformed signals:

RawScore(r) = 0.50 · ln(stars + 1)  +  0.30 · ln(forks + 1)  +  0.20 · ln(watchers + 1)

3.2 Ecosystem Tier Multiplier

A domain-expert multiplier M(r) is applied to reflect the architectural centrality of each repository within the Ethereum stack, independent of its raw GitHub activity. Repos not listed receive a neutral 1.0x multiplier.

Repository	Tier	Multiplier
ethereum/go-ethereum	Core Execution Client	2.5x
ethereum/solidity	Core Language	2.5x
ethereum/EIPs	Protocol Standards	2.0x
ethereum/consensus-specs	Consensus Layer	2.0x
NomicFoundation/hardhat	Dev Tooling	1.8x
foundry-rs/foundry	Dev Tooling	1.8x
OpenZeppelin/openzeppelin-contracts	Contract Library	1.7x
ethers-io/ethers.js	JS Interface Library	1.6x
wevm/viem	TS Interface Library	1.4x
paradigmxyz/reth	Rust Execution Client	1.4x
sigp/lighthouse	Consensus Client	1.3x
prysmaticlabs/prysm	Consensus Client	1.3x
hyperledger/besu	Enterprise Client	1.3x
ethereum/web3.py	Python Library	1.3x
ethereum/py-evm	Python EVM	1.3x
All other repos	General Ecosystem	1.0x

3.3 Impact Score

The tier multiplier is applied to the raw score to produce the final pre-normalization impact score:

ImpactScore(r) = RawScore(r) × M(r)

3.4 Temperature-Scaled Softmax Normalization

Raw impact scores are converted to a valid probability distribution via softmax with temperature T = 25:

w_i = exp(ImpactScore_i / T)  /  Σ_j exp(ImpactScore_j / T)

A lower T sharpens the distribution toward high-scoring repos; a higher T spreads weight more evenly. T = 25 balances concentration on known core repos while preserving meaningful long-tail weight for smaller dependencies.

This guarantees Σ w_i = 1.0 exactly. Softmax is preferred over simple linear normalization because it is less sensitive to outliers and produces smoother distributions that better align with how human jurors perceive relative importance.

4. Implementation

The pipeline consists of two scripts that run in sequence:

github_metrics_collector.py Reads repos_to_predict.csv, fetches star_count, fork_count, and watcher_count for each repo via a single GitHub API call, and writes results incrementally to predicted_repo_metrics.csv. Incremental writes ensure no data is lost if the script is interrupted mid-run. Automatic back-off handles GitHub rate-limiting using the X-RateLimit-Reset header.

compute_weights.py Reads predicted_repo_metrics.csv, filters strictly to parent == "ethereum" repos, computes ImpactScore for each, applies softmax normalization, sorts by weight descending, and writes final_submission.csv in {repo, parent, weight} format. Prints top-10 results and total weight sum for immediate sanity-checking.

---

5. Key Design Decisions

Logarithmic Scaling Stars, forks, and watchers span several orders of magnitude across repos. Log-transforming collapses this range and mirrors how human jurors perceive differences — a repo going from 1K to 10K stars feels more significant than one going from 100K to 109K, which log(x+1) correctly captures.

Softmax over Linear Normalization Linear normalization (w = score / sum) is sensitive to a single very high outlier which can compress all other weights near zero. Softmax with temperature smooths this, directly reducing expected Huber loss on log-ratio evaluations.

Tier Multipliers Raw GitHub metrics measure popularity, not architectural importance. go-ethereum and solidity are foundational to the entire stack but may not have proportionally more stars than a popular tooling library. The multiplier table encodes this domain knowledge explicitly.

Ethereum-Only Filter The scorer explicitly filters to parent == "ethereum", ensuring no level-2+ dependency repos accidentally receive weight in the Level-1 submission.

---

6. Conclusion

This model produces a valid, human-aligned weight distribution over 98 Ethereum Level-1 dependencies using three well-chosen GitHub signals, logarithmic scaling, domain-aware tier multipliers, and softmax normalization. The pipeline is lightweight (one API call per repo), reproducible, and guarantees Σw = 1.0 by construction — fully satisfying the submission format requirement.

The temperature parameter T = 25 and the tier multiplier table are the primary tuning levers for future iterations. Both can be refined based on Huber loss feedback from earlier submission rounds or augmented with additional signals such as recent commit activity or contributor count if a more comprehensive data collection pass is warranted.

[achankun]

---

Deep Funding Contest Level II: Tier-Based Domain Classification Strategy

1. Author Information

• Username (Cryptopond): Achankun

• Email: ichsanbit45@gmail.com

• GitHub Username: achankun

---

2. Executive Summary

This document presents the methodology, experiments, and results for the Deep Funding Contest Level II machine learning competition hosted by Gitcoin and the Ethereum Foundation. The objective was to assign an originality score between 0 and 1 for 98 open-source repositories, reflecting how much of the project’s value is original work versus work inherited from its dependencies.

• Best Score Achieved: 0.1521 ( v21)

• Total Iterations: 22 model ve r sions

• Final Method: Tier-Based Domain Classif i cation

• Key Innovation: Iterative bottom-up tier cal i bration

• Leaderboard Position: Top 5 (as of the latest su b mission)

---

3. Methodology: Tier-Based Domain Classi f ication

The model evolved through four distinct strategic phases, moving from manual heuristics to a sophisticated classification system. The breakthrough occurred in Phase 3 (v13+) with the implementation of a 5-tier domain classification system that maps specific repository categories to originality ranges.

The core model assigns each repository a tier score (from 28 to 100) and maps it linearly to an originality score using the following formula:

$$originality = 0.10 + (tier - 28) \times \frac{0.87}{72}$$

The 5-Level Classificatio n System:

• Tier 1: Languages & ZK-VMs (Score 92-97): Original compilers and zero-knowledge research. (e.g., Solidity, Vyper, SP1, Powdr)

• Tier 2: Core Specs & Primitives (Score 79-91): Fundamental protocol specifications and cryptographic primitives. (e.g., Consensus-Specs , Reth, blst)

• Tier 3: Clients & Tooling (Score 67-83): Major execution/consensus clients and developer infrastructure. (e.g., Geth, Lighthouse, Fou n dry, Hardhat)

• Tier 4: SDKs & Libraries (Score 50-66): Smart contract libraries and integration wrappers. (e.g., ethers.js, OpenZep p elin, web3.py)

• Tier 5: Infra & Config (Score 28-49): Configuration registries, Docker setups, and data repositories. (e.g., chains, chainl ist, e th-docker)

---

4. Key Findings f r om Experiments

• ZK-VM Premium: Market prices for ZK projects (like SP1 and Plonky3) were initially low, but iterative experiments showed that jurors correctly identify the immense depth of original cryptographic work involved, requiring significant upward score adjustments.

• Infrastructure Value: Infrastructure and configuration repos were not penalized by jurors as much as expected, suggesting that the coordination work represented by these repos carries intrinsic value.

• Dual-Direction Calibration: The most significant improvements resulted from simultaneously raising bottom-tier repos that were too low compared to market sentiment and lowering extreme top-tier repos that exceeded juror expectations.

---

5. Sc ore Progression

Across 22 iterations, the model showed a consistent reduction in the compe t ition score (SAE):

• v9 (M a rket Blend): 0.2191

• v13 (Firs t Tier-Based): 0.1921

• v19 (Bottom Ra i se Continued): 0.1604

• v21 (Dual Direction Calibration): 0.1521

---

6. Conclusion

The tier-based classification approach effectively captures the categorical nature of code originality in the Ethereum ecosystem. By refining the classification and calibrating against market gaps, this methodology achieved a top-tier score and provides a robust foundation for future dependency graph analysis.

---

Appen dix: Submission Details

• Competition URL: joinpond.ai/modelfactory/detail/17346979

• Tot al Submissions: 22 versions

• Best Version: v21 (Score 0.1521)

---