Retro Funding 5: OP Stack - round details

[system]

Retroactive Public Goods Funding (Retro Funding) 5 will reward contributors to the OP Stack, including core Ethereum infrastructure that supports or underpins the OP Stack, advancements in OP Stack research and development, and tooling which supports its accessibility and usability.

Timeline

Please note that all dates are preliminary and might change. This post will be updated to reflect future changes.

1. Sign up: Aug 22nd - Sept 5th
2. Application Review Process: Sept 6th - Sept 20th
3. Voting: September 30th - Oct 14th
4. Results & Grant delivery: October 21st

Contributing to the OP Stack

If you’re looking to make contributions to the OP Stack which could be rewarded within a retro round, check out open ideas describing impactful initiatives on the OP Stack repo here

---

Round Scope and Eligibility Criteria

Retro Funding 5: OP Stack will reward impact which has been generated between October 2023 - August 2024. Impact will be rewarded within the following categories:

Ethereum Core Contributions

Ethereum infrastructure which supports, or is a dependency, of the OP Stack.

Examples: Smart contract languages, Ethereum consensus & execution clients, EVM, Ethereum testnets, Cryptography research

Eligibility: The following types of projects are eligible:

• Ethereum client implementations
• Infrastructure to test and deploy chains
• Languages that are dedicated to the development of smart contracts
• Research that informs Ethereum core development

Not eligibile: The following types of projects are not eligible

• Projects that are used to develop or deploy contracts or apps, including in the development and deployment of Optimism contracts, may be rewarded in Retro Funding 7: Dev Tooling, and are not in scope for this category.
• Extended Ethereum related tooling that is not listed under eligibility, including analytics/data infrastructure, frontend libraries, indexers and more. These may be rewarded in Retro Funding 7: Dev Tooling and are not in scope for this category.
• Generic Ethereum related research that does not inform Ethereum core development

OP Stack Research & Development

Direct research & development contributions to the OP Stack, and contributions that support protocol upgrades
Examples: Optimism Protocol upgrades, OP Stack Client Implementations, modules & mods, audits and Fault Proof VM implementations.
Eligibility: The following types of projects are eligible:

• Work on core components of the OP Stack, including client implementations, modules, and modifications.
• Research or development that introduced features, improvements, or capabilities to the OP Stack.
• Security audits specifically on the OP Stack or its components.

Not eligibile: The following types of projects are not eligible

• Optimism Monorepo contributions by non-core devs: Only Optimism Monorepo contributions by core devs may be rewarded within Retro Funding 5. Commits to the monorepo are currently mainly done by Optimism core devs and the core dev program is not developed enough to support outside contributions to the monorepo yet. As the core dev program evolves, more contributions to the monorepo may become eligible.
• Submissions to the Optimism Bug Bounty Programs are not eligible to participate in this round

OP Stack Tooling

Efforts that improve the usability and accessibility of the OP Stack through tooling enhancements.
Examples: Integration and load testing infrastructure, scripts for running an Optimism node, RaaS providers, OP Stack tutorials & documentation

Eligibility: The following types of projects are eligible:

• Tools that facilitate the deployment, operation, or testing of the OP Stack. This includes integration tools, load testing infrastructure, and scripts for node management.
• Services for deploying and hosting an OP Chain
• Documentation and tutorials which aid in understanding of the OP Stack’s components and its development

Not eligibile: The following types of projects are not eligible

• Projects that are used to develop or deploy contracts or apps, including in the development and deployment of Optimism contracts, may be rewarded in Retro Funding 7: Dev Tooling, and are not in scope for this category.
• Extended tooling that is not listed under eligibility, including analytics/data infrastructure, frontend libraries, indexers and more. These may be rewarded in Retro Funding 7: Dev Tooling and are not in scope for this category.
• Documentation and tutorials which are not about the OP Stack’s components or development, such as non technical tutorials about Optimism.

---

Round Sizing: 8m OP to reward OP Stack contributors

Retro Funding 5 will allocate 8m OP to reward the impact of OP Stack contributors. The Foundation will size Retro Funding 4 & 5, and will propose round sizes for Retro Funding 6 & 7, to be ratified by the Citizens’ House. In the future, this process will gradually transition to be more community-led, which may involve the creation of a Budget Board, or similar, in future Seasons. Below you find some considerations that informed the round sizing:

1. Retro Funding 3 benchmark: In retro round 3, approx 6.5m+ OP were allocated to projects contributing to the OP Stack.
2. Rapid development of the OP Stack: Since round 3, 5+ Protocol upgrades took place that introduced major performance improvements to the OP Stack. Research has accelerated with the deployment of the OP Stack fault proof system on mainnet. Thus, the impact generated by contributions to the OP Stack has increased significantly since October 2023.

Voting design

Retro Funding 5 will sort Badgeholders into smaller groups dedicated to evaluating a specific set of applications, with the hypothesis that voter experience and allocation of rewards are improved, compared to past rounds. For the round, a number of guest voters with expertise relating to the OP Stack will be selected, to test if there are significant differences in how experts versus non-experts vote to allocate rewards to OP Stack contributions. You can find out more about the rounds governance design here Retro Funding 5: Expert voting experiment

KYC & Grant delivery

The Optimism Foundation is making continous improvements on the KYC & Grant delivery process. Grants will be streamed to recipients over 100 days, following the announcement of results and approval of KYC. Superfluid is providing infrastructure for the streaming of Retro Funding grants. Grantees must receive a minimum of 1,000 OP to be eligible for rewards.

FAQ

How do I apply?

Go to https://retrofunding.optimism.io/ and follow the steps of this tutorial: Retro Funding - 27 August 2024 | Loom

When will grant disbursements happen?

Retro Funding 4 will conclude in October 2024, following KYC approval, tokens will be streamed to you over 100 days via Superfluid.

Where can I ask questions?

You can ask questions in the Optimism Discord in the #retrofunding-discussion channel.

I'm not sure my project is eligible, what should I do?

You can ask questions in the Optimism Discord in the #retrofunding-discussion channel.

My project doesn't have any contracts, what should I do?

For Retro Funding 5, providing onchain contracts is optional and not required to apply

I will apply with multiple projects, do I have to report my funding & grants for each?

Yes, if you’re applying with multiple projects, you need to report your funding & relevant grants for each

Can I apply for multiple categories?

Each project can only apply to one category.

What happens if my application violates the Application Rules?

If badgeholders find that you violate the Application Rules listed above, your project will be disqualified from participating in this round of Retro Funding. You will be able to apply again for future rounds.

Where can I nominate projects?

Theres no nominations process in this round, instead projects sign-up directly. So remind your favourite projects to apply!

Why do I need Farcaster to sign up for Retro Funding?

You will need Farcaster account to sign up for Round 4, if you don’t already have a Farcaster account, you’ll need to make one. Your Farcaster account isn’t just a sign-in method for Round 4, it’s also your Optimist Profile and will be used for future Retro Funding applications and other interactions with the Optimism Collective.

The easiest way to sign up for a Farcaster account is via the [Warpcast](https://warpcast.com/) app, which acts as a wallet to easily manage the keys of the newly created account. Upon sign-up, Warpcast currently charges a $7 fee to rent storage on the network. As a decentralized social network, Farcaster content is not stored on centrally controlled servers, but rather in Hubs, which are a [distributed network of servers](https://docs.farcaster.xyz/learn/architecture/hubs). Each unit of storage buys 5000 casts, 2500 reactions and 2500 follows. For those who prefer to register a Farcaster account via contracts directly, this can be done via the [ID Registry Contract](https://docs.farcaster.xyz/learn/architecture/contracts). Storage can be rented via the [Storage Registry Contract](https://docs.farcaster.xyz/learn/architecture/contracts). There are alternative Farcaster clients beyond Warpcast that also support account creation and storage renting.

Can I apply with two different projects?

Yes, one person can apply to two different projects, so long as there is no overlap in the work. You will need to complete the sign-up flow twice.

Can individuals apply or just projects?

You and your team should apply together with your project. Applying for individual contributions to a project is not recommended.

Can a team that has gotten a grants council grant, partner fund grant, mission grant get Retro Funding?

Yes! As long as you’ve deployed your contracts on one of the qualifying OP Chains and meet the application criteria.

Do I need to report my Airdrops under Grants & Funding?

No, you don’t need to report airdrops that you have received

Are Token sales considered as Investment?

Yes, if you consider them to be equity in your project

[Jonas]

The post has been updated to reflect new timelines for the round. The original timelines were moved back by a week, as the team needs more time to launch the sign up process

Based on feedback from Citizens’ and the CH Feedback Commission, the Eligibility has been updated to include a “not eligible” section which aims to provide more clarity to projects.

[system]

Round sizing update

The Foundation initially set the rounds token allocation to 8M. The application process saw a lower than expected turnout, raising concerns that 8M OP is disproportionate to the impact that is being rewarded within the round. To allow for the adjustment of the token allocation, this round introduces an experiment in community-lead budget allocation.

Citizens will vote on the round’s OP allocation within the rounds voting experience. The Foundation is assigning a minimum OP Amount for the round of 2M OP and a maximum OP amount of 8m OP. Citizens will be able to vote for an OP amount within the range of minimum and maximum which they believe appropriately rewards the impact within the round. The round allocation will be decided by taking the median of Citizens’ votes.

The voting on the rounds OP allocation is an experiment in community-lead budget allocation.
The outcomes of this experiment will inform the evolution of the budgeting process in the future, which is subject to change based on learnings.

Round timeline update

To allow for more testing and support of the additional scope in community-led budgeting, the voting process will start on September 30th

[grapebaba]

It is unfortunate to see this decision; this round includes the most influential projects in the ecosystem, such as Ethereum core contributors and OP protocol layer research. The impact of these projects is self-evident, and most of them were ranked highly in previous rounds, with this category receiving 6.5M in funding in the Retro3 statistics. Since then, many new projects have emerged, and 8M seems to be a reasonable budget.

[joanbp]

Citizens may still decide that this is the case.

With a smaller than expected turnout, it seems reasonable to raise the question.

If fewer projects than expected apply to round A, and more apply to round B, then it could make good sense to allocate more of the funds to round B.

Surely the projects in all of the rounds are important, or they should not be eligible at all…

Also, some great projects currently stand to be rejected from RF5 because reviewers think they fit better in RF7. If RF5 turns out to be a bit ‘over-restrictive’, it would be great to make sure that being considered in, say, RF7 instead is not a disadvantage.

[Kim]

Hi, I think this decision really doesn’t make sense.

1. Can you clarify where the 2 million figure is coming from?If RPGF4 is used as a reference, where 10 million was allocated to about 200 projects, calculating the average per project, the total allocation for the numerous projects under RPGF5 also exceeds the current figure of 2 million. Most projects in RPGF4 were profitable and received investment, whereas many in RPGF5 are not profitable.
2. The 8 million budget was established quite long time ago, which was sufficient for most projects to get started. If the issue now is not a shortage but an excess of projects, doesn’t it seem unreasonable to increase the funding? Moreover, if these projects are still being actively developed in the current market conditions, shouldn’t we be encouraging that?
3. RPGF was initially set up not only to reward past projects but also to attract new builders. We can’t make precise calculations of each project’s impact and rewards, but we still base potential contributions on the rules from previous rounds. Changing these rules arbitrarily could deter potential developers or projects from joining the ecosystem.
4. Let’s not debate whether 8 million is too much, but rather discuss the implications of excessive rewards. Projects with more funding can develop further and expand their teams, which benefits the OP ecosystem. I believe NONE of the selected projects would just hoard these funds. Also, generous rewards attract more contributors to the ecosystem. This is a dynamic balance that should be left to develop naturally rather than being artificially adjusted. Even if adjustments are needed, they should be prepared for in advance of the next round, not made abruptly.
5. This approach seems unfair to small and medium-sized projects that are just starting. If RPGF funding were to be reduced to a quarter of what was anticipated, the impact on large projects might be minimal because they will likely receive more rewards anyway. However, for small and medium projects, it could drastically reduce their funding and severely affect the potential growth of the OP stack.
6. Considering the allocation in RPGF3, projects related to the OP stack were already fewer in number and had a unique and significant influence that’s often not visible to the public. I’m skeptical of the technical understanding of those who think allocating 8 million is too much.

[joanbp]

@Kim

If we take RPGF4 as a reference, where 10 million was allocated to about 200 projects, each project received more than 2 million on average.

Respectfully, the maths here do not add up.

[Kim]

re-edit to make it more clear now, thanks.

[grapebaba]

You can’t just look at the number of projects, because the scope of this round means there will inherently be fewer projects. However, in retro3, many of the projects received donations of 150,000 to 220,000. If calculated this way, around 10 projects could allocate 2 million.

[joanbp]

@grapebaba

You can’t just look at the number of projects

I’m not.

I’m just saying that I think it makes sense to reconsider the allocation, given that fewer projects than expected have applied (and some of those that have applied may be rejected with the recommendation that they apply in a later round).

Now it will be up to the voters to decide, and I’m sure they will consider all of the points that you bring up here.

[grapebaba]

I can understand, I just want to emphasize the impact of the Ethereum Core Contributor project, sorry for my inappropriate wording,

[joanbp]

No worries. Discussion is great.

[timbeiko]

Can you share more about the rationale for this? Looking at the list of applications, 63 projects are currently accepted, with some of the rejected ones expected to appeal and raise the total.

Even at 63 projects, 8M $OP / 63 = 126,984 $OP per project, which doesn’t look too far from the final distributions for RPGF3.

“Projects” are also an imperfect unit of measure. Notably, Protocol Guild (disclaimer, I’m part of it) has >180 members, and many of the client teams in the round have dozens of employees.

It’s also worth noting that allowing people to choose between 2-8M $OP and choosing the median means that a majority of citizens need to vote for the absolute max amount to “retain the status quo”. If the goal is to empower citizens to choose, then why not have the min and max values be equidistant from the status quo (e.g. 2-14M $OP, or 4-12M $OP, etc.)?

[cheeky-gorilla]

I know that “impact = reward” has been a guiding light for RPGF, and thus concerns about rewards > impact should be taken seriously, especially to ensure long-term sustainability and legitimacy of the mechanism. I also understand the gut reaction that “lower turnout should mean lower total reward”.

That being said, it isnt clear to me that a mid-round pivot in this fashion is a helpful approach. Please consider;

• This round includes the category “Ethereum core maintenance”, which is of existential importance to both Optimism and any project built on Optimism
• As Tim indicated, the “turnout” should be contextualized properly; funding from this round will be distributed to hundreds of extremely impactful individuals
• Rushing a vote that biases towards reducing funding is harmful to the legitimacy of RPGF, especially considering that I havent actually seen any arguments that “8M OP is disproportionate to the impact generated in this round”

Simply increasing or decreasing funding for rounds is a very blunt instrument that will be less effective at balancing “impact” and “reward” versus introducing checks and balances into the voting mechanism itself. Earlier rounds trusted badgeholders to roughly dictate “how much” funding projects could get, but this was removed in newer rounds for the sake of simplicity and homogeneity. Perhaps a middle ground needs to be explored.

If we do in fact move forward with this vote, I will vote to keep the round size as-is. I hope I wont have to!

[Jonas]

Appreciate the feedback on the decision to have voters decide on the rounds token allocation @grapebaba @timbeiko @cheeky-gorilla.

Agree here that the number of projects is not sufficient information to decide on the rounds token allocation. Also hear that voters shouldn’t be biased by the Foundation’s view on this, will take this as feedback to not surface the Foundation’s opinion in the voting experience.

To expand on the rationale for this decision: At the Foundation, we are concerned that the token amount is too high for the round (as mentioned in the original post). Voters will have better insights into this decision, as they will review projects and exchange information on what amount they deem appropriate to reward their impact. Having voters make this decision seems like a sensible experiment instead of the Foundation readjusting the rounds token allocation.

[timbeiko]

@Jonas

At the Foundation, we are concerned that the token amount is too high for the round (as mentioned in the original post). Voters will have better insights into this decision, as they will review projects and exchange information on what amount they deem appropriate to reward their impact. Having voters make this decision seems like a sensible experiment instead of the Foundation readjusting the rounds token allocation.

In that case, will you consider having voters signal beyond the 8M, since otherwise it is more likely than not the round size is reduced and impossible for it to grow?

[saulius]

@joanbp

With a smaller than expected turnout, it seems reasonable to raise the question.

I’m not very familiar with the other applications, but I hope that turnout will improve significantly after the Appeal period, because there is a really large amount of rejected applications and a lot of appeals. My main concern is that the applications were rejected by inconsistent evaluation. Some applications were rejected by argumentation that applies to the other accepted applications. So it would be really great to carefully examine rejected applications, cross-check with similar accepted applications in order to eliminate inconsistencies in evaluation.

For example, Grandine Ethereum consensus layer application was rejected because it mentioned PeerDAS (upcoming feature in Ethereum for L2 scaling). It’s not a future promise, the code is available for everyone. But Grandine got rejected by 3 out of 5 reviewers. Meanwhile, another client application also mentioned PeerDAS and they got accepted by all 5 reviewers.

So our first suggestion would be to carefully evaluate appeals. Hopefully, more applications will be evaluated correctly and hopefully, the increased number of applications will become high enough so that it eliminate doubts on the round size.

[joanbp]

@saulius

I’m not very familiar with the other applications, but I hope that turnout will improve significantly after the Appeal period

I don’t know for sure, but I understand ‘turnout’ to be the number of applicants, not the number of accepted applications.

As I have understood it, based on discussions in the context of the Collective Feedback Commission, the original expectation was that ~300 projects would apply for RF5. The reality is closer to half of that.

If on top of that a large percentage of the applicants are found to be in-eligible, according to the round rules as they have been defined, then that is an extra concern, not the only one.