OP Stack

Retro Funding is at an inflection point and the decisions we make will set the incentives moving forward.

Under consideration is the enabling of voters to exclude projects that permission the reuse of so much as a single line of contract code.

A reductive view of openness. 👇

TL;DR - This will be the Collective's fourth shot at Retro Funding and it is critical that it sends a strong message to app layer builders that on @Optimism impact = profit.

Solidity file licenses are a poor prognostic for openness and should not be used as a binary filter.

Retro Funding is core to Optimism’s Economics.

It is designed to fuel a flywheel whereby builders/users create demand for block space, that demand drives sequencer revenues, and those revenues are shared as rewards to those creating the most impact.

In short, impact = profit.

Retro Funding has had two primary issues to date:
1) There are not enough revenues to sustain the program
2) Those generating the most revenues are under rewarded

Simply, the Collective needs to incentivize orders of magnitude more impact to sustain RF.

And the results of the last round did not accomplish this.

The top OP Stack application layer projects earned 5% of the total rewards.

Forks with single digit TVL earned more funding than the projects they copied despite delivering 1% of their impact.

And the results of the last round did not accomplish this.

The top OP Stack application layer projects earned 5% of the total rewards.

Forks with single digit TVL earned more funding than the projects they copied despite delivering 1% of their impact.

https://x.com/carl_cervone/status/1750005488949903817

The changes made to the latest round of Retro Funding seemed designed to change this, the message being: 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.

However, it is now being suggested that we should introduce tools that empower Badgeholders to systematically exclude some impact.

Specifically, any that comes from projects who require any kind of permission to reuse so much as a single line of contract code.

This is justified primarily in the fact that a commitment to "Open Source / Open Access" is one of the Collective's core values.

Implicit to this is the idea that open systems can create more impact through the network effects of their reuse than closed ones.

The issue is that whether or not a project requires permission for the reuse of a single solidity file doesn't actually tell us much about its relative openness or potential for positive network effects.

It just risks (once again) over rewarding lower impact work.

The relative open versus closed nature of a project cannot be distilled down to a single license in a single solidity repo.

Tokenomics, value-accural, governance mechanisms, non-solidity code, product specs are all dimensions of openness left unconsidered and unrewarded here.

Projects that give 90%+ of their tokens to their communities and ecosystems are more open than those that engage in private sales.

Projects that direct 100% of the value they generate to their users and ecosystem are more open than those that direct it to themselves.

Projects that build non-solidity OS software or IP to support their project's operations are more open than those who do not.

Projects thats that operate via fully decentralized, immutable, and permissionless systems are more open than centralized ones.

And the potential for these types of openness to create downstream network effect multipliers is just as powerful as an OS smart contract.

Simply, openness of network share, value accrual, and usage are no less important/impactful than the usage rights of every line of SC code.

This is why the idea that we should enable voters through to systematically exclude projects based on just one of many dimensions openness seems so contrary to our values.

It is a poor prognostic, and if we can't measure openness holistically, it should not be a filter.

And importantly, as of now the recommendation is not just to ONLY look at openness from the perspective of solidity code, but to evaluate a project that use 90% OS contracts the same as one that uses 0% OS contracts -- this a blunt instrument that does not reward net openness.

It just shifts the focus away from impact in a way that will make it trivial for bad actors to game the system and once again receive a disproportionate share of funding with low lift projects that deliver far less impact.

"Show me the incentive and I'll show you the outcome"

And it ignores so many of the nuances and complexities associated with definitions of "Open Source / Access."

Even the OP Stack has adopted a dual-licensing like framework with the Law of Chains whereby receiving upgrades has conditions.

And it ignores so many of the nuances and complexities associated with definitions of "Open Source / Access."

Even the OP Stack has adopted a dual-licensing like framework with the Law of Chains whereby receiving upgrades has conditions.

https://x.com/kaereste/status/1786818247267844110

Or the ways in which private interests can use programs like Retro Funding to be rewarded for work they later intend to take private.

An issue that is currently endemic in the OSS community.

Or the ways in which private interests can use programs like Retro Funding to be rewarded for work they later intend to take private.

An issue that is currently endemic in the OSS community.

https://www.youtube.com/watch?v=hNcBk6cwim8

In the end, the most important thing for Retro Funding this cycle is provide a strong signal to app-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.

This is how we get new and existing projects to invest in building on the Superchain even in its nascent form: 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 Retro Funding has got you covered.

Design decisions that risk again rewarding low impact work at the expense of high impact work must be avoided.

We can do this while designing RF rounds focused on holistically measuring and rewarding network effects of openness.

But for now, focus on impact is key.

Retro Funding has had two primary issues to date:
1) There are not enough revenues to sustain the program
2) Those generating the most revenues are under rewarded

Simply, the Collective needs to incentivize orders of magnitude more impact to sustain RF.

https://x.com/opmichael_eth/status/1726609910404903240