Funding Ethereum's Future: EIPs, Profit-Sharing & Security Incentives

Transcript

Overview of three funding sessions

Hey guys. Yeah. So we had like a uh three sessions which was in terrible turtle where we tried to dig deep into some of the public goods funding questions. So to quickly summarize the three sessions were one was um how do we increase top of the funnel funding? How do we get more funding in the first place? I think as a community we've overindexed on allocation and how we divide the money which we also haven't done a great job with but like that's what we spent most of our time on and less about where the money comes from in the first place. So the first was an invitation to get ideas and brainstorm on how we can do that. The second was actually looking more concretely at which was held by Awoki. the second session which was on his past attempts at proposing Ethereum improvement

proposals which uh tried to actually increase funding towards Ethereum growth. So that was the second session and the third and final session was by Raymond Cheng on a new form of license which is like similar to open source to the open source license except it has profit sharing clauses and what would such a license look like and he shared some updates which he made that also like registering a foundation and actually like getting things moving on the ground. So these are the three things in like are these interesting topics to people here? Yeah that's great. Um so the first one was uh I'll start with the attempts at the EIP because I think that was an a spicy topic. So the two EIPs for those in the

The real problem: increasing top-of-funnel funding

hall with like some elephant memories they were 1890 and 6969. Uh it actually became 6968 because the Ethereum moderator said we can't just give you the number that you want. You know there's a process for it. So the meme fell flat uh because the because they had to follow the rules. Um so 1890 was the first real attempt. This was made in 2019 when the worry was that the that there would not be enough funding for Ethereum clients. At that time go Ethereum was the only client and EF was mainly the biggest funer at that time.

EIP-1890 & the credible neutrality backlash

So there was real worry that if EF doesn't if something happens then how do we actually figure it out? So Awoki proposed an an EIP called 1890 which changed the variable so that some amount of money gets sent directly to the client and that in the first 3 to four weeks he said he was just evangelizing this EIP and he was telling people about it and then once it actually hit home what he was proposing after that like hit the fan and people started accusing him saying that you're just trying to like you know impinge on Ethereum's credible neutrality. you're trying to make the devs allocate money towards themselves and it got very ugly very quickly and after that Awoki had to repair his reputation in some respect.

So then he focused on raising funding outside of block rewards which ultimately led to the Gitcoin matching funds and a bunch of other things which really helped the ecosystem quite a bit. Um so I think that was like there's this funny thing about all the dogmas which I think paradigm had written which is the dogmas of every blockchain. So it said that Bitcoin's dogma against programmability led to Ethereum. Ethereum's dogma for solo staking led to Solana. Solana's dogma for um for being a generalized chain where everything happens led to hyperlquid. And now we need to see what hyperlquid's dogma leads to. So and then they actually give a list of dogmas of blockchains. So I think it is another dogma of the

Contract Secured Revenue (CSR) attempt

Ethereum blockchain for like good or bad about credible neutrality that we don't and when we actually start allocating in protocol funding for the developers who are working on it uh there's a real risk of this credible neutrality. It's like oh what a surprise Ethereum developers are choosing to pay themselves and give themselves money like what a surprise. So I think that's the biggest risk with these EIPs in the past especially with 1890 which as Aoki said it died with a bang because it got withdrawn because it created so much controversy that they finally ended up withdrawing that EIP.

The second attempt the first one was 2019. Second attempt was made in 2023 um which was the idea of contract secured revenue where if a person if whichever address launches a contract when it gets deployed a certain amount of money gets sent to the deployer address. So like the example which Awoki gave as a as an example was open zeppelin. Open Zeppelin had a lot of contracts like the entire governance frameworks all the auditing and if we could figure out programmatically whenever that contract gets invoked a certain percentage goes to open Zeppelin it could really revolutionize smart contract development on Ethereum and other blockchains. Um so this was

another EIP another EIP in 2023 and the most famous one to implement it was Kanto which all which at that time had a version of contract secured revenue but Awoki said that this ended up dying with a whimper like you know no one really paid attention to it and it didn't go anywhere. Um so these were the two ideas that he spoke about and then the last part of that session looked at um what would the next such EIP look like if we actually wanted in protocol funding for Ethereum and here we came up with like uh two three like you know one trend that we've been seeing is the idea of funding from yield. So if you look at the DAO security fund which Griff was talking about, if you look at Octint, a lot of ideas center around the fact that

Why in-protocol funding is controversial

you can stake ETH and then give the staking returns to funding the ecosystem. So I think like one aspect of like an EIP should just be to bandwagon off the fact that people are willing to share their yield and uh it's I presented this in a talk yesterday about um similar to how validators can indicate uh put their flag up to show how much they want to increase Ethereum gas limits. They should be able to put their flag up to show how much of their rewards they want to allocate to the ecosystem. And if a majority put their flag up to 5% all 100% now have to give.

Oh yeah, Griff is here. We are just summarizing the session from earlier in the day. Um, so that was like one example of an EIP like eating actually being used to fund the ecosystem and the rewards for that. And I think that comes at a good time because there's a lot of debates happening around issuance and like Winston Churchill said we should never waste a good crisis. And so I really think that now is the right time to figure out an EIP which looks at Ethereum staking and how some of that can be enforced at a protocol level to funding Ethereum growth. Um so that was one and the second untapped opportunity is a general incentive misalignment that we are seeing in blockchains which is um all blockchains want to essentially increase the number of transactions that

Validator yield as ecosystem funding

happen on a on their chain. Um so the more transactions the more ETH gets burnt the more ETH is valuable. But what is Ethereum fundamentally good for? Ethereum is a hard blockchain, which means you can trust your wealth on Ethereum. But most wealth does not like to be moved around. It doesn't like to be making a transaction on Ethereum. It likes to just be one transaction, it's on chain and then like don't touch it again. That's how most wealth likes to be because every time you you make a transaction, you have to pay taxes and like there's a lot of administrative stuff that happens. So even though a lot of the yield which is earned from each staking is already like there are examples like the DAO security fund and octant which use yield for funding

Ethereum goods there's no example of stable coin yield which funds Ethereum goods or at least not at a sufficient scale as the other two examples. So how can we figure out like you know if you look at Ethereum's uh trillions dollar security initiative we're trying to get like we are at 300 billion assets of wealth being stored on Ethereum today if we succeed and we get uh 1 trillion stored on Ethereum how can that tie back into making the Ethereum ecosystem more secure by putting some of that money there. So this is a lot of like draw the rest of the owl but how do we actually tie in um increased TVL to increased funding for the ecosystem. I think

Stablecoin yield & TVL-aligned incentives

there's scope for an EIP of some sort over there and the and the best example I can give is like which we discussed was uh USD like blast of all chains like I don't know how many of you know blast as in layer 2. Okay, like most people know Blast. It's not around anymore or not active anymore, but um they had an interesting and like very nondentralization idea where any stable coin you bridge onto Blast, it forcibly converts that into USD Blast and all the yield from USD Blast goes to funding their team and like their ecosystem. So that's actually like a very crude example of what it might look like where if Blast TVL had risen to 100 million, they also get more

revenue from it. They don't care about increasing the number of transactions. They care about increasing their TVL on their chain. That's what their incentive is. Um and the and the and the experiment I'm looking at most closely today is Mega ETH. They it has a lot of hype today. But if I look at what the true innovation of Mega E is, it's that they have their own stable coin ecosystem called USD Mega. And yield from USD mega goes back to funding the ecosystem of Mega Eat. um and they can do it because they are an ecosystem starting from day one. It's much harder to do that for an ecosystem like Ethereum where you already have stable coins and you don't want to keep changing the rules of the game because then it becomes a less predictable place to build your business. Um but yeah that's kind of the uh things we talked

Blast & MegaETH as funding experiments

about and I think like the broad the fifth point which was on this session was about how we have this like weird quirk in the public goods space and in the crypto space not even the public goods in the web 3 crypto space where we separate out governance from public goods funding. So if you look at web 2 um a like the the way that a lot of open source repos and their foundations raise money is by selling both seats and by selling control. So, for example, in Linux, if you pay $500,000 every year, you get a boat seat at Linux Foundation. And we don't have that. And how many of you here are like running some form of company by yourself? Okay. So, you have like three or four people. Yeah. How many of you would sell both seats in your company for money?

>> How much money? >> Yeah. Like, let's say maybe 10% of your existing revenue. >> Wait. Sell it. I I'm the one making money if I sell my board. >> Yeah. Yeah. You're the one making money. So if the person is willing to offer you 10 to 20% of the revenue that you already have in your company, would you be willing to give them a board seat? >> Yeah. But not where they can have any power. >> Oh, but board is power, right? I mean >> observer. No. Then like see that's actually the biggest difference in ethos like web two actually wants to like they are willing to accept the trade-off that I will give away my governance power but I will be getting money in return. But that's something which makes us deeply uncomfortable in web 3 for some reason.

Governance vs funding separation in Web3

So that's like an interesting quirk in our space that we actually separate out governance from public goods funding. Public goods funding, okay, give money but don't expect anything in return. And that's kind of in some sense inherently unsustainable because what are they getting for giving the money in the first place? They're not getting governance. They're not getting board power. Like why would they do it? Um yeah. So that was on the on the session of EIP um which was uh quite meaty as you all saw. Um then I'll talk about the profit sharing license because that was the other interesting one. um where so we have like licenses like open-source licenses today and then the biggest innovation in open-source licenses was by Richard Stallman who

created the idea of copy left and how many of you know what copy left is and the difference between MIT and okay so maybe like 30% of the room so I'll then quickly sum up the difference which is in an MIT license which is pure open source or what you you can you can fork it and you can do whatever you want with it And in a copy left license, you can fork it, but any work you do has to also be open- source. So it's more of a defensive measure where you like if I take the example of Ethereum, like what would our nightmare scenario be? Our nightmare scenario would be that we've spent years giving up blood and sweat and then some big banking consortium comes, folks our entire code base and all our work and then they just like

Web2 board seats vs Web3 donations

build some proprietary version of it which we can't even do anything about. And then that becomes like the dominant standard. So copy left mitigates this exact scenario where if anyone folks a codebase they also have to be open source. So then whatever they do we can fork it back into us and then there's like a like there's a good evolutionary pressure which uh happens. Um so so those are the two dominant licenses we see today in open source like very broadly and what Raymond is proposing is like a third version of some form of profit sharing which happens. So if you as a company are earning a million dollars a year in profit, you have to give one bip or like you know $100 that would be back to the open source

ecosystem and the dependencies that you rely on. Um so there's obviously a lot of things to look at. So the biggest feedback they got from lawyers on such a license was on non-inforcability of contract which basically means that you can't propose licenses which you can't enforce. So that was the biggest push back that they got from the lawyer community that if you propose this profit sharing thing, how are you actually going to be able to enforce that contract? What happens if someone breaches it? Because like you see in a lot of trademark cases, if someone infringes on your trademark, even if you don't care, you still have to defend it.

Because if you don't defend it, then that's implicitly accepting the fact that others can breach your trademark. So it's a similar case over here where you have to have enforcability of contract. And so when Raymond spoke to the creative commons people he found that um that uh they said that like if someone like in creative comments you have to give attribution you can you can use it but you have to attribute it. So what happens if someone doesn't give attribution under the creative common license he's saying well he's saying they just shrug their shoulders and they move on. So it's like this nice relation between soft power and hard power where you like your hard power is what you can actually exert like the threat of legal force and legal violence and soft power

Profit-sharing license concept

is what you build norms around. So um ideally you have a mix of both. So you have soft power which is you you're expected to give credit attribution but you also have hard power backing it which is that if you don't we can file a lawsuit against you. So that's like the beautiful mix. I think right now we have a lot of soft power only that yeah please donate to Ethereum public goods and like you get soft power for doing so but how do we also back it up with hard power in some way through these kind of profit sharing licenses. So that was one theme we spoke about which is enforcibility of contracts. And the second theme was really about just how we uh approach this entire angle in an AIcentric world where AI is like even if like so so so how many of you know the

difference between source available and open source? One two okay less people than the other case. Sir source available means that anyone can see your codebase but they're not allowed to use it themselves. They aren't allowed to fork it and use their own version of it. That's source available. So bsl license is maybe the most famous example of source available which arbitrum and some other layer tools use. Um and open source means that you can use it. So in an AI world does this distinction even make sense between source available and open source?

MIT vs. copyleft vs. revenue sharing

because AI is going to be able to inspect your source available codebase and generate a derivative version of it which is not exactly forking it but it's still using it in some respects. So how does the source available and open- source distinction even matter over here? And um so how do we actually enforce this profit sharing license if an AI can just read your codebase create a derivative version of it and then they don't have to pay any revenue for it which is like the beautiful part that you want. Um so one aspect is like how many of you know how much like how many like how many of you all have companies which pay money for software subscriptions that you don't really use a lot.

Enforceability challenges & AI derivatives

Okay, all of you are judicious with your money. That's like really good. But that's what like the Doge team found. Uh they found that actually the biggest way of saving money was just by looking at software subscriptions and like no one was using those subs like those subscriptions and then just going ahead and canceling them. Um, and the reason that software subscriptions or SAS is more acceptable than donations is that it's in the opex column of a company. Whereas when you donate to open source, it comes in your donation column. So how do we actually make open-source fall into the opex of companies rather than in the donation of companies. I think that's the larger area to kind of work around and that's what this license can uh eventually aim at. And the last like

idea was around tokens like you know around one way of enforcing a profit sharing license would be that if an AI is using your codebase to generate its own derivative codebase it can somehow charge extra tokens and those like so supposing I'm paying money to Claude for creating my new app over the weekend and Claude uses my profit licensed uh software. um Claude then charges extra API tokens to the user and then and then that cost is passed on to my repo. So that might be like one way of implementing it where and this is actually acceptable to a lot of open

Hard power vs soft power in licensing

source people because they're kind of pissed at AI coming and training on their code bases and like generating slop code from them. So if you actually tell AI like like the general open source community that hey if a human is using the codebase that's fine but if an AI is using it you can explicitly use this license which says it's open source for humans but if AI is using it consume an extra amount of tokens for that AI and charge those extra amount of tokens to the user and then that extra amount can go to the license and to the person who holds it. Um so yeah there had a lot of open questions still around it but I think like licensing innovation is what we're all going to come back to eventually and that's something which open source needs a lot of work on um so

Open source as OPEX, not donation

I'll quickly wrap up now I think on the last on the first sessions so I've spoken about the other two sessions EIPs and the past attempts at EIP and the profit sharing license for opensource software and the third session was on how we increase funding in the first place and one insight was about how it has to be in a security framework. So you're it's it's an insurance fund like when you give money into open source software that is some form of it's giving you increased security or increased insurance and uh there's a and the and the danger here which is what we uncovered in the discussion was that if you exaggerate or not even exaggerate if you if you state that hey if you don't get money it is going to be insecure then no one wants to build on your

product or build on you. So there's this like fine line to tread between that hey we need money to maintain this thing and hey if we don't get money we are not secure so you better not build on us that's like the kind of line to traverse and it can be a delicate one to actually communicate where your private communication and your public communication has to be very different in your public communication you have to be very secure and be like yep even if you don't get money we are still going ahead you can trust us you can build on us but in your private communication once people are building on you you can be a little more you have to you have to phrase things differently and one example of this was in Google where a particular dependency like Google sent a request saying hey could you please

Security framing & insurance logic

build this because it would make our product better and then that opensource software repo said that okay could you give us some money to build it out and then Google just decided that instead of giving them money they would just use another dependency which was willing to do it so there's also like a collective action problem amongst open-source repos which kind of goes was underststudied where um like there's no union for open source repos. If one repo tries to assert its like purchasing power, then another repo can just come and be like, "Yep, we'll do that for free. Google is using us. That's great." And then that undercuts everything and that's part of the competition effects of the free market. But that was the other aspect of like unionizing which can help somewhat.

Impact evaluation & code diffs

Um then we kind of transition into the role of impact evaluation and how hard it is. Um and why people don't want to give money because they don't know if they're getting bang for their buck if anything is being done with it. And one idea we came up with was about how uh earlier a lot of projects including with give it and git bitcoin and others was self-reporting like you go on karma gap you report what you'll do and then 6 months later when you reapply for funding you have to state whether you did it or not. So a lot of that is basically self-reporting but at and in the real world it's very hard but in the software domain it's slightly easier because all of it is on the codebase. So one cool idea would just be asking for C diff like see difference from in your

Streaming vs lump-sum funding

codebase from 6 months ago to now and then any prospective funer can actually see that okay we gave them money 6 months ago what improvements have been done in their open-source repo in the last 6 months and you can actually see diff with an LLM which is at least better than self-reporting. LLM is better than self-reporting would be the hypothesis here. Um yeah and the last point I'll make and then I'll wrap it up is about streaming money and how it changes people's mentality. So rather than giving money in a lump sum when you stream it out over a period of time it usually uh changes their own mentality and how they see things. And the flip side of that is that costs are never linear. Like an example is the arbitum

foundation which uh got money streamed to them from the DAO. But that actually didn't work out too well in practice because arbitrary foundation had a lot of costs which were to be incurred up front and then the cost comes down. Whereas when you stream money it's usually on a linear basis. So they could often not really make commitments or be as aggressive as they could because money was streamed to them. So that's kind of uh the range of issues we went through. Some people here are in this session. If I missed out on anything feel free to shout it out. But um yeah, like not a lot of answers, but at least some provocations about what directions to think in.