Retro Funding 4: Voting Experience

This thread is to collect feedback on the Retroactive Public Goods Funding (Retro Funding) round 4 voting experience :sparkles:

Please read Retro Funding 4: Onchain Builders - round details to gain relevant context on the mechanics of Retro Funding 4.

Iterating on Retro Round 3 learnings

A number of learnings from the voting process in Retro Funding 3 were identified in the retrospective:

  1. The broad scope of projects and lack of comparable metrics made data-informed voting decisions difficult. Despite the challenges, there was a movement towards more data-driven decisions in evaluating open source contributions and onchain deployments.
  2. The quorum requirement had a negative effect on the applicant and badgeholder experience, transforming the process into what some perceived as a popularity contest.
  3. The self-selection of applications to review by badgeholders does not ensure a fair review by a minimum number of badgeholders for each application.
  4. While a vast improvement to RetroPGF 2, the implications of the voting algorithm were difficult to understand and leave room for further research and improvement

Retro Funding 4: Voting experience

Retro Funding 4 will be experimenting with a new approach to voting, in which badgeholders vote via weighting metrics rather than voting on individual projects. The thesis behind this experiment is that by leveraging quantitative metrics, citizens are able to more accurately express their preferences for the types of impact they want to reward, as well as make more accurate judgements of the impact delivered by individual projects.

This design aims to address feedback and incorporate learnings from retro round 3 by exploring data driven decision making and eliminating the quorum requirement and self-selection of applications by badgeholders.


The implementation of this voting experience is a collaboration between a number of teams across the Collective.

  • You can find product designs created by the Optimism Foundation design team here. Thanks to Ed, @joanbp @mitch @Michael @LauNaMu @Tamarandom @amer and @Griff for participating in user interviews to improve the designs!
  • The voting interface is being implemented by West, who were selected via a Foundation Mission. You can find the relevant repo here
  • Open Source Observer is creating the data infrastructure to power metric-based voting, you can find the relevant documentation here.
  • Agora is providing underlying voting infrastructure, you can find their API, which will power the voting interface, here

Impact Metrics

A key part of Retro Funding 4 is the creation and selection of impact metrics to measure the impact of Onchain Builders.

The following data sources will be available to power metrics:

  1. Blockchain trace data from OP mainnet, Base, Metal, Zora, Mode, and Frax, powered by GoldSky
  2. Web 3 social & reputation data from Farcaster, ENS, Gitcoin Passport, EigenTrust and Lens
  3. Code contributions (e.g. Github) and data collected during the Retro Funding application process

To shape the creation and selection of impact metrics, badgeholders have been involved in an ongoing process involving surveys, polling and a comprehensive survey. This process is facilitated by @simonapop. The findings and refined results of this engagement with badgeholders will be shared shortly as we continue to iterate these processes in a meaningful way.
The final list of metrics available in the voting interface will be curated by badgeholders around mid-July. In addition to contributing to the design of metrics, anyone can create & propose an impact metric via Open Source Observer. There’s an ongoing data challenge by OS Observer with a total of 3k OP in rewards for proposing new metrics, more details here.

Rewarding the use of Open Source licenses

One of areas of impact which Retro Funding aims to reward is the use of Open Source licenses. “Open Source / Open Access” is one of Optimism’s Collective values and has been the most popular among governance participants during the creation of the Collective’s values.
In the voting interface, badgeholders will have the option to assign a multiplier to Open Source projects, as well as exclude all non open source projects (see WIP designs).

  • The licenses used by projects are identified by collecting the Github repo which holds the projects contract code during the application process.
  • To define Open Source licenses the definition of the Open Source Initiative, a long standing non-profit dedicated to the definition of open source, will be used.
  • If a project holds their contract code within multiple repos with different licenses, of which at least one is a closed source license, the project will be considered as closed source. This rule keeps the implementation practical, and avoids arbitration about which repo is how important to a project, or how to handle semi-open-source projects. We’re open to proposed solutions to this edge case which are operationally and technically viable.

Voting algorithm

The Foundation will published a Mission Request to do research on different voting designs and their tradeoffs. This research will inform the selection of a voting algorithm which will be applied in Retro Funding 4, updates will follow.

Defining profit within in the impact = profit framework

The Collective is experimenting with using a deliberative process to come to consensus on a definition of profit, which will be universally applied to the Retro Funding 4. You can find more information on the deliberative process here.


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:

  1. We need orders of magnitude more demand for blockspace as the program is not even close to being sustainable on sequencer revenues alone
  2. 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.


Completely agree with Alexander for all the reasons mentioned, especially those that point out alignment with Optimism ethos. We want to encourage things that we want to see more of, and the biggest services offered and problems solved are often completed through many painful hours of effort. Stars are not things that burn bright and then fade or run away. They are constants that draw people to them. We need stars, not flashes of light that are mere reflections.

not much to add that alex hasn’t already outlined

other than to say that if this implementation goes as planned i’m going to have to spend, just like last time, about three months explaining to people, don’t worry, next time will be better, we’re always improving

and i really don’t want to have to do that when there’s a chance just to get it right now because each time the argument gets weaker when the outcomes are way off - and the audience is now not just partner protocols but partner chains

the downside of not implementing this at all isn’t anywhere near the downside of getting this wrong


Hey @alexcutlerdoteth! Appreciate your thoughts and feedback on this. Below is a response to some of your points

We fully heard your feedback on the lack of rewards for onchain builders in Retroactive Public Goods Funding 3. The feedback you and others provided heavily informed the design of Retro Funding 4.

The distinction between open source and a mixture of open and closed source licenses

It is suggested that there are should be no distinctions to be made between a 90% OS project and a 100% OS project

As the post flags, this is something we’d love to iterate on in the future, to get to a more granular method of allowing badgeholders to reward open source work. In its current form, it’s not practical to make claims on the “open source percentage of a project”, as this requires to judge the importance of each piece of code of a project. As flagged in the post, we’re very open to suggestions for how this could be achieved!

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.

The definition of the Open Source Initiative is applied to classify licenses as open source. While this can be a controversial topic, the Open Source Initative’s classification is the most widely accepted and used framework.

As we’re implementing this as a multiplier, this means that using an open source license in isolation is not rewarded, but that instead badgeholders can add this as an additional consideration to reward impact.

Allowing badgeholders to make informed decisions

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.

In our user testing, we have received strong feedback from badgeholders that they want this functionality. This functionality allows individual Badgeholders to express an important element of how they’ve previously rewarded impact. Each Badgeholders retains the agency not to use this option, and as described below, we’ve taken efforts to ensure they understand the implications of choosing this option.

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.

Fully understand the concern that badgeholders are not able to understand the implications of their choice, to mitigate that we’ve implemented some features to enable badgeholders to understand how their choices impact the allocation of OP among projects. Badgeholders are shown a table and graph with their OP allocation, which is based on the impact metrics they weighted and the open source multiplier. Within the table badgeholders can see the resulting allocation of OP to each project, filter based on the performance against specific impact metrics and the open source multipler and discover which projects are labeled as open source.
When badgeholders use the multiplier, they will see how the table and graph is updated to reflect that (see screenshot below). In addition, they’re able to filter the table to only show none open source projects.

On the advantages and drawbacks of Open Source

Building Open Source is one of the Collective values, which have been shaped by both Citizens’ House as well as Token House members. The Optimism Collective believes that building open source gives rise to rapid innovation, permissionless experimentation and open knowledge sharing. It is core to combatting the centralization of power and lowering the barriers to entry for builders within the Collective. This leads to increased competition, higher quality products for users and less value extraction. One of Retro Funding’s core goals is to reward open source contributions which benefit the Collective.

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.

The OP Stack is MIT licensed and has a large number of forks. The Optimism specs repo, which outlines the specs of the OP Stack, is currently under a Creative Commons 1.0 Universal license, which is not considered as open source by the Open Source Initiative, but is a public domain dedication which allows anyone to build upon, modify, incorporate in other works, reuse and redistribute.
In Retro Funding 4, for a project to be considered open source, only the repo which contains their contract code needs to be under an open source license, not all repos which the organization owns need to fulfil that requirement. Thus, the OP Stack would pass the test.

Regarding concerns on the missing license on the OP-Atlas repo, we’re in the process of building this (you can see that the repo is only a few weeks old). We’ll add an open source license to it shortly.

Allowing badgeholders to reward the use of open source licenses also does not imply that the Optimism Foundation or OP Labs team requires all partners that it references, or uses to build products, to be open source.

Thoughtful implementation

The team has invested lots of time into getting this feature to a state in which we feel confident. It’s been included in the spec for the voting experience from the very beginning.
The “Open Source license of contract code” has been shared as one of the areas of impact that will be rewarded from the very beginning in the Retro Funding 4 announcement. This was not a rushed decision.

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?

Within the sign up experience, we’ve added a disclaimer to projects that they should attach a license to be classified as open source. An export from the previous retro round shows that most projects have a license on their contract repo, we will run this query again and report back!

Open source is important to the achievement of Ether’s Phoenix. Badgeholders have previously expressed a strong desire to reward open source projects and so we’ve thoughtfully, albeit imperfectly, designed an option that allows them to express this preference. Just as it’s important that Badgeholders be empowered to make their own decisions, it’s important that they understand the implications of the decisions they make. Inspired by this feedback we’ll take the following actions:

  1. Take special care to ensure that badgeholders understand the implications of using the open source multiplier and add a disclaimer on this to the feature.
  2. Dive deeper into the data to understand how many repos are missing licenses, who would be affected etc.
  3. During the curation of metrics, badgeholders will be asked to signal if they want this feature.

Hey @Jonas -

I appreciate the response. Since it sounds like mostly you are suggesting you’ll (more or less) move ahead as planned, I wonder if you’d willing to address some of the other points and clarify some points in your post before I respond further? Some specific follow-ups below.

I don’t think you addressed this example directly, so I’d like to understand your take on the implications of facilitating the rewarding Project A over Project B? What sort of distribution of rewards relative to impact do you expect to see and why is this more optimal to simply not adding the filter and multiplier and letting Badgeholders choose? If you were a developer focused on making as much as you could with the least amount of effort, would you build Project A or Project B?

I’d also be interested in your perspective on other dimensions of the open vs closed as the Collective Values you cite do not seem to just be singling out OSS and thus I’m curious why you’d prioritize build tooling to enable the filtering based on one dimension of openness while ignoring others? Are there other features that have been requested by Badgeholders or ecosystems builders are not being incorporated into this round? Has the survey data been made public so we can see how it was constructed? Did you also survey application layer builders?

Can you address specifically how you intend to address the ways in which this process could easily gamed such as?

  • Submitting a repo that doesn’t contain all of the code on which a projects depends
  • Submitting a repo that points to OS contracts, but those contracts rely on proxy contracts that are not public, unverified, upgradable, and/or ever changing

A few other points to clarify from your post:

If a more robust solution is not currently practical currently, what is rationale in shipping this now knowing the potential for penalizing high impact projects that are even 99% OS or don’t have the means to engage the legal resources required to add a license ahead of the round? What does the collective gain by doing this and what are the risks in your eyes? If we again see high impact projects going unrewarded, how long would it be before there was another round focused on onchain builders that would include any iterations?

So are you implementing it as a filter or multiplier or both? How is the net effect of this not rewarding an open source license in isolation if in effect a reward for OS in isolation? Can you give some examples of how this would affect the distribution in practice? Also, have you modeled out the multiplier to support that? How did you arrive on the multiplier range you’ll allow?

Can you tell me what % of Badgeholders are currently application layer builders building on OP Stack chains? Only ~50 out of 130 voters even cast ballots for leading Optimism protocols last round, so I’m curious how many are steeped in the challenges and nuances of this issue? Did you consider increasing builder representation prior this round?

Why specifically is contract code being specified here and no other kind IP is being subjected to the same requirement? The Collective Values are no specific here so why are we being specific? Was this distinction documented prior to pointing out the specs repo or is this a new qualifier only after my post pointing out the incurrence?

Is there a distinction between “allowing badgeholders” and “enabling badgeholders” that you acknowledge here? How would one not allow them to do so?

Can you break this out in more detail? What % have one and what % don’t? And what type?

Can you share at what point the OP Stack and any other OP Labs smart contracts became fully opensource and what other liscence types were used prior to their being fully open sourced and why those decisions were made?

Can you detail any other cases where OP IP is not fully open sourced and the liscence types used and the rationale?

Are there any other areas of impact that can be filtered or multiplied by the voting tool? If not, why not? Are some values more important than others?


I’m pretty ambivalent when it comes to open source, VC funding, or other measures of what makes a “public good” since ultimately what I think we should be rewarding is impact. I’m curious how the top 5 protocols as measured by TVL on Defi Lama would be rewarded in the current framework and impact metrics?

If we are going to say impact = profit, then we really need to mean it in order to keep, and bring in serious protocols. If we are not rewarding our largest protocols then they will not be incentivized to stay and we will attract low value projects, because that’s what we are rewarding.

I very strongly agree with others in this thread that we are at an inflection point and we need to get this round of retro funding right.


Attempted to better distill some thoughts here:

1 Like

I’m with those who believe we may have many ways we can help/solve the sustainability of the Superchain.

I think before demanding more open source we should probably be ready to support it. Atm I don’t think we’ve proven any economical sustainability to demand the adoption of such (legal) requirements from builders.

If the tokenomics aren’t making that public good a sustainable economy, then it’s like we’re burning VC money, except that’s the project tokens [1]

Demand for open source should definitely be encouraged! Ideally in a neutral way across multiple areas, (not just the codebase) and incrementally over multiple seasons/years. I don’t think this is an overnight effect we can achieve.

Especially if we don’t prove as a collective that this is where we reward builders with impact. It makes more sense to me to support and scale the impact we’ve reached so far and not leave ways to exclude projects that can’t go fully open source yet.

I think a lot of those projects have gone a long way to become public goods in many other ways, it is a survival.

  1. Warpcast ↩︎

1 Like