I pulled out my phone, sent 0.01 USDC to another guest, and seconds later it showed up in his wallet.  

"That was USDC, the stablecoin issued by Circle, sent on Base, the Layer 2 run by Coinbase. It cost me less than a cent," I said.

"Cool trick," my first friend replied. "But how much actual usage is stuff like this, people sending small amounts of money back and forth?"

Another cool trick: anyone can verify that usage. I will do it for you in a moment.

But first let's teleport halfway around the world and 20 years back in time, to one of the more formative experiences of my time as an American living abroad.

Mailing money to Tanzania

I moved to Tanzania immediately after graduating college.

This was 2004, the heyday of the internet café. For younger readers, internet cafés were places where you would pay by the minute to rent a desktop computer with a 56 kbps internet connection.

I was at an internet cafe composing an email to my mother, asking her to send me $400 via snail mail, hidden in the pages of a reference book.

Here's a screenshot:

It worked. Two weeks later, I had 400 USD (cash) plus some batteries for my mp3 player and soap for my sensitive skin. It probably cost about $30 in postage.

Fun fact:

Another hassle with using US dollars in places like Tanzania at that time is that not all forms of cash are valued equally. There was often a discount for smaller bills (below $50), older bills (pre 2000 mint), and even worn bills. You would get the best exchange rate for crisp, new $100 bills. Some forex bureaus and banks would simply reject older or frayed notes.

American exceptionalism

Fast-forward four years: I was still in East Africa. ATMs were more widespread, but you could only withdraw local currency.

The Bitcoin whitepaper appeared. I remember trying to download it at a hotel in Rwanda and the electricity went out. I didn't get around to actually reading it until several years later, but crypto's potential was immediately obvious to me.

Crypto's potential is still not obvious to most people in the US.

Most Americans have never been paid in anything but dollars. They carry multiple credit cards and have Venmo, PayPal, and Cash App on their phones. They are, therefore, the least likely population on Earth to need stablecoins.

Yet stablecoins are exploding globally, precisely because billions of people don’t live inside a seamless USD banking system.

Measuring stablecoin demand

So, how much demand is there to send small-value USD transfers online? Let's go back to answering the question from my dinner party.

I ran a 20-line SQL query on Base’s blockchain data and plotted a heatmap (see my code here).

Circle launched USDC on Base in August 2023. Since then:

• ~300 million small-ticket transactions under $500 have been posted

• $18 billion has moved peer-to-peer in the form of small-ticket transactions

For comparison, credit-card networks charge 1.5 - 3% per swipe. At a 2% fee, $18 billion would cost users $360 million in fees. International wires are even worse, especially into countries with less sophisticated banking sectors. Sending cash via snail mail might even be cheaper in some cases.

On Base those same transfers cost < $0.01 each. The total network fees for processing 300 million transactions: roughly $3 million. That’s a 99% savings, settled instantly, 24/7, anywhere.

Solving a real problem

When someone in Tanzania can get paid in minutes—without a 10% remittance haircut or a three-day wait—the impact is tangible. When a Turkish family can park savings in digital dollars during a currency crisis, that’s life-changing.

This is what the heatmap below shows: each pixel is a block, shaded by sub-$500 transfer volume of USDC on Base, starting from August 2023 and going up to the present (June 2025). This is just a single coin on a single network but the adoption arc is unmistakeable.

Lately, I’ve been spending less time on X/Twitter and more time heads down, trying to make public goods funding work better. When I poke my head up, the sentiment seems to have gotten more negative, especially toward Retro Funding, and increasingly toward the whole idea of public goods funding in crypto.

Criticism is good. I’ll talk all day about the immaturity of the mechanisms or the fragility of governance. I even miss the days when people earnestly debated what is and isn’t a “public good.”

What’s frustrating is how intellectually lazy so much of the bearish commentary has become.

There are three common critiques I see over and over. They all miss the point.

1. “X is better than Y, but Y got more, therefore the whole system is broken.”

This is bias masquerading as principle.

Every Retro round publishes its full scoring equation and raw datasets on GitHub. If you think the current formula overweights developer history or underweights utility, great. Open an issue. Fork the coefficients. Publish your own analysis.

Pointing to an anecdote isn’t analysis. It’s like saying the scale is broken because you feel lighter than your friend.

Yes, there will always be noise. Yes, there will be Type II errors. That’s the cost of using an open filter. The way to improve it is by proposing better designs, not arguing from vibes.

2. “So-and-so left governance, therefore the whole system is broken.”

This confuses star power with governance power.

Delegates churn. Contributors burn out. Politics get messy. That’s life. What matters is whether there’s enough continuity and commitment from the people doing the work.

If your trusted delegate or thought leader steps back, the adult move is not to rage-quit. It’s to support the next rising contributors and give them room to find their voice.

3. “This decision was made the wrong way, therefore the whole system is broken.”

People love to complain that consensus governance is slow. They also love to complain when hard decisions are made without a vote.

Yes, process matters. But what matters just as much is the impact of the decisions.

Did dropping “PGF” from the name dilute the public goods mandate? Show the budget allocation before and after.

Did a voting change skew outcomes? Point to the data.

Governance doesn’t evolve through outrage tweets. It evolves through analysis, iteration, and amendments backed by evidence.

If you think something’s broken, show receipts.

So what's the point?

The right question isn’t “Did the results match my priors?”

It’s: Are we laying better rails each season?

Especially in a down market, the easy move would be to slash budgets and fund only “core” infra. But Optimism keeps choosing the harder path: running a live experiment in how to allocate protocol revenue to the people who had the most meaningful impact, direct and indirect.

That choice deserves respect.

Doing the hard thing means mistakes. It means tension. It means testing assumptions, measuring impact, and iterating in public.

That’s the whole point. Retroactive public goods funding isn’t a static mechanism. It’s a rare, live experiment in economic design—one of the only ones still running, still adapting, still trying.

You can debate the models. You can audit the process. You can propose changes.

But if your reaction to a single funding round is to declare the whole thing a failure, you’re not helping - you’re heckling from the cheap seats.

This space doesn’t need more quick takes. It needs more people in the arena.

Last round, voters were tasked with comparing the contributions of more than 500 projects, from underlying infrastructure like Geth to pop-up cities like Zuzalu, and then constructing a ballot that assigned a specific OP reward to each project based on its perceived impact.

This round, voters will be comparing just 16 impact metrics – and using their ballots to construct a weighting function that can be applied consistently to the roughly 200 projects in the round. The long-tail has also been truncated by applying a series of programmatic eligibility checks, removing 200+ projects from voting contention.

This post serves mainly as a brain dump on the work our three person team at Open Source Observer did over the past few months to help organize data about projects and prepare Optimism badgeholders for voting.

Here’s what’s included:

• General reflections

• Where the metrics come from

• Critical design choices

• How the metrics evolved

• FAQs

We finalized the metrics at 18:00 UTC on 2024-06-26. Getting to that point was a tremendous lift – the result of many, many contributors beyond the OSO team.

We’re grateful to the teams at Agora, Gitcoin/West, and CharmVerse who worked closely with the Optimism Foundation to build the voting, sign-up, and review platforms; to our data partners including GoldSky, Passport, and Karma3, who provided foundational datasets as a public good; to the OP Labs data team who helped us build good models on top of all that data (and never tired of our ELI5 questions); to Simona Pop for facilitating discussions about the metrics and to the numerous badgeholders who participated and provided thoughtful feedback throughout the design process; to the reviewers who rose to the challenge of enforcing eligibility criteria and resolving every last edge case; and to the onchain builders who showed up, often in pull requests (and sometimes in my DMs too), to help us correctly catalog their work artifacts. Thank you.

I was searching for an eloquent way of describing this whole process, and came across this quote from Jesse Pollak on the gov forum earlier this week. Although he was referring to the profit side of the “impact = profit” equation, I think it applies just as well to the impact side:

“This is the hard work of incrementally building new governance systems that work better than anything our world has seen before.”

Regardless of how the round plays out, RF4 will have accomplished at least one great thing: it will have elevated the debate to what forms of impact matter most, where that impact can be observed, and who deserves to claim it.

This is what governance is all about.

The models that we shipped for RF4 are by no means perfect but we do think they are useful. They are a step forward towards creating a more level playing field and giving voters a more direct mechanism to vote their values.

For instance, there has been a lot of debate over these last 6 months about the impact of meme coins and whether they are good or bad for crypto adoption. In RF4, we have both meme coins and foundational protocols in the same arena. Now we can critically compare which ones attract and retain more users, generate more blockspace demand, are most used by Optimism badgeholders, and so on. This is the potential of metrics-based voting.

But there will also be lots to criticize and learn from.

If the metrics are correct, no one will say anything. If there is something off or missing from the data, people will speak up. It’s nerve-wracking being close to the process, but as Jesse said this is how we incrementally build better systems.

Zooming out, the true test is not whether the metrics attain 99% accuracy but whether this experiment gets Optimism closer to optimal retro funding. Although we won’t have the ability to compare the allocations we get from RF4 against what would have happened in a round that was run the same way as RF3, or that had 1500 projects in it, we will be able to compare the performance of different portfolios of projects over time. We can compare the projects that were accepted into the round to the ones that weren’t – and to the ones that didn’t apply. We can analyze the impact of deploying funding against specific metrics.

One of the most important jobs for governance is to continuously critique and tweak the grants flywheel over each successive round, bringing the collective closer to optimal allocation.

Now let’s get into the data.

At Open Source Observer, we built a first-of-its-kind data pipeline for the Superchain: not only the data but also all source code, query logic, and underlying infrastructure is publicly available for use. We aren’t aware of any other fully open data pipelines of this size or complexity built this way.

You can check out the docs for how to get or build on top of the data here. We also published a companion blog post last month that explains each of the impact metrics in detail.

In the case of RF4, there are four key sources of data:

• Unified events model for the Superchain

• Tagged project address registry

• Contract discovery and attribution graph

• Trusted user model

There previously didn’t exist a unified transaction + trace model for the Superchain. Dune, for example, currently includes Base, Optimism mainnet, and Zora chains – but not Frax, Metal, or Mode.

With data generously provided by GoldSky, Open Source Observer built a unified Superchain event model which anyone can access directly and do whatever they want with. Although the model contains all Superchain transactions and traces, it does not have logs in it (yet).

A unified events model means you can write a query like this:

select *
from `opensource-observer.oso.int_events`
where
 event_source in (‘BASE’, ‘OPTIMISM’, ‘FRAX’, ‘METAL’, ‘MODE’, ZORA’)
 and event_type = ‘CONTRACT_INVOCATION_DAILY_COUNT’

And generate a graph that looks like this:

You can also do the same thing for GitHub and other types of events.

select *
from `opensource-observer.oso.int_events`
where 
 event_source = ‘GITHUB’
 and event_type = ‘PULL_REQUEST_MERGED’    

We quietly released our unified events model last month and already have a number of teams building on top of it. As new OP stack chains come online, this unified events model should prove even more helpful.

Another foundational building block is a registry we maintain called OSS Directory. It is a public repository of projects and their associated GitHub repos, NPM packages, deployers, contracts, and other open source artifacts, with a strict schema and validation logic to ensure consistency.

Every project that applied for Retro Funding (and met eligibility criteria) is included in OSS Directory.

OSS Directory has one strict rule: an artifact can only belong to one project at a time. This means that a blockchain address or a repo cannot be included in multiple projects. I won’t get into all the nuances here, but there was considerable work mapping every relevant artifact to the appropriate project and resolving collisions. Many projects also made their own updates via pull request.

You can get the data by cloning the repo, API, NPM or Python libraries.

In the first version of OSS Directory, we enumerated every contract deployment as well as the root deployer, if it was owned by the same project. This quickly became unwieldy and impractical to maintain, as new contracts are being deployed all the time.

While we still maintain the legacy artifacts that were added in this way, we’ve moved to a more scalable method of contract discovery. If a project owns its deployer and gives it the any_evm tag, then we monitor every EVM chain for deployments from that address. If a project deploys a factory, then we also associate every contract deployed by that factory with the project that owns the factory. Chain-specific deployers or factories can also be enumerated in a similar fashion, and we discovered everything downstream from them on just that chain.

There are several notable exceptions, for instance, contracts deployed using a create2 factory are not credited to the deployer of the create2 contract.

In general though, a project owns everything downstream of its artifacts in OSS Directory. Thus, from the 2240 contracts that were verified through the RF4 sign-up process, we “discovered” 376,000 downstream contracts. These include everything from smart contract wallets created by Biconomy and Daimo, to NFTs minted on platforms like Zora and Sound, to perps on Kwenta and pairs on Aerodrome.

You can see all of the discovered contracts here.

A "trusted user" represents an address linked to an account that meets a certain threshold of reputation.

This metric aggregates reputation data from multiple platforms (Farcaster, Passport, EigenTrust by Karma3Labs), the Optimist NFT collection, and the OP Labs data team.

In order to be consider a trusted user, an address had to meet at least two of the following requirements as of 2024-05-21:

• Have a Farcaster ID of 20939

• Have a Passport score of 20 points or higher

• Have a Karma3Labs EigenTrust GlobalRank in the top 42,000 of Farcaster users

• Hold an Optimist NFT in their wallet

• Qualify for at least two (out of four) Optimism airdrops.

A total of 83K addresses met these requirements. A complete list is available as a CSV file here.

The following design principles guided the development and evolution of impact metrics.

• Verifiability: Metrics should be based on public data that can be independently verified. They should not rely on proprietary data sources or private APIs.

• Reproducibility: Metrics should be easy to reproduce, simulate, and audit to ensure they are achieving the intended results. They should not have a "black box" element that makes them difficult to understand or replicate.

• Consistency: Metrics should be consistent across projects and artifacts. They should be calculated using the same methodology and data sources to ensure that they are comparable.

• Completeness: Metrics should be comprehensive and cover all projects and artifacts in the OSO database that fulfill basic requirements. They should not be highly sector-specific (eg, only relevant to Defi or NFT projects)

• Simplicity: Metrics should have business logic that is easy to understand. They should not require a deep understanding of the underlying data or complex statistical methods to interpret.

Given limited time and bandwidth, it was impossible to implement and test every good idea we received. We also set an explicit goal at the start of the round of choosing the best 15-20 metrics.

The round had very explicit eligibility criteria as well as impact attribution rules. They were determined at the start of the process by the Foundation, turned into automatic checks that we ran when projects applied, and vetted closely by the team of badgeholder reviewers.

To be eligible for RF4, a project had to:

• Deploy its own contracts on the Superchain (not via another project’s factory)

• Have its first transaction on the Superchain before 2024-04-01

• Have at least 10 days of onchain activity

• Have at least 420 unique addresses initiating transactions with contracts they own

All of these checks were applied to a tight time interval of 2024-01-01 to 2024-05-01. There were over 200 projects that applied and did not meet these requirements.

Some of the most common reasons for otherwise strong projects failing to meet eligibility criteria included:

• They were initiating transactions on behalf of users (eg, the user was the to address in the transaction)

• They were using factory contracts deployed by other projects (eg, minting platforms like Zora or Sound)

• They work by enabling their users to deploy their own contracts without interacting with a factory (eg, JokeRace)

• They were built on primitives that made it impossible to trace user interactions with the data available for the round or without employing some form of project- or use case-specific analysis on top of that data (eg, interactions via Farcaster frames or certain types of account abstraction projects)

Leveraging impact metrics requires the round to have a standardized model for measuring and attributing impact. Many of the above cases are from highly impactful projects that unfortunately were not a good fit for the specific requirements of this round. These cases were examined very closely by OSO and the review team, and many provide lessons for future rounds.

There were two exceptions made to the business logic above.

Projects interacting with the 4337 EntryPoint contracts were given credit for transactions and smart contract wallet addresses that were directly linked to contracts they owned, although the gas associated with such interactions was still attributed to the team that deployed the 4337s contracts. This (positively) affected metrics for a handful of account abstraction projects, including Beam, Biconomy, and Daimo. Unfortunately, projects that were one step further along the value chain, ie, that interacted with popular account abstraction operators like Biconomy and Pimlico, were not captured by the metrics.

Account abstraction is an extremely important growth vector for the Superchain. However, we can only reward what we can measure and verify. We need better data standards and public datasets for 4337 related contributions. These learnings should be taken to heart and hopefully improved upon in future rounds.

The other exception was for transactions made to EOA bridges. These were treated like interactions with a standard contract.

Another key design choice was the “open source software multiplier”. In badgeholder surveys, there was a strong desire to reward projects that are open source and permissively licensed. As result, an is_oss criterion was created for projects through a combination of automated checks and manual review by the Foundation.

The receive an open source badge, projects had to:

• Include the relevant GitHub repo(s) that contain their source code in their application;

• Have licenses that meet the requirements of the Open Source Initiative as a license.md or license.txt file in the root directory of their repo(s);

• Have their first public commit before 2024-05-01 (if commits were private up until the RF4 window, then they would not qualify for the open source badge). This was checked via gharchive.org.

File-specific licenses were not considered. Ambiguous cases were resolved manually. In total, 95 out of 230 eligible projects received an open source badge.

You can view a spreadsheet of the license checks here.

There were many excellent suggestions for impact metrics leading up to the round.

In the end, we arrived at a hopefully well-balanced set of 16 metrics. Once again, you can see the full details on the metrics from our companion post here.

We expect even more recommendations to emerge now that voting is open.

The governance forum includes a lengthy post detailing the full process of arriving at a distilled set of impact metrics together with badgeholders.

There was an initial survey that badgeholders took in April, before the start of the round, to gauge community perspectives on qualitative and quantitative measurement approaches and gathering input on a potential first draft list of metrics.

Building on the survey insights, Simona Pop facilitated a workshop on May 7th that enabled badgeholders to provide more in-depth feedback on impact metrics. We also took a first pass at selecting the most meaningful metrics grouped around:

• Network growth: quantifying raw, high-level economic impact across the network in the form of blockspace demand.

• Network quality: evaluating the trustworthiness and integrity of interactions on the network, not just sheer volume.

• User growth: measuring new, active and consistent participation in the network.

• User quality: assessing the value and consistency of user contributions, not just their numbers.

Following the workshop discussions, we at OSO refined the initial metrics and created new ones based on feedback. We then sent out another survey to get a pulse check on the refined metrics.

Much of the feedback at this stage focused on improving the “Trusted User Model”. OSO implemented these recommendations and released a final version of the Trusted User Model shortly after the application period ended.

At the same time, the Agora and Gitcoin/West teams released a test version of the voting interface that included the proposed impact metrics but showed dummy data about projects. Badgeholders got the chance to test out the metrics through an interface that simulates IRL voting and submit commits directly in the UI about each metric.

In the last week before voting opened, the feedback from user testing was incorporated into the final version of the metrics.

All in all, it was a highly iterative design process.

While the list of projects was getting finalized by reviewers and the Foundation, the OSO team worked to stress-test the metrics from every angle.

The primary focus was ensuring that all eligible contract interactiond were attributed appropriately and not double counted. We published a list of all contracts by project here and encourage you to check our work.

We also sanity checked the metrics for as many projects as time permitted, comparing the results we saw against block explorers and Dune dashboards.

One observation that surprised us was that some of the projects on Mode had very high gas contributions. Apparently, this is the result of a bug in MetaMask that had a higher default gas setting for OP chains for a period of time.

From a network growth perspective, gas is gas, so we haven’t applied any normalization to gas prices. Fortunately, badgeholders who are concerned about this have 15 other metrics to choose from.

As a badgeholder myself, my hope now that the metrics are locked in is to leave the proverbial sausage-making factory and start looking at what the metrics tell us about the projects in the round.

I’ve included a few data visualizations performed on top of the metrics below.

RF4 represents an experiment strongly on the “objective” (as opposed to “subjective”) end of the impact evaluation spectrum. In contrast, RF3 was probably closer to the other extreme.

Any round that leverages impact metrics needs to have standardized models for measuring and attributing impact. They shouldn’t be overfitted to specific types of projects or domains. (In such cases, a standalone round just for those types of projects might be a better fit.)

Moving forward, there should be more efforts to verify and measure subjective forms of impact, and get that data into public databases that are easy to compose with. Of course, we’d love to include as many of these efforts as possible as datasets on OSO. Please reach out if you have ideas. We’re currently working on developer docs to make connecting new datasets as seamless as possible.

We use the same underlying transaction and trace data as Dune. Assuming that you are looking at the same contract transaction activity across the same time interval (2023-10-01 to 2024-05-31), then the results should always be the same, or at least within a small margin of error due to time zone differences, rounding, etc. There may also be differences in how interactions that come from safes and other smart contract wallets are handled.

The more likely explanation is that you are either looking at a different set of contracts or attributing impact in a different way than we have for this round. For example, with the exception of 4337-related transactions, we only consider users who initiate transactions (ie, from addresses). We don’t consider to addresses users. We currently don’t have access to logs and, as a design requirement, can’t implement any custom, project- or use case-specific business logic.

If you want to do your own comparisons, you can grab any set of contracts assigned to projects from here and run it against any of the queries included here.

If you notice a significant difference, please reach out and we can investigate. We probably got forwarded at least 20 versions of this question from projects during eligibility checks.

The Trusted Users Onboarded metric is one of the more complex indicators used in the round.

First, the user’s address must be on the trusted address list. Second, the user must have had their first interaction anywhere on the Superchain at some point within the RF4 window. Only 26K addresses meet these two criteria. Finally, the user must have interacted with your project within the first 30 days of their being active on the Superchain. The user address is the from address and the project address is the to address.

Unfortunately, users onboarded via smart contract addresses will likely not be considered in this metric unless they took other actions to achieve trusted user status. This metric also does not count users onboarded as the to address on a transaction; the user must appear as a from address.

Any successful transaction that you see in a block explorer is considered. Gas is also considered for failed transactions (a very small percentage of overall transactions).

Internal transactions are only relevant for 4337 activity with the two canonical EntryPoint contracts.

All gas paid by projects interacting with EntryPoint contracts used for account abstraction was credited to the developers who worked on ERC 4337. Fun fact: this was the top contributor to gas fees in the round (8.55%).

However, projects interacting with the 4337 EntryPoint contracts were given credit for transactions and smart contract wallet addresses that were directly linked to contracts they owned. Specifically, they were credited with a transaction whenever a contract they owned appeared in the trace data of a successful EntryPoint call. The smart contract wallets associated with those transactions were also counted towards their address-related metrics. This (positively) affected metrics for a handful of account abstraction projects, including Beam, Biconomy, and Daimo. We recommend Kofi’s excellent registry of 4337 Operators to learn more about these actors.

Unfortunately, projects that are one step further along the value chain, ie, that interacted with popular account abstraction operators like Biconomy and Pimlico, or that built on top of others’ smart contract wallet account factories, were not captured by the metrics.

If you’re interested in working on data and attribution standards for 4337 interactions, please reach out.

In order to receive an open source badge, projects had to:

• Include the relevant GitHub repo(s) that contain their source code in their application;

• Have licenses that meet the requirements of the Open Source Initiative as a license.md or license.txt file in the root directory of their repo(s);

• Have their first public commit before 2024-05-01 (if commits were private up until the RF4 window, then they would not qualify for the open source badge). This was checked via gharchive.org.

File-specific licenses were not considered.

In cases where projects did not check the “contains open source contracts” box in the application, we looked at all of the repos in their GitHub org space that contained Solidity.

Further questions about this criterion should be addressed to Jonas at the Optimism Foundation.

Here’s a list of relevant resources maintained by OSO:

• Docs on how to directly query or integrate with OSO data: https://docs.opensource.observer/docs/integrate/

• Catalog (and compiled query logic) of all OSO models: https://models.opensource.observer/#!/model/model.opensource_observer.rf4_impact_metrics_by_project

• Interactive visual of the complete data pipeline leading up to impact metrics: https://models.opensource.observer/#!/model/model.opensource_observer.rf4_impact_metrics_by_project?g_v=1&g_i=%2Brf4_impact_metrics_by_project%2B

• Tagged project artifacts: https://github.com/opensource-observer/oss-directory

• Collection of projects included in RF4: https://github.com/opensource-observer/oss-directory/blob/main/data/collections/op-retrofunding-4.yaml

• Dumps of trusted addresses and contract attribution: https://github.com/opensource-observer/insights/tree/main/analysis/optimism/retrofunding4/data

• CSV version of impact metrics: https://github.com/opensource-observer/insights/blob/main/analysis/optimism/retrofunding4/data/op_rf4_impact_metrics_by_project.csv

This post is inspired by the work and thought leadership of organizations explicitly mentioned (Gitcoin, Optimism, Drips, Superfluid, Hypercerts, etc) as well as various conversations with Juan Benet and Raymond Cheng regarding the features of network capital vs private capital.

Gitcoin visualized this concept of nested scopes nicely in a blog post in 2021. The original post described a stack of impact funding mechanisms, initially concentrated in the inner circle (“crypto”), spilling over to the next circle (“OSS”), and eventually eating the world.

It’s a good way of saying: Start by solving problems close to home and scale from there.

Optimism has also used a similar visual in explaining its vision for retroactive public goods funding.

Optimism is within Ethereum. Ethereum is contained within “all internet public goods”. And “all internet public goods” is contained within “the globe’s public goods”. Each of the outer domains is a superset of the domains inside of it.

Here’s my generalized version of the four concentric circles meme.

Even though I personally may spend zero time thinking about biodiversity in the deep sea or noise pollution in Kolkata, there are many people who definitely care about those things. Simply becoming aware of something often moves it from the “all the things” to the “things that I hope other people care about” circle.

We can usually do a reasonable job evaluating things we are close to on a day-to-day basis. This is our inner circle or the things we definitely care about.

In an organization, one’s inner circle might include your teammates, projects you work with closely, tools you use regularly, etc.

We can also evaluate some (but probably not all) things that are one degree upstream or downstream from our day-to-day circle. These are things we sometimes care about.

In the case of a software package, upstream might be your dependencies and downstream might the projects that depend on your package. In the case of an educational course, upstream might include valuable curricula or resources that influenced the course, and downstream might include students who recommend the course to their friends.

Both software developers and educators can look even further upstream to research, to the institutions that stewarded that research, and so on. Now we are in the realm of caring about all of the things.

However, most reasonable people stop caring deeply about any of the things at this point. Once we go beyond one degree of separation, it gets murky. These are things we hope other people care about.

While it may be true that everything in our inner circle depends on the outer circles remaining well-funded, it’s hard to justify contributing more than one’s “fair share” (however one might attempt to calculate this) to things that are more than one circle away. There are good reasons for this.

First of all, it’s hard to triage within large domains. A category like “all internet public goods” is sufficiently broad that, if you squint, you can make the case for pretty much anything fitting inside it and deserving funding.

Second, it’s hard to motivate stakeholders to care about funding things outside their proximate circles because the impact is so diffuse. I’d rather fund a whole person on a team I know than a faceless fraction of a person on a team I don’t know.

Finally, there’s no immediate consequence to not funding these things - assuming, of course, that everyone else continues to fund them and doesn’t defect.

Thus, we arrive at the classic free rider problem.

Apart from governments, which have the ability to print money, collect taxes, and issue bonds to pay for long-term public goods projects, we as a society don’t have good mechanisms for funding things outside of our most immediate circles. Most capital is routed to things with shorter-term returns and more proximate impact.

One way of solving this is to have people focus on funding things that are close to them (i.e., things that they can assess personally) AND to build in mechanisms for continually pushing some portion of funding outward to the edges.

Incidentally, this is how private capital flows. There are some features of private capital we should try to emulate.

There’s a model for funding hard tech with 5-10+ year paybacks: it’s called venture capital. Sure, in any given year, the magnitude of funding that goes to projects with long time horizons is influenced more by interest rates than by terminal values. But VC is a proven model in the sense that it’s been able to attract and deploy trillions of dollars over the past several decades.

The model works in no small part because venture capital (and other sources of investment capital) are composable and easy to fractionalize.

By composable, I mean you can receive VC funding and also have an IPO, get a bank loan, issue bonds, raise capital through more exotic mechanisms, etc. In fact, you’re expected to. All of these funding mechanisms are interoperable.

These mechanisms compose well because there are explicit commitments about who owns what and how cash gets distributed under different scenarios. Indeed, most companies utilize a range of financing instruments during their lifetime.

Investment capital is also easy to fractionalize. Many individuals pay into the same pension fund. Many pension funds (and other investors) LP into the same VC. Many VCs invest into the same company. All of these fractioning events happen upstream of the company and its day-to-day concerns.

These features make private capital highly effective at flowing across a complex network graph. If a VC-backed company has a liquidity event (IPO, acquisition, etc), the returns are distributed efficiently between the company and its VCs, the VC and its LPs, the pension fund and its retirees, even from the retirees to their children.

This is NOT how funding flows across networks of public goods. Instead of a large patchwork of irrigation channels, we have a relatively small number of massive water towers (governments, major foundations, high net worth individuals, etc).

To be clear, I am not advocating for VC funding for public goods per se. I am only pointing out two important features of private capital that don’t have an equivalent in public capital.

Optimism recently announced new plans for retro funding in their ecosystem.

In the last round of Optimism’s retro funding, there was a very wide aperture of things that could be funded. For the foreseeable future, the scope will be much narrower, targeted on the more proximate upstream and downstream links in their value chain.

It should be no surprise that the feedback has been mixed about these changes. Many projects that were in scope historically are now outside the scope of upcoming rounds.

The first of the newly announced rounds is earmarking 10 million tokens for “onchain builders”. Onchain builders received a disproportionately small share of funding during Round 3 - only about 1.5 million of the total 30 million that was up for grabs. What would these projects do with 2-5X times the retro funding?

One thing they could do is put some of the tokens into their own retro funding or grants rounds.

Concretely speaking, if Optimism funded DeFi apps that drive network usage, then those apps could fund the frontends, portfolio trackers, etc that enable whatever impact those apps care about.

If Optimism funded dependencies that are core to the OP stack, then those teams could fund their own dependencies, research contributions, etc.

What if projects take the retro funding they feel they deserve and recycle the rest?

This is already happening in various forms. Ethereum Attestation Service now has a fellowship program for teams building on top of its protocol. Pokt just announced its own retro funding round, rolling all of the tokens it received from Optimism (and Arbitrum) into the round. Even Kiwi News, a below-median recipient in Round 3, has implemented its own version of retro funding for community contributions.

Meanwhile, Degen Chain has pioneered an even wilder concept of giving community members token allocations that they have to give away in the form of “tips” to other community members.

All of these experiments are routing public goods funding from central pools (like the OP or Degen treasury) to the edges, expanding their circle of influence.

The next step is to start making these commitments explicit and verifiable.

One way of doing this might be to have projects determine a floor value and a percentage above the floor that they’d be willing to put into their own funding pool. For instance, maybe my floor value is 50 tokens and my percentage above the floor is 20%. If I receive a total of 100 tokens, then I would allocate 10 tokens (20% of the 50 tokens above my floor value) to funding the edges of my network. If I only receive 40 tokens, then I keep all 40.

(FWIW, my project did something like this as well during the last round of Optimism funding.)

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

In addition to pushing more funding to the edges, this would also serve a critical function of helping establish a cost base for public goods projects. Over the long run, the message to projects that continually receive less than expectations is that they are mis-pricing their work or its undervalued by the ecosystem they’re getting funding from.

Projects that have surpluses will be evaluated in subsequent rounds not just for their own impact but for the broader impact they create by being a good capital allocator. Projects that don’t want the overhead of running their own grants program should have options for parking that surplus in other productive places, like the Gitcoin matching pool, Protocol Guild, or maybe even burning it!

In my view, the two values determined by projects ahead of receiving their funding should remain a secret. If a project receives 100 and gives 10 away, no one else should know whether their values were (50, 20%) or (90, 100%).

The final step is to plug these systems into each other.

The examples of EAS, Pokt, and Kiwi News are encouraging, but they all require standing up new programs, then claiming / swapping / transferring grant tokens to new wallets, and eventually transferring funds to a new suite of recipients.

Protocols like Drips, Allo, Superfluid, and Hypercerts provide underlying infrastructure for more composable grant flows - now we need to connect the pipes, like this pilot from Geo Web.

https://twitter.com/thegeoweb/status/1760320354394771577

In crypto, we are still at the stage where we are experimenting with lots of mechanisms for deciding what to fund and allocating funds. And public goods funding rails are still an order of magnitude less sophisticated / composable / battle-tested than DeFi’s.

For any of this to scale beyond the experimentation stage, we need to solve for two things:

1. Measurement not only that this stuff works but that it works better than legacy models of public goods funding (see this post on why this is an important problem for people to work on and this post with some longitudinal analysis on Gitcoin’s impact); and

2. Explicit commitments for how “profit” or surplus funding flows to outer circles.

In venture capital, there is always an investor behind the investor - and eventually it’s your grandmother (or, more aptly, all of our grandmothers). Each one of these investors is incentive-aligned to allocate capital effectively in order to be entrusted with a large share of capital to allocate in the future.

For public goods, there is always a set of proximate actors, both upstream and downstream of your work, that you depend on. But there is currently no commitment to sharing surplus back with these entities. Until such commitments become the norm, it will be difficult to scale public goods funding beyond our immediate circles.

I don’t think it’s enough to pledge "when we get to a certain size, then we will fund those things”. It’s too easy to shift the goalposts. Rather, these commitments need to be built in as soon as possible, incorporated as primitives in the funding mechanisms and grants programs that get built.

I don’t think it’s reasonable to expect a few whale treasuries to fund everything either. That’s the water tower model we currently have in traditional governments and large foundations.

But, the more we make explicit commitments to funding our dependencies while we’re still small, the more we signal that there is indeed a marketplace for public goods, we grow the TAM, and we shift the incentive landscape.

Only then will we have something that’s truly worth exporting, something that will gather its own momentum and create the “pluralistic, civilizational scale infrastructure for funding public goods” of our dreams.

But then, a few days ago, I was nerd-sniped by this dataset of anonymized voting results. I vowed to only take a quick look at the end of my workday. Guess how well that went…

The dataset shows how 21,813 votes were cast across 643 projects by 100+ independent voters (“badgeholders”). Each vote is essentially a project : number-of-tokens pairing that is intended to signal how much profit a badgeholder thinks a project deserves in relation to its impact on the Optimism Collective. It is not possible to see how any individual voter voted, only the distribution of votes received by each project.

As I wrote about previously, the voting rules matter – a lot. I have no desire to open Pandora’s box and look for signs of rule bending, collusion, or conflicts of interest. The OP Labs team already did its own digging. I am not going to revisit the topic of whether certain types of projects were under- or over-valued by the voting mechanism; you can find some of my observations on that topic here. I am also not going to simulate the impact of different scoring functions; Amy and I posted some preliminary work on that topic right after the round ended.

In this post, I just want to let the data speak for itself and share a few high level observations about the scoring algorithm and where voters reveal strong preferences towards projects.

Here’s the tl;dr-

1. Badgeholders cast more votes than they probably should have. The average badgeholder voted on 200+ projects, but the highest density of votes was in the 1.5 - 25K range. This behavior likely shifted the median to the left for some higher impact projects.

2. There were 33 projects that were pretty divisive. These projects had a lot of votes at the extremes of the distribution, implying badgeholders have strong diverging views about how much funding they deserve.

3. The “zero vote” was a powerful weapon. Each vote of 0 OP correlated with a reduction of 2K OP from a project’s final score – and in one case a reduction of 35K OP.

FYI, this post is light on text and heavy on dataviz. As always, you can fork my work and take the analysis in other directions.

This post won’t make sense unless you understand some of the basics of Optimism’s voting rules for RetroPGF3.

Each badgeholder was given 30M tokens to allocate across as many projects as she liked. The max vote size for any one project was 5M tokens. A badgeholder could also vote 0 for a project she didn’t like.

The anonymized voting results show there were 788 votes of 0 and 61 votes of 5M. The average badgeholder voted for ~200 projects (!) and expressed no opinion on the remainder.

The project’s eventual token distribution was a function of its median vote amount. In case you’re rusty on your stats, the use of medians means that a voting result of (0,1,5000000) is equivalent to (1, 1, 1, 1, 1, 5000000) or (0, 2). A vote of 0 has potential to shift a project’s median to the left – and is therefore a pretty powerful move.

In order to qualify for a payout, a project needed to receive at least 17 votes and a median of more than 1500. There were 142 projects that did not meet these requirements.

You can find more details about the results here.

The histogram below shows the composition of the 20K+ votes cast, grouped by the amount of OP they awarded to a project. Nearly ⅓ of votes were in the 1500 to 25K OP range.

These relatively small votes of 1500 to 25K helped borderline projects meet quorum requirements, but they also had potential to bring down the median of higher impact projects.

Modular Crypto is an example of a project that was quite popular – it received 50 votes, including 18 over 25K - but its median was dragged down by 31 small votes (and one zero).

By comparison, Aestus Relay was much less popular – it only received 22 votes – but it benefited from not having a long tail of small votes.

Building on the type of analysis shown above, I plotted the projects along two axes:

• How well-known a project is, ie, how many total votes it received. A project was “more well-known” if it received at least 36 total votes.

• How much variance a project had in its individual votes. A project had “high variance” if it had a coefficient of variation of at least 1.35 (the ratio of its standard deviation to its mean).

Then I assigned each project into a category based on its quadrant in the 2x2 below. (Each dot represents a project.) Each category holds roughly 100 projects in it.

In general, projects that had less variance in their vote distribution had a higher median. More well-known projects also had a higher median.

These patterns are shown in the plot below. (Each dot still represents a project.) Unsurprisingly, the best category to be in is “lower variance, more well-known”.

A “divisive” project is one that has a relatively high number of votes at the two extremes of the spectrum, ie, zero and 500K+. For example, Immunefi received 6 votes of 0 OP and 7 votes of 500K OP or more. In total, there were 33 projects that appear to be divisive.

The chart below shows the vote distribution for these projects. (Each dot represents a vote. You can see charts like the one above for the other project categories in the appendix.) The small numbers on the left side of the axis indicate the count of zero votes the project received and the numbers on the right side indicate the count of 500K+ votes. To appear in this chart, a project had to have a least two 0 and at least two 500K+ votes.

The composition of these projects may reveal some of the Collective’s “wedge issues”. A wedge issue is a political or social issue which is controversial or divisive within a usually-united group. In this context, it could be whether a software project has received venture capital or not.

Some projects received a lot of zero votes as shown in the table below. In a few cases (eg, NFTEarth), this prevented the project from receiving any RetroPGF. In most cases, the zeros brought down the project’s median.

In the case of Immunefi, they had a median vote of 130K OP with 6 zeros in their distribution. The graph below shows the distribution of all votes to Immunefi, and the median of 130K.

We can model the impact of each zero on Immunefi’s overall allocation. For instance, with 5 instead of 6 zeros, Immunefi would have had a median vote of 165K OP – a large difference. In other words, the additional zero – their 52nd vote – brought their median down by 35K OP.

Although the drop of 35K was extreme, the impact of zero votes was not distributed equally. The average zero vote cost a project 2K from its final allocation. The chart below shows the incremental impact of every zero vote that was cast.

The figure below shows that zeros were a pretty blunt instrument. A single zero caused Solidity, a very popular project with more than 100 other votes, to lose 35K OP. At the same time, Nación Bankless received 6 zeros (out of 40 total votes) and *only* lost 10K. This kind of unpredictability could be a drawback of using the median vote amount to determine a project’s overall OP award.

As I wrote previously, we can only build a better game by studying whether the rules and player dynamics are having the intended effect. With that in mind, here are some thoughts on where to go from here. I believe many of these points are already being addressed by the Optimism Collective.

1. Badgeholders shouldn’t be voting on this many projects, especially if it’s to signal lukewarm support for a project they don’t know much about.

2. The use of the median led to some counterintuitive results, with voters who “like” a lot of projects reducing the RetroPGF for projects they “love”. It’s worth experimenting with other algorithms that lead to more intuitive voting strategies.

3. Projects that were well-known and didn’t have any haters performed best. To prevent RetroPGF from becoming a Keynesian beauty contest, the Collective should experiment with different round formats, project curation, and ways of surfacing impact metrics in the voting UI.

4. Zero votes, if these continue to be a thing, should probably have a cost associated with them. FWIW, Gitcoin did a fleeting experiment with negative voting.

5. The Collective should identify any wedge issues among badgeholders and seek to mitigate their impact on the voting mechanism. Whether a project has VC funding or not is perhaps the clearest wedge issue, but there are probably others.

I had a lot of fun playing with this dataset and making these exhibits. Below you’ll find the distribution charts from the remaining categories of projects. Again, you can fork my notebook and take this analysis in other directions.

You can find higher resolution versions of these images, including ones sort projects by median vote (not alphabetical), here.

These projects had at least 36 votes and a coefficient of variation below 1.35.

These projects had at least 36 votes and a coefficient of variation more than 1.35.

These projects had less than 36 votes and a coefficient of variation below 1.35.

These projects had less than 36 votes and a coefficient of variation of more than 1.35.

We can learn a lot by plotting and analyzing the distribution patterns of tokens to projects. In domains where the signal is too weak (ie, impact > profit) or too strong (ie, profit > impact), the Collective should be more explicit in shaping the distribution patterns it wants to see and then making tweaks to the RetroPGF process and game design.

In this post we will take a look at:

1. 30,000 foot view: the signals that everyone in crypto should pick up on

2. Box seat view: the signals that badgeholders and engaged community members should pick up on

3. In the arena view: the signals that live players and builders should pick up on

I also want to make sure I don’t bury the lead:

• Less than 20% of the RetroPGF 3 allocation went to projects that directly contribute to sequencer fees.

• Every badgeholder and citizen who wants the best for Optimism probably feels that this allocation level is too low.

• This is not a sustainable trend, given that sequencer fees are the long-term revenue engine for this whole experiment.

Many factors likely contributed to this outcome. In a previous blog post, I discussed how the round’s game dynamics could make it difficult for voters to express their true preferences.

Nevertheless, perfect allocation is an elusive goal. Good governance means quickly spotting and correcting errors. It’s encouraging to see the Collective already taking action on a number of issues and remaining open to feedback.

Now let’s explore the data. (You can explore and fork my analysis here.)

As move into the next phase, these are the signals that everyone in the ecosystem should pick up on.

The OP token price surged immediately after the round closed in early December. Basically, every project ended up getting 2-3x the USD value of what badgeholders thought it deserved during the voting process.

The price increase gives an already highly visible program a huge tailwind. That said, the coincidental market action will make it much harder to interpret the long-term impact of the allocations from this round

The distribution pattern for RetroPGF3 is pretty different than RetroPGF2. It is more of what Owocki would call a peanut butter spread rather than a power law distribution.

With a peanut butter spread, every bite is pretty good, not just the first ones

In both rounds, there were a few standouts all the way to the left of the curve (ie, Protocol Guild). However, in Round 3, there’s a clear top tier of projects that received over 100K OP followed by a long, relatively flat tail of projects after the top 50 that still received meaningful sums of money.

We can zoom in on the distribution below the top 10% of projects and see a lot of clustering at certain levels

In Round 2 (below), we saw a more traditional power law distribution with a steady decay pattern all the way to the end.

In Round 2, the median project received 24K OP, worth around $40-50K at the time. In Round 3, the median project received 45K OP, worth $175K on the day the results were announced. There’s very high upside to taking a bite.

The message many builders in the crypto universe will take away from this distribution is, “I just need to do something related to Optimism and I could earn $100K next round”. This is a massive tailwind in the sense that every talented developer who is not already deeply embedded in an existing ecosystem will be looking at Optimism now. But it will make the work of separating the signal from the noise even more important.

If you want to explore other token allocation simulations, check out this post Amy and I co-authored here. None of our simulations predicted a distribution that was this flat in the middle

Projects with at least some OSS component to their work represented 50% of the applicant pool but 80% of the funding distribution.

This is extraordinary. The median OSS project received over 50K OP.

At Open Source Observer, we made a very strong push to include every project that had at least one open source repo associated with it in our dataset. Most projects included a public GitHub repo in their application, but some didn’t, so we had to track down their repo information manually (or they sent us a PR).

Although we still missed a few, a total of 315 of the 643 projects that applied for RetroPGF 3 had a profile on OSO at the time of voting. Here is the token distribution across those projects

One thing that everyone should be celebrating is that RetroPGF is giving open source software projects a recurring revenue model.

I also suspect that closed source projects did rather poorly in the round. Although we don’t have the data to validate this, as an anecdote, there were at least five well-funded, closed source projects I can point to that failed to meet quorum.

I’d be negligent if I didn’t mention that open vs closed source isn’t a binary distinction. There’s a spectrum of approaches businesses take (eg, some only open source a small portion of their code) and a variety of licensing models. If there’s someone out there who wants to further deep dive on this, here’s a dataset of all the licenses for every repo we indexed during RetroPGF 3.

Despite these nuances, RetroPGF 3 should send a very strong signal to builders that open source is deeply valued

Now let’s apply this same type of distribution analysis to some more specific domains. These are the signals that badgeholders and engaged community members should pick up on.

One of the best places to look for signal is in the public artifacts that projects are leaving behind.

I constructed some MECE (mutually exclusive & collectively exhaustive) category tags for projects based on their work artifacts: GitHub repos, onchain contracts, Dune dashboards, NPM libraries, Substacks, etc. These results imply, for instance, that the Collective currently values NPM libraries more than Substacks. This is a highly imperfect method, as many projects will have impact that is observable in multiple places (eg, both on GitHub and onchain), but it’s a worthwhile starting point.

I also made umbrella tags for “Harder to Measure Contributions” that include educators, IRL events, white hats, governance contributors, and a long tail of other forms of contribution. In most cases, I also tagged whether the category applies to project (group) or individual contributions.

The tags below are only a quick first pass, but they provide some context as to the types of work domains that are more valued by the Collective.

It would be a valuable exercise to have more people in the box seats sketch out what they think the correct distribution metrics should be for these categories / tags.

This is the largest domain both in terms of OP received (over 50% of the total round) and projects. The vast majority of projects with this tag received some funding, and the median project did quite well (50K OP).

Note that OSS projects with onchain contributions on OP Mainnet and/or developer libraries are not included here. This is effectively a bundle of all of the other types of OSS contributions.

Unsurprisingly, the most prominent projects are core infrastructure and other keystones of the Ethereum and OP ecosystems. A few projects like ETH Global probably wouldn’t self-identify as OSS Projects but are nonetheless important players in the OSS space.

I hope talented builders see this and are inspired to become an active contributor or start their own open source project.

I was blown away by how well these projects (all of which have an NPM package) performed. To be honest, this finding gave me goosebumps and made me feel really proud to work in crypto.

https://x.com/carl_cervone/status/1745564803165262155?s=20

The distribution of funding to these projects looks like chunky peanut butter.

This outcome should send a very clear signal to builders: make sure your library has good support for Superchain applications.

On the other hand, the allocations for projects that are generating actual sequencer fees on OP Mainnet were surprisingly low. T

There were numerous Twitter threads pointing out that onchain projects where undervalued by voters. I think the distribution pattern confirms it. Outside the top five or so projects, the distribution is pretty flat and undifferentiated.

Two of the top three projects (DefiLlama and Remix) with contracts on OP Mainnet probably don’t belong in this category since their impact is much more of the general OSS flavor.

In any case, I have a hard time imagining that badgeholders, if presented with the option, would say “let’s give less than 20% of the RetroPGF pool to apps that create demand for blockspace and over 60% to tooling and infrastructure.” This high-level allocation split feels incorrect.

Now let’s look at the other 20% of the funding pool that went towards 300+ non-OSS contributions. Does it make sense to invest that much of the funding pool into these areas? (FWIW, in my own voting strategy, I thought the answer was yes.)

We’ll start with some of the easier categories: Substacks and Dune Wizards.

Both categories have more of a standard distribution pattern, not a power function or a peanut butter spread. It was harder for these contributions to make quorum. There weren’t any outsized favorites either.

Again, remember that these categories are mutually exclusive, so a project with work happening in a public GitHub repo and a Substack would not appear in the distribution above.

It’s also encouraging seeing a cohort of Dune data wizards getting recognized for their contributions.

Maybe one day we’ll see Dune and Substack become contributors to the RetroPGF pool or even stand up their own funding pools!

Other pathways for individuals having impact that is rewarded by the Collective are harder to measure and most likely harder for builders to replicate. The chart below shows the distribution of OP that went to 50+ individual applications for a variety of contribution types.

ZachXBT and Polynya need no introduction and represent the two outliers all the way to the left of the curve. Beyond that, there isn’t a whole lot of signal apart from the fact this is the one category where nearly half of the applicants failed to make quorum.

This isn’t that surprising because this category includes everything from people doing on-the-ground work in a specific region of the world to researchers in niche subject matter areas. My sense is that badgeholders are like fish out of water trying to evaluate these types of contributors holistically.

If these forms of contribution are to be rewarded through RetroPGF, it probably makes sense to stand up mini-rounds with oversight from people who have more context into specific impact domains than the average badgeholder.

Last but not least, we also have projects that had harder to measure contributions. This is a real motley crew. It included software projects like Gitcoin and Rainbow Wallet that had overlapping impact claims (Gitcoin Passport was included in the onchain category and Rainbow Kit was included in the developer libraries category), a few closed-source projects building on Optimism like BasePaint and Layer3, and a few that didn’t include GitHub links in their applications and we missed in our follow-up coverage (eg, ImmuneFi, Conduit … sorry!).

However, the majority of projects in this category are much harder to classify. They include teams of OP contributors like the Optimism Ambassadors and Translators. IRL events like Zuzalu and ETHSafari. A variety of DAOs, NFT communities, Nouns forks. There are some up-and-coming consumer apps that haven’t open sourced. As the British say, it’s a real dog’s breakfast.

A more diligent analyst could probably subdivide these projects into dozens of categories.

However, the thing I care about is separating the signal from the noise. For the average badgeholder, it was very difficult to mine this long tail of projects for hidden gems unless you knew about them already or they showed up in your DMs.

If we want to avoid a popularity or Keynesian beauty contest, we have to do better here. I would argue that rounds of RetroPGF in their current configuration (uncapped project set, capped voter set, undefined metric set) are not a great mechanism for identifying long tail public goods. Better curating or breaking up into smaller rounds “all the other stuff” feels essential for future rounds.

In addition to the incentive for everyone to throw their name in the hat next RetroPGF, there may also be a perverse incentive for individual contributors or factions from within larger projects or DAOs to apply.

If there were a peanut butter spread across every full-time developer in the ecosystem, then you’d see every developer receiving around 28K OP. If the voting mechanisms determined that larger teams had super-linear impact, then a top project with a big team like Protocol Guild would probably be receive well over 1M OP. Instead, the distribution appears to favor smaller teams.

A number of smaller teams received well over 50K OP per active developer whereas none of the medium to larger teams receive anything close to this.

Even if we believe that impact should be evaluated independent of the team size or composition, the Collective most likely doesn’t want to incentivize projects to fractionalize their contributions into separate applications.

This isn’t a new phenomenon; I wrote about the same thing after RetroPGF 2.

As a badgeholder, I used Open Source Observer to experiment with a variety of metrics-driven Lists. (You can see a full list of Lists and a retro on how they performed here.)

The intention was to start identifying a set of broadly applicable impact metrics that give builders a sense of where to focus. If one goal is to generate sequencer revenues, then you’d expect a project generating a lot of sequencer revenues to receive more RetroPGF than one that isn’t. If another goal is to onboard and retain new developers to the ecosystem, then you’d expect a project with high developer growth and low developer churn to perform better than a project run by a single person who has been at it since 2014.

These metrics need not be deterministic, but they should be reasonably predictive.

We called these types of metrics “Impact Vectors”.

An impact vector is a direction of positive impact that projects in the Optimism ecosystem should work towards. More concretely, each vector represents:

• a quantitative impact metric (eg, a project’s contribution to sequencer fees)

• measured over a discrete period of time (eg, the last 6 months)

• normalized across a distribution of relevant projects in the ecosystem (eg, all projects with onchain deployments)

This method explicitly seeks to identify positive outliers, ie, the signal, in an otherwise noisy distribution.

It’s very cool to see some of this thinking taking shape in the form of an impact calculator for future rounds!

In the meantime, we can look at my V1 impact vectors and see how the “excellent” and “exceptional” projects performed relative to their peers. Warning: there a lot of data in this chart.

As brought up early, the impact vector that was least predictive in terms of RetroPGF rewards was onchain activity. Projects that a transaction count of more than 1 standard deviation from the mean (ie, over 200K transactions) received on average 87K OP vs projects that were within 0-1 standard deviations received 83K OP.

In fact, all metrics related to onchain activity were weak predictors of token distributions, with a spread of only 15K OP between “above average” (0-1 stdevs) and “excellent” (>1 stdevs) performers along this vector.

Perhaps badgeholders aren’t active users of these types of apps or think they have already received “profit” from elsewhere in the value chain. But I would expect the next round of RetroPGF to correct for this.

Team size, both in terms of active developers and overall contributors, were lukewarm impact vectors. It’s common for ecosystems to explicitly state that they want to attract new developers, so this observation should be explored more deeply. The trend that contributors on smaller teams tended to receive proportionally more RetroPGF is also relevant here.

However, badgeholders tended to reward projects that had steady, well-established teams more generously than up-and-coming ones.

I would expect this balance to shift over time. Some experimentation is needed, but it should be possible to define vectors that reward projects that onboard new developers who stick around in the ecosystem.

The strongest predictors of RetroPGF distributions for OSS projects were … drum roll please … NPM downloads. You can read our critique of downloads as a metric and a proposal for three better metrics for developer libraries here.

Stars and forks were also pretty strong signals. The chart below shows the average OP reward for excellent and exceptional projects for any given impact vector.

However, it reveals a simple truth that it was easy for badgeholders to achieve consensus on who the well-known OSS projects in the Ethereum and, to a lesser extent, Optimism ecosystems are. And they allocated large token amounts to those projects.

If that’s the intended outcome, great. These are amazing projects. Although we probably don’t need all this governance and complex voting to achieve it.

If it were easy and all we had to do was figure out how to count GitHub stars, then this whole economic and governance experiment wouldn’t matter. But it does matter. And it won’t be easy.

We need to level up the game and find new signals for the players.

That’s the Optimism Collective’s primary objective between now and the start of RetroPGF 4.

If you’re interested in working on this problem directly or helping shape the research dialogue around measuring open source impact, please reach out.

You can explore and fork my analysis here.

This post looks at the psychology of the game during Round 3, identifies mechanics that might have caused us to deviate from our intended strategy, and suggests ways of mitigating such issues in the future.

Disclaimer: I was a voter and had a project in Round 3. I also made a lot of Lists.

It is impractical to thoroughly review more than 100 projects, let alone 600+.

Here’s what Greg did:

https://x.com/gregthegreek/status/1732552831196876816?s=20

Spray and pray is a natural reaction to cognitive overload and limited bandwidth.

However, our focus shouldn't be solely on creating more efficient tools for spraying. A new feature like a CSV upload button would make the work go faster, but it still encourages us to spray.

What we actually need are better ways of designing, iterating, and submitting complete voting strategies.

A voting strategy is a way of testing a hypothesis that funding certain types of projects (X) in the past will result in more desirable outcomes (Y) in the future. We want to use our voting power to incentivize agents to work in areas they know will be rewarded.

There are at least four components to designing a voting strategy:

• Impact Vector: Identifying the type of impact you want to amplify over time.

• Distribution Curve: Determining how flat or skewed the eventual distribution of tokens to projects should be.

• Eligibility Criteria: Establishing parameters to determine which projects qualify.

• Award Function: Creating a formula or rubric to equate impact with profit.

Currently, badgeholders don’t have much scaffolding to build voting strategies. It’s unrealistic to expect badgeholders to do this work from scratch.

The initial step of defining the impact vector is often the most challenging. To assist in this, we should provide badgeholders with comparative choices to help them identify their preferences. Examples could include:

• Focusing on attracting new developers versus enhancing the experience for existing ones.

• Prioritizing virtual community-building efforts versus more in-person events.

• Concentrating on impacts specific to the Superchain as opposed to impacts affecting the entirety of Ethereum.

Performing these kinds of assessments at the beginning or even during the planning stage of the next RetroPGF round would not only aid badgeholders in formulating their voting strategies but also ensure alignment with the broader intents of the Citizen’s House.

Popularity and name recognition are seldom reliable measures of true impact.

When we look for a restaurant on Google or Yelp, we usually don’t want the one with the most reviews. Instead we look for restaurants with a high proportion of detailed five-star ratings. In RetroPGF, the List feature aimed to highlight impactful projects for voters to add to their ballots. However, most Lists showed a conservative distribution of tokens, with little variance between top and median recommendations. This is the equivalent of going onto Yelp and only finding average three-star reviews.

Katie Garcia made a similar point on the forum about low-quality Lists being a drag on the process.

To get stronger opinions, we need to encourage experts to step up and make Lists.

As with any independent review, the expertise, affiliation, and reputation of the List maker is just as important as the List itself. Voters should be able to quickly discern the credibility of a List creator.

While "liking" a List provided some measure of quality, it was unclear how many badgeholders actively utilized this feature. Another problem was that the likes only accrued to the List, not the List maker. Because we could not edit a List, a V2 of the same List started off at zero likes.

Finally, most Lists were generated towards the end of the round, giving the creator very little time to develop a reputation and voters little time to determine if it was useful to their voting strategy.

Experts should be encouraged to play a larger role in reviewing projects and crafting Lists within their areas of expertise. This includes both helping categorize projects effectively at the start of the round and offering ratings across the full quality spectrum.

Experts should be evaluating projects on multiple impact dimensions, not just issuing absolute scores. For example, a List focused on user growth will have different project rankings than one centered on security. It’s common to see product reviews that consider multiple features and then weight those features to arrive at a final score.

Experts need to be placed in a position where they don’t feel pressure to conform to social pressure. The same is true for whisteblowers. It’s hard to combat the herd mentality that forms in large groups with only certain types of people speaking.

In academia, there's an awareness that today's reviewer could become tomorrow's reviewee. To address this awkwardness, academics use blind reviews. The identities of the reviewers are kept hidden from the participants. A double-blind review extends this anonymity further, concealing the identities of both parties involved. For RetroPGF, implementing blind reviews could mean adopting pseudonymous reviews and List creation. A double-blind system, while more complex, could be realized through the use of standardized impact reports. Another possibility is to organize reviewers so that they are grouped in a domain where there’s no potential for conflict of interest.

While expert-driven systems can be criticized as technocratic, Optimism can address these concerns by promoting transparent and replicable project metrics, supporting its community of grassroots analysts (e.g., Numba Nerds), and requiring experts to publish their evaluation criteria along with their recommendations.

The site growthepie played a vital role during the voting period by providing easily accessible and filterable data about projects, such as their presence on ballots/Lists and funding history. This addition, as well as other sites like RetroList, RetroPGFHub, and hopefully our own, Open Source Observer, gave voters more data points to assist with voting.

Across the board, voters demonstrated a strong preference for having data in the loop when voting or coming up with their strategies.

As we saw during the round, the best time to request relevant data from projects is during the application phase. However, while projects submitted numerous links to their contributions and impact metrics, the numbers were all self-reported. The nature of self-reported metrics raises concerns about accuracy and data entry errors.

Moreover, the data was cumbersome to analyze without individually examining each project's page. There was no way of comparing similar metrics about similar projects unless you cleaned the data and did the analysis on your own.

Although some badgeholders are committed to conducting their own research, the process of gathering and synthesizing information from various public sources is time-consuming. Streamlining access to comparable impact metrics would significantly aid in the efficient filtering and ranking of projects.

A better approach than self-reporting would be for projects to directly link all relevant work artifacts, such as GitHub repositories, in their applications. This would enable comparable impact metrics to be surfaced automatically from any source where data integration is possible. After linking their artifacts, perhaps projects could get the option to include different “impact widgets” on their profile to highlight the ones that are most relevant to assessing their project.

Data doesn’t tell the whole story. And not all forms of impact are well-suited to some kind of metrics integration. Those are places where tools for making relative comparisons can really shine.

Another thing we learned from all our “three-star Lists” is how difficult it is to quantify impact in absolute terms. It’s much easier to assess impact in relative terms.

This is what algorithms like pairwise matching are good for. I experimented with the Pairwise app during RetroPGF, but found it difficult given the sheer number of projects and the nature of comparing two projects objectively. A more targeted approach, asking voters to make a more specific comparison, e.g, “do you think Project A or B had more impact on X”, could be more effective.

Another twist on pairwise is to rate a project's recent impact against its past performance. This is reminiscent of the traditional budgeting process of setting this year’s budget in relation to last year’s, only now we’re doing it retroactively and from the vantage point of a community not a CFO.

There’s also setwise comparison, where we analyze how often a project appears in different sets. The most impactful governance project might be the one that appears on a large number of lists independently. Quadratic voting harnesses the power of setwise comparisons. However, effort needs to be taken to prevent sets that are purely based on popularity or name recognition.

In the final 48 hours of the vote, we saw a good example of setwise comparison. Badgeholders made a push to identify borderline projects that needed just a few more votes to meet the quorum.

https://twitter.com/the_ethernaut/status/1732164445197967576?s=20

When looking at a borderline project, the voter just had to make one decision: do I want this project to be in the above or below quorum set.

Yet, as Andrew Coathup noted, this well-intentioned approach might have inadvertently skewed our true preferences:

Badgeholders who "like" a project rather than "love" an impactful project are likely to bring down a project’s median.

In retrospect, it would have been more effective to focus on removing bad apples at the start rather than searching for good apples at the end.

The experience above is just one of numerous examples of how the rules of the game will affect the distribution.

If you give the same voters the same projects, but vary the rules, you’ll almost certainly get different results. It’s not clear which type of curve the Collective wants to design for.

The results from RetroPGF 2 were pretty exponential. The top project received 20 times more tokens than the median project. Voters didn’t seem upset about this outcome. A comparison with RetroPGF 3’s outcomes and the community’s reaction will be insightful, and may surface if there are strong preferences for one form of distribution pattern over another.

Exponential distributions are generally better for tackling complex problems with low odds of success. They channel more resources into fewer, higher impact projects. Conversely, flatter distributions encourage a broader range of teams to pursue more achievable objectives. Both have their place.

The other big distribution question is how meritocratic it is. A meritocratic system would consistently elevate the highest-impact projects to the top of the token distribution, independent of voter identity or the number of competing projects. If the distribution has a long tail, then there will always be a high degree of randomness and variation in it.

The distribution patterns that emerge through repeated games will inevitably affect the mindset of projects and builders who continue to participate. If the model feels like a black box, then the best players will lose the motivation to keep playing.

Given the significance of these outcomes, it’s crucial to simulate and understand the implications of different rule sets before implementing them in upcoming rounds.

There was a lot of debate within the badgeholder group and on Twitter about how a project’s funding history and business model should affect its allocation. Many community members including but not limited to Lefteris had strong views.

https://x.com/LefterisJP/status/1730689350659129804?s=20

Like most political issues, once you dig deeper, you realize there’s a lot of nuance. People’s opinions fall along a spectrum. We can get a sense for where the community is on this spectrum by giving them hypothetical comparisons like the following:

1. Should a ten-person team receive more funding than a two-person team?

2. Does a full-time project deserve more support than a part-time effort or side hustle?

3. Should a team in a higher GDP region receive more funding than one in a lower GDP area?

4. Does the absence of venture capital funding merit more allocation compared to projects with such backing?

5. Should teams with limited financial resources be prioritized over those with substantial funds?

6. Does a team generating no revenue deserve more support than one with recurring revenue?

7. Should projects offering solely public goods receive more funding than those mixing public and non-public goods?

8. Do teams without prior grants merit more support than those frequently receiving grants?

9. Should a project never funded by Optimism be prioritized over one that has received multiple grants?

10. Should a protocol on Optimism with no fees receive more funding than one with fees?

Currently, guidelines state that voters should only consider points 9 and 10. Yet many voters struggle to disregard the other aspects.

To prevent these financial factors from skewing voting, the Collective might need to reevaluate its approach. This type of challenge is another reason why academics use double-blind reviews: the reviewer is forced to only consider the quality of the paper, not how deserving is the team behind the paper.

A potential solution for RetroPGF could involve segregating projects and funding pools. This could alleviate some of the pressure on voters to choose between projects with vastly different funding requirements and access to capital.

While this issue is important, it's regrettable that the focus on reviewing a project's funding sources may have gotten in the way of reviewing its actual impact.

I’ll end with a recap of my recommendations for how Optimism might get better at playing the game both next round and over the long run.

Our primary goal should be to surpass the 'spray and pray' approach. To achieve this, we need to dig deeper into understanding voters' value preferences and let this knowledge shape the game's dynamics. This encompasses everything from the types of impact voters care about to the financial aspects they consider relevant in reviewing projects. We can start by gathering insights from surveys, forum discussions, and post-round retrospectives. However, acquiring more substantial data before and during the round is essential. This data will be instrumental in differentiating between UI/UX challenges (like updating ballots and lists) and game mechanics issues (such as whether voters should review every project). Critically, we should monitor and simulate how closely the actual outcomes align with voters' expectations regarding funding allocation and distribution patterns.

Improving project comparison methods, reducing bias, and encouraging independent thinking are crucial. We must avoid turning this into a popularity contest by empowering domain experts to have greater influence and build their reputation. Since quantifying absolute impact is challenging, we should focus on better understanding relative impacts and making more effective comparisons. To combat herd mentality and the pressure to conform, exploring blind review mechanisms could be beneficial. Having objective data readily available will assist in making informed decisions and identifying both the strongest and weakest projects.

The voting experience should be optimized to support voters in testing and implementing a well-defined strategy. At the end of each round, voters should have a clear understanding of the process and feel confident about their participation and choices. Speaking from personal experience, I am uncertain about my own effectiveness in the game. Despite investing time in identifying worthy projects and avoiding less desirable ones, I'm unsure if I maximized the potential of my top picks. There's a need for a system that helps voters articulate and evaluate their strategies clearly, as this is key to getting better at a repeated game.

This work won’t be easy. But the upside is huge.

✨ An impact vector is a direction of positive impact that projects in the Optimism ecosystem should work towards.

As the L2 space grows more competitive, Optimism needs to maintain its early advantage and ensure it keeps improving the ROI of its grantmaking. Improving ROI means making both the process more efficient for all participants and the allocations more impactful for the ecosystem.

Data is critical for badgeholders to transition from working at the middle of the grants funnel (i.e., reviewing individual projects) to working mostly at the top and bottom of the funnel (i.e., deciding what forms of impact matter most and reviewing the distribution formula).

Badgeholders should be badgeholders because they care deeply about the health and growth of the ecosystem as a whole, not because they know the intricacies of projects. For most badgeholders, evaluating the quality of a portfolio of projects is a much better way of leveraging their time and expertise than evaluating each individual project. This should become even more apparent as the mechanism scales to more projects and larger funding pools.

My latest list of lists is just one person’s attempt to contribute to that transition.

This list measures progress against eight experimental impact vectors that, hopefully, over the long-run, prove impactful to the growth and adoption of Optimism and the Superchain. Not every vector is relevant to all projects. There are also many, many forms of impact not included here.

Each vector represents:

• a quantitative impact metric (eg, a project’s contribution to sequencer fees)

• measured over a discrete period of time (eg, the last 6 months)

• normalized across a distribution of projects in the ecosystem (eg, all projects with onchain deployments)

The eight experimental impact vectors included here are:

1. Grow full-time developers. Measured by full-time developer months since the project's first commit.

2. Expand the open source community. Measured by GitHub users who made their contribution to a project in the last 6 months.

3. Support modular, permissionless contributions. Measured by highest fork count among repos owned by the project.

4. Be beloved in the OP community. Measured by stars received from other developers in the OP community.

5. Make it easier to build awesome apps. Measured by NPM downloads over last 6 months.

6. Grow sequencer fees. Measured by all-time OP ETH contributions.

7. Increase onchain activity. Measured by all-time transactions on OP Mainnet.

8. Grow ‘high value’ users. Measured by multi-app users on OP Mainnet with more than 30 total transactions and some activity in the last 90 days.

There is a “ninth vector” that considers past funding the project has received from the Optimism treasury. Projects that have received larger amounts of past funding receive a discount on their final token allocation.

Note: this methodology does NOT include Protocol Guild in order to prevent double-counting of other projects that are housed on the ethereum GitHub namespace (eg, geth, Solidity, etc.) or represented elsewhere (eg, Nethermind). It also does not properly capture valuable contributions from projects such as Test in Prod which have occurred mostly on forked repos.

All data come from opensource.observer. You can find the notebook used to run the analysis here and spreadsheet with summary figures here. Reach out if you want data or help forking the analysis.

For each vector, projects’ contributions are plotted on a log-normal distribution as shown in the graphic below. A project that is 2 standard deviations from the mean is “exceptional” and a project that is 1 standard deviation from the mean is “excellent”.

Projects are awarded OP tokens based on where a project is in the distribution above.

• Exceptional: 2+ standard deviations = 150K OP (dark purple)

• Excellent: 1-2 standard deviations = 100K OP (red)

• Honorable mention: 0.5-1 standard deviations = 25K OP (light red) (Note: projects that only have honorable mentions are included in the list but not shown in the table below)

A discount is applied to projects’ token allocations based on the (self-reported) funding they’ve received in the form of OP tokens via Gov Grants, RetroPGF2 and incentive programs. (We know this is not always a complete or fully accurate picture. Please continue to DYOR.)

This discount is as high as 200K for larger projects that received large grants during Phase 0 of the governance fund.

More details on the methodologies for each impact vector are included below.

Full-time developers are GitHub users who makes code contributions more than 10 days in a given month. This vector considers a project’s cumulative full-time active developers since 2019.

• Unit: Full-time developer months (cumulative)

• Stats: mean of 21 months and standard deviation of 83 months

• Results: 44 projects, including 5 exceptional ones

Synthetix, libp2p, Pyth Network, Nethermind, IPFS, ShapeShift DAO, Kernel, Crust Network, Dappnode, BrightID, State Channels, Giveth, Public HAUS, Gelato, Hop DAO, Flipside Crypto, Coordinape, Pocket Network, ethOS, Guild.xyz, TrueBlocks / Unchained Index, Lodestar, OpenZeppelin Contracts, Rollup.codes, Patrick Workman, Nimbus, Tenderly, beaconcha.in, Yearn, Blockscout Block Explorer, DefiLlama, Sushi, Ethereum Cat Herders, Snapshot, Kwenta, RainbowKit, Erigon, Solidity, 🏰 BuidlGuidl, ZORA, Remix Project, Gitcoin, Blocknative | Web3 Onboard, rotki

Commits aren’t the only way to contribute to a project. Other forms of contribution to an OSS project include reviewing pull requests and creating issues. This vector considers the total number of new contributors to a project, across all its repos, in the last six months.

• Unit: Distinct GitHub contributors (who made their first contribution in the last 6 months)

• Stats: mean of 9 contributors and standard deviation of 31 contributors

• Results: 45 projects, including 13 exceptional ones

OpenZeppelin Contracts, RainbowKit, OP Reth, foundry, ethers.js, Erigon, Blockscout Block Explorer, go-ethereum, IPFS, Snapshot, libp2p, DefiLlama, Hardhat, Revoke.cash, Ethereum Attestation Service, Slither, WTF Academy, draper, Alchemy, Alloy, Department of Decentralization, L2BEAT 💗, Crust Network, Lattice (OPCraft & MUD), ChainList, EthStaker, Covalent, PatrickAlphaC, revm, beaconcha.in, Lighthouse, Remix Project, Solidity, Gitcoin, 🏰 BuidlGuidl, Tenderly, Web3js, rotki, Dappnode, Nethermind, Ethereum Cat Herders, Synthetix, Account Abstraction - ERC-4337, Sourcify, Blocknative | Web3 Onboard

Forks represents efforts to reuse, extend, or take a codebase in a different direction. This vector considers the fork count of a project’s most heavily forked repo. For projects with multiple repos, it only considers the repo with the highest number of forks.

• Unit: Number of times a project’s most popular repo has been forked (all time)

• Stats: mean of 33 forks and standard deviation of 257 forks

• Results: 45 projects, including 8 exceptional ones

IPFS, Web3js, Solidity, Ethereum Cat Herders, DefiLlama, go-ethereum, OpenZeppelin Contracts, 🏰 BuidlGuidl, Guild.xyz, Hardhat, Slither, Sassal.eth, rotki, libp2p, EthereumETL, ethers.js, Remix Project, RainbowKit, Protofire Blockchain Learning Path, PatrickAlphaC, foundry, Lighthouse, OP Reth, Gitcoin, Nethermind, Giveth, Snapshot, Account Abstraction - ERC-4337, DappRadar, The Ethernaut, Yearn, WTF Academy, beaconcha.in, Blocknative | Web3 Onboard, Blockscout Block Explorer, Vyper, UseDApp, Dapp-Learning, TypeChain / DethCode, ChainList, Erigon, Sushi, Synthetix, CryptoZombies, Sourcify

Aggregate star counts may be a vanity metric, but stars that come solely from developers in the OP community aren’t! This vector counts the number of stars a project has received from developers within the RetroPGF 3 community, including contributors to ethereum/, optimistic-etherum/, and duneanalytics/spellbook repos. It ignores any stars to a project that a developer has also committed code to.

• Unit: Number of stars a project has received (all time)

• Stats: mean of 33 stars and standard deviation of 183 stars

• Results: 52 projects, including 6 exceptional ones

foundry, go-ethereum, IPFS, Snapshot, DefiLlama, OpenZeppelin Contracts, OP Reth, Pyth Network, Protofire Blockchain Learning Path, Paco Bytes, Otterscan, Lighthouse, Nethermind, Remix Project, libp2p, Lattice (OPCraft & MUD), Hardhat, Giveth, Gitcoin, Frame, RainbowKit, Account Abstraction - ERC-4337, Flexible Voting, The Ethernaut, 🏰 BuidlGuidl, ZORA, Yearn, Vyper, Vectorized, TypeChain / DethCode, TrueBlocks / Unchained Index, Tenderly, Ronan Sandford, Synthetix, Sushi, Sourcify, Solidity, Slither, ShapeShift DAO, rotki, Rollup.codes, Lodestar, Dappnode, ethers.js, Ethereum Cat Herders, Boardroom, Blockscout Block Explorer, EthereumETL, Blocknative | Web3 Onboard, Erigon, CryptoZombies, Dapp-Learning

Most user-facing apps are written in JavaScript and therefore make use of NPM. The more useful packages that are available in the developer ecosystem, the easier it is for developers to build awesome apps. This vector considers the number of NPM downloads a project has had over the last 6 months.

• Unit: downloads on NPM (last 6 months)

• Stats: mean of 154K downloads and standard deviation of 5.9M downloads

• Results: 6 projects

TypeChain / DethCode, Web3js, OpenZeppelin Contracts, Wagmi / Viem, Hardhat, ethers.js

Sequencer fees are the revenue engine of Layer 2s. This vector considers the cumulative sequencer fees contributed by a project on OP Mainnet.

• Unit: Layer 2 sequencer fees (Optimism ETH)

• Stats: mean of 0.03 ETH and standard deviation of 1.51 ETH

• Results: 13 projects

RabbitHole, Synthetix, Sonne Finance, Lyra Finance, Gelato, Holonym, Socket, Kwenta, Across Protocol, Account Abstraction - ERC-4337, Sushi, Galxe, Velodrome

Transaction activity is the simplest way to capture that users are doing more things onchain. This vector considers the number of transactions a project has had since it deployed on OP Mainnet.

• Unit: Transactions on OP Mainnet

• Stats: mean of 3K transactions and standard deviation of 228K transactions

• Results: 15 projects

Account Abstraction - ERC-4337, Clipper, Lyra Finance, Across Protocol, Kwenta, RabbitHole, Hop DAO, Gelato, Galxe, Sonne Finance, Sushi, Synapse Labs, Synthetix, Socket, Velodrome

High value users are defined as addresses that have done something onchain in the past 90 days, that have made more than 30 onchain transactions total, and that have interacted with at least 3 protocols. This vector considers the number of high value users a project has on OP Mainnet. A user may belong to multiple projects.

• Unit: Unique addresses that fulfill ‘high value’ user criteria

• Stats: mean of 289 users and standard deviation of 8,231 users

• Results: 9 projects

Socket, RabbitHole, Galxe, Kwenta, Velodrome, Clipper, Clique, Sushi, Synapse Labs

Here’s a Venn diagram of high value users from within the RetroPGF 3 pool of projects.

We can also look at the (self-reported) funding received by projects in the form of OP tokens via Gov Grants, RetroPGF2 and incentive programs. Of course, this is not a complete a picture, but helpful in grouping projects into bands.

• Unit: OP tokens received (excludes USD and funding from other sources)

• Stats: mean of 29K OP and standard deviation of 270K OP

• Results: 18 projects, including 4 exception ones

Synthetix, Velodrome, Test in Prod, TypeChain / DethCode, Lyra Finance, Yearn, Synapse DAO, Hop DAO, Agora, Across Protocol, Pairwise, Kromatika Finance, DefiLlama, Sushi, Socket, Spearbit, dForce, Slither, rotki, L2BEAT 💗, Gelato, Immunefi

This report is a shallow dive on the 300+ open source software projects participating in the latest round of retroactive public goods funding (RetroPGF 3). It combines both off- and onchain data about projects.

The report itself has two objectives:

• Kickstart more rigorous analysis on the effectiveness of RetroPGF as a mechanism

• Snipe some data nerds to join this groupchat

Let’s jump in.

Over 600 projects and individuals applied for RetroPGF 3. This report only includes the 311 projects that are contributing open source software and that included links to GitHub repos (plus any OP Mainnet contract addresses) in their applications.

We also have data on projects that applied for previous RetroPGF rounds (but not the current one). A total of 366 OSS projects are represented in the Venn diagram below, of which 205 have no prior experience with RetroPGF.

These projects have lots of shared contributors too — a theme will explore further later on in this doc!

There are a number of places to find aggregate or project-specific GitHub activity metrics, but we think it’s interesting to look at cohorts of projects over specific time periods.

Among the RetroPGF 3 cohort, we can see this number hovering between 500-600 developers around the time of RetroPGF2 (March 2023), and, general, up sharply from late 2021, when the first RetroPGF occurred.

(Note: we are not implying that RetroPGF produced these developer activity numbers. Macro trends have probably been far more important. We’re just providing these dates for context.)

We’ve defined a “monthly active developer” in the same way as Developer Report, ie, anyone who has committed code on at least 10 days in a given month to a project (excluding bots and forks).

We can also do some light cohort analysis to compare growth among projects that also received funding from RetroPGF 2 versus those that only applied for RetroPGF3.

As expected, the cohort that received funding from both RetroPGF 2 & 3 rounds has generally been around for longer. Both cohorts, however, exhibit high growth during 2021-2022 and relative stability during 2023.

We can extend this further to include all OSS projects that have participated in RetroPGF at some point in their history.

The cohort of 55 projects that participated in RetroPGF 1 or 2 but did not participate in RetroPGF 3 represents a fairly small share of the overall mix but includes well-known (and still very active) projects like code4rena, Safe, and Wallet Connect.

Finally, we can see some high level trends regarding the change in developer activity across RetroPGF 2 projects before and after RetroPGF. The vast majority of projects maintained the same level of activity post-RetroPGF 2 as they had pre-RetroPGF 2. Given the sector has been in a bear market, it would be interesting to compare these trends to other ecosystems.

If all of these projects were committing to the same GitHub, here’s what it would look like. It’s no surprise to see Protocol Guild at the top of the list with a large network of active developers, but don’t sleep on IPFS or Synthetix either.

(It’s a huge image, scroll down for more analysis afterwards!)

A total of 86 of 296 OSS projects (not individuals) participating in RetroPGF 3 included contracts deployed on OP Mainnet in their application. There were a total of 1.4M unique users across all of these projects over the past two years.

Here’s the same type of heatmap we saw above, now applied to projects’ active onchain users. A dark red box signifies a month where a project had more than 1000 users making transactions.

Only a few projects such as Velodrome have been able to sustain high levels of onchain activity since their launch on OP a year ago.

We can also analyze user profiles across these different projects. Of the 1.4M total users shared among these projects, around 400K interacted with at least three projects. About 40K are what I’ve called ”high value active users” who have done something onchain in the past 90 days and have made more than 30 onchain transactions total.

We can plot these two dimensions for all of the onchain projects participating in RetroPGF 3. While projects like Galxe, Rabbithole, Synapse, and Velodrome stand out for having very large numbers of users in general, projects such as Clipper (by Shipyard), Kwenta, and Lyra are notable for having had a large share of users who both use a variety of dapps and are high value actives.

We can also try to attribute impact to protocols that onboarded new users to OP Mainnet who would go on to be active onchain users. Of the 40K high value active users identified above, here’s a breakdown of the first dapps (from the RetroPGF 3 cohort) they interacted with on OP. It’s notable to see that Synapse (a cross-chain communications protocol) really stands out here.

One of the most straightforward ways of measuring a project’s impact on OP Mainnet is to calculate its sequencer fees. The protocols participating RetroPGF 3 have generated a combined 148 ETH in Layer 2 sequencer fees. This is actually quite small in comparison to all activity on OP Mainnet. We’ve indexed transaction data from another ~150 projects with high levels of onchain activity on OP Mainnet and those have contributed 894 ETH at the time of writing.

The treemap below shows both cohorts and the most active contributors in terms of sequencer fees. Perpetual Protocol has the largest contribution in our dataset of all projects on OP Mainnet.

If we just zoom in on the RetroPGF 3 portion, here’s what it looks like. Infinitism (ERC-4337) - Account Abstraction is an important case study because its primary users are other projects providing account abstraction services, not individuals.

It’s also important to look upstream of these protocols and capture the impact of the libraries and projects they depend on, which make it easy to deploy or improve UX.

Our first attempt at this is something we call “downstream impact” — a way of tracing the impact of certain libraries, clients, etc on sequencer fees. We do this by looking at the dependency tree of onchain projects and identify the offchain projects they depend on.

Our first version looks solely at package data from npm, a small slice of the actual dependency graph among projects. For instance, ethers.js and web3.js are two very popular npm packages in the dependency graph of other onchain projects.

Soon, we hope to be able to surface the downstream impact via a far more robust graph.

Now that we have these graphs, we can start doing other cool things, like curating lists of projects that have contributed to different forms of impact, and surfacing new insights.

For instance, if we run a network graph across the GitHub contributors in the Optimism community, there’s potential to identify projects that have had outsized impact but previously flown under the radar, such as libp2p and Tenderly.

The graph below shows teams with high network centrality participating in RetroPGF 3.

We can also identify individuals that have played an outsized role in contributing to multiple projects in the Optimism ecosystem. Here’s a list of the top 150 contributors across all RetroPGF 3 projects since 2019, based on commits and PRs. Individuals like tjayrush (TrueBlocks) and lefterisjp (rotki) have a tremendous history of consistency not only on their own projects but across the ecosystem.

The hope is that this kind of data can take what has previously been an almost entirely qualitative process and turn it into one where humans have some data in the loop.

Of course, there is a risk that any metric that starts to be heavily relied upon by funders could be easy to game. And then, per Goodhart’s Law, it ceases to be a good metric.

Plurality is the best antidote for this: we need both a multitude of impact metrics and a multitude of communities assigning weight to those metrics based on different values sets. That’s why we need you, anon.

It’s unlikely that there is much low-hanging fruit to pick here. We can agree that things like GitHub stars and the number of unique addresses that have interacted with a protocol are not great metrics.

But that shouldn’t prevent us from seeking out and experimenting with other metrics, particularly “ecosystem-level” metrics, which seek to measure a project’s relative impact within a network of projects, or “derivative” metrics, which combine two metrics from different sources.

You can see my dataviz notebook here.

If you’re a data nerd who wants to contribute to this effort, please join this group chat and tell us what you’re up to!

Stay optimistic!

We’re here because we are optimistic about the future of public goods funding and want to see the space evolve from crypto funding its own public goods to crypto being foundational infrastructure for funding all sorts of digital and real world public goods.

To get there, we need to speed run all the lessons learned by legacy institutions when it comes to public goods funding. This is still a young, fringe movement, but there are some genuine tailwinds behind us.

In preparing for this talk, I created a 7-point scorecard to rate the state of crypto public goods funding vs legacy systems. It’s neither scientific nor exhaustive, but I hope it offers some inspiration for where to go and clues for how to get there.

Spoiler alert: the size of the crypto space for public goods funding is tiny.

Before talking numbers, let me define the space I’m referring to more precisely. I’m talking about decentralized public goods funding on crypto rails. I’m not talking about more traditional foundation grants or VC-style funding, which still have centralized coordination mechanisms and disburse funds on legacy rails.

The Ethereum PGF ecosystem includes players like the Ethereum Foundation, Protocol Labs, Gitcoin, Giveth, clr.fund, Optimism RetroPGF, Protocol Guild, DAO Drops, Arbitrum DAO, Octant, Celo, Uniswap, Starknet, Polygon, and various others. Collectively, these players allocate approximately $100 million annually to public goods.

Now let’s put this figure into perspective.

A hundred million is less than the budget allocated for public goods in Samoa. Samoa, if you’re not familiar, is an island nation in the Pacific Ocean with a population of around 200,000. It’s the smallest public sector budget that I could find data on here.

Getting to $500 million would put us on the same level as Chad. The point is we have a long way to go if we want to make waves relative to traditional public goods funding.

Early in my career, I worked for an international development NGO. We received a $50 million grant from the Gates Foundation and my team grew to employ hundreds of people. At that organization, we didn’t really get out of bed for grants of less than $1 million. It was a completely different scale.

Right now, no one in crypto is getting grants for over $1 million. A few of the top projects on Optimism RPGF have gotten grants over $200K. The top projects on Gitcoin these days may earn $30K per round.

Specifically in the case of Gitcoin, we’re talking about a matching pool of $1M divided across several hundred projects. We’re orders of magnitude smaller than the most discretionary segments of traditional public goods funding like international development. We don’t even register in comparison to the big fish like health care, education, and infrastructure.

We’re a rounding error and it’s OK. We’re the underdogs. To crossover, we need to grow this movement to nation state scale: billions and eventually tens of billions in decentralized public goods funding.

Crypto PGF 0, Legacy PGF 1

This one is more of a mixed bag.

Everyone is familiar with the fundraising problem. Fundraising is hard. All the time you spend fundraising is time you are not spending doing good work. It’s also expensive.

My first job back in high school was canvassing for an environmental activist group. We’d get paid something like $8/hour and had a target of raising $120/night. Anything you raised above $120, you kept 50% of it. I had a few nights where I raised over $300 and a lot of nights where I came back with less than $100. So the cost of fundraising at that org was basically 50%. What did they do with the surplus money? It would go towards lobbying and media campaigns, which also had their own overheads. So for every $1 raised, probably less than 10 cents went towards the intended mission.

This is actually pretty typical.

There’s an organization called Charity Navigator that rates the efficiency of different nonprofits based on the ratio of their fundraising costs to the program costs. The problem is that most nonprofits have worked out how to manipulate the formula by categorizing people like me, the door-knockers, as a part of program costs.

There are exceptions. Give Directly, for example, give money directly to poor people with no strings attached and rigorously track their efficiency and impact.

There are some parts of the crypto public goods funding cycle that are very efficient. I absolutely love how I can go on Gitcoin grants and fund 50 projects all over the world in minutes. But I’ve also been on the other side of the table as a recipient. You need to be popular in order to perform well in quadratic funding  – and that takes a fair amount of time. There’s also all the issues around fiat on/off ramps and L2 bridging. Plus tax stuff if you’re here in the US.

So I’m going to call this a draw and assign a half point to each side.

Crypto PGF 0.5, Legacy PGF 1.5

In the future, I think crypto has to win this battle hands down. I hope projects like tea.xyz and drips v2 get widely adopted because they have potential to make getting paid extremely efficient. And I hope these models permeate beyond open source software.

There’s really not much incentive to iterate rapidly in the legacy public goods space. It’s quite rare. And there are a lot of things that still happen that everyone recognizes is bad or ineffective but no one can change. That’s the definition of coordination failure.

David Deutsch has this saying that “preserving the means of error correction is the heart of morality”. In other words, a well-designed system is one that is always open to criticism and looking to improve itself. A poorly designed or in his words “immoral system” is one that continues to operate in failure mode.

I think crypto has a real advantage here. There’s just so much experimentation happening.

I also think there’s something compelling about protocols ossifying and iterating less as they become more widely adopted. The cost of maintenance decays. In the legacy world, as something becomes more widely adopted, the bureaucracy to sustain it grows more complex. It compounds at 5% year over year.

My hope for the future of crypto public goods funding is that you have a lot of experimentation at the edges and then a series of hardened protocols at the center which have minimal or no governance. This is exactly the opposite of legacy systems, where there’s very little funding at the periphery and most of the funding remains at the center and goes towards sustaining an ossified structure.

One point for crypto on this one.

Crypto PGF 1.5, Legacy PGF 1.5

The good and the bad thing about legacy public goods funding is that there’s a real career path in it. In fact, legacy public sector jobs probably offer the most predictable career path one can imagine these days. This is true for civil servants and teachers. It’s also true for international aid workers and employees of large nonprofits.

I lived in East Africa for a while and I knew people who were trying to get into the United Nations system. Once you got in, you’d effectively have your housing and living costs paid for for life, you’d earn a tax free salary, and you’d never have to wait in the passport lines anywhere you traveled. It was hard to get in, but once you were in, you were effectively set for life.

I love the meme of the “quadratic freelancer” - an open source contributor who lives off Gitcoin grants - but I don’t think it’s a lifestyle that everyone wants.

A quick tangent and then I’ll return to this point…

The first thing I did out of college was set up a microfinance bank in a rural part of Tanzania. We would give out uncollateralized loans of around $100 for people to start small-scale businesses – like running a vegetable stand or repairing bike tires. It worked, and most people repaid their loans, but there was a critical flaw in our logic. We assumed everyone wanted to be a small scale entrepreneur. The reality is that most of the so-called micro entrepreneurs we were lending to would have happily traded their vegetable stand or bike shop for a job in a factory.

You know the saying “sell the hole, not the drill”. Most people just wanted to make a stable living, not be entrepreneurs.

The same is probably true over here. I think a lot of people just want what this:

https://twitter.com/dabit3/status/1695040015108133266

I hope the future means that there is not only more public goods funding available but also more business models and therefore job opportunities at organizations or DAOs or guilds or whatevers to survive and prosper on public goods funding.

I know that goal was at the heart of Gitcoin’s origin story and hopefully unites all of us in this room. If crypto can enable a range of fulfilling career paths in the public goodsy space, from being a quadratic freelancer to an Allo round manager to a local Greenpill chapter organizer to an enterprise scale hypercert selling beach cleaning service, then that would be good.

Right now though, it’s precarious. So I have to hand this one to legacy PGF.

Crypto PGF 1.5, Legacy PGF 2.5

Of all the things discussed so far, this is actually the criterion that I think will be most important in the long run and where crypto has the biggest advantage.

Traditional nonprofits and public sector organizations are highly territorial. It’s so zero sum and myopic despite the rhetoric of being in service of the public good.

Can you imagine a world where, say, a Brooklyn school proudly announced that they were forking an idea from a Boulder school? Look at cannabis regulations. Every state is literally coming up with its own slightly different variation. Where’s the pride in saying “we cloned this from Colorado” or “we took these parts from California but this one from Massachusetts”.

It’s even worse in the nonprofit sector. How often do universities collaborate on research? Do donor governments co-fund a road or school? Do NGOs partner on a training program? It’s exceedingly rare.

Sadly, there is a pervasive scarcity mindset at least in the parts of the public sector I’ve experienced.

Crypto feels different. Sure, we have other forms of tribalism like Bitcoin maximalism, EVM supremacists, etc. But within ecosystems of values aligned people, the connectivity and interdependence is something truly special.

This connectivity is more than vibes. (A lot of it is vibes though, which is fine.) You can see it in network graphs of Twitter followers and Github contributions. People literally depend on each other and promote each other.

This is probably the thing I love most about Gitcoin’s community. Even though there’s only a limited matching pool, everybody is supporting each other and trying to grow the pie. It’s extraordinary and a breath of fresh air.

Why is this the case?

I think it’s at least partly because crypto still feels like a David vs Goliath type endeavor, and WAGMI is a powerful drug. But I think it’s also because so much of crypto is open source and has to be open source in order to plug in properly. This effectively enshrines connectivity and interdependence as a foundational properties of the crypto economy, in the same way that limited liability and bankruptcy protection enshrine risk-taking as a foundational property of the real world economy.

I think in the long run this is going to be crypto public goods funding’s greatest lesson for the rest of the world. Sure, there’s still plenty of politicking, infighting, FUDing, etc at the day-to-day social layer, but crypto value chains are much more circular and intertwined than legacy ones. It’s like the Flatland parable, trying to explain three dimensions to a world that has only conceived of two.

Anyway, one very big point for crypto on this one and I hope it only continues in this direction.

Crypto PGF 2.5, Legacy PGF 2.5

This is a semi-related point, but let’s just acknowledge that funding web3 public goods is much more fun. I look forward to Gitcoin Grants rounds. I love learning about new projects and novel funding mechanisms. Maybe it’s just because we’re a bunch of nerds, but I think the fun and social aspect of this is really important.

When you think about it, sharing the public goods you care about is one of the most important and meaningful ways of asserting your personality and social influence.

Compare this to the cynicism that you see in the traditional public goods space. Cynicism is putting it lightly.

My grandmother used to say that she loved paying taxes because of all the good things they funded. Can you imagine anyone saying that in 2023?

Last November, I voted here in the New York primaries, and one of the ballots I was presented with was for the state supreme court. There were twelve positions up for election and twelve people running. In addition, each person running was able to identify with any number of parties. So most candidates chose to appeal to multiple parties: Democrats, Republicans, Libertarians, Working Families, and probably a few others. All in all, it was a matrix of 12 rows representing the people and 6 columns representing the parties they represented. I stared at it for 5 minutes thinking I was missing something. There were 12 candidates. Running for 12 spots. And each candidate was able to identify with as many parties as they wanted. So, no matter how I colored in the ballot, the outcome would be exactly the same. What the f is going on.

Thank you for the “I ✔️oted” sticker but I’d actually prefer a POAP.

Anyone, one point goes to crypto public goods on this one.

Crypto PGF 3.5, Legacy PGF 2.5

Let’s recap. We’re at 3 for crypto, 2 for legacy, and 1 draw. The last one is impact.

Impact is the reason we’re all here, I think. We want to fund what matters. Well, what matters to you? And are you achieving it?

It’s complicated. In my case, I usually fund a range of projects on Gitcoin. Some I benefit from directly and really want to continue. Some I don’t benefit from at all directly but want to support the teams.

Let me rephrase this slightly. There are some projects that are good for now me. There are some that I believe are good for future me. And there are also some that really have no impact on now or future me but I appreciate the team and want to support anyway.

Unfortunately, all of this nuance is lost when I give each of them 5 dollars. It also reveals some of the disconnect between a relatively close-knit community deciding which public goods are most impactful and me asserting some preferences on other communities based on vibes or perception.

I don’t think the second case is wrong, but I don’t think it’s as impactful as the first one. In the first case, as a beneficiary, I’m happy to vote directly. In the second case, I care about the overall impact domain, but don’t really have an opinion that should be weighted more than people who are actively impacted by the work.

So I think we need to work on this. There’s something incredibly impactful about a community deciding which public goods it values most. But I don’t think we’ve struck the right balance of that happening in all the rounds.

In addition to getting the right voices elevated, we also need data.

Right now it’s mostly anecdotal. There’s a couple ways to fix this. One is to get the data to prove it and start measuring impact ROI. This is a problem I’m personally passionate about and am going to be focusing on. Another is to build up the primitives we use to account for impact. This is where hypercerts come into play.

The end state though is that you have credibly neutral ways of measuring and evaluating impact. Balaji refers to this as the ledger of record or a model of cryptoinformation.

Contrast this with the current state, where you either have organizations marking their own homework or strong perverse incentives to say everything is going just great.

This is where I think crypto has the great potential to eclipse the legacy model, but little to show for it today. If I had to vote, I’d give my vote to legacy systems having more impact than crypto public goods funding.

Of course, this has to change, and that’s why we’re here. That’s why we show up. To events like this. To every Gitcoin round. Because this is a movement.

I’ll end with one last story. A few months ago, one of those environmental activists knocked on my door. Now these groups have data to track who regularly gives them money; I’m one of those people, so they make sure to come to my apartment each year. I listened to the whole spiel. Honestly, it wasn’t very persuasive. The CTA is always the same: we did great things with your donation last year, but this year there’s something even more important so you need to give us 2x more.

Anyway, I cut her a check (yeah, one of those paper things) and as I handed it to her I asked if she’d heard of something called “quadratic funding”. She had! She knew about Gitcoin too! She even said she’d tried doing some DAO stuff!

I went back inside and gave her my copy of the Greenpill book – and a photocopy of an essay I wrote back in high school and published in my local newspaper about being a door-to-door activist just like her.

There was a part of me that hoped she’d be in this room today. Maybe at the next one.

I hope this movement grows. It’s fun being the Gen X speaker sharing stories about how bad the legacy system is, but I look forward to a day when the scorecard is a unanimous 7-0 and it feels quaint that there was ever a time when this was in doubt.

Public goods are good.

We don’t have a great response yet.

Consider the following one-liners that are out in the wild:

• Hypercerts are a new primitive for public goods funding.

• Hypercerts are a tool to build scalable retrospective reward systems for impact.

• Hypercerts are a specific, interoperable data layer to account for actions that are expected to have a positive impact.

I worry you need to be pretty deep down the regenerative cryptoeconomics rabbithole to understand these product statements and to start imagining how such a primitive / tool / interoperable data layer would be useful.

This is hard. (FWIW, I didn’t arrive at a decent product statement until three years into my last startup, so I only know the pain of a weak pitch, not the joy of a good one.)

Coming up with an effective elevator pitch is one of the most frustrating parts of starting something. Founders are obsessed with the problem and the vision, but flexible on the solution and the immediate form it takes. This makes it hard to “just” pitch a solution.

However, when giving an elevator pitch, you don’t have time to give a lengthy exposition of the problem. You need to jump straight to (your latest working version of) the solution. The main thing the person you’re talking to cares about is “will this be useful to me?”

For most people I think, crafting a good pitch is more science than art, a numbers game. You need to keep versioning and practicing over and over again. If the question “what are you building” makes you squirm, then you’re not there yet.

Having a weak product statement won’t kill you. You can overcome it by conveying genuine passion and commitment about what you’re building. People are drawn to that energy, so you can brute force your way through hiring, sales, defining product requirements, etc. by doing a lot of 1-1 communication and explaining. That’s what we’re all doing now, which is fine if we only talk to friendlies. But it probably won’t get us to $50M by Q3 2023.

The other problem is that all the time we spend explaining the thing is time not spent building the thing (or learning about our users). This is more of an issue going forward: if we get 20 minutes with a VIP, we don’t want to spend 10 of them explaining hypercerts.

Sorry for the rant. Let’s keep working on our pitch!

What are the components of a good pitch? Google says:

An elevator pitch (often referred to as a product statement) is a short description of a product that explains what the product is, who it's for, and why it’s better.

A product statement can often be assembled from the following components:

[name of project] is a [product category] for [group of users] to [accomplish something] [optional: positive adverb]

Here are some modulations that we came up with during a timebound exercise yesterday in Lisbon:

1. Hypercerts are digital twins for public goods for funders to only have to fund projects with 100% success rate.

2. Hypercerts make impact tangible and trackable.

3. Hypercerts make it easier to coordinate public goods. They’re the foundation for cheap impact moonshots.

4. Hypercerts create powerful incentives for project success and efficiency by making impact tangible and trackable.

5. Hypercerts allow funders to push their portfolio’s success rate to 100% by making public goods tangible, comparable, and trackable.

6. Hypercerts allow funders to separate predicting what projects will be impactful and what impact they value by enabling participants to track participation throughout the project lifecycle.

7. Hypercerts are a protocol for funders to reward positive impact.

8. Hypercerts are a protocol for funders to incentivize more work in the areas they care about.

9. Hypercerts are a protocol for funders to coordinate impact projects in a way that incentivizes the best talent to work on the most impactful projects.

10. Hypercerts are a protocol for funders to incentivize and coordinate work on the highest impact problems.

11. Hypercerts are a tool for funders to incentivize the best talent to work on the most impactful projects.

12. Hypercerts are a tool for funders to allocate their resources to incentivize the best talent to work on the most impactful projects.

13. Hypercerts are a protocol to create highly efficient, scalable transactions for public goods projects

We probably have identified most of the keywords for an effective statement. But bear in mind there are 427,518,000 permutations formed by choosing 6 words from a set of 30, so we can’t brute force a good statement either.

We should keep iterating, sharing feedback, and practice pitching regularly.

The hypercerts vision is extremely compelling from first principles thinking, eg:

• Public goods are good.

• More public goods will accelerate humanity’s progress.

• People will make more public goods if given the right incentives.

• But existing incentives are pretty broken [point to your favorite underfunded public good].

• One of the strongest incentives is money.

• A liquid market for impact would enable all sorts of new money to enter the mix.

• Markets are built on reliable data, which enables efficient transactions.

• Hypercerts solves the data problem for public goods and impact claims.

• Hypercerts improves the efficiency of public goods transactions

• This breakthrough will lead to a renaissance in public goods!

However, the present reality includes a spicy set of stakeholders who need to be convinced of this vision.

“Impact Creators”

They have been conditioned to operate with a scarcity mindset – always looking and competing for more funding / recognition. They also tend to have a larger than average amount of ego invested in the belief that what they’re working on deserves more funding / recognition. They see themselves as snowflakes. Exhibit A: there is virtually zero M&A in the nonprofit sector. Exhibit B: the failure rate for nonprofits is only 30%, versus at least 50% for small businesses and ~90% for startups. These suggest that (a) “bad” operators don’t exit the market quickly, and (b) a large proportion of existing operators may feel threatened by a more efficient market.

“Impact Funders”

There exists a relatively small set of institutions and individuals who control large amounts of money. But most of the people with decision making power either inherited or were promoted into a position where they control these resources. Thus, they also inherited a playbook for how to deploy these resources. What incentive do they have to buck with tradition? A small proportion built wealth more recently and care enough to have a system for thinking about how to deploy it wisely. Yet these people got to where they are today by being good at things other than picking the right basket of public goods to fund (like running a tech startup). So they are smart people who may not realize they are making suboptimal funding decisions. How motivated are they to get better?

“Impact Evaluators”

This group is perhaps the least studied. Impact evaluators tend to be highly specialized – the experts who evaluate clinical control trials don’t really swap notes with the experts who verify carbon credits. Even well-defined international standards, like ISO, don’t have legions of people equipped to evaluate compliance. It’s not sexy work. Expertise is highly fragmented. Impact evaluators, who usually operate as consultants charging a day rate, don’t have strong incentives to collaborate with other impact evaluators. They do have incentives to collude with whoever is paying them to produce a more favorable result. And, regardless of who is paying them, there is little business model in offering negative results only. For hypercerts to realize its vision, it will need a deep liquidity of credibly neutral impact evaluators. (FWIW, my previous startup served as an impact evaluator for coffee companies – it was extremely difficult maintaining neutrality.)

Suffice it to say, the present reality includes a large number of stakeholders who may not be intrinsically motivated to change their behaviors – and may feel threatened to do so.

A brief word on effective altruism (EA)

The EA community has thought deeply on the problems with the present reality and developed a set of highly opinionated expressions of what constitutes “effective” funding. They seek to narrow the field of “impact creators” to a much smaller pool, all subjected to rigorous impact evaluation. Then, the role of “impact funders” is primarily to determine an allocation of funding across those projects.

I agree with Nadia Asparouhova that, while EA is an important voice, the present reality may be hindered by EA being the only outspoken voice. Thus, what we really need is more idea machines like EA, not necessarily more EA.

Every product faces the cold start problem at its inception, when there are no users. Networks face a harder cold start problem because they need users in order to create any value. There is no value in a social network of one. Andrew Chen of a16z has a whole book on this topic.

More traditional businesses have a one-dimensional cold start problem: finding customers.

Many web2 marketplaces or gig economy businesses have a two-dimensional cold start problem: Uber needs riders and drivers; OpenTable needs diners and restaurants.

It’s harder to think of three-dimensional cold start problems in web2. Uber Eats only added a food dimension once it had strong network effects elsewhere in its business.

Gitcoin had a unique web3 cold start problem: they needed to attract big-check match funders, a diversity of credible public goods projects, and a large number of retail public goods supporters from the Ethereum community. If my understanding is correct, they built a project network first [because they were close with many open source developers], then the big-check funder network [through Vitalik and a few other crypto HNWIs], and finally a community of retail supporters [by turning quadratic funding into a fun, gamified experience].

Hypercerts feels like a hyperdimensional cold start problem. We need impact creators, impact funders, impact evaluators, and application builders. You could further split the impact funders into two categories: those who want to exchange hypercerts and those who want to accumulate hypercerts

I think it’s impossible to push hard on all dimensions from day one. Product guru Lenny Ratchitsky has an incredible series on kickstarting two-sided marketplaces. His advice: decide which side of the marketplace to concentrate on.

The general pattern appears to be to focus on the more tightly constrained part of the marketplace first. With Airbnb, there were fewer people who conceivably had a nice room to rent to a stranger than there were potential guests. With TaskRabbit, they had thousands of people on their waitlist to provide services, but no one was looking for services.

Lenny doesn’t have any advice for an n-dimensional web3 marketplace, but my current instinct would be to:

• Focus on one side to concentrate on

• Ignore as many other sides as possible

• Dogfood whatever is left over (dogfooding means using your own products… I feel like it has a bad connotation in some circles, but I think it’s a good thing in many situations)

With hypercerts, this could take the form of:

• Focusing on funders (specifically funders who want to own hypercerts because they care about impact)

• Ignoring impact evaluators and speculative funders (for now)

• Dogfooding the application building [build it ourselves for the uses cases we know best]

• Assuming that with sufficient funding and a decent application stack, impact creators will be motivated and able to participate

On Tuesday’s roadmapping session, we arrived at a decision to focus on funders, ie, the demand side of the market. This means we need to talk to funders and learn about their needs before we build too much.

We then developed a set of assumptions about what we think funders care about – and applied a quick ranking method to it. Here’s what we came up with (in order from strongest to weakest preference):

• I have an impact area that I care about deeply and want to incentivize more good work in that area

• I want to have impact on a very large scale

• I want to compare projects based on their impact track record

• I have very specific public goods needs that I want people to build

• I want to see more money go towards moonshot ideas

• Too few projects succeed post-funding

• Not enough promising/high-potential projects

• I like leveraging my funding to bring in other funders

• I don't know how successful the funded projects have been

• I want to see public goods funding much more streamlined and standardized

• There's not enough retrospective funding

• I want to push for more efficient ROI (impact per dollar spent)

• I want to be seen as a thought leader and innovator

• I spend too much time / money reviewing grant proposals

• I want impact creators to spend less time worrying about grant writing

• I find it hard to keep track of project progress

• I want to let the people decide what I should fund

• I am disillusioned by the current ways of funding public goods

• I only want to fund things that have a high success rate

• I like funding things that are high risk and relatively unproven

• I want to find projects that are off my radar

• I find it difficult to find promising projects

• There are more promising projects than funding available

• I find it hard to compare my portfolio to other funders

• I want to fund impact in areas that I am not very knowledgeable about

• I want to support under-represented projects

It’s not a MECE list and, again, these assumptions need to be validated through user interviews. But if we see strong signals from users who say “I have very specific public goods needs that I want people to build” then a product statement like “hypercerts are a protocol for funders to incentivize more work in the areas they care about” could be very compelling. However, the same statement would miss the mark if what we hear from funders is “I want to find projects that are off my radar”.

We also started narrowing down the types of funders we want to focus on, at least for the purposes of user research. These include governments (think: Taiwan’s g0v), legacy foundations (think: Gates), crypto foundations (think: FTX* Future Fund), EA funds (think: Scott Alexander’s ACX grants), crypto high net worth individuals, and DAOs (think: Vita DAO).

* this was written two weeks before FTX imploded 🙈

We made a simple 2x2 with potential check size on the y axis (log scale) and a very handwavy measure of adoption on the x axis.

Finally, we took our users on one axis and the customer problem statements on another and attached a very non-scientific preference strength to it. [0 = not important, 2 = most important]

This exercise suggests there may be some important differences among users, some of which may be incompatible with the version of hypercerts. For example, funders are likely to have different reactions to the prospect of “leveraging my funding to bring in other funders”. A government may be categorically opposed to the idea of having outside funders join them, whereas a DAO may view it as one of the biggest value adds.

The answer to the “what markets do we focus on first” question is coalescing on DeSci and OSS. These seem very on-brand for Protocol Labs and would tap into existing communities where the team already has strong networks.

These markets also present numerous opportunities for dogfooding. We had an idea of running a prize competition on hypercerts for retrieval market research, which would be valuable both from a DeSci and OSS public goods perspective. (Maybe we should use hypercerts to incentivize user research on donors…)

We made some updates to the hypercerts roadmap. Juan Benet’s CTA is our headline goal: create a $50M impact market with hypercerts as the leading standard.

Achieving the goal requires two sets of objectives: finding community-market fit and growing protocol adoption. The community-market fit piece feels clear – and even clearer after the work done over the past week. The protocol adoption piece feels a bit more open-ended. Now that we have decided to focus on the funder side of the market first, we need to be careful to not build too much of the technology stack without first learning more about what funders want to use.

With a sizable sovereign wealth fund and an expanding tax base, the nation has adopted an unconventional approach to public sector funding. Instead of the traditional budgeting process, they focus on retroactive funding.

Retroactive funding simply means funding work after it’s had some impact, not before. The idea is that it is much easier to look back and identify what is working than it is to look forward and predict what might work.

Indeed, the heart of this experiment lies in the nation's unique funding approach.

The government has a highly publicized and ceremonious process for looking back and determining which infrastructure and contributions have been most impactful to their nation. These projects then receive cash grants, no strings attached.

This system is open to any organization or individual, promoting a diverse range of contributions. It’s extremely easy to participate.

The social links among citizens are dense enough that groups of similar contributors are able to self-organize. There’s also a culture of openly addressing conflicts of interest between the people in government and the people applying for funding.

Another notable aspect of this experiment is the nation's efficient and transparent tax collection system. Anyone can see how the treasury is being replenished and who is paying for it. Although debates arise on the allocation of funds, the collection process itself is universally accepted.

The program began with a modest $1M retroactive funding pool. Then it grew to around $20M. Now, entering its third round, the nation is preparing to disburse roughly $50M next month and has even larger commitments earmarked for the 2024 fiscal year.

These figures may seem like a drop in the bucket in comparison to the budgets of bigger nations. However, the grants are meaningful to this nation’s economy and have garnered a lot of attention from regional trading partners.

But is it working?

It’s too soon to tell how this type of funding compares to traditional approaches. Like the mechanism itself, it will be easier to look back in a couple years and see what impact the program has had than to extrapolate from early signs.

That said, the best analysis of how it’s going is from the government’s own retrospectives of its retroactive funding rounds. After each cycle, results are discussed publicly and analyzed with citizens. The government shares the data on who made what impact claim and how much they were ultimately compensated for it. There is also a growing community of researchers pouring over the data and citizen journalists reporting on the whole process. Feedback is fed into the next round. Each round is therefore not only getting bigger but more sophisticated.

Organizations that received significant lump sums from past rounds say the experiment is changing the economics of working for the public sector. This new form of funding is starting to feel like recurring revenue. They are reorienting their work in anticipation of retroactive support.

The experiment also appears to be attracting immigrants. The nation has coupled its unique “impact meritocracy” with a highly permissive immigration policy. Like Florence was for painters, and Silicon Valley for hackers, it’s becoming an innovation hub. The government explicitly wants to create a fly trap for people motivated to re-imagine and contribute to the public sector.

“Move here so you can contribute to our public sector” isn’t a call to adventure you hear very often. But it might as well be this government’s party line.

So, what is this experiment and where is it happening?

“It’s not capitalism, it’s not communism, it’s Optimism.”

That’s the name of this nation: Optimism.

It’s a decentralized network economy running on top of the Ethereum blockchain. They’ve created their own digital currency, bicameral governance, and economic engine. There are over 100,000 citizens and a GDP, so to speak, of over $3 billion at the time of writing.

The name “Optimism” is not just a hope that all this will work out and lead to a better future but also a nod to the “optimistic roll-up” technology and game theory underpinning the whole system.

Winston Churchill famously said, “democracy is the worst form of government — except for all the others that have been tried.”

You can roll your eyes and identify a thousand reasons not to be optimistic about this experiment. But who else is trying? What other interesting economic experiments of this scale and complexity are underway right now?

A nation is forming that hopes its biggest export will be a new model for funding public infrastructure and services. Even if you have no intention of ever visiting this strange corner of the internet, you should know about it.

Write anything - from your smallest paragraph to your grandest masterpiece - and publish it online or send it as email newsletters directly to your readers.

Your Paragraph publication is blazing-fast, SEO optimized, and combines the best parts of both web2 and web3 to help you create content and grow your community better than ever.

Getting started

What you're looking at right now is the Paragraph editor. We support markdown, callouts, code, and rich media embeds like Twitter and YouTube.

paragraph.xyz

@paragraph_xyz

On http://paragraph.xyz, all posts are stored on @ArweaveTeam. This means they're immutable, uncensorable, permanent, and composable ✨

8

05:12 PM • Aug 18, 2022

When you publish a post, you'll have the option of sending it as a newsletter or storing it in the permanent & uncensorable Arweave.

Helpful links

Here's a few helpful pointers to customize your publication & get the most out of Paragraph:

• Theming & customization. Change your publication's font & colors; truly make this space your own.

• Set up a welcome email. This is the email your readers receive when they subscribe to your newsletter.

• Configure your publication's settings. Add links to your homepage, set up a custom domain, configure Google Analytics & more.

Need help or have feedback?

We've put together some documentation here, but if you still have questions you'd like answered we’d love to hear from you.

You can reach us via email at hello@paragraph.xyz or subscribe to our newsletter here. We're also pretty active on Discord.

RetroPGF has great potential to attract the best builders and users to Optimism.

However, as the L2 space grows more competitive, Optimism needs to maintain its early advantage and ensure it keeps improving the ROI of its grantmaking. Improving ROI means making both the process more efficient for all participants and the allocations more impactful for the ecosystem.

Fundamentally, this requires a shift from vibes-driven to data-driven funding.

Data is critical for badgeholders to transition from working at the middle of the grants funnel (i.e., reviewing individual projects) to working mostly at the top and bottom of the funnel (i.e., deciding what forms of impact matter most and reviewing the distribution formula).

Badgeholders are badgeholders because they care deeply about the health and growth of the ecosystem as a whole, not because they know the intricacies of projects. For most badgeholders, evaluating the quality of a portfolio of projects is a much better way of leveraging their time and expertise than evaluating each individual project. This will become even more apparent as the mechanism scales to more projects.

If one views impact optimization as a reinforcement learning problem, then badgeholders are the humans-in-the-loop giving feedback on algorithm selection.

The recent RPGF3 announcement post shows that Optimism is already moving in this direction of more data-driven funding.

First, there will be an emphasis on getting structured project data.

In Round 2, voting was high-friction due to low quality project information… Round 3 will introduce more structured project applications to gather better data.

Second, Optimism wants to enlist the community in impact evaluation.

In Round 2, badgeholders had to review nearly 200 projects, many in areas outside their expertise. Round 3 will introduce a process for community-sourced recommendations and curation to allow badgeholders to both vote directly, and incorporate the research and expertise of the community.

These are great developments. Getting more structured project application data is key to unlocking community-sourced recommendations.

In order to measure the ROI of Retro PGF, one needs to trace both a project’s work outputs and its finances.

We conducted an analysis on RPGF2, merging both onchain and off-chain sources. Although we’re currently limited by the lack of structured data, it provided a small taste of what may be possible in the future.

For novel funding mechanisms like Retro PGF to gain traction and transform funding for digital public goods, we need solid proof that they outperform traditional funding models.

Before sharing the outcomes of our analysis, here are four key suggestions for enhancing the project application specifications. These improvements aim to enable more insightful project comparisons and permit permissionless impact measurement.

The focus areas include:

1. Creating precise entity definitions such as individuals, organizations, and collections.

2. Verifying eligibility requirements for each entity type during the application phase. For instance, an "organization" should control a GitHub organization.

3. Requiring entities to link at least one source of public work artifacts, such as a GitHub repo, a factory contract on OP mainnet, or an RSS feed.

4. Requiring entities to share a dedicated address for receiving grant funds, such as a Safe, splits contract, or ENS.

Most projects already have these details embedded somewhere in their application. Structuring this data for all projects will pave the way for permissionless observation and decentralized impact measurement.

Now let’s get into some of our analysis on RPGF2.

We began by pulling metrics on each project, including data from its GitHub repo and onchain history, and joining this on the data included in the project application.

We also did some manual matching between the RPGF2 projects and the 500+ projects with contracts on OP mainnet that are being tracked in this epic Dune dashboard. (Interesting note: only 38 of 195 RPGF2 appeared to have contracts on Optimism, implying most of the impact that RPGF rewards is upstream of sequencer fees.)

You can view a summary of the analysis here.

In their application, projects had to select a category. The categories available were infrastructure, tooling & utilities, and education.

We experimented with adding some additional labels to each project:

• Entity. Is the project a dedicated team, a team of teams, or an individual? We derived this mostly from analyzing the projects’ GitHub organization.

• Address Type. What type of Ethereum address is associated with the project? We looked for onchain info about the type and usage of the project’s payout address.

• Team Size. Roughly speaking, how many people are working on the project? We turned the free text data on the project form into a numeric estimate.

• Team Composition. Is the team mostly devs or non-technical contributors? We compared the team size estimate above with pattern analysis of GitHub contributions.

• Years Active. How long has the project been around? We analyzed GitHub data all the way back to 2018 for some projects.

• Momentum. What does the contribution pattern look like over time? We came up with names for several different patterns of GitHub activity.

We performed some initial analysis on the funding patterns and composition of projects for the round’s three self-assigned project categories. 

This is old news, so let’s quickly move on to some of the new dimensions we added.

Entity. Is the project a dedicated team, a team of teams, or an individual? We derived this mostly from analyzing the projects’ GitHub organization.

The most common entity type was the “organization repo”, i.e., a dedicated team sharing a common GitHub repo. These were often startups and DAOs. A substantial share of projects were linked to personal repos in their applications, including several large ones with outsized impact like Ethers. Projects without a GitHub linked in their application were mostly in the education category. There were also five projects working primarily on Ethereum repos (e.g., Solidity). We moved Protocol Guild into this category as well.

For RPGF3, we recommend creating more precise entity definitions: e.g., individuals, organizations, collections. If these labels are MECE, then no project should be in the “other” category, where it requires specific knowledge to work out what type of team or project it is.

We also recommend making a public GitHub an eligibility requirement, at least for OSS projects. If it’s an organization, then the project should have a GitHub organization. If it’s an individual, then it should be a repo owned by the user’s personal GitHub. For non-OSS projects, there should be thought put into identifying good sources other than GitHub for tracking public work artifacts.

Address Type. What type of Ethereum address is associated with the project? We looked for on-chain info about the type and usage of the project’s payout address.

The address type dimension differentiated between smart contract-based addresses and EOAs. For EOAs, we also analyzed transaction counts on both Ethereum mainnet and Optimism. A high number of projects (45) set their payout address to an EOA with minimal or no history, suggesting it was created purely for receiving grant funds. Some projects did not have a payout address listed.

Out of the 195 total projects, 66 were ideal for permissionless impact measurement because they shared both an organization GitHub repo and an address with a robust transaction history. An additional 39 projects, which were either solo or team of team initiatives, had an active GitHub and verified address.

On the other hand, there were 8 projects with no repo or onchain history provided, which made it difficult to evaluate anything about them without doing additional research.

Anecdote: the project page for Goerli, which received 140K OP, had no payout address, no GitHub, and no website link (apart from an empty Notion page) in its application!

As mentioned earlier, we’d like to see organizations adopt a more transparent model of receiving grants through a dedicated address.

Team Size. Roughly speaking, how many people are working on the project? We turned the free text data on the project form into a numeric estimate.

Most projects indicated a team size of 2-10 people in their application. Larger teams tended to receive larger grants. The median solo project received the same grant amount as the median small team project.

We can extend this analysis to calculate the average grant amount per team member. As projects get larger, the amount of grant funding per contributor becomes less significant. For instance, a project like Flipside Crypto has a team of 80 people, so an average-sized grant of 40K OP works out to just 500 OP per team member.

The average funding per contributor declines markedly for projects with more than 10 full-time team members.

This inverse relationship between team size and funding per team member is displayed in the chart below. The size of the bubbles corresponds to the total amount of grant funding received from Optimism.

It’s powerful to see solo projects like Ethers and ZachXBT receive grants of more than 100K OP. However, you don’t want to discourage less visible teamwork either. This dynamic is most problematic for the “collection” entities, which received a total of 1.6M OP, split across 418 individual contributors, for an average of just under 4K OP per individual. By comparison, the 47 solo projects received about 1.6M OP, or an average of 35K OP per individual.

This tendency is visualized in the treemap below, which takes all projects that received a grant of at least 35K and creates a box for every team member’s “share”.

This observation is worth monitoring over future rounds. The current funding mechanism may incentivize builders to focus on visible solo projects rather than less visible team projects.

Team Composition. Is the team mostly devs or non-technical contributors? We compared the team size estimate above with pattern analysis of GitHub contributions.

For projects with organization repos, more than half appear to have a team composition that includes active contributors from the open source community. These projects also received more funding than projects with less active repos / less technical teams.

There’s a lot that could be discussed here. Impact measurement methodologies that rely on GitHub (or other software-related) artifacts are likely overlook the impact of other types of contributors, e.g., to education, user onboarding, or governance. It’s important to identify other public artifacts (such as RSS feeds, attestations, etc) that are better suited to non-software public goods.

The chart below provides more details on the size of projects. The black dot represents the number of contributors derived from the project profile, whereas the colored bars represent the difference between that number and the number of monthly active contributors on the organization’s GitHub repo. Projects with blue bars have more active contributors on their GitHub than listed on the project page. (Safe, for instance, reported 45 contributors on its project page but had an average of 73 monthly active contributors on its GitHub over the past year.) Projects with red bars have fewer contributors on their Github, likely implying they are less developer-focused projects or are part of a larger organization (For example, Messari Protocol Services is a grant-funded, open source arm of VC-backed Messari.)

Years Active.* How long has the project been around? We analyzed GitHub data all the way back to 2018 for some projects.*

In aggregate, projects with more years active received more funding – roughly 10,000 OP for every additional year of activity.

(Note: this indicator is derived solely from GitHub activity and may not always be a good proxy for the actual number of years a project has been around.)

However, the tendency for more established projects to receive more funding isn’t as strong within categories. In education, for instance, newer projects tended to perform better than older ones.

Momentum.* What does the contribution pattern look like over time? We came up with names for several different patterns of GitHub activity.*

There’s an open question about how retro does Optimism want to go.

Many of the projects have been around for years while others are newer, hopefully rising stars. Should retro-funding be “exit liquidity” for hardened projects that have stood the test of time and are now in maintenance mode or sunsetted? Or should it be more like “recurring revenue” for projects that are still in active development? This is a clear example of where governance and badgeholders’ preferences are instrumental.

In RPGF2, projects with “steady” momentum – i.e., consistent activity on their organization’s GitHub for over two years – received much larger grant sizes on average than newer, “rising” projects and older projects with “bursty” activity. There weren’t any projects with a “hardened” pattern -- though Goerli probably would have met this criterion if its GitHub had been listed in the application.

The following charts show a subset of relevant GitHub contribution activities (i.e., pull requests created, pull requests merged, and issues created) over the last five years for each type of momentum.

It’s natural to look for projects that have “steady” or “rising” activity. Funding them not only rewards past work but also serves as motivation to keep building.

A large number of projects demonstrated a “bursty” activity pattern. CryptoZombies is a good example of one of the more “hardened” projects that has been creating value for a long period of time.

We can also visualize different combinations of dimensions as treemaps. These are just screenshots – we have interactive versions as well.

It’s worth noting that a number of personal projects received more funding than many of the organization-run projects – and more funding than some of the teams of teams projects like Remix and Support NERDs.

Unsurprisingly, long-standing projects with steady momentum tended to receive the highest grant sizes. Over time, it will be interesting to see how preferences change and if subsequent rounds start to favor younger, rising projects, or alternatively the oldest, most hardened projects.

We hope that this analysis hints at what becomes possible if projects provide structured data that facilitates permissionless observation. Optimism is in a position to create grant eligibility requirements that promote transparency and building in public across its entire ecosystem.

GitHub and onchain activity are just the tip of the iceberg – and the metrics we happened to pull about RPGF2 projects’ GitHub and onchain activity are just the tip of that iceberg!

To recap our recommendations for initial requirements:

1. Create precise entity definitions: e.g., individuals, organizations, collections.

2. Verify eligibility requirements for each entity-type during the application phase: e.g., an “organization” has a GitHub organization in its control.

3. Require entities to link at least one source of public work artifacts: e.g., a GitHub repo, a factory contract on OP mainnet, an RSS feed.

4. Require entities to share a dedicated address for receiving grant funds.

Ideally, all of these metrics can be tracked passively, simplifying the application process for projects. This would make it possible for funding rounds to happen continuously, e.g., projects are fundable as long as they remain active or until they opt-out. It’s also possible to create impact oracles that trigger funding when certain milestones are reached.

We view impact optimization as a reinforcement learning problem: badgeholders are the humans-in-the-loop giving feedback on algorithm selection, while the foundation has the ability to modulate all sorts of design parameters like funding pool size and frequency.

With better data, onchain results oracles, and the emergence of new forms of impact attestations, it’s possible to not only to improve the ROI of RetroPGF but to transform how digital public goods are funded. We came for the vibes and low gas fees, we’re only going to stay if the public goods are good.

Introduction

Our lives are increasingly moving online, sparking new modes of interaction, communication, and creation. As we transition to a world where we occupy both physical and digital spaces, the concept of a "public good" must evolve accordingly.

Public goods already exist in the digital realm. Open source software is a prime example of a digital public good, underpinning everything from fundamental internet protocols like HTTP to the 'awesome' list of lists.

Yet, despite the significant societal value they generate, open source software projects frequently struggle with the existential challenge of acquiring stable funding.

Part of the problem is that we haven't found the right, digitally-native mechanisms for funding open source. Traditional approaches, from soliciting donations to applying for government grants, aren't a good fit for open source.

Consider Wikipedia, a household name in the realm of digital public goods. You've likely encountered the seemingly ever-present appeal banners asking for donations:

If a digital public good as prolific as Wikipedia remains strapped for cash, what can we assume about all the other, less visible open source initiatives?

It doesn't need to be this way. The big tech giants and internet-based businesses continuously vie for our attention, turning every click, like, and share into a monetizable event. This attention economy generates immense profits, a portion of which is paid as taxes to governments in the countries where these companies operate. These taxes are used for traditional public goods, infrastructure, education, healthcare, and more, but these businesses seldom directly fund the digital public goods that underpin their operations and profits.

What if the same type of rigorous analysis used to measure attribution was applied towards measuring impact? What if your favorite delivery app used the same type of programmability that allows you to order a pizza, tip the driver, and pay taxes in one transaction to fund the open source software they depend on?

Programmable retro-funding offers a solution to the imbalance between the value created on the internet and the value that flows back to support digital public goods.

"Retro" is short for retrospective or retroactive, meaning projects are funded for work that's already happened, while "programmable" means there are pre-defined rules for distributing funds across individuals and teams.

Programmable retro-funding is a digitally-native form of grantmaking that's a much better fit for funding open source than existing approaches.

At least five elements are critical to effective retro-funding:

1. Proven Impact: Fund projects based on their established track record and demonstrated value, rather than speculative future promises.

2. Permissionless Monitoring: Make it so all stakeholders can see what's happening within a project, providing a transparent view of the project's progress and finances.

3. Fluid Entity Constructions: Embrace the often decentralized nature of open source, where the lines between contributor and user are blurry, and there is often no traditionally organized entity behind the project.

4. Plural Definitions of ROI: Encourage a multitude of ROI definitions and impact metrics in recognition of the fact that open source projects impact various participants and layers of the stack differently.

5. Programmable Funding Streams: Pre-define rules for distribution of funds across multiple projects and contributors, fostering a fair and incentivized ecosystem.

Now, I will dive into each of these ingredients in more depth, exploring their significance and the roles they play in programmable retro-funding.

Fund projects based on their established track record and demonstrated value, rather than speculative future promises.

Forecasting the success and broad adoption of software projects often feels like a game of chance. Many factors, including market readiness, contributor reputation, technical robustness, and community adoption, are difficult to predict accurately.

Retro-funding is a viable alternative, enabling us to support projects that have already established their value and demonstrated significant impact.

Retro-funding operates on a simple principle: reward projects for the value they have already provided.

Unlike prospective funding models that bank on potential and predictions, retrospective funding relies on concrete evidence of success. This evidence can manifest in various forms, such as widespread usage, active community contributions, or notable advancements in the respective field.

This does not mean that projects shouldn't receive any prospective funding, just that more funding should be allocated retrospectively, when the reputation and impact of a project is already established.

Retro-funding also provides a powerful incentive for contributors to keep developing and maintaining their work. When we support creators on Substack or Patreon, we do so not because we want them to retire but because we want to motivate them to keep creating.

Make it so all stakeholders can see what's happening within a project, providing a transparent view of the project's progress and finances.

Programmable retro-funding aligns nicely with the open source ethos of transparency and accountability.

Public repositories on platforms like GitHub provide an additional--albeit incomplete--picture of the work that's happening on a project. They offer a data-rich view of a project's development progress, showing the frequency and volume of code commits, contributor counts, and the nature of collaborations among contributors. Furthermore, issues and pull requests provide insight into community engagement, illustrating the vibrancy and responsiveness of a project's base of contributors and users.

Package dependency trackers reveal the degree to which other projects rely on a particular open source project, reflecting its importance within the broader software ecosystem. In crypto networks, smart contract events can signal how important a given protocol or implementation is to an ecosystem's overall activity.

All this is just scratching the surface. The open source nature of these projects presents the opportunity for innovative, crowdsourced metrics and attestations. Communities can define their own success metrics, aligning them closely with their own unique goals and data feeds.

Permissionless monitoring is also possible for finances. If a project uses an open treasury management tool, like those developed by Open Collective or Safe, anyone who cares about the organization can see where funds are coming from and where they are going.

Such transparency builds trust, reassures funders that their contributions are being used effectively, and demonstrates the project's financial sustainability to potential supporters.

Embrace the often decentralized nature of open source, where the lines between contributor and user are blurry, and there is often no traditionally organized entity behind the project.

Many leading open source projects are decentralized in nature. They tap into a global pool of contributors and users. They don't have a traditional organizational structure or entity like an LLC or nonprofit.

The image below, proposed by Nadia (Eghbal) Asparouhova, contains a useful categorization of open source projects:

While each type of project has unique dynamics and needs when it comes to funding, "clubs" and "federations" are typically farthest out on the decentralization axis and therefore face a unique set of challenges when it comes to funding and incentivizing positive contributions.

Traditional funding models can conflict with the decentralized ethos of such projects. They usually necessitate the establishment of formal organizations to receive and distribute funds, which can add considerable administrative overhead. This overhead can divert resources away from the actual development work.

Moreover, the need for a formal organization can create barriers to entry for smaller projects or individual contributors that lack the capacity or desire to navigate this complexity.

The Open Collective was created in response to this problem, providing financial and legal infrastructure for thousands of open source projects. They serve as a fiscal host that takes care of accounting, taxes, banking, and non-profit status for open source teams.

Crypto funding is another alternative. Crypto makes it easy from day one to receive and distribute funding across geographic borders.

Retro-funders need to feel comfortable with the reality that the relationships among open source projects and their core contributors are often fluid, dynamic, and informal.

Encourage a multitude of ROI definitions and impact metrics in recognition of the fact that open source projects impact various participants and layers of the stack differently.

Quantifying impact at diverse scales and across varied ecosystems presents a significant challenge.

Trying to create an overarching impact metric, akin to "internet GDP," would be a formidable if not impossible task.

Moreover, any such universally applicable metric would still require support from a robust network of telemetry tools, data aggregators, and analysts.

As no single ROI metric may be able to capture the full impact of an open source project, it's more pragmatic to approach this as a collective intelligence problem. Make it so communities can easily compute their own ROI benchmarks.

For this to happen, we need generalized impact evaluators, broad and adaptable tools for measuring impact. These should rely on both observable impact outcomes and transparent financial data. The data sources and measurement instruments can be fine-tuned to the unique needs and characteristics of individual communities.

Open data sets pave the way for plural ROI measurements. Different stakeholders can leverage the same data to compute ROI from their unique perspectives.

Pluralistic measurement capabilities can provide crucial insights for retrospective funding decisions. They help correct for errors and ensure that funding allocations are based on demonstrable success and widely-observed impact.

Pre-define the rules for distribution of funds across multiple projects and contributors, fostering a fair and incentivized ecosystem.

Programmability is essential to route funding across large groups of projects and within decentralized projects.

Programmability in this context means that rules can be pre-defined for how funds are split or otherwise distributed amongst a group of accounts.

Once a split is established, a funder can simply send money to single node and it will automatically be distributed pro-rata to other nodes according to a predetermined, auditable formula. The formula could leverage metrics such as contributions to a codebase or a set of parameters defined by the community. This introduces a simple, transparent way to reward contributors, and moreover, it automates what would otherwise be a complex and time-consuming process.

For example, the Protocol Guild has effectively used an Ethereum-based splits mechanism to distribute more than $10 million to over 100 developers working on Ethereum's core infrastructure. Here, the mechanism effectively recognizes and rewards the individual contributions of a diverse set of developers, fostering a culture of meritocracy.

https://twitter.com/ProtocolGuild/status/1600549804236341248?s=20

Programmable funding mechanisms extend beyond the realm of individual projects. They enable easy and fair distribution of funds within or across projects through community voting mechanisms. Platforms such as Gitcoin and Optimism RPGF are two more leading examples from the Ethereum ecosystem. Gitcoin uses quadratic funding; Optimism uses retroactive public goods funding. Both rely on large communities of voters to allocate millions of dollars of funding to a range of open source projects. In doing so, they have reshaped the norms and expectations of open source contributors and how people think about contributing to the ecosystem.

Recurring streams of retrospective funding suddenly give every open source project a revenue model -- and transparent distribution rules give contributors confidence they will be rewarded fairly.

Programmable retro-funding not only provides a dynamic solution to the enduring challenge of sustainable open source funding but also holds potential to transform the broader landscape of public goods financing.

Today, most grantmaking and sponsorship models used to fund open source mirror the requirements of traditional public goods and non-profit funding models. They have been designed to support registered organizations engaging in high upfront cost projects, often carried out by in-person teams. However, this mold doesn't fit the creators of digital public goods, who are usually decentralized, distributed, and face relatively low upfront costs. Here, programmable retrospective funding appears to be an ideal solution.

Furthermore, open source is a motley crew of projects and people. There's no single path from crowdfunding to corporate sponsorship, nor a universal metric for impact. programmable retrospective funding offers the flexibility to adapt to the distinct needs of various project types.

To fund digital public goods more effectively, we need to speedrun the lessons learned over the last half century of grantmaking and develop powerful digitally-native mechanisms for raising, distributing, and measuring the impact of funds.

That's why we need to embrace programmable retrospective funding and open the taps to fund our public goods.

In the previous round, I utilized a scoring algorithm to determine which projects to support. I had intended to deploy an improved version of the scoring script with new data sources in time for this round. However, I was unable to complete it on time. The number and diversity of projects available was overwhelming. Each pool of projects required customized metrics and analysis, making a one-size-fits-all approach impractical. Additionally, I had to travel during the round, making it even more challenging to evaluate the projects properly.

So, the combination of a more challenging evaluation task with less time to complete it is my weak excuse for not having something more comprehensive than a set of heuristics and a little data viz.

In the end, I chose to donate to seven funding pools for individual projects, including Web3 OSS, Web3 Community & Education, Climate Solutions, DeSci, Ethereum Infrastructure, The Sybil Resistance (The Phantom Menace), and ReFi Local Nodes.

I did not donate to individual projects in the Metacrisis or Advocacy rounds but opted to contribute directly to their matching pools via the Metacrisis.xyz crowdfund and Coinbase/Zora NFT sale.

If I had more time, I would have liked to explore the ZK projects and devise some evaluation metrics to select the ones that deserved funding.

Over the past month, I’ve doing a lot of analysis that combines on-chain financial transactions with Github activity. The eventual goal is to test the effectiveness of different funding mechanisms and help funding ecosystems better allocate their capital. It’s too early to offer any meaningful insights, but I used the data I’ve been gathering to vet my grantees.

Here are the 16 Web3 OSS projects I donated to this round:

• BrightID 🔆 Universal Proof of Uniqueness

• Commons Stack

• Covoco / Voting Contracts

• datalatte ☕️

• DeCartography

• FundPG

• Giveth

• ITU Blockchain

• Praise

• Scaffold-ETH 2

• ShapeShift DAO

• Spect

• TrueBlocks and the Unchained Index

• Umbra

• viaPrize

• White Hat DAO

I appreciate that this is a small, well-curated group of long-standing projects. I applied the same GitHub x on-chain analytics on these projects that I used for the Web3 OSS cohort. The list includes perennials like ethers.js and rotki. I also added clr.fund and Protocol Guild because I love funding funding mechanism.

• clr.fund

• ethers.js

• L2BEAT

• Otterscan

• Protocol Guild

• rotki

I have been keeping tabs on most of these projects across various rounds, and I commend the communities they have fostered around their initiatives. They have a positive-sum mentality and are supportive of one another, which I find inspiring. I am particularly enthusiastic about the projects in Africa and Latin America, where the need for both crypto and climate solutions is more pressing than in the US. Crowdmuse is a project I learned about very recently and found very compelling.

Here are the 20 Climate Solutions projects I donated to this round:

• AgroforestDAO

• Atlantis

• AYOWECCA UGANDA

• Barichara Regeneration Fund

• Bloom Network

• Climate & Nature Hyperstructure | .basin

• Coffee Impact Collective

• Crowdmuse

• de_plan ostrom

• Digital Gaia

• D-MRV for Africa

• GainForest

• Impact Verification Infrastructure Bundle

• KOKO DAO

• Kokonut Network

• Solarpunk nomads

• The Impact App + Eco Labs

• The Solar Foundation

• Urbanika

• Web3beach

I didn’t attempt any quantitative impact evaluations and instead focused on 10 projects that have had an impact on me personally.

• Dream DAO - a learning DAO with an incredible community of GenZ builders from around the world; I’ve been an active member since it began in 2021

• Rehash - a podcast NFT community that I’ve been a part of since it began

• LexDAO - the only lawyer you’ll ever need (they also host great events)

• Njombe Academy - because I spent a lot of time in this area of Tanzania and was excited to see a project from here!

• Buidl Guidl - love their tools, their hackathons, and their spellings

• ImpactDAOs Research & Podcast - Deepa keeps shipping new things; I’m excited to see what the future holds for this budding regen media empire

• Crypto Altruism - a podcast and web3 x social impact learning community that I recently made a guest appearance on

• Web3ForGood - a web3 x social impact newsletter that keeps steadily shipping and getting better

• Greenpill Podcast - the green heart of crypto, where I learned most of my new vocabulary

• Greenpill Global - this one is more a bet that this will have an impact on future me, someday, somewhere

It's already 1 am, and the round is set to close tomorrow. I swiftly filled my cart with the projects that caught my attention, although I might have missed some initiatives that I have supported in the past. There were also a few projects I skipped because I funded them in other rounds (eg, OSS, Climate Solutions, Sybil Resistance).

Here are the five projects I supported:

• OpSci

• Crowd Funded Cures

• LunCo

• PlantGang

• DeSci Round Operations Fund

I was also quite happy to donate to the DeSci Round Operations Fund. I really appreciate the cohesion within this group of projects. It was observing the DeSci x Gitcoin Telegram community that inspired this thread last month:

https://twitter.com/carl_cervone/status/1643630067300311041?s=20

I funded five nodes, all in Africa: Lagos, Dar es Salaam, Nairobi, Cape Town, and DRC.

I’m especially keen on the DRC node which includes an initiative to bid against oil & gas companies and preserve some 30 tracts of pristine rainforest.

I am keen to fund an anti-sybil army of data scientists, game theorists, and meme lords. I contributed to two projects led by Gitcoin FDD alumni: zer8’s Grant Review Dashboard and Omni’s Learning Data Science on the Ethereum Blockchain.

Spoiler alert: I’ve met Omni in real life and he does not look anything like the bearded purple professor in the banner image.

And here are my transaction logs:

• Sybil Resistance

• ReFi Local Nodes

• Decentralized Science

• Web3 Open Source Software

• Climate Solutions

• Ethereum Infrastructure

• Web3 Community

• Metacrisis

• Advocacy

The Problem

Most family-oriented educational placemats suck.

They look like color photocopies of text books. They encourage kids to memorize arbitrary facts like state capitals, multiplication tables, or words in foreign languages.

Here is an example of a placemat on Amazon that retails for $10.

How many 6 year-olds are interested in learning that Jefferson City is the capital of Missouri while they eat a bowl of Cinnamon Toast Crunch on a Saturday morning?

Parents, on the other hand, just have a job to be done. They want something that keeps food off the table and is easy to wash. Given the choice between a nondescript placemat and one that has a nonzero chance of inspiring the next Ken Jennings, many parents are willing to pay a premium for the latter.

The other issue is that the useful life of the “educational” component of the placemat is much shorter than its useful life as an actual placemat. For kids who are placemat power users, it might only take a few cereal sittings for them to finish memorizing all the facts off a new placemat.

I would assume there are very few families who cycle through placemats every few months because their kids get bored of them. So even the best placemats quickly grow stale and boring for their primary users.

To recap the issues with educational placemats:

1. They look like textbooks

2. They just encourage rote memorization of arbitrary facts

3. Even for kids who like rote memorization, they will quickly get bored of them

What if there were an opportunity to turn placemats into something both kids and parents wanted to collect and trade? What if, in doing so, we could also onboard the next million Ethereum users?

Step 1. Create cool puzzles for kids

The first objective is to make a more engaging placemat for kids.

If we accept that a placemat has a short useful life as an educational device, then let’s create logic puzzles or games that kids will immediately want to play and can repeat a dozen times before they get bored.

Let’s find something that is more engaging to more kids than memorizing facts.

Ideally, kids look forward to getting new placemats. Ideally, kids are excited to choose the placemat they want to eat with. Ideally, kids keep interacting with the placemat after they finish their bowl of cereal.

Step 2. Create art that adults like too

Placemats have two sides. Let’s use both of them.

If the back has logic puzzles or games, then the front could have unique artwork that adults like to stare at too. Perhaps there could be a series with a solarpunk vibe.

Step 3. Drop a QR code on the placemat

Now is where it starts to get interesting.

When you buy the placemat, you scan the QR code and are prompted to “mint” your placemat. Under the hood, you are initializing a custodial wallet and transferring ownership of a placemat token to your wallet address.

You are the owner… for now.

In addition to claiming your token, you can also add metadata about yourself such as your name, photos, where you live, what your favorite foods are, etc.

All metadata fields are optional, but their purpose will hopefully make more sense soon.

Step 4. Encourage a secondary market

A secondary market for placemats? Yes!

As discussed earlier, educational placemats have a short useful life. We want to encourage families to circulate them as quickly as possible.

They circulate when one family sells or trades their placemat with another family.

The placemat is transferred when another user scans the QR code and performs a transaction to purchase it. The secondary price could be fixed, negotiated between the two parties, or follow an exponential decay function. Regardless of the pricing mechanism, the ownership of the placemat should be transferred both physically and on-chain to a new owner.

The previous owner receives 90% of the sale. The remaining 10% flows back as royalties to everyone who has owned the placemat before them.

Let’s assume you purchase a new placemat for $10. Then you sell the placemat to a friend for $8, keeping 90% of the proceeds or $7.20. Your friend sells the placemat for $8 too; they keep the first 90% ($7.20) and you split the remaining 10% ($0.80) in half, netting you an additional $0.40. It gets sold again and now the 10% is split three ways, netting you $0.27. The placemat is now on its fourth owner. Overall, you paid $10 upfront and have received a total of $8.07 ($7.20 + $0.40 + $0.27). Not bad!

The royalty math could be refined. Nonetheless, the goal is to create a modest financial incentive to cycle through placemats quickly -- and for users to promote their favorite placemats.

The new owner is also able to attach their own metadata to the token.

Step 5. Create a UI for owners to explore the life of their placemats

Imagine a timeline of where your placemat has been that’s combined with the ability to explore the placemat collections of other users. This could facilitate trading and secondary sales. You can also track your account balance and how close you are to breaking even on your placemat through royalties / secondary sales.

With an “investment” of $20, an active placemat trader who is able to command good secondary prices should be able to cycle through at least five new placemats -- and perhaps many more if they focus on used placemats.

Step 6. Enable withdrawals and self-custodying

The first “withdrawal” is not really a withdrawal. Users should be able to easily purchase new placemats if they have enough of a balance in their wallets. The financial tokens in their wallet should be redeemable for placemats.

The second use case is letting users export their private key so they can take custody of their wallet address. This is how we onboard a million new users!

A third use case, similar to how CEXs operate, might be to enable users to transfer their balance (of money, not placemat tokens) to another Ethereum address.

There could be a mechanism to incentivize users to take custody of their wallet address. Perhaps their financial tokens go back to the protocol if they aren’t used or transferred within a given period of time. Perhaps they go towards buying a placemat for a family in need! (Think Warby Parker or Tom’s buy-one-give-one)

Step 7. Make it a headless brand

Headless brands refer to community-driven brand dynamics, without a centralized managerial body.

Make it easy for any artist + educator to quickly spin up and distribute their own placemats!

Why stop at placemats?

The same circular economy / game mechanisms could be applied to other items that have a long shelf life but short useful life: books, physical art, coffee mugs, winter hats, etc.

If you like this idea and want to collaborate, collect it and then send me a DM on Twitter or look me up on Telegram.

This is my first attempt at creating a series of modular, oracular impact assessments for Gitcoin Grants.

Each assessment is modular because it is derived independently, is self-contained (within a round), and is easy to combine with other assessments. Each assessment is oracular in the sense that it is automated and built on top of public datasets that capture real-world events.

Communities of projects and funders can benefit from better feedback mechanisms and finer-grained tools for allocating resources.

In the long run, I’d love to see a large, decentralized ecosystem of impact assessments. No single impact assessment can capture the full impact of a project. Nor should any one assessment be relied upon for 100% of resource allocation decisions.

We need many credibly neutral, open, and forkable impact assessment methodologies working together.

Think of how Rotten Tomatoes combines expert and amateur movie reviews. Maybe there could be something similar for retrospective grantmaking?

My own impact evaluation should be viewed as nothing more than a single data point. I happily concede that the metrics I picked are pretty easy to game. Per Goodhart’s Law (when a measure becomes a target, it ceases to be a good measure), I expect some if not all of these methods to be laughably insufficient at predicting future impact - especially if people start to think that they are useful predictors of impact or funding. 

You can view my processed dataset here on IPFS. You can also see a Google Sheet with the output assessment scores.

I hope this inspires you to create your own, better assessments!

The 158 projects currently on Gitcoin Grants have been deployed across three rounds:

• Climate Solutions (50 projects) - donate here

• Ethereum Infrastructure (22 projects) - donate here

• Open Source Software (86 projects) - donate here

To get the data on the projects, I queried the subgraph for each round and extracted the metadata blobs from IPFS. The metadata contains information about each project including its wallet address, main Github repo, and Twitter handle. 

Next, I ran some scripts to gather additional public data about each project:

• On-chain: I checked if the project’s wallet address has an ENS domain or Lens profile registered. I like seeing projects commit to building an on-chain reputation. These are two of the most popular web3-native identity protocols currently.

• Github: using the basic Github API, I gathered metrics on when the repo was created, when the last commits were made, and how many forks/stars it has. These are reasonable proxies for the longevity and activity of a project. My impact assessments for projects in the Ethereum Infrastructure and OSS rounds were heavily weighted by Github metrics.

• Twitter: using the Twitter API, I pulled metadata about each account, including follower/friends lists. Then, for the projects within each round, I constructed a network graph and determined which project nodes had the most centrality. (Yes, this is basically a popularity contest.) Mutual support is a common theme in web3 communities, particularly the ReFi / climate community, so this is a reasonable approximation of which projects are having the most impact at least in terms of meme propagation.

Once my datasets were ready, I normalized the indicators and created ranking formulas for each round. For example, Github activity is weighted more heavily in the ranking formula for Open Source Software projects than for Climate Solutions. You can fork or play with the data here (IPFS) and here (Google Sheet).

Finally, I selected the top 20% of projects from each round (for a total of 30 projects).

• Natives in Tech

• TaterDAO

• Shamba Ecological Oracle and DMRV Network

• Bloom Network

• .basin - perpetual place-based climate & nature finance

• ReFiDAO X Commons Stack: ReFi Commons Prize

• Treejer Protocol

• Kokonut Network

• Web3beach

• BETTER

• ethers.js

• Blockscout 2.0 - Premium Open-Source Block Explorer

• rotki

• TrueBlocks and the Unchained Index

• Lenster

• web3swift

• Vyper Smart Contract Language

• Electronic Frontier Foundation

• Dapp-Learning

• vfat.tools

• DefiLlama

• The MoonMath Manual to zk-SNARKs

• Giveth

• Tally Ho! - Open Source and Community Owned Wallet

• Jolly Roger

• POAPin

• BrightID 🔆 Universal Proof of Uniqueness

• CirclesUBI

• Lenstube

• devpill

What are some of the dimensions beyond taste and nutrition that we can use to describe the value of food? What makes for a truly rich food?

Before answering those questions, let me first share a personal story about a favorite food of mine. It’s a food that I believe is among the most valuable foods on Earth!

I grew up in Rhode Island, in a family that would rarely go out for dinner.

My father, who immigrated to the US from Italy as a teenager, did all the cooking at home. This meant that six out of seven nights a week we’d eat pasta for dinner. And, if we went out for dinner, it was usually to an Italian restaurant on Federal Hill, Providence’s Little Italy.

So it was unlikely that I would be exposed to Ethiopian food at an early age.

But I had an older cousin who lived in Boston. An adventurous college student, she invited us out for Ethiopian food one night.

I was probably only seven or eight years old, but I remember the experience vividly. The restaurant was dim and spacious. We sat on the floor, surrounding a large basket that served as our table. The food was like nothing I’d experienced before -- rich, full of unfamiliar flavors and textures. We ate with our hands.

It felt like a celebration, an occasion centered on the food, which we all partook in as equals; not an occasion centered on grown-up talk with a kid’s meal and placemat for me to draw on.

I’m assuming what we ate was beyaynetu.

If you’ve ever had Ethiopian food before, then you’ve most likely had beyaynetu. It’s a colorful spread of different vegetarian sauces served on a large roll of injera.

This is what it looks like.

We went to the Ethiopian restaurant in Boston a handful of times after that. If we were going to Boston, that was my one request. It was something I looked forward to for days in advance.

In middle school, I created a kid’s cookbook that included a recipe for injera in it. As I got older and became more independent, I sought out Ethiopian food whenever I had the chance.

In 2007, I visited Ethiopia for the first time. I would go on to live in Addis Ababa from 2008-2013. I still travel to Ethiopia often, and seek out Ethiopian food whenever I’m exploring a new city with a large Ethiopian diaspora.

I recently learned of a concept called the “Eight Forms of Capital”. It provides some new language for thinking about the value of things.

The idea was first published in a blog post on AppleSeed Permaculture by Gregory Landua and Ethan Roland.

The Eight Forms of Capital are:

• Social capital, such as influence and connections.

• Material capital, non-living physical objects, both raw and processed

• Financial capital, currencies and other tools of the global financial system

• Living capital, living beings including plants, animals, and soil

• Intellectual capital, knowledge learned from a book or school

• Experiential capital, knowledge gained by doing

• Cultural capital, shared knowledge of a community

• Spiritual capital, religion, spirituality, or other means of connection

The most important takeaway is that there’s more than just financial capital. Even in your food.

Ethiopian food -- and beyaynetu in particular -- is rich in all eight forms of capital. I think this is what has captivated me about it ever since childhood.

Here’s what I mean.

At meals in Ethiopia, everyone gathers round and eats off of the same spread. It doesn’t matter if you are lifelong friends or new acquaintances.

People feed each other (”gursha”). With their hands. It’s a sign of unity and togetherness.

https://twitter.com/ObangMetho/status/1172593051702910976?s=20&t=fKQOB6-nfI_TRRFVUKZuWw

Ethiopian stews (a.k.a wots) are cooked in clay pots.

There are no plates or silverware -- just injera, which you eat, and your hands.

There are no napkins -- water is brought to you before and after eating to clean.

Yes, you can purchase Ethiopian food with money at a restaurant. However, it will never taste as good as a home-cooked meal.

Beyaynetu is a staple food eaten by the rich and poor, peasants and emperors.

Injera is made from teff, a lovegrass native to Ethiopia.

Farmers grow teff in rotation with lentils & split-peas, which are nitrogen-fixing. They take advantage of bacteria already in the soil to capture nitrogen from the air -- essentially making their own fertilizer.

A typical Ethiopian spread is full of kale, collard greens, carrots, lentils, and split-peas. These foods are rich in brain-healthy nutrients like vitamin K, lutein, folate, and beta carotene.

Plus, the darker the injera is, the more iron it has in it. Ethiopian food is good for your brain and your body.

It also carries deep ancestral wisdom. Recipes have been passed on for generations. There are no cooking schools. There is only learning as an apprentice.

“Individual family matriarchs would experiment and add their own unique additions to their spice blends, tweak recipes and techniques, perfecting them through the years.”

--Tsehai Fessehatsion

Methods for fermenting and baking injera, for cooking and seasoning the stews, maintain a close connection to the land and reflect the unique constraints and gifts of the Ethiopian highlands.

Ethiopians give great attention to the experience around the meal.

At feasts and holidays, people wear traditional clothes, dance. They sit on traditional 3-legged stools, eat off woven baskets.

Meals are completed with fresh coffee, roasted on the spot.

Ethiopia is a pluralist nation with different religions and ethnic groups all sharing the same food. “National” food has the same meaning anywhere you go, regardless of other regional specialties.

Beyaynetu is halal, kosher, & “fasting”. Fasting is what Ethiopian Orthodox Christians call food that is free from animal products, effectively vegan food. Orthodox Christians are expected to fast for ~180 days, including the lent period before Easter and on Wednesdays and Fridays throughout the year.

https://twitter.com/MarcusCooks/status/1039999666933256192?s=20&t=fKQOB6-nfI_TRRFVUKZuWw

Eating Ethiopian food is a celebration of Ethiopian culture & heritage.

Sharing a meal - and receiving a “gursha” (someone else feeding you) - is the most important induction into Ethiopian culture.

The most famous Ethiopian restaurant in Addis Ababa, Yod Abyssinia, bills itself as a “cultural restaurant”. It fills up each night with families, friends, tourists, office workers, and partygoers looking for much more than a good meal.

Once I grokked the Eight Forms of Capital, I started looking at everyday objects in a new light.

“Much of our food system depends on our not knowing much about it, beyond the price disclosed by the checkout scanner; cheapness and ignorance are mutually reinforcing.”

-- Michael Pollan

White bread, for example, may be rich in financial capital: it’s cheap to consume and profitable to produce. But it is exceedingly poor in other forms of capital.

When we only prioritize financial capital, we miss out on the richness of ancestral wisdom and culture. We neglect the living and material connections to our food.

Natural wine, on the other hand, is rich in all forms of capital. Each producer, each vintage offers a wealth of latent value. No two wines are alike. And this value manifests in an equally rich range of settings and contexts at the time of consumption. Sometimes an occasion calls for a specific wine and sometimes a wine calls for a specific occasion.

These are the types of foods we need to seek out and create more of. We need much more than financial capital in our world to make us healthy and whole. We need foods that regenerate our land, our bodies, and our communities.

I encourage you to reflect on that the next time you eat a meal -- and to share it with the people sitting next to you.

You made it!

First off, congratulations for making it this far! Hopefully it’s been an interesting and engaging 14 days, going from setting up your first wallet to learning about NFTs, DeFi, and DAOs, to funding public goods on Gitcoin.

I began this series in April 2022. Over the last few months, the price of Ethereum (and other crypto assets) has fallen precipitously. I had to update my intro paragraph multiple times over the course of the past few months.

However, if you’ve made it this far, I hope it’s become clear to you that this series is not about trying to get rich or make money. It’s about learning to use a nascent technology and, in doing so, grasping this technology’s potential to reshape the internet.

Although we’ve done some token transfers and swaps, we’ve neglected to cover one of the earliest and most obvious use cases for crypto: sending money.

Nearly a decade ago, crypto was heralded as a way to move money freely and anonymously. Here is an excerpt from a 2012 article in Wired:

Once users download the bitcoin app to their machine, spending the currency is as easy as sending an email. The range of merchants that accept it is small but growing; look for the telltale symbol at the cash register. And entrepreneurial bitcoiners are working to make it much easier to use the currency, building everything from point-of-service machines to PayPal alternatives.

The article continued by enumerating all the dubious things one could do with crypto payments:

Mark Suppes, an inventor building a fusion reactor in a Brooklyn loft from eBay-sourced parts, got an old ATM and began retrofitting it to dispense cash for bitcoins. On the so-called secret Internet (the invisible grid of sites reachable by computers using Tor anonymizing software), the black-and-gray-market site Silk Road anointed the bitcoin the coin of the realm; you could use bitcoins to buy everything from Purple Haze pot to Fentanyl lollipops to a kit for converting a rifle into a machine gun. A young bitcoiner, The Real Plato, brought On the Road into the new millennium by video-blogging a cross-country car trip during which he spent only bitcoins.

These early use cases damaged the sector’s reputation. Unfortunately, many still associate crypto with buying drugs on the dark web.

Since then, the hype around anonymous payments has certainly died down. I would hazard a guess that money transfers represent a relatively small proportion of all activity on the Ethereum network -- and the transfers that do happen are far more likely to be in a stable coin like DAI or USDC in exchange for legitimate work, rather than ETH or Bitcoin in exchange for illicit goods.

Why aren’t crypto payments more common?

Money must be a medium of exchange, a unit of account, and a store of value. ETH meets the first two conditions, but has not yet proved to be a reliable store of value. Look no further than the price action over the last three months.

Stable coins, ie, coins whose value is pegged to the dollar, address the “store of value” problem. But one of the challenges with using stable coins for payments is gas fees, at least with Ethereum-based stable coins on Layer 1. You don’t want to spend $5 in gas to send $5.

Several alternative Layer 1s are working on this issue. One chain, called Luna, recently crashed. Another, called Binance Smart Chain, is cheap and easy to use, but highly centralized.

Celo is a smaller Layer 1, but more decentralized and explicitly focused on increasing financial access around the world. The Valora App, which is built on Celo, lets users make cash transfers quickly and cheaply, through an interface that looks and feels like a web2 app like Venmo. (You can buy Celo on Coinbase and transfer it to your Valora wallet through a similar process as described here.)

Today, we’ll just make a simple transfer using MetaMask’s built-in send function. We’ll be sending a nominal amount of money only. You can send it to a friend; you can set-up another MetaMask wallet and send it to yourself; you can even send it to me :)

Steps

1. Open the MetaMask extension. (It doesn’t matter what page you have up in your browser.)

2. Switch the network from Ethereum to Polygon (Matic Mainnet).

3. Click the Send button.

4. Copy-paste the wallet address you want to send money to. (If you want to send to someone’s .eth address, then unfortunately, at present, you still need to look up the public key first. You can do that easily by going to Etherscan, searching for the .eth address, and then copying the Resolved Address like you see here.)

5. Choose the Amount you want to send. You can pick something small like 1 MATIC or even 0.1 MATIC.

6. Click Next, review the gas fee (it should be negligible), and confirm the transaction. Hopefully it will execute in a few seconds!

You’ve covered a lot of ground in 14 days!

At this point, it may be helpful to review your transaction history using a site like Zapper. If you set the currency to ETH (not USD), you can see how much of your ETH has been preserved (and how much has been spent on other things, such as your .eth domain name and those pesky gas fees).

If you want to know how much has gone to gas fees, then go to Etherscan and check out the TxnFees widget on the Analytics page associated with your wallet address. You can see mine here. I spent a total of 0.03 ETH on gas fees.

If you want to check how your Klima tokens are doing, go to the Klima app. In my case, I purchased 1.6 KLIMA back in April and, by staking them, my balance has grown to a little over 2.3 KLIMA today.

You can also check out your staked Ethereum on Lido, although the 4% APR will be harder do discern. (My balance has grown from 0.0329 to 0.0331 stETH in about one month.)

While this concludes our immersion program, hopefully it marks the beginning of your journey in web3.

This is a new frontier: I recommend exploring it with other people. Share this course with friends and family who are crypto curious. Read articles; listen to podcasts; explore crypto Twitter; join a Discord server or two. Ask questions. Everyone was new to this -- and most people were in your shoes a few months or at most a few years ago.

Most importantly, learn by doing and experimenting with different dapps, chains, and protocols.

As you explore further, I think you’ll appreciate that web3 encompasses a lot of communities, belief systems, and hopes for the future.

If you want any specific advice, such as particular communities to get involved in (e.g., “Regenerative Finance”, “Impact DAOs”, “Coffee NFTs”), then send me a direct message on Twitter and I’ll try to help.

So long, and good luck!