this repo has no description
💰 Add Deep Funding
+72
-1
+70
Deep Funding.md
+70
Deep Funding.md
···
1
+
# Deep Funding
2
+
3
+
The goal of [Deep Funding](https://deepfunding.org/) is to develop a system that can allocate resources to public goods with a level of accuracy, fairness, and open access that rivals how private goods are funded by markets, ensuring that high-quality open-source projects can be sustained. Traditional price signals don't exist, so we need "artificial markets" that can simulate the information aggregation properties of real markets while being resistant to the unique failure modes of public goods funding.
4
+
5
+
In Deep Funding, multiple mechanisms work together:
6
+
7
+
1. A mechanism that generates an up to date and comprehensive DAG of relevant dependencies given a source node.
8
+
2. Another mechanism that fills the the graph with relevant weights. This might be broken down into:
9
+
1. Collecting human judgement accurately.
10
+
2. Scaling Human Judgement to fill the rest of the graph. This can be something like a prediction market, a AI models, ... Basically anything that predicts the human judgement
11
+
3. Reward Distribution.
12
+
13
+
This problem touches data, mechanism design, and open source! Each layer can be optimized and iterated independently.
14
+
15
+
In its current shape, the graph's vertices are projects and the edges are the relative impact of each project in it's parent. The same approach could be used for anything that matches the graph shape (e.g: science research).
16
+
17
+
## Desired Properties
18
+
19
+
- Credible Neutrality Through Transparent and Simple Mechanisms
20
+
- Comparative Truth-Seeking Over Absolute Metrics
21
+
- Plurality-Aware Preference Aggregation
22
+
- Collusion-Resistant Architecture
23
+
- Practical Scalability
24
+
- Credible Exit and Forkability
25
+
- Works on Public Existing Infrastructure
26
+
- Decentralized and Market Like Mechanisms to Incentivice Useful Curation
27
+
- Dependencies reveal themselves through market mechanisms rather than being declared
28
+
- Skin in the Game. Participants have something to lose from bad assessments
29
+
- Project Independence (no need to participate in the process to get funded)
30
+
31
+
## Ideas
32
+
33
+
- Let the dependent set their weight percentage if they're around.
34
+
- The most elegant mechanism is probably something like a [prediction markets](https://docs.fileverse.io/0x7248Fe92e7087d02D3604396b057295026FC62A1/49#key=DgfQgJ-bCAVr0NNFU0vp1HNW_Sh23GVieRmA_QXsDbHIRVyhv37c1XnOBM8lW6PT).
35
+
- Solves the current issues there of missing dependencies (due to technical issues or because they're more abstract), preference drift, adversarial situations, ...
36
+
- Replaces the "Collecting accurate project dependencies" issue with an ongoin market
37
+
- Instead of one canonical graph, allow different stakeholder groups (developers, funders, users) to maintain their own weight overlays on the same edge structure. Aggregate these views using quadratic or other mechanisms.
38
+
- If there is a plurality of these "dependency graphs" (or just different set of weights), the founding organism can choose which one to use! The curators gain a % of the money for their service. This creates a market like mechanism that incentivices useful curation.
39
+
- Have hypercerts or similar. The price of these (total value) sets the weights across dependencies (`numpy`'s certificates trade at 3x the price of a utility library, the edge weight reflects this)
40
+
- If there are reviewers/validators/jurors, need to be public so they have some sort of reputation.
41
+
- Reputation system / ELO for Jurors which score is closer to the final one. This biases towards averages.
42
+
- Stake based flow:
43
+
- Anyone can propose a new edge, and anyone can stake money on that. If they get funding, you get rewarded. Could be also quadratic voting style where you vouch for something.
44
+
- Should the edge weights/stake decay over time unless refreshed by new attestations?
45
+
- Quadratic funding or similar for the stake weighting to avoid plutocracy
46
+
- Anyone can challenge an edge by staking against it
47
+
- Human attestations from project maintainers or a comitee
48
+
- Doing [something similar to Ecosyste.ms](https://blog.ecosyste.ms/2025/04/04/ecosystem-funds-ga.html) might be a better way
49
+
- A curated set of repositories. You fund that dependency graph + weights.
50
+
- Could be done looking at the funding or license (if there is a license to declare your deps).
51
+
- Graph Completion (Scaling Humand Judgmeent) might be done in different ways:
52
+
- Constraint-Based Optimization (`scipy.optimize.minimize`)
53
+
- Collaborative Filtering (like a recommendation system where you're predicting weights between nodes)
54
+
- Matrix Factorization (NMF)
55
+
- Prediction Markets
56
+
- AIs
57
+
- Run the mechanism on "eras" / batches so the graph changes and the weights evolves.
58
+
- How to expand to a graph of dependencies that are not only code?
59
+
- Academic papers and research that influenced design decisions
60
+
- Cross-language inspiration (e.g., Ruby on Rails influencing web frameworks in other languages)
61
+
- Standards and specifications that enable interoperability
62
+
- Allow projects to "insure" against their critical dependencies disappearing or becoming unmaintained. This creates a market signal for dependency risk and could fund maintenance of critical-but-boring infrastructure.
63
+
- Composable Evaluation Criteria
64
+
- Rather than a single weighting mechanism, allow different communities to define their own evaluation functions (security-focused, innovation-focused, stability-focused) that can be composed. This enables plurality while maintaining comparability.
65
+
- Create a bounty system where anyone can claim rewards for discovering hidden dependencies (similar to bug bounties).
66
+
- This crowdsources the graph discovery problem and incentivizes thorough documentation.
67
+
- Projects can opt out of the default distribution and declare a custom one. Organizators can allow or ignore that.
68
+
- Self declaration needs a "contest process" to resolve issues/abuse.
69
+
- Harberger Tax on self declarations? Bayesian Truth Serum for Weight Elicitation?
70
+
- Projects continuously auction off "maintenance contracts" where funders bid on keeping projects maintained. The auction mechanism reveals willingness-to-pay for continued operation. Dependencies naturally emerge as projects that lose maintenance see their dependents bid up their contracts.
+1
-1
Impact Evaluators.md
+1
-1
Impact Evaluators.md
···
73
73
- Evolution through recombination rather than redesign.
74
74
- To create a permissionless way for projects to participate, staking is a solution.
75
75
- Fix a Data Structure (API) for each layer so they can compose (graph, weight vector).
76
-
- E.g: Deepfunding problem data structure is a graph. Weights are a vector/dict, ...
76
+
- E.g: [[Deep Funding]] problem data structure is a graph. Weights are a vector/dict, ...
77
77
- **Embrace plurality over perfection**.
78
78
- [No single mechanism can satisfy all desirable properties](https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem) (efficiency, fairness, incentive compatibility, budget balance). Different contexts need different trade-offs.
79
79
- There will be no "stable state". Whenever you fix an evaluation, some group has an incentive to abuse or break it again and feast on the wreckage.
+1
Public Goods Funding.md
+1
Public Goods Funding.md
···
27
27
- [Publig Goods Funding Mechanism List](https://docs.google.com/document/d/1n8fP3tWfLBIa-w4wC0rbOw2wo7odWvwseWptbuBdg6c/edit?tab=t.0)
28
28
- [List of Public Goods Funding Mechanisms](https://harsimony.wordpress.com/2022/02/10/list-of-public-goods-funding-mechanisms/)
29
29
- [Funding public goods using the Nash product rule](https://victorsintnicolaas.com/funding-public-goods-using-the-nash-product-rule/)
30
+
- [[Deep Funding]]