Summary
Retro Funding has the potential to be highly impactful to the growth of the Superchain, but to date it doesn’t have as much mindshare as it rightly should amongst application layer builders due to sub-optimal distributions in previous rounds that uniquely impacted the largest drivers of demand for blockspace. While this new round of Retro Funding made some promising changes, I am very concerned about some of the suggestions made above.
At issue is adding an overly-simplistic binary choice for Badgeholders to penalize projects that have even one line of code contained within them that requires some sort of permission to reuse. This choice may seem intuitive, but delves into an incredibly complex area that deserves careful consideration not a rushed last-minute addition under an imprecise classification methodology. If not done right, we risk repeating the mistakes of past rounds and under rewarding the impact we desperately need once again.
Retro Funding (formerly Retroactive Public Goods Funding) is core to Optimism’s Economics. It is designed to fuel a flywheel effect whereby builders/users create demand for block space, that demand drives sequencer revenues, those revenues are shared as rewards to those creating the most impact, which incentivizes more impact, more demand, more rewards, etc etc.
To distill this down, on Optimism, “impact = profit” or, in a more focused setting, “Build on Base”, be Rewarded”. A clear value prop to attract world-class builders to the Superchain. No qualifiers, no asterisks; just build impactful stuff here, and you’ll be rewarded. Simple and effective.
“Retro Funding is not merely a charitable endeavor; it’s building an impact system where contributions are valued and rewarded.” - RetroFunding Announcement
The two biggest issues with Retro Funding to date are:
- We need orders of magnitude more demand for blockspace as the program is not even close to being sustainable on sequencer revenues alone
- Projects creating the most demand for blockspace have been dramatically under rewarded proportional to their impact due to design decisions made in previous rounds
So far, for the most impactful onchain builders, the type we most need to attract and support for Retro Funding to be successful, impact ≠profit.
Last round, just 5% of the rewards in the went to the top 20% of projects in terms of sequencer fee generation. Straight forks of OS codebases were rewarded at rates comparable to projects with 100x their impact. The message to builders was this: the fastest path to reward is not impact but simply deploying forked OS code. Individuals could make more by launching simple forks or participating in governance than contributing to the most impactful and innovative projects.
This has created a flywheel working against the intention, as reflected in the fact that OP Mainnet’s ETH-denominated TVL continues to go down 30% YoY. You can see it in that we’ve seen some of the biggest Optimism projects shift their focus to other ecosystems. Despite multiple large RPGF rounds and considerable business development efforts, there remain such large gaps in builder representation that the hope appears now to be that new chains will pick up the slack from OP Mainnet’s lackluster expansion.
The fact is that the perception amongst application layer builders, a group woefully underrepresented in the current Badgeholder community as demonstrated by the lack of votes for leading OP protocols, that it simply is not designed to reward them, and they’re acting accordingly to determinant of the growth of the Collective.
This is a recipe for less impact, not more. And less impact means less Retro Funding.
Many of the design decisions in overhauling this round seem to oriented towards correcting for this, including more focused rounds, data-based voting, and a focus on onchain builders.
“This category will reward onchain builders who contribute to the success of Optimism. This round seeks to expand the reach and impact of the network by rewarding those building across the Superchain, increasing demand for blockspace, and driving value to the Collective. This includes builders who bring new users to the Superchain, drive network effects and protocol usage.” - RetroFunding Announcement
The desire with the changes this round seemed oriented toward ensuring that Retro Funding delivered on its core promise of impact = profit to reinvigorate the growth flywheel it is designed to create. The program shift even went so far as to drop the “Public Goods” portion in an attempt to convey that the focus was rewarding a project’s impact regardless of whether it came from original code or copy pasted code, from VC-funded projects or self-bootstrapped projects, from those delivering back to the Collective all of the value they create or privatizing it for a few.
The message here: we need more impact, and we don’t care what you are or how you get there. Please come create demand for OP Stack blockspace however you see fit, and we’ll reward it.
In the announcement of the overhaul and its subsequent communication, there was zero indication that certain code repositories would be privileged over others. However, the above post is now suggesting that there is exactly one type of impact that should be excludable: impact that comes from any project with so much as a single line of code that requires any kind of permission to reuse. It is suggested that there are should be no distinctions to be made between a 90% OS project and a 100% OS project, no distinctions to be made between the multitude of different types of licenses and their purposes, that simply if a builder is asking for permission for reusing any portion of their work, their impact may be systematically ignored—and that some builder who forked OS portions of their code should rewarded at 5x the value. This is frankly shocking and runs against the purpose of Retro Funding.
This suggestion will likely take us right back to the results of RPGF3, creating the conditions where impact is arbitrarily qualified and simple forks of existing OS codebases, whose code creates no additional value beyond that of the original and whose creators take on little legal or regulatory risk, will have the opportunity to be funded at rates much higher than those creating the most demand for OP Stack blockspace, generating substantial novel OS work, and do so at great personal risk given the profile of their projects.
It is also confounding as there was no lack of funding for OSS projects in the last round as they represented 80% of the total distribution. The reputational issue we need to fix in this round of Retro Funding is with high impact builders who have largely written off the promise of Retro Funding — OS has been and will continue to be well rewarded.
Let’s explore some of issues here in more detail.
OS status alone is a flawed proxy for greater impact
It is tempting to enable a single filter for what appears on the surface to many Badgeholders—many of whom aren’t familiar with the nuances of different licensing practices—to be unequivocally a desirable things. But in making a design choice to allow voters a one-click exclusion or 5x boost exclusively for OS—and ignore other important characteristics, such as VC funding or open tokenomics—the Collective seems to be implying that 100% OSS is necessarily more impactful than even 99.99% OSS, which is, frankly, indefensible.
Let’s look at a hypothetical example:
- Project A: Straight fork of OS code from Pancakeswap with $1M in TVL
- Project B: Sroject combining 90% OS code and 10% non with $700M in TVL
Under the current proposal, we are suggesting that we should empower Badgeholders to fully exclude Project B to the benefit of Project A, even if an impact measure of Project B is 700x. There is no additional positive externalities created by privileging Project A over Project B. A copy-paste of an existing codebase doesn’t result in larger downstream impact by virtue of it being OS. There is no reason why the impact of Project A should be rewarded over the impact of Project B.
And, more crucially, enabling this filter means that Badgeholders will never even have the opportunity to observe the enormous disparity in outcomes between the two. There is no way for them to see that there is currently a far more impactful alternative to what they see on the market. They merely shift the weight of the rewards from higher impact to lower impact.
OSS can create powerful network effects, but it does not always do so in every vertical. And creating binary filters just incentivizes “spray and pray” forking of existing OS software—not innovation or impact—which can have obvious adverse ecosystem consequences extending well beyond a simple misallocation of resources.
This prioritizes one dimension of a project’s status as a public good, while ignoring others
Creating a filter that allows for the privileging of impact of one kind of project over another is valid, but focusing it exclusively on the usage rights of code is arbitrary and myopic. Open versus closed is bigger than just whether or not there is a line of code that requires permission to reuse. Projects can be open-source while building eight-figure war chests from private interests. These private interests do not do it out of the goodness of their own hearts, but because they believe that have ways other than code usage to privately extract value from the project or protocol.
Open token distributions and value accrual mechanisms are just as important in creating positive network effects as open sourcing code but are completely ignored here. No multipliers, no filters exist for other dimensions of openness. Instead, developers are asked that every single line of code they developed can be used freely by every VC who could dedicate millions of dollars to undercutting and destroying their projects while ensuring they get a larger slice of the pie.
Surely, this is not what Retro Funding is designed to do.
Optimism itself would be filtered out by the blunt, rushed criteria proposed
The notion that having even a single repository with some sort of license is enough to label the entire project closed-source is a bar that not even Optimism would clear. What this tells me is that adding this filter seems rushed, as confirmed by Jonas’ own communication.
And this raises a question: why are we rushing an implementation to create binary filters for OS in a round focused on onchain builders when we haven’t even taken time to assess what exactly here is desirable? If Optimism itself is failing the proposed standard, maybe there’s a need to more fully consider that standard.
The proposed implementation misses the mark and will cause confusion
The lack of detail on how specifically this will be implemented is a major cause for concern here, as it will likely allow for proposals to be miscategorized at the voting level and once votes are cast there will be no way to retroactively to reweight or fix anything.
A review of many of the top prior recipients indicates they have no licenses in place in their repos; are we asking every project applying to Retro Funding to engage lawyers to draw these things up to avoid being filtered? Even the code used to identify which project is OSS is closed source (no license). The Optimism dev console is recommending a bunch of projects that are not open source, in that there’s no code publicly available, but claim to be under an OSI license. Plenty of projects could appear to be OS via their repos but use private proxy or unverified contracts in their actual implementation; there will in effect be no viable way to systematically verify things. Bad actors will game it, and well-meaning badgeholders will never look into it. Once again, impact will be diluted.
In my opinion, the most important thing for Retro Funding to do this cycle is provide a strong signal to application-layer builders that the promise of impact = profit is more than a platitude. It is to make building on the Superchain such a no-brainer that we cannot keep up with the demand of projects flooding out of other ecosystems and into ours with the goal of creating impact. It is to make any shifting of investment to other L2s seem foolhardy. This is how we get new and existing projects to invest in building on the Superchain. Be the best at what you do, work to meet ecosystem demand, and seek impact even if there’s no immediate profit to see from it—because we’ve got you covered.
Any design or policy choices that could result in complicating the simple and eloquent message that impact = profit on Optimism risks perpetuating the failures of the last round and reinforcing the perceptions among application layer builders that this program is not designed for them. If we do want to go this route, we need to do so extremely carefully and not in a haphazard way.
My suggestion would be to remove the filters and multipliers from this round and instead use it as an opportunity to test and learn what kind of impact they could have if implemented in future rounds.
Something along the lines of:
- Include a button to flag a desire to filter non-OS projects this round, but do not let it impact distributions; instead use the data to understand and model the potential impact of the design choice if used in future rounds
- After the round, audit projects labeled as OS using the current methodology, and determine whether this labeling accurately captured truly 100% OS projects or whether the live contracts look different in application and are not truly OS, use this to refine things
- After the round, analyze how many OS projects represent novel interactions versus straight copy-paste jobs—and develop mechanisms to reward progenitors of the original code in these cases so that we actually reward the multiples of impact OS can create
In the mean time, design a round focused exclusively on rewarding OSS. Build in methodology to that round to parse the complexities of license types, find ways to attribute the origin of the codebases to reward their progenitors and contributors not the copiers. Keep the focus on impact = profit, but find ways to measure and reward the network effects of OS independently.
