Episode 281_ Devconnect 2025 with Devansh Mehta

# Episode 281: Devconnect 2025 with Devansh Mehta ![Cover](https://wsrv.nl/?url=https%3A%2F%2Fassets.fireside.fm%2Ffile%2Ffireside-images-2024%2Fpodcasts%2Fimages%2F2%2F27729c65-f4a6-4496-8c86-820e7f13b285%2Fepisodes%2Fc%2Fc9baacf9-b698-44b6-8470-d1056b176e75%2Fcover.jpg%3Fv%3D1&w=500&h=500) ## Episode metadata - Episode title: Episode 281: Devconnect 2025 with Devansh Mehta - Show: Sustain - Owner / Host: SustainOSS - Guests: [Devansh Mehta](https://share.snipd.com/person/c1132a3f-09d9-49b7-a425-6004ed30ce4f) - Episode publish date: 2026-02-06 - Episode AI description: Devansh Mehta, a researcher at the Ethereum Foundation working on funding mechanisms for public goods and open source infrastructure. He explores quadratic funding, credit assignment, dependency graphs, Goodhart’s Law, and how AI can help without taking over. He also discusses why open networks struggle against corporations and introduces new approaches like Deep Funding to better link revenue to costs. - Duration: 23:07 - Episode URL: [Open in Snipd](https://share.snipd.com/episode/ef2a199f-209a-4223-b3b8-7ff8b861fb31) - Show URL: [Open in Snipd](https://share.snipd.com/show/0692a062-4bc7-4dce-9318-0f57031ff1d4) - Export date: 2026-02-17T23:36:37 ## Snips ### [Two Core Funding Problems](https://share.snipd.com/snip/68e56a77-ed9d-4096-8b1a-5e8f1e30630a) 🎧 00:42 - 03:32 (02:50) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/9475743f-703d-476b-b8b2-4d24f7f345b6" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Open-source funding has two core problems: credit assignment and the funding loop. - Algorithms like quadratic funding can decentralize credit decisions and feel more dignified than human gatekeeping. #### 💬 Quote > I call that the credit assignment problem who deserves how much and the funding loop problem. How do we actually get the funding to assign according to the credit which is derived. > — Devansh Mehta Devansh Mehta defining the credit assignment and funding loop problems #### 📚 Transcript **Devansh Mehta:** Yeah, so maybe I can divide it into two parts. Ethereum itself is underpinned by a collection of open source repositories. These include consensus and execution clients. It includes dev tooling. So the entire network of Ethereum is basically a collection of open source repos, which then makes us have to answer the question that how do we actually sustain this for the long haul? So that's basically my work, which is looking at these different open source repos, figuring out where the funding is coming from. And I can divide that into two parts. One is where the money money coming from and the second after the money comes how do we divide it between these different open source repos. So I call that the credit assignment problem who deserves how much and the funding loop problem. How do we actually get the funding to assign according to the credit which is derived. Can **Eriol Fox:** you tell us a little bit more about those two loops? Like how do decisions get made in those loops? How is the community involved? Is the community involved? Is there prioritization? Tell us a little more about those loops. Yeah, **Devansh Mehta:** so I'll talk about the first part, which is credit assignment, because that comes prior to funding. In credit assignment, my personal belief is that we should move away from humans deciding who is worth how much i think it's kind of demeaning when a human is deciding your worth and i prefer when an algorithm decides it in some way that so you just have to do your work and an algorithm decides how much you should get paid i think that's a more egalitarian and more dignified way of working and some of the work that we've done so like the common one is quadratic funding where a funder just puts money into a matching pool and then based on how many different how varied the base of supporters is the money gets allocated from the funding pool and i've seen a lot of high profile people want to give money through such mechanisms because rich people don't want to be bothered. That's like rule one. And rule two, they don't want to put their reputation on the line by making judgments that this repository is worth this much, this other repository is worth that much. Because if they get those individual judgments wrong, their reputation comes on the line. So similar to how just because Donald Trump got elected in the US, we don't blame the US electoral system because we trust the legitimacy of the system even if we don't like the outcome. So I think a similar process has to be done for funding decisions where even if I don't like the outcome, I still respect the credibility of the process which led to the outcome. So my work at the EF, at Ethereum Foundation, is figuring out what processes can we derive, which then spit out a distribution between various open source repositories. Quadratic funding being one of them, and deep funding, which I'll maybe go into later on, being another that I'm working on. --- ### [Finding Quadratic Funding Liberating](https://share.snipd.com/snip/18e5b7ec-0e07-490c-b9d3-5f18bd306e68) 🎧 04:54 - 05:43 (00:49) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/89b90c60-135a-40e5-a9be-c1362a9145c5" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Devansh found quadratic funding liberating after moving from grant-based nonprofit work. - He appreciated registering a project and getting community support rather than asking for permission from grantmakers. #### 💬 Quote > I found quadratic funding very liberating because I can register my project and I get my own community to vote and I get matching funds from the pool. > — Devansh Mehta Devansh Mehta on his personal experience with quadratic funding versus grants #### 📚 Transcript **Devansh Mehta:** And both have its strengths and negatives. I don't think one is better or strictly better or worse than another. What I do, like I entered the crypto and the Web3 space with quadratic funding, and I found it very egalitarian. I was working in non-profits before I joined, and that was all based on grant applications. And the rule was you first get the grant and then you apply for it. So you first have to talk to the decision makers and they decide and then you have to go through the bureaucratic process of applying. That was how that side of the world worked. And I found quadratic funding very liberating because I can register my project and I get my own community to vote and I get matching funds from the pool. So I don't have to ask permission. I always end up getting some amount of money to compensate my time, as opposed to a grant process where either you get everything or you get nothing. --- ### [Bitcoin As A Clean Funding Loop](https://share.snipd.com/snip/43ecaf7c-66fb-47b7-a4fe-dda7f098643a) 🎧 06:00 - 06:52 (00:52) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/db2c5d52-41da-48d1-a5bd-c19663f0d7e2" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Bitcoin shows a clear impact-evaluator loop: miners get credit and new BTC funds the reward. - This model cleanly ties credit assignment to funding distribution through protocol-native issuance. #### 💬 Quote > In Bitcoin, the credit assignment is solved by whoever has enough hash power to mine the next block. So whoever mines it gets 100% of the credit of the next block and the funding loop is basically the new bitcoin which is mined to reward according to the credit of mining. > — Devansh Mehta Devansh Mehta explaining Bitcoin's credit and funding loop #### 📚 Transcript **Devansh Mehta:** other part is the funding loop. So like, I mean, I'll give you the example of Bitcoin, which is a very clear cut example. So in Bitcoin, the credit assignment is solved by whoever has enough hash power to mine the next block. So whoever mines it gets 100% of the credit of the next block and the funding loop is basically the new bitcoin which is mined to reward according to the credit of mining so that's an example of what a van bennett calls the impact evaluator loop and there's a paper called impact evaluators which is great to read in this regard so that's basically the problem it's a good way of breaking it down one how do we assign credit and two where does the funding loop come from whether it's in the form of your own currency or it's in the form of an external funder putting money in the matching pool like quadratic funding and quadratic voting i **Eriol Fox:** really want to hear --- ### [Connecting Cost Centers To Revenue](https://share.snipd.com/snip/0d8603ff-dd97-411e-b646-2272b02cc97f) 🎧 07:11 - 09:05 (01:54) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/fd68f3e9-b4c7-49a6-953e-7f3d0a9df0c8" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Corporations win because they can route revenue from profitable divisions to internal cost centers. - Open networks lose when cost centers must apply for external grants instead of receiving integrated revenue support. #### 💬 Quote > The reason corporations can produce better products is because they can take money from the revenue center...and give it to community notes which is a cost center for a better end product. > — Devansh Mehta Devansh Mehta on why corporations outcompete open networks #### 📚 Transcript **Devansh Mehta:** Yeah, sure. So I find the public goods framing to be very divisive. I think public goods are good and I'm on that side. But at the same time, I want to be a bridge connecting the skeptics who believe that public goods represent a lack of accountability, throwing money and that full side of the world with the side that we actually do need, that there is value creation, which can be higher than value capture so that's my definition of public goods is the amount of value that you create versus the amount of value that you capture so something like Facebook they create value for the world but they also manage to capture a lot of that value through advertisement revenue and other ways so the difference between value creation and value capture is what I define as public goods in a very mathematical sense. So the framing that I've now started adopting to move away from public goods which has a bad rap in some corners of the world is the idea of connecting cost centers with revenue centers. So why do corporates currently outcompete open networks? It's because in a case like say X you have a revenue center like the ad division which is earning money and you have a cost center something like grok or something like community notes which is doing incredible work community notes and the reason corporations can produce better products is because they can take money from the revenue center which is the ad division and give it to community notes which is a cost center for a better end product and it's not like community notes has to apply for a grant to the ad division which would be ridiculous but that's exactly the situation in open networks where you have cost centers which have to apply for a grant from the revenue center and as long as we fail to solve this problem of better integrating the revenue centers with the cost centers, I don't see us as being able to seriously compete on a product level with corporations. --- ### [Three-Step Funding Pipeline](https://share.snipd.com/snip/4a6c485a-54cc-4014-8796-8c325d15bd73) 🎧 09:37 - 11:22 (01:44) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/9ca276f1-a430-42a5-a604-1a15eda3cc48" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Build a three-step pipeline: generate an accurate dependency graph, weight its edges, then flow money through the graph. - Put funds into one address and let weighted edges distribute value to cost centers automatically. #### 💬 Quote > Step number one is generate a dependency graph...the second step is make it a weighted dependency graph...and then the third step is finally putting money into one public key and it gets sent across the entire graph based on the weights and edges. > — Devansh Mehta Devansh Mehta describing the dependency-graph funding model #### 📚 Transcript **Devansh Mehta:** Maybe draw a line. This is what's touching on my work at the EF right now, which I've been focused on over the last one year. So I think it's basically a three-step process that we want. Step number one is generate a dependency graph, which is unweighted. So you have a particular project which is using many open source dependencies so just being able to map out that that this revenue center is dependent on these different cost centers and don't try giving weights to it just generate that graph and make it as accurate as possible we found this in practice to be quite difficult we were using a github software build of materials github sbomb but a lot of the maintainers said i don't recognize half of these dependencies and they are like invalid or outdated and even more upsetting to them was that some of their core dependencies were not mentioned over there so that itself is its own beast to tackle generating an accurate dependency graph but that's the first step the second step is make it a weighted dependency graph. So once you have the graph with nodes and edges, the nodes are the different software dependencies and the edges are the relations between them. You try to give a weight to the edges, not to the nodes. Because giving weights to the nodes is a value judgment that I think you are worth this much. Whereas giving weights to the relations between nodes is less of a value judgment on that person or maintainer or repository and more about how much value do I derive from you and it can be different for different projects one project uses a dependency a lot another uses it in a marginal way so the second step is giving a value to that dependency graph so that it's weighted and then the third step is finally putting money into one public key and it gets sent across the entire graph based on the weights and edges. --- ### [Avoiding Goodhart With Non-Determinism](https://share.snipd.com/snip/95fe4be9-6763-4916-872a-0d149a0db8ee) 🎧 11:38 - 15:01 (03:23) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/195759e4-14f2-4d7f-9cb2-e19839243464" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Goodhart's Law warns that metrics like stars or downloads fail when tied directly to money. - Use non-deterministic methods (humans or LLMs) and competitions to select aligned models for weighting dependencies. #### 💬 Quote > Goodhart's law is that when measure becomes a target, it ceases to be a good measure...we can use a non-deterministic method where it's not a fixed target and use LLM competitions to pick aligned models. > — Devansh Mehta Devansh Mehta on Goodhart's Law and using AI competitions #### 📚 Transcript **Devansh Mehta:** So I think I'll take a step back and talk about something called Goodhart's law. So Goodhart's law is that when measure becomes a target, it ceases to be a good measure. So if we just try to say based on number of GitHub stars, we will give funding based on that. number of package downloads with some groups like ecosystems.ms is trying to do like based on number of package downloads. But then the problem is I'll just set up a bot which tries to download the packages and that ends up getting more money. So when we use something which is a decent measure, but we make it into a target which gives you money, then it being a good measure and that's why we find a lot of open source communities very skeptical towards crypto in general because we try to financialize and then it ceases to be a good measure and then it brings in a lot of noise so that's the first step so what are the ways out of good heart's law so one way is to just have a very good metric. So we see this with something like revenue. Even if you make revenue into a target, that's like, okay, because revenue is super to earn. So it's a good metric. So it doesn't, it's still, even if you try to optimize for revenue, unless in the case of Enron, which tried to massage the numbers, the revenue was higher. So even there, we saw some cases where it became like Goodhart's law applied. But by and large, it's a very good target, which is very resilient. That does not work in the case of public goods and open source repositories. So the second route to solving Goodhart's law is to use a non-deterministic method where it's not a fixed target. One example is human beings. Human beings are essentially non-deterministic. Whether I give the money to you or to someone else is something which is based on a subjective judgment. And that's what I find most exciting about artificial intelligence, LLMs in particular, large language models, that they are the first computer program we've devised which is non-deterministic. If I ask how are you to an LLM it will give me a different answer and that's what's so exciting that we can actually get a non-deterministic computer program so now the question becomes how can we use artificial intelligence and large language models to give weights on the dependency graph and so that's something I've spent a lot of time thinking about and there's a great article which Vitalik has written called AI as the engine, humans as the steering wheel. So initially, when I was working on this problem, I tried to build this great AI, which everyone is going to like respect as being amazingly accurate. And then it gives weights on the graph. But Vitalik corrected me and said that, look, this is the wrong approach. Because what if your AI just is bad? how do we even know if your ai is good so the approach he advocated was making ai into the player of the game but not the game itself so one example which we ran about five competitions is we collected ground truth data from maintainers. So maintainers of a particular revenue center would say which dependency is more important. Is dependency A or dependency B more important? So they make these very local judgments which they can do fairly accurately and we use that as ground truth data to run a competition like on Kaggle where multiple data scientists submit their LLMs, trying to predict the weights on the dependency graph. And we then select the winning AI. --- ### [Design For Confusion And Diffusion](https://share.snipd.com/snip/ea333a81-ae61-43d2-9280-b4f28184d4be) 🎧 16:54 - 18:12 (01:18) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/99f1735b-e928-4796-9668-2bf26c3d156d" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Design mechanisms with confusion and diffusion to reduce conflicts of interest. - Make individual votes locally focused and ensure no single judge can strongly sway outcomes. #### 💬 Quote > Confusion means...confusing the relationship between how you vote and how money is allocated. Diffusion means that no one person can have a big impact on the mechanism as a whole. > — Devansh Mehta Devansh Mehta advocating cryptographic properties to mitigate bias #### 📚 Transcript **Devansh Mehta:** confusing the relationship between how you vote and how money is allocated. So to give an example, which is maybe more clear, assume that I'm a US senator and I want to help Elon Musk. There is no direct way for me to help Elon Musk. At the most, I can appoint a friendly FCC commissioner and that FCC commissioner gives a license to Elon Musk, but I can't directly help him. that's a good thing we want that so the relationship between the senator and helping Elon Musk is confusing there's no direct way of them being able to do it so that's what we see in deep funding the AI competition approach where even if a judge has a bias towards one project they are just making local judgments between two repos which might not even include their own project but even if it does include their own project it's only being used to select the winning ai model which might not even reflect their preferences so the relationship between how the judge votes and which ai gets selected is confusing and the second term is diffusion. So diffusion means that no one person can have a big impact on the mechanism as a whole. So even if one judge is super biased, they cannot have big impact because we have the property of diffusion. So confusion and diffusion are the cryptographic terms to try having in these mechanisms. --- ### [RFPs Cause Cyclical Funding Instability](https://share.snipd.com/snip/8faf7221-104d-4447-a5d6-355e76f96650) 🎧 18:34 - 19:42 (01:08) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/8f89b481-1cf3-42c7-9416-c8bba9ce78ed" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - RFP-driven grant systems create instability: good times yield long RFPs, bad times shorten them. - Funding mechanisms can provide steadier, automated distributions and avoid cyclical insecurity for maintainers. #### 💬 Quote > In good times the RFP is a two-year RFP so you get funding for two years and in hard economic times they reduce the RFP time to just being six months which is terrible as a system. > — Devansh Mehta Devansh Mehta critiquing traditional RFP grant cycles #### 📚 Transcript **Devansh Mehta:** So basically, I think of funding mechanisms as like a Netflix algorithm. A Netflix algorithm shows you what movie to see. So funding mechanisms show you how much money a particular project should get. And honestly, the alternative to this, which a lot of open source repos do today, is the RFP process. And I've actually dug a bit deeply into the open source funding outside of web3 as well and it basically operates through request for proposals where in good times the RFP is a two-year RFP so you get funding for two years and in hard economic times they reduce the RFP time to just being six months which is terrible as a system it basically means that you're operating in a cyclical manner where in bad times when repos need the most money and the most security of being able to work long they get a lower rfp of only six months and in good times they get an rfp of two years so i think that's basically the existing system which a lot of open source repos have so our question is can we just build something better than that and I think funding mechanisms are better than that. And sure, you could do that in the Web2 way, where you give money to bank accounts. --- ### [EF's Policy Of Subtraction](https://share.snipd.com/snip/00fc694d-2d27-4841-8723-ebe303ef380e) 🎧 22:00 - 22:40 (00:39) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/effd9ecb-4ae9-4152-b7b0-69a490b8408d" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Ethereum Foundation follows a 'policy of subtraction' and partners to accelerate others. - Deep Funding partners include Seer, Pond, and Drips for prediction, AI competitions, and distribution. #### 💬 Quote > The Ethereum Foundation believes in the policy of subtraction. We worked with many partners...one is a prediction marketplace called Seer...we worked with Pond...we worked with Drips. > — Devansh Mehta Devansh Mehta on partners in Deep Funding and the Foundation's approach #### 📚 Transcript **Devansh Mehta:** Yeah, so we've actually, the Ethereum Foundation believes in the policy of subtraction. So we don't want to be the ones building everything. We to get others to accelerate them on their product journey. So in deep funding, we worked with many partners. I'm just the coordinator, but the partners are one is a prediction marketplace called Sear, which ran one of the rounds and is now running the $350,000 funding round using this mechanism. We worked with Pond, so CryptoPond.xyz, which is running the AI competitions for us. We worked with Drips and Drips is a way of distributing money directly to GitHub repos. --- Created with [Snipd](https://www.snipd.com) | Highlight & Take Notes from Podcasts > [!note]+ Document Notes > tags: [ethereum, funding-mechanisms, open-source-sustainability] > author: Sustain OSS > source: YouTube > reference: https://www.youtube.com/watch?v=YWnLWnAsg9Y > date created: 2024-12-19 16:30 > > # 🏷️ Title: Episode 281: Devconnect 2025 with Devansh Mehta >  ## 🧰 Action Inbox - [H1] Explore quadratic funding for project funding — alternative to traditional grant processes #funding - [H2] Generate accurate dependency graphs for projects — first step in connecting revenue/cost centers #tooling - [H3] Join agent allocators community for AI-driven funding — deepfunding.org and t.me/agentallocators #community ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Deep Funding](https://deepfunding.org) - [Agent Allocators Telegram](https://t.me/agentallocators) ## 📝 Summary - Devansh Mehta from Ethereum Foundation discusses innovative funding mechanisms for open source projects - Two core problems: credit assignment (who deserves what) and funding loops (where money comes from) - Proposes algorithmic approaches like quadratic funding and AI-driven evaluation to replace human judgment - Goal is creating networks of open source software that can compete with corporations - Process involves generating dependency graphs, weighting them, and automated fund distribution ## 📖 Main Content Devansh Mehta works on funding mechanisms at the Ethereum Foundation, focusing on sustaining the open source repositories that underpin the Ethereum ecosystem. He identifies two fundamental challenges: the credit assignment problem (determining who deserves how much funding) and the funding loop problem (generating and distributing funds). His approach emphasizes algorithmic decision-making over human judgment to create more egalitarian and dignified funding processes. Key mechanisms include quadratic funding, where community support determines matching fund distribution, and "deep funding" using AI competitions to evaluate project dependencies and allocate resources accordingly. The ultimate vision is creating networks of open source software that can compete with corporations by better connecting "cost centers" (development work) with "revenue centers" (funding sources), similar to how corporations internally fund different divisions. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/YWnLWnAsg9Y?t=0) — [H1] Introduction and role overview - Key idea: Devansh works on funding mechanisms for Ethereum's open source infrastructure - Evidence: "Ethereum itself is underpinned by a collection of open-source repositories" #### ⏱️ [02:15](https://youtu.be/YWnLWnAsg9Y?t=135) — [H2] Two core funding problems identified - Key idea: Credit assignment and funding loops are the fundamental challenges - Evidence: "One is where the money is coming from and the second after the money comes how do we divide it" #### ⏱️ [03:30](https://youtu.be/YWnLWnAsg9Y?t=210) — [H2] Algorithmic over human judgment - Key idea: Algorithms should determine funding allocation rather than humans making subjective decisions - Evidence: "I prefer when an algorithm decides it in some way that so you just have to do your work and an algorithm decides how much you should get paid" #### ⏱️ [05:45](https://youtu.be/YWnLWnAsg9Y?t=345) — [H2] Rich funders prefer systematic approaches - Key idea: High-profile donors want algorithmic systems to avoid reputation risk - Evidence: "Rich people don't want to be bothered...they don't want to put their reputation on the line by making judgments" #### ⏱️ [08:20](https://youtu.be/YWnLWnAsg9Y?t=500) — [H3] Popularity contest vs lobbying spectrum - Key idea: Funding mechanisms exist on spectrum from crowd discipline to insider access - Evidence: "Two ends of the spectrum...disciplining the crowd...and the lobbying problem where if there's a grant committee" #### ⏱️ [12:10](https://youtu.be/YWnLWnAsg9Y?t=730) — [H2] Bitcoin as credit assignment example - Key idea: Bitcoin solves both problems through hash power and mining rewards - Evidence: "Whoever has enough hash power to mine the next block...gets 100% of the credit" #### ⏱️ [14:45](https://youtu.be/YWnLWnAsg9Y?t=885) — [H1] Competing with corporations through revenue-cost integration - Key idea: Open networks need to connect revenue centers with cost centers like corporations do - Evidence: "Corporations can produce better products...they can take money from the revenue center...and give it to community notes" #### ⏱️ [18:30](https://youtu.be/YWnLWnAsg9Y?t=1110) — [H2] Three-step dependency graph process - Key idea: Generate unweighted graph, add weights, then distribute funds automatically - Evidence: "Step number one is generate a dependency graph which is unweighted...second step is make it a weighted dependency graph...third step is finally putting money" #### ⏱️ [21:15](https://youtu.be/YWnLWnAsg9Y?t=1275) — [H3] Goodhart's Law challenges - Key idea: When measures become targets they cease being good measures - Evidence: "When measure becomes a target it ceases to be a good measure...I'll just set up a bot which tries to download the packages" #### ⏱️ [24:00](https://youtu.be/YWnLWnAsg9Y?t=1440) — [H2] AI as non-deterministic solution - Key idea: Large language models provide first non-deterministic computer programs - Evidence: "Large language models...are the first computer program we've devised which is nondeterministic" #### ⏱️ [26:30](https://youtu.be/YWnLWnAsg9Y?t=1590) — [H2] AI competitions for weight assignment - Key idea: Run competitions where AIs compete to predict human judgment on dependency importance - Evidence: "Collect some ground truth data and run a competition where anyone can submit their own AI" #### ⏱️ [30:45](https://youtu.be/YWnLWnAsg9Y?t=1845) — [H3] Confusion and diffusion principles - Key idea: Cryptographic principles help reduce bias by making vote-outcome relationships unclear - Evidence: "Confusion means that how you vote it's confusing the relationship between how you vote and how money is allocated" #### ⏱️ [35:20](https://youtu.be/YWnLWnAsg9Y?t=2120) — [H3] Current RFP system problems - Key idea: Traditional funding operates cyclically with shorter grants during hard times - Evidence: "In good times the RFP is a 2-year RFP...in hard economic times they reduce the RFP time to just being 6 months" #### ⏱️ [38:15](https://youtu.be/YWnLWnAsg9Y?t=2295) — [H3] Partner organizations and community - Key idea: Ethereum Foundation works through partners rather than building everything internally - Evidence: "Ethereum Foundation believes in the policy of subtraction...we want to get others to accelerate them" ## 📚 References - [Deep Funding](https://deepfunding.org) - [Agent Allocators Community](https://t.me/agentallocators) - [SEIR Prediction Marketplace](https://seir.io) - [Crypto Pond](https://pond.xyz) - [Drips](https://drips.network) ## 🗣️ Paraphrase - Open source funding faces two main challenges: deciding who deserves what amount (credit assignment) and generating/distributing the funds (funding loops) - Algorithmic approaches like quadratic funding and AI-driven evaluation can create more equitable funding than human judgment systems - The goal is building open source networks that can compete with corporations by connecting revenue sources to development costs more effectively ## 📰 Newsletter **Revolutionary Funding Mechanisms for Open Source Sustainability** The Ethereum Foundation is pioneering algorithmic approaches to open source funding that could transform how we sustain critical digital infrastructure. Instead of traditional grant committees and RFP processes, they're using quadratic funding and AI competitions to determine project allocations. The key insight: open source networks need to connect "revenue centers" with "cost centers" just like successful corporations do internally. This three-step process involves mapping project dependencies, weighting their importance through AI competitions, and automatically distributing funds. **Practical Applications:** - Projects can receive more predictable, merit-based funding - Funders avoid reputation risks from subjective decisions - Community voting replaces insider lobbying dynamics **Resources:** [Deep Funding](https://deepfunding.org/), [Agent Allocators Community](https://t.me/agentallocators), [Learn WordPress](https://learn.wordpress.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create content explaining funding mechanisms, demo quadratic funding tools - Education: Workshop on dependency mapping for project sustainability - Developer experience: Document APIs for funding mechanism integration - Community management: Facilitate discussions on fair funding approaches #### OSPO - Policy & Governance: Develop policies for algorithmic funding participation - Software Inventory: Generate accurate SBOM data for dependency graphs - Strategic Alignment: Align funding mechanisms with open source strategy - Community Engagement: Evaluate quadratic funding for upstream projects #### Community - Maintainers: Participate in dependency weighting exercises - Contributors: Advocate for transparent funding allocation - Sponsors: Consider algorithmic funding over traditional grants #### WordPress - Core: Evaluate funding mechanisms for core development sustainability - Community: Pilot quadratic funding for community initiatives - Documentation: Document dependency relationships for funding allocation ## 🧪 Hypotheses - Algorithmic funding mechanisms reduce bias compared to human judgment systems - Quadratic funding creates more equitable distribution than traditional grants - AI competitions can accurately predict human preferences for project importance - Dependency graph funding will improve open source sustainability ### 📊 Methodology - Study design: Compare outcomes between algorithmic and traditional funding - Data sources: GitHub dependency data, maintainer surveys, funding outcomes - Experiments: Run quadratic funding pilots with control groups ### ❓ Questions - How can dependency graphs capture indirect value creation beyond code dependencies? - What safeguards prevent gaming of AI-based funding competitions? - How do these mechanisms handle projects with different sustainability needs? ### 🔮 Future Research - Long-term impact of algorithmic funding on project health - Cross-ecosystem comparison of funding mechanism effectiveness - Integration with existing grant and foundation funding ### 💡 Implications - Practice: Organizations may shift from grant committees to algorithmic systems - Policy: New frameworks needed for transparent funding governance - Security: Dependency mapping reveals critical infrastructure vulnerabilities - Funding: Traditional foundations may adopt quadratic and AI-driven mechanisms ### 🧠 Learning Styles Assessment Reading level estimate: Grade 12 #### 👀 Visual learners - Present: Conceptual frameworks, dependency graphs mentioned - Improve: Actual dependency visualizations, funding flow diagrams #### 🔊 Aural learners - Present: Full audio interview available - Improve: Key concept audio summaries #### 🗣️ Verbal learners - Present: Clear definitions of credit assignment, funding loops - Improve: More analogies comparing to traditional systems #### 🧩 Kinesthetic learners - Present: Step-by-step process description - Improve: Interactive dependency mapping tools, funding calculators #### 🧠 Logical learners - Present: Clear problem breakdown, systematic approach - Improve: Mathematical formulas, quantitative comparisons #### 🧑‍🤝‍🧑 Social learners - Present: Community involvement in quadratic funding - Improve: Collaborative workshops, peer evaluation exercises #### 🧘‍♀️ Solitary learners - Present: Individual project evaluation prompts - Improve: Self-assessment tools for project dependencies #### 🌿 Naturalistic learners - Present: Ecosystem thinking about project relationships - Improve: Biological analogies for funding mechanisms ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive timestamps - Improve: Alt text for any visual elements, ARIA labels #### Keyboard navigation - Present: Standard web navigation - Improve: Skip links to major sections #### Contrast and readability - Present: Standard text formatting - Improve: Ensure 4.5:1 contrast ratios #### Media and captions - Present: Full transcript available - Improve: Time-synced captions, chapter markers ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global cryptocurrency perspective - Improve: Examples from different cultural funding approaches #### Inclusive language - Present: Technical but accessible language - Improve: Define more cryptocurrency-specific terms #### Representation - Present: Focus on systemic rather than individual solutions - Improve: Examples from diverse project types and communities ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear problem identification leading to solution framework - Inductive strength: Uses Bitcoin example to generalize funding principles - Causal reasoning: Links current funding problems to proposed solutions - Analogical strength: Corporate revenue/cost center comparison #### Fallacies - Appeal to technology: Assumes AI/crypto necessarily better than human judgment - False dichotomy: Presents only algorithmic vs. human judgment options #### Tone of voice - Overall tone: Enthusiastic but analytical, technical but accessible ### 🛡️ DARVO Analysis - Deny: No denial patterns observed - Attack: No attacks on accusers - Reverse victim/offender: No reversals noted - Emotional cues: Positive, solution-focused rhetoric ## 🎯 Conclusion Devansh Mehta presents a compelling vision for algorithmic funding mechanisms that could revolutionize open source sustainability. By treating funding allocation as a technical problem solvable through dependency mapping, AI competitions, and automated distribution, these approaches offer alternatives to traditional grant processes that often suffer from bias, favoritism, and cyclical instability. The practical next steps involve generating accurate dependency graphs, participating in AI-driven funding competitions, and experimenting with quadratic funding mechanisms. This work has broader implications for how we structure incentives in open source ecosystems and could help create networks that better compete with corporate development models. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Algorithmic funding reduces human bias in allocation > [!quote] Episode 281: Devconnect 2025 with Devansh Mehta by [[Sustain OSS]] via [[YouTube]]. Published 2024. Accessed 2024-12-19. > "I prefer when an algorithm decides it in some way that so you just have to do your work and an algorithm decides how much you should get paid." Context: Alternative to grant committees making subjective judgments about project value. [view highlight](https://youtu.be/YWnLWnAsg9Y?t=210#H1) #xref #funding ID:rw_001 ### [H2] Open source needs revenue-cost center integration > [!quote] Episode 281: Devconnect 2025 with Devansh Mehta > "Corporations can produce better products because they can take money from the revenue center which is the ad division and give it to community notes." Context: Explaining why corporations outcompete open networks currently. [view highlight](https://youtu.be/YWnLWnAsg9Y?t=885#H --- ## Full Transcript [00:00] [music] [00:06] [music] [00:10] Hello and welcome to sustain the podcast [00:13] where we talk about sustaining open [00:16] source for the longhaul. [00:19] I Errol Fox and with me today is [00:21] >> Victory Brown [00:23] >> and we are speaking to Dvanch. He is [00:27] working on the funding mechanisms in the [00:29] Ethereum Foundation and specifically [00:31] around the public goods that underpin [00:33] the Ethereum ecosystem. Dvanch, great to [00:36] have you. Can you tell us a bit more [00:38] about the work that you do around [00:39] funding mechanisms and these public [00:41] goods? [00:42] >> Yeah, so maybe I can divide it into two [00:44] parts. Ethereum itself is underpinned by [00:47] a collection of open-source [00:49] repositories. These include consensus [00:51] and execution clients. It includes Chev [00:54] tooling. So the entire network of [00:56] Ethereum is basically a collection of [00:58] open-source repos which then makes us [01:01] have to answer the question that how do [01:03] we actually sustain this for the long [01:04] haul. So that's basically my work which [01:07] is looking at these different [01:08] open-source repos figuring out where the [01:10] funding is coming from and I can divide [01:12] that into two parts. One is where the [01:15] money is coming from and the second [01:17] after the money comes how do we divide [01:19] it between these different open-source [01:20] repos. So I call that the credit [01:23] assignment problem. who deserves how [01:25] much and the funding loop problem. How [01:27] do we actually get the funding to assign [01:29] according to the credit which is [01:30] derived? [01:32] >> Can you tell us a little bit more about [01:34] those two loops? Like how do decisions [01:36] get made in those loops? How is the [01:40] community involved? Is the community [01:41] involved? Is there a prioritization? [01:44] Tell us a little more about those loops. [01:46] >> Yeah, so I'll talk about the first part [01:47] which is credit assignment because that [01:49] comes prior to funding. In credit [01:52] assignment, my personal belief is that [01:54] we should move away from humans deciding [01:56] who is worth how much. I think it's kind [01:58] of demeaning when a human is deciding [02:01] your worth. And I prefer when an [02:04] algorithm decides it in some way that so [02:06] you just have to do your work and an [02:08] algorithm decides how much you should [02:10] get paid. I think that's a more [02:11] egalitarian and more dignified way of [02:13] working. and some of the work that we've [02:16] done. So like the common one is [02:18] quadratic funding where a funer just [02:20] puts money into a matching pool and then [02:22] based on how many different how varied [02:25] the base of supporters is the money gets [02:27] allocated from the funding pool and I've [02:30] seen a lot of high-profile people want [02:33] to give money through such mechanisms [02:35] because rich people don't want to be [02:37] bothered. That's like rule one. And rule [02:39] two, they don't want to put their [02:42] reputation on the line by making [02:44] judgments that this repository is worth [02:47] this much, this other repository is [02:48] worth that much. Because if they get [02:50] those individual judgments wrong, their [02:52] reputation comes on the line. So similar [02:55] to how just because Donald Trump got [02:57] elected in the US, we don't blame the US [03:00] electoral system because we trust the [03:02] legitimacy of the system even if we [03:04] don't like the outcome. So I think a [03:06] similar process has to be done for [03:08] funding decisions where even if I don't [03:10] like the outcome, I still respect the [03:12] credibility of the process which led to [03:14] the outcome. So my work at the EF at [03:17] Ethereum Foundation is figuring out what [03:20] processes can we derive which then spit [03:23] out a distribution between various open [03:25] source repositories. Quadratic funding [03:27] being one of them and deep funding which [03:29] I'll maybe go into later on being [03:31] another that I'm working on. I'm really [03:33] curious if you have found that. So [03:37] something that I think personally is an [03:39] opinion of mine happens in open source [03:42] funding is a sense of favoritism and [03:44] about a popularity contest. Essentially, [03:47] it's often because I have conversations [03:49] with people about how many stars their [03:52] repository has or whether there was some [03:55] press that happened recently about the [03:57] project. Do you think that this process [03:59] that you're describing helps to avoid [04:02] that or do you still think that that [04:04] creeps in somehow into these processes? [04:07] >> Right. So I'll talk about two ends of [04:08] the spectrum here. One end of the [04:10] spectrum is mechanisms like quadratic [04:13] funding where you have to get votes from [04:14] as many people as you can. That involves [04:18] what Vitalik calls disciplining the [04:20] crowd. Who whichever community can [04:23] better discipline their crowd in order [04:26] to vote for them, they end up getting [04:28] more money. So that's the full [04:29] popularity dynamics and the zero sum [04:32] nature of it which we don't like about [04:34] quadratic funding. And on the other end [04:36] of the spectrum is the lobbying problem [04:38] where if there's a grant committee which [04:40] is giving money, if I'm able to take [04:42] them out for drinks, if I'm able to be [04:43] good friends with them, then I'm going [04:45] to get money from them. So I think these [04:47] are the two ends of the spectrum like [04:48] the issue with lobbying and that getting [04:51] you more money and the issue with being [04:53] a popularity contest and both have its [04:55] strengths and negatives. I don't think [04:57] one is better or strictly better or [04:58] worse than another. What I do like I [05:00] entered the crypto and the web 3 space [05:03] with quadratic funding and I found it [05:05] very egalitarian. I was working in [05:08] nonprofits before I joined and that was [05:11] all based on grant applications and the [05:13] rule was you first get the grant and [05:15] then you apply for it. So you first have [05:17] to talk to the decision makers and they [05:19] decide and then you have to go through [05:20] the bureaucratic process of applying. [05:23] That was how that side of the world [05:24] work. And I found quadratic funding very [05:27] liberating because I can register my [05:29] project and I get my own community to [05:31] vote and I get matching funds from the [05:33] pool. So I don't have to ask permission. [05:36] I always end up getting some amount of [05:37] money to compensate my time as opposed [05:40] to a grant process where either you get [05:42] everything or you get nothing. So I [05:44] think that each has its strengths but [05:46] each also has its drawbacks. [05:49] >> There was another process that you [05:50] mentioned in your first answer to the [05:52] first question. Is there other loops and [05:54] processes you want to explain and cover [05:56] before we move into other questions? [05:59] >> Yeah. So the other part is the funding [06:01] loop. So like I mean I'll give you the [06:03] example of Bitcoin which is a very [06:04] clearcut example. So in Bitcoin the [06:07] credit assignment is solved by whoever [06:10] has enough hash power to mine the next [06:12] block. So whoever mines it gets 100% of [06:15] the credit of the next block and the [06:17] funding loop is basically the new [06:19] Bitcoin which is mined to reward [06:21] according to the credit of mining. So [06:24] that's an example of what Van Bennett [06:26] calls the impact evaluator loop and [06:29] there's a paper called impact evaluators [06:31] which is great to read in this regard. [06:34] So that's basically the problem. It's a [06:36] good way of breaking it down. One, how [06:38] do we assign credit? And two, where does [06:40] the funding loop come from? Whether it's [06:42] in the form of your own currency or it's [06:44] in the form of an external funer putting [06:47] money in the matching pool like [06:48] quadratic funding and quadratic voting. [06:51] I really want to hear more about how [06:54] networks of open source software can [06:56] compete with corporations that you [06:58] mentioned just before we started [07:00] recording. I find that really an [07:02] interesting statement. It sounds like [07:03] quite controversial in a lot of ways, [07:06] but please tell us more about what your [07:07] thoughts are on these networks that can [07:09] compete with corporations. [07:11] >> Yeah, sure. So, I find the public goods [07:14] framing to be very divisive. I think [07:16] public goods are good and I'm on that [07:18] side. But at the same time, I want to be [07:20] a bridge connecting the skeptics who [07:22] believe that public goods represent a [07:24] lack of accountability, throwing money [07:27] and that full side of the world with the [07:29] side that we actually do need that there [07:31] is value creation which can be higher [07:34] than value capture. So that's my [07:36] definition of public goods is the amount [07:38] of value that you create versus the [07:40] amount of value that you capture. So [07:43] something like Facebook they create [07:45] value for the world but they also manage [07:46] to capture a lot of that value through [07:49] advertisement revenue and other ways. So [07:51] the difference between value creation [07:52] and value capture is what I define as [07:54] public goods in a very mathematical [07:56] sense. So the framing that I've now [07:59] started adopting to move away from [08:01] public goods which has a bad rap in some [08:03] corners of the world is the idea of [08:06] connecting cost centers with revenue [08:08] centers. So why do corporates currently [08:10] out compete open networks? It's because [08:13] in a case like say X, you have a revenue [08:16] center like the ad division which is [08:18] earning money and you have a cost center [08:21] something like Grock or something like [08:24] Community Notes which is doing [08:25] incredible work, Community Notes. And [08:28] the reason corporations can produce [08:29] better products is because they can take [08:32] money from the revenue center which is [08:34] the ad division and give it to community [08:36] notes which is a cost center for a [08:38] better end product. And it's not like [08:40] community notes has to apply for a grant [08:42] to the ad division which would be [08:44] ridiculous. But that's exactly the [08:45] situation in open networks where you [08:48] have cost centers which have to apply [08:51] for a grant from the revenue center. And [08:53] as long as we fail to solve this problem [08:56] of being of better integrating the [08:58] revenue centers with the cost centers, I [09:00] don't see us as being able to seriously [09:02] compete on a product level with [09:04] corporations. [09:05] >> And what do you think this means when we [09:09] think about sustaining open source and [09:12] keeping open source as like our critical [09:15] digital infrastructure? I mean it is our [09:16] critical digital infrastructure already. [09:19] What do you think that these potential [09:22] interventions and what the web 3 crypto [09:26] decentralization space can do to [09:30] I guess innovate or change or adapt new [09:34] processes that help keep this sustained? [09:37] >> Maybe draw this is what's touching on my [09:40] work at the EF right now which I've been [09:42] focused on over the last one year. So I [09:44] think it's basically a three-step [09:46] process that we want. Step number one is [09:49] generate a dependency graph which is [09:51] unweighted. So you have a particular [09:53] project which is using many open-source [09:55] dependencies. So just being able to map [09:58] out that that this revenue center is [10:01] dependent on these different cost [10:02] centers and don't try giving weights to [10:05] it. Just generate that graph and make it [10:06] as accurate as possible. We found this [10:09] in practice to be quite difficult. We [10:11] were using a GitHub software build of [10:13] materials GitHub sbomb. But a lot of the [10:15] maintainers said I don't recognize half [10:17] of these dependencies and they are like [10:19] invalid or outdated. And even more [10:22] upsetting to them was that some of their [10:23] core dependencies were not mentioned [10:25] over there. So that itself is its own [10:27] beast to tackle generating an accurate [10:29] dependency graph. But that's the first [10:30] step. The second step is make it a [10:33] weighted dependency graph. So once you [10:35] have the graph with nodes and edges, the [10:38] nodes are the different software [10:40] dependencies and the edges are the [10:42] relations between them. You try to give [10:44] a weight to the edges not to the nodes [10:46] because giving weights to the nodes is a [10:49] value judgment that I think you are [10:50] worth this much whereas giving weights [10:53] to the relations between nodes is less [10:56] of a value judgment on that person or [10:58] maintainer or repository and more about [11:00] how much value do I derive from you and [11:02] it can be different for different [11:03] projects. One project uses a dependency [11:06] a lot another uses it in a marginal way. [11:08] So the second step is giving a value to [11:11] that dependency graph so that it's [11:12] weighted and then the third step is [11:15] finally putting money into one public [11:17] key and it gets sent across the entire [11:20] graph base based on the weights and [11:22] edges. So that's the larger framework [11:24] that we should be operating in for [11:26] connecting cost and revenue centers. And [11:28] then the thorny question which I'm happy [11:29] to get to next is how do you actually [11:31] give weights to the different edges in [11:33] the dependency graph. [11:35] >> Do you want to talk about that before I [11:36] ask my question? [11:37] >> Yeah, sure. [11:38] So I think I'll take a step back and [11:40] talk about something called goodart's [11:42] law. So goodart's law is that when [11:45] measure becomes a target it ceases to be [11:47] a good measure. So if we just try to say [11:50] based on number of GitHub stars we will [11:53] give funding based on that or number of [11:56] package downloads which some groups like [11:58] ecosystems.ms [12:00] is trying to do like based on number of [12:02] package downloads but then the problem [12:04] is I'll just set up a bot which tries to [12:05] download the packages and that ends up [12:07] getting more money. So when we use [12:09] something which is a decent measure but [12:11] we make it into a target which gives you [12:13] money then it stops being a good measure [12:15] and that's why we find a lot of open [12:17] source communities very skeptical [12:20] towards crypto in general because we try [12:22] to financialize and then it ceases to be [12:25] a good measure and then it brings in a [12:27] lot of noise. So that's the first step. [12:29] So what are the ways out of Goodart's [12:31] law? So one way is to just have a very [12:33] good metric. So we see this with [12:36] something like revenue. Even if you make [12:38] revenue into a target that's like okay [12:41] because revenue is super hard to earn so [12:42] it's a good metric so it doesn't it's [12:45] still even if you try to optimize for [12:47] revenue unless in the case of Enron [12:49] which tried to massage the numbers the [12:50] revenue was higher so even there we saw [12:52] some cases where it became a like good [12:54] art's law applied but by and large it's [12:56] a very good target which is very [12:59] resilient that does not work in the case [13:01] of public goods and open source [13:02] repositories so the second route to [13:04] solving goodart's law is to use a [13:07] non-deterministic method where it's not [13:10] a fixed target. One example is human [13:12] beings. Human beings are essentially [13:14] non-deterministic. [13:16] Whether I give the money to you or to [13:18] someone else is something which is based [13:20] on a subjective judgment. And that's [13:22] what I find most exciting about [13:24] artificial intelligence LLMs in [13:26] particular large language models that [13:28] they are the first computer program [13:30] we've devised which is nondeterministic. [13:33] If I ask how are you to an LLM, it'll [13:35] give me a different answer. And that's [13:38] what's so exciting that we can actually [13:39] get a non-deterministic computer [13:41] program. So now the question becomes how [13:43] can we use artificial intelligence and [13:45] large language models to give weights on [13:48] the dependency graph. And so that's [13:51] something I've spent a lot of time [13:52] thinking about and there's a great [13:54] article which Vitalik has written called [13:57] AI as the engine, humans as the steering [14:00] wheel. So initially when I was working [14:03] on this problem, I tried to build this [14:04] great AI which everyone is going to like [14:07] respect as being amazingly accurate and [14:09] then it gives weights on the graph. But [14:11] Vitalik corrected me and said that look [14:13] this is the wrong approach because what [14:15] if your AI just is bad and how do we [14:18] even know if your AI is good? So the [14:20] approach he advocated was making AI into [14:23] the player of the game but not the game [14:25] itself. So one example which we ran [14:28] about five competitions is we collected [14:32] ground truth data from maintainers. So [14:34] maintainers of a particular revenue [14:36] center would say which dependency is [14:40] more important is dependency A or [14:41] dependency B more important. So they [14:44] make these very local judgments which [14:45] they can do fairly accurately and we use [14:48] that as ground truth data to run a [14:51] competition like on Kaggle where [14:53] multiple data scientists submit their [14:55] LLMs trying to predict the weights on [14:57] the dependency graph and we then select [15:01] the winning AI. So I think the core [15:02] insight I want people to go is that if [15:05] you're using AI to distribute money, [15:07] don't do it by enshrining one particular [15:09] AI as the one that's going to distribute [15:11] money, but collect some ground truth [15:13] data and run a competition where anyone [15:17] can submit their own AI, including you, [15:19] and then you choose the winning AI based [15:21] on their error score to the collected [15:23] human judgment. So we actually ran this [15:26] competition and we got weights between [15:28] about 44 open-source repos. And the [15:30] amazing part was that all open source [15:32] repo maintainers agreed with these [15:34] weights saying that yeah like it could [15:36] be better it could be worse but we like [15:37] the process by which these weights were [15:39] derived and they're roughly accurate. So [15:41] I think so that's the approach that I've [15:43] been advocating that humans are good at [15:46] making decisions but we can only make a [15:48] few decisions. AI is good at making many [15:50] decisions but it may be unaligned with [15:53] our preferences. So use the few human [15:55] decisions to select the most aligned AI [15:58] which then makes the many decisions. [16:00] >> Okay, great. I think you've answered a [16:03] bit of my question I was going to ask, [16:04] but I want to talk about this process. [16:07] How can we make it more ethical, right? [16:10] That we're not letting our own biases at [16:13] some point influence this decision or [16:15] even like the data that we feed to the [16:17] AI. So like do you have anything to talk [16:19] about that at all? [16:21] >> Right. So this actually goes into I've [16:22] sat on many committees and something [16:24] which I've noticed is that the people [16:27] who have the most expertise also have [16:29] the most conflicts of interest and so it [16:33] almost feels tragic to me at some level [16:35] that this person is clearly the most [16:37] knowledgeable but he can't vote on this [16:39] which is so sad but it has to be done [16:41] because of conflict of interest and like [16:43] them being biased. So I think like [16:45] that's where the level what in [16:47] cryptography there are two terms called [16:49] confusion and diffusion. So confusion [16:52] means that how you vote it's confusing [16:56] the relationship between how you vote [16:58] and how money is allocated. So to give [17:01] an example which is maybe more clear [17:03] assume that I'm a US senator and I want [17:05] to help Elon Musk. There is no direct [17:08] way for me to help Elon Musk. the most I [17:10] can appoint a friendly FCC commissioner [17:13] and that FCC commissioner gives a [17:15] license to Elon Musk but I can't [17:16] directly help him and that's a good [17:18] thing we want that so the relationship [17:20] between the senator and helping Elon [17:22] Musk is confusing there's no direct way [17:25] of them being able to do it so that's [17:27] what we see in deep funding the AI [17:30] competition approach where even if a [17:32] judge has a bias towards one project [17:35] they are just making local judgments [17:36] between two repos which might not even [17:38] include their own project, but even if [17:40] it does include their own project, it's [17:42] only being used to select the winning AI [17:44] model, which might not even reflect [17:46] their preferences. So the relationship [17:48] between how the judge votes and which AI [17:52] gets selected is confusing. And the [17:54] second term is diffusion. So diffusion [17:57] means that no one person can have a big [18:00] impact on the mechanism as a whole. So [18:02] even if one judge is super biased, they [18:04] cannot have big impact because we have [18:07] the property of diffusion. So confusion [18:09] and diffusion are the cryptographic [18:10] terms to try having in these mechanisms. [18:12] >> Okay. And we're almost at time, but I [18:14] wanted to ask more specifically around [18:17] this process and how it relates to open [18:19] source for open source project that may [18:22] not always have this ability to use some [18:25] cryptography and all of this. What would [18:27] be a good way to do more ethical funding [18:30] and remove that bias for the [18:32] sustainability of projects in the long [18:34] run? So basically I think of funding [18:37] mechanisms as like a Netflix algorithm. [18:40] A Netflix algorithm shows you what movie [18:42] to see. So funding mechanisms show you [18:44] how much money a particular project [18:46] should get. And honestly the alternative [18:48] to this which a lot of open source repos [18:50] do today is the RFP process. And I've [18:53] actually dug a bit deeply into the [18:54] open-source funding outside of web 3 as [18:57] well. And it basically operates through [18:59] a request for proposals where in good [19:02] times the RFP is a 2-year RFP. So you [19:05] get funding for 2 years and in hard [19:07] economic times they reduce the RFP time [19:09] to just being 6 months which is terrible [19:11] as a system. It basically means that [19:14] you're operating in a cyclical manner [19:16] where in bad times when repos need the [19:18] most money and the most security of [19:20] being able to work long they get a lower [19:22] RFP of only 6 months and in good times [19:24] they get an RFP of 2 years. So I think [19:26] that's basically the existing system [19:28] which a lot of open-source repos have. [19:30] So our question is can we just build [19:33] something better than that and I think [19:34] funding mechanisms are better than that [19:37] and sure you could do that in the web [19:39] two way where you give money to bank [19:42] accounts but I think cryptograph using [19:45] the blockchain systems just make that [19:47] much easier to actually automate and [19:49] make it quicker. [19:50] >> I do see this. I'm on an advisory board [19:53] for a fun and yeah, now that you say it, [19:56] I think about how in times that are [20:00] good, projects are receiving more money [20:04] or longer amount of time on their funds [20:08] for grants. And then in harder times, [20:10] it's harder. But then there's no [20:13] mechanism in the current way of doing [20:15] things for those projects to think about [20:18] what they might want to save from their [20:20] grant funding because it's all allocated [20:21] to specific activities or specific [20:24] things in grant funding. If you don't [20:27] use, unless it's unrestricted core [20:29] funding, which is really rare in open [20:32] source that I know of, you have to use [20:34] it for, you said you want to build [20:36] feature X, you have to use the money to [20:38] build feature X and you can't sort of [20:40] say, well, actually, can we save some of [20:43] this money just in case something [20:45] happens unpredictable in the world or [20:48] politics or something else? So yeah, [20:50] it's really interesting to hear you talk [20:51] about alternatives, but sadly we're out [20:54] of time and maybe we can have you back [20:55] for a longer podcast to talk about these [20:57] alternatives in more depth. But for now, [21:01] where can people find you on the [21:04] internet to connect with you or to hear [21:05] more about what you have to say on this? [21:07] >> Yeah, so I write every day on Twitter. [21:10] The handle is at the Dwancha. [21:13] So that's where I share a lot of [21:14] thoughts and we've built a community of [21:16] people who are behind this idea. And if [21:18] you're an AI developer, if you're an [21:20] open source evaluator, you should join [21:22] our Telegram group which is called [21:24] agentallocators. So [21:26] t.me/agentallocators. [21:28] You can go to deepfunding.org and find [21:30] all of this information. That's my [21:32] pitch. Like if you are an expert, we [21:34] want you to make local judgments. If you [21:36] are an AI developer, we want you to [21:38] submit models which allocate funding. [21:40] That's the call to action for anyone [21:41] hearing this podcast. And yeah, so [21:44] that's where you can find me. I'm very [21:46] easily available via DM, via Telegram, [21:48] via Signal. [21:50] >> Okay. And just before we say goodbye, is [21:52] there a project that you haven't [21:54] mentioned already that you want to again [21:56] promote or is there another project that [21:57] you want to talk about that's really [21:59] meaningful to you in your work? [22:00] >> Yeah, so we've actually the Ethereum [22:02] Foundation believes in the policy of [22:05] subtraction. So we don't want to be the [22:06] ones building everything. We want to get [22:09] others to accelerate them on their [22:12] product journey. So in deep funding, [22:14] we've worked with many partners. I'm [22:16] just the coordinator, but the partners [22:18] are one is a prediction marketplace [22:20] called SEIR, which ran one of the rounds [22:22] and is now running the $350,000 funding [22:25] round using this mechanism. We worked [22:27] with Pond, so crypto pond.xyz, which is [22:31] running the AI competitions for us. We [22:34] worked with drips and drips is a way of [22:37] distributing money directly to GitHub [22:38] repos. So probably forgetting some [22:41] partners, but these are three that I [22:43] really want to highlight and that have [22:44] been a big help to us. [22:45] >> We can always add them in the show notes [22:47] afterwards. So everyone listening, [22:48] please do check out the show notes. And [22:50] with that, thank you so much for [22:52] speaking to us, Dvanch. I've really [22:53] enjoyed hearing about your processes and [22:55] the steps and everything [music] that [22:57] you're working on. It's been really [22:59] fascinating and really cool to listen to [23:01] you. [23:01] >> Yep. Thanks for bringing me on.