ERC 1789 — Stable Funding for Open Source Maintainers #1789
ERC 1789 — Stable Funding for Open Source Maintainers
A Proposal for Inflation Funding for Protocol Maintenance
Table of Contents
My name is Kevin Owocki and I am a co-founder of Gitcoin. I am co-authoring this proposal to sustainability fund Ethereum Development with other members of the Ethereum community; In particular, @ameensol has been a very valuable co-author.
This ERC is a proposal to fund ongoing ecosystem stewardship with inflation funding. As a starting point, we propose that 20% of the issuance rewards (both transaction fees + block rewards) are allocated for ecosystem stewardship.
In this ERC, I will break down my argument into four basic sections:
My goal for this ERC is to establish a strong argument for (1). Stewardship is the most important driver of long-term value creation in the Ethereum space, and open source communities more broadly. Rewarding maintainers of Ethereum is critical. I am willing to die on this hill.
Sections (2) (3) (4) are arguments that are more loosely held, and serve to start the conversation. My goal for the ERC is to facilitate discussion on each of these topics.
Without further adieu,
1. Why ecosystem stewardship is important
I define ecosystem stewardship as:
Despite the tremendously large use of Open Source Software by companies around the world, Open Source Software has historically had a problem sustaining itself. Even though Open Source Software creates $400 billion in economic value yearly, there has not been a rational economic reason to work on open source software. There is more upside available in the private sector, working for high growth startups.
Because of the above reasons, 65% of Open Source Projects have only one or two maintainers. The foundation of our public digital infrastructure is being supported by benevolent billionaires at best, and in spare hours on nights and weekends at worst.
This is clearly not sustainable. In recent years, we have seen the symptoms of this problem,
Each of these symptoms are merely examples of the core problem of there not being enough funding and support for Open Source Software. The world gets open source software for free, and they take for granted that developers will keep it maintained.
If one projects these trends into the future, it is not easy to imagine a critical bug created in an important project. Will we wake up tomorrow and discover that a security hole destroyed billions of dollars in value? Will our most important repo's continue to have few developers who suffer from lack of funding?
Recent hope from the blockchain ecosystem
Recent innovation within blockchain protocols has provided a glimmer of hope for OSS maintainers and those interested in it's further development. Because open blockchain protocols commonly have native tokens (some worth billions of dollars), there is now more funding available for open source projects to build than ever before. This coincides with a tangible financial incentive to pay maintainers - if a maintainer builds valuable software, the value of the token they work on rises.
Specifically in Ethereum, there is millions of dollars of funding available from the ECF, the EF, and Consensys Grants. (Disclosure: I am an advisor to Consensys Grants). There are also prominent ICOs that have launched OSS Grant funds (Status Incubate, Aragon Nest). These organizations have a rational economic incentive to support Open Source:
2. Why ecosystem stewardship cannot be properly funded without inflation
Funding for core Ethereum infrastructure today should be:
While these ecosystem funds are great, the ECF, the EF, and Consensys Grants will not be around forever. While the financial holdings of each of these grant programs are not publicly available, it is clear they do not have infinite runway. It is surmised in the Ethereum community that while the Ethereum blockchain will be around for a very long time, the Ethereum Foundation does not plan to be around (at least in it's current iteration) 10+ years into the future.
More Details From The Community
It is worth noting that a few prominent members of the community have laid out their vision for how long, and within what scope, innovation should happen in Ethereum.
From Lane Rettig:
Per Vitalik Buterin:
I believe that the upcoming innovation in the Ethereum ecosystem will be measured in decades, not months or years. This timeline is significantly longer than the runway that the funding from the aforementioned Grants programs provides.
Exhausting other options beyond inflation-funding
For these reasons, it is incumbent upon us as a community to find new and sustainable ways to fund Open Source Software.
I have a unique purview on this problem, having spent the better part of the last two years focusing on Gitcoin’s Mission, to Grow & Sustain Open Source.
Did you know that there is a movement happening in the broader Open Source ecosystem, called SustainOSS? There is a broad collection of Open Source sustainability mechanisms that the SustainOSS community has put together. From Nadia Eghbal’s Lemonade Stand, they are:
I have discussed these mechanisms in large part on this post. TLDR: How do we solve the burnout loop for software developers in OSS? We we think sustainability options which meet the following criteria are the only options:
Unfortunately, many of the tried and true funding mechanisms won’t work at ETH-Scale.
We at Gitcoin have spent the last two years traversing the cartography of funding options for Open Source Software, and we keep on coming back to one place.
The one and only place to achieve sustainable funding that has the following characteristics is inflation funding.
These three characteristics represent a necessity in meeting the motivational needs of developers. It fundamentally recognizes the reality that people will not dedicate nights and weekends to Ethereum forever, and we want to bring full time developers into the space on an ongoing basis.
While the mechanics of inflation funding are up for conversation as this ERC unfolds, we feel strongly it is the right mechanism to ensure alignment of incentives for maintainers of Ethereum infrastructure. It simultaneously serves as an example to other open source platforms on the value of the mechanism.
3. Administration of funds
There are many avenues on administration of funds received through inflation funding. We will add some of these for discussion, to add color to ways the 20% block reward can be appropriately allocated.
We think it makes sense to consider the following two paths as we explore this problem:
We suspect that while there will be some overlap between the two groups, they will require very different methodologies. The first is more theoretical while the second is more experimental. A fine place to start, in our view, would be adding support for collecting block rewards to each client, with a parameter that could be set, controlling the portion of the reward to be captured (and the beneficiary). This mechanism would be initially set to 0%, and could be edited via some on-chain mechanism or via a hard fork. The hard fork option is safer and probably less controversial since the on-chain option raises tons of questions around keys and governance.
It's worth mentioning why this isn't being proposed for something like Bitcoin. Bitcoin is intended to stay the same, while Ethereum is intended to evolve. Part of the reason this ERC makes more sense now than it did last year is because Ethereum's evolution is accelerating in the presence of other smart contract platforms. I suspect it will take 1-2 years at least to ramp up to 20% inflation rewards to stewardship, but as the EF fades and the ecosystem grows more competitive the community will increasingly see the logic of this action. I just hope it isn't too late by that point, which I why I think it's great timing that you're starting this discussion now.
This being said, administration of funds should be considered a ongoing topic of discussion, outside of the main topic of the ERC - securing 20% of block rewards for maintainers of Ethereum.
In practice, we recommend adding support for collecting block rewards to each client, with a parameter that could be set, possibly via some on-chain mechanism, controlling the portion of the reward to be captured (and the beneficiary). Initially the parameter would be set to zero, but adopting the ERC and implementing the code is making a credible commitment to the community that if another solution isn't found, and a reasonable amount of funds collected by some point in time, then we will "turn on the faucet" and begin collecting block rewards.
Criteria for Administration of Funds
We propose these criteria when evaluating
Consensys Grants, the ECF, and the EF have been deploying capital to help accelerate the space, and we should take best practices and learnings from those teams, and apply them in whichever model we choose. In the short to medium term, we imagine these programs would receive a yearly budget via block rewards, upon which there would be transparent reporting around which projects those funds support and the reasoning.
In the spirit of decentralization, I believe that administration of funds from inflation funding should be administered via DAOs that are accountable to the community, and to their participants.
In making this proposal, I would like to first acknowledge the long road we’ve got ahead of us when it comes to DAO research and development, especially with respect to this use case. In the spirit of decentralization and trustless technology, we are not used to giving a lot of discretion to actors to administer funds and deploy capital. Many of the protocol maintenance, development, and design tasks that need to be done require abstract thinking, vision, and strong execution. Thereby, it will be important to design a DAO which both simultaneously holds itself accountable, but also has the capacity for abstract, thoughtful consideration of funding proposals.
One promising advancement for DAOs in this space is the recent mainnet launch of MolochDAO. Moloch operates through the submission, voting on, and processing of a series of membership proposals. I am looking forward to the results form the first MolochDAO experiments, and I am cautiously optimistic that Moloch could be forked and adjusted for the purposes of this ERC.
Another promising project that is administering funds to support Open Source Software Development is Gitcoin Grants. (Full Disclosure: I am a founder of Gitcoin). We recently ran an experiment in CLR Funding for Open Source Software and raised $50k for ETH 2.0 projects in the first round. Details here.
We should also note that Open Collective has pioneered, in many ways, what an organization that is transparent by design, would look like.
I am looking for collaborators who are knowledgeable about DAOs. Please see the “Get Involved” section below.
4. Other ideas and tuning of parameters
This proposal is based in part upon the funding model for the ZCash Foundation, in which “80% of the newly created ZEC will go to the miners, and 20% ZEC to the founders.” As we design a system for the Ethereum community to consider, I believe there is much to be learned from the ZCash model.
As mentioned in the introduction, my goal for this ERC is to establish a strong argument for (1). OSS Stewardship is the most important driver of long term driver of value creation in the space. I am willing to die on this hill.
Sections (2) (3) (4) are arguments that are more loosely held. My goal for the ERC is to facilitate discussion on each of these topics. In particular, I’m interested in hearing the community debate various mechanisms for supporting OSS in the Ethereum space.
Off the top of my head, here are some variables we can tune: (this list is not exhaustive)
What inflation funding rate is correct?
Team Gitcoin has started to model what we think the correct amount of inflation funding is. Here is a snapshot:
As you can see, if this ERC is successful and 20% of the block rewards go to developers, then $98mm / year will be distributed to developers. According to our models, this is $43k per dApp, $196 per developer in the space.
We look forward to revising this model with the help of the Ethereum community.
One consideration that we advise the community to take into account is, that because Ethereum is so vast, it's going to take a long time to get widespread buy-in for inflation funding stewardship at all so it might as well be large enough that it's worth the coordination cost to even talk about. Miners are getting ~$500M/y at these prices so even 1% is $5M over the course of a year. Starting with 0.1% ($500K) seems like a waste of time, maybe 1% is the minimum. You could pay ~33 devs $150k/y with that.
It is possible that we could fund parts of the ETH community OSS dev via inflation, as discussed on EthMagicians.
Dynamic provisioning of fees
One interesting idea that was shared with me last night by a prominent member of the space is that, when the community releases a new fork (Byzantium to Constantinople for example), they could scope the next fork, and dynamically allocate a different percentage fee based upon the scope of the next fork and the consensus for said fork.
In forming this proposal, I did my best to anticipate possible counter-arguments. Here is the output from that process.
This proposal reduces miner incentive to secure the chain
I anticipate this proposal will generate a fair amount of pushback from miners, and possibly stakers. A miner has a rational economic incentive to argue that, without 100% of the issuance rewards, they are not properly incentivized to secure the blockchain.
Before addressing this argument, I would like to acknowledge that I have worn both hats in my career. I have been both a miner and a developer over the last several years. I have deep empathy for both parties, and believe that there is a rational economic that increases the size of the pie for both parties.
My counter-argument to this point is that this proposal will increase the size of the value of the Ethereum ecosystem sufficiently that miners will actually make more profit in the long-term by securing a better, more sustainable ecosystem. By ensuring that the best and the brightest in the ecosystem can work in the Ethereum ecosystem on important maintenance and protocol tasks, we will
One interesting thing to note when it comes to miners paying software developers, there is a precedent: proprietary miners (like Claymore) that give 1-3% of the mining rewards to the developers of the mining software.
There is a counter-argument that developers who HODL ETH have enough of an incentive to maintain the protocol. I believe that this argument is naive, for the following reasons:
This ERC is a proposal to create sustainable funding for projects in the Ethereum commons.
This proposal funds ongoing ecosystem stewardship with inflation funding. As a starting point, I propose that 20% of the issuance rewards (both tx fees + block rewards) are distributed to the stewards of the Ethereum ecosystem.
In this ERC, I broke down my argument into four basic sections.
My goal for this ERC is to establish a strong argument for (1). Stewardship is the most important driver of long-term driver of value creation in the space. I am willing to die on this hill.
Sections (2) (3) (4) are arguments that are more loosely held. My goal for the ERC is to facilitate discussion on each of these topics.
To get involved in the working group for this ERC, please comment on this thread or engage with the project board here.
There is also a telegram group for the inflation funding working group.
I am particularly looking for collaborators who:
Special Thanks to Nick Miller, Jeff Scott Word, Ameen Soleimani, Dan Lipert, Scott Moore, Vivek Singh, and XYZ who reviewed this ERC before it was submitted
We recommend the following writing for further exploration of this topic:
The text was updated successfully, but these errors were encountered:
NOTE: I'm going AFK and will add to this further tomorrow.
I'm elaborating on a twitter thread as I think it adds useful context to this:
Basically, there exists a networking issue that needs to be solved.
A few conditions:
A barebones example:
In ETH1.x we could have the miner could sign a message (with their private key) stating the address to send to and the allocation amount. This could be stored in the extra_data field, and we could reserve a key for it, perhaps something like:
In Eth2.x we could follow a similar pattern although we need to further spec out how our messaging will look. I believe the recent Wire protocol should help with that.
Edit 1 - formatting.
@owocki this doesn’t really follow an EIP process. I think it would be more helpful as a blog post that points to a (future) actual EIP.
Specifically I’d like to engage with the content but I don’t want to mess up the EIP registry with something that is a long form discussion.
Does that make sense?
I’m happy to help format this as an EIP that can be submitted as a PR and merged as a draft. I’ve gone ahead and setup a repo, put this content as the README, and added the EIP template. https://github.com/spadebuilders/eip1789
Note: I couldn’t copy the Markdown source from your issue so the README will need to be updated.
@bmann thanks for the feedback. feedback is a gift!
i was treating this issue as a ERC (which i understand stands for Ethereum Request for Comment), not an actual EIP (Improvement Proposal). The actual EIP will come later, after we've built economic models, designed a DAO, built a technical reference implementation ,etc.
I'm tracking tasks for this at https://github.com/gitcoinco/ERC-1789/projects/1
For the long form discussion, I'm happy to use the above repo, the repo you set up, ETHMagicians Forum, Google Groups, or something else. Let me know what you prefer... We are debating where the working group for this initiative should live within team Gitcoin this week!
I hope I don't come across as really nitpicky but ERCs are actually proposals for "application-level standards and conventions" , and therefore should be used to propose standards on the application level. Your proposal doesn't fit into that category.
This comment may seem aggresive, I've been trying to rephrase it for about 30 mins and I don't know how to do it so I'll just state it explicitly: please don't take it as aggresive, I'm just trying to provide information.
First off, let me say thank you for getting the ball rolling here. Proposing a block-reward share for core infrastructure has been on my todo list for several months now (just so busy with multiple other EIPs
Thinking out loud, even if it's not Ether (to keep the miners at current levels), but some additional special "maintainer reward token" (MaRT?
A thousand times yes.
You've probably seen this already, but I'd like to toss a Nadia Eghbal post on decentralized funding into the discussion.
Yeah, it's super confusing. ERCs are a subtype of EIPs (
This is probably not ready to be codified as an EIP yet, and when it is it probably belongs as a "Core" EIP when there's enough technical detail (example Core EIP). A lot of the material here is what would need to go into that format eventually, so we could get this into an EIP format, and plug away at the technical details. More than happy to help get this into a format.
I very much appreciate the conversation starting, regardless of what it's labelled as
@owocki If you have a repo already, great. I can shut mine down ;)
It’s not an ERC either. You need to actually make a PR in the specified Markdown template. This is “just an issue” at this point.
If you use your repo with a README and make a Markdown doc following the EIP template, then you can manage changes and PRs in your own repo AND have any PRs you do to this repo reflect the source changes. Hope that makes sense.
I’m working on improving and documenting the EIP/ERC process, so I’m trying to help jump in and explain. More docs coming.
This is the only thing close to a community wide governance channel we have, so assigning a number to it is great.
@bmann I'd like to get this pushed through so signalling can start on Tennagraph. Is there an EIP format that works existing? perhaps meta? I understand this is in a state not yet to be "codified as an EIP" , but that poses a problem in the case where signalling is exactly what we need to progress it.
I want to approach this direction before building a separate system for signaling on these kinds of issues.
note that this issue is meant primarily to create discussion, and to lay out a case. ideally tennagraph would be able to get signal on each of the following pieces discretely @MadeofTin
is that possible?
Definitely possible. I am a little confused on how to approach the second explicitly, but I think there is a way to get there. What are your thought on how the modules would be set up? @owocki
Overall, I have been reading over the recent discourse and recommend implementing 3 different voting modules to be effective.
I wrote up a visual example as a starting point for discussion.
this makes sense at a high level to me. i appreciate all the thought going into this! let me circle up with a few people in the working group
at first glance, one thing that we'll need to do is further bake the inflation funding proposal (there are different flavors of what could/should be implemented based upon how we design the body that maintains those funds)
Another option would be to release each module separately. Something like module 1 then a week later release 2 and then a week after that release 3.
And, just to be clear, creating custom modules isn't a feature supported on Tennagraph right now, but all of the tech to make it happen is there for someone to put together. So, either someone from your team could submit a pull request and we can launch or we can raise some funds for the Dev team to work on this piece.
EIP-1789 as an Informational EIP can form the philosophical basis, design principles, and requirements for a system to provide stable funding for Open Source projects in the community.
As EIP-1789 matures, it can be referenced in a future Core EIP defining the inflation funding mechanism in the protocol, and subsequent ERCs which would define the mechanisms of fund distribution. Also, critically, it would be referenced in a Meta EIP which would define the process for managing such a system.
EIP-1789 is the overarching philosophy which will drive a number of proposals. It can then evolve, enabling the dependent proposals to evolve along with it.