The Web3 Sustainability Loop

A system design for long-term growth of Web3 projects, with application to Ocean Protocol

Introduction

The prequel to this essay posited the following: Imagine that you’re a founder of a Web3 project and there are several teams building applications on your technology in your nascent ecosystem. You’re asking:

How do we grow the ecosystem and make it truly self-sustaining?

The prequel surveyed existing Web3 grants programs. The challenge to any grants program is: do the dynamics truly support growth, and long-term sustainability? What if grants are a black hole? Or, if grants end, will the ecosystem survive?

I believe this should be a genuine concern for every Web3 project. If it isn’t, then it might be worth becoming a concern, lest the project fades into oblivion. Massive funding masks the problem, but doesn’t make it go away.

I believe there’s a way. As inspiration, we can look to organizations that have survived for decades and even centuries. That is, successful companies and nations. In this essay, I describe a core growth/sustainability loop and the role of stock and of fiat, for both both companies and nations.

This growth / sustainability loop can be used for Web3 projects: the Web3 Sustainability Loop.

The British Parliament symbolizes UK’s history over many centuries. [Image: CC-BY-SA-3.0]

The rest of this essay is organized as follows.

• First, I describe company business models (section 1), powered by revenue, with a focus on Web1 & Web2. However, that’s not the complete picture; we also need to include the role of company stock (2).
• Then, I describe nation-level sustainability / growth models (3), powered by taxes. To complete the picture, I then describe the role of printing fiat (4).
• Then, I describe Web3 sustainability / growth models (5), powered by transaction fees. To make a complete Web3 Sustainability Loop, we also need to include token generation (6).
• Finally, I give an application of the Web3 Sustainability Loop (7) to the Ocean Protocol project.

(1) Company Business Models

Introduction

Every business needs a means to sustain itself. If they don’t, they die. Evolution filters, mercilessly.

In companies, sustainability generally means getting people to pay you for your product or service (revenue), and using that to pay for costs (salaries, office, etc). As soon as revenue exceeds costs, you are self-sustaining, which is a first sustainability milestone. With profitability, the business is qualitatively different, since cash is no longer an existential threat. But startups aim not only to sustain, but to grow by putting surplus revenue back into growth. It’s a positive feedback loop, a snowball.

Web1 and Web2 companies explored many business models. Successful companies point to the successful models.

Web1 Business Models

When the web started to get commercial in the mid 1990s, everyone searched for business models. The web was originally about content: one giant hyperlinked document. Many people tried business model of copying and pasting offline content into the online world. Or purely online content. This mostly failed.

Some Web1 companies tried a web-native business model: treat the webpage as an application to buy things or interact with others, and take a cut. Some of these worked quite well, such as Ebay and Craigslist.

Amazon’s famous loop, pictured below, worked particularly well. Better customer experience begets more traffic, begets more sellers, begets better selection, begets customer experience. This is growth. And this growth gives even more benefit: growth allows to lower the cost structure, which lowers prices, which further improves the customer experience. With the help of this loop, and with time to see the results, Amazon has become one of the world’s most valuable companies.

The Amazon loop. Source: Amazon.com

Web2 Business Models

The Web2 generation brought mobile, social media, and the cloud. There are many models which have led to successful, sustainable businesses. Here’s a sampling.

• Paid subscriptions. This includes for software (SalesForce, Meetup, MailChimp), for content (New York Times), and more.
• Transaction Fees. Here, a platform is a middleman that charges a fee to connect buyers and sellers. This is done in in payments (PayPal, Stripe), transit (Uber, Lime), lodging (Airbnb), e-commerce (Amazon for 3rd party merchants), and more.
• Affiliate programs. Here, the referrer gets a cut of the final sale. This includes travel (Kayak) and e-commerce (Amazon Associates).
• Ads. Being the middleman for ads is the biggest internet business of all. Thus, ads are all over the place. Ads are in dedicated search platforms (Google AdWords), 3rd party webpages (Google AdSense), social media (Facebook, Twitter), apps (most free mobile apps), and content (YouTube). We may hate ads, but they do make for sustainable businesses on the web. (Let’s aim higher with Web3!)

This generalizes: all businesses need a business model to sustain themselves and grow. A business model is the design for a business machine, in the sense of Andy Grove’s breakfast factory, Ray Dalio’s Principles, or Jay Forrester’s dynamical systems research. The figure below illustrates a business machine designed to sustain and grow. At the center are the Workers: company employees who do *work* to grow company revenue by bringing the company’s product or service to market. The company’s management allocates (curates) the company revenue to get more resources (e.g. hire more workers) to grow the company even further. It’s a loop: revenue put into growth, allocated well, begets more revenue yet.

Company business model with a focus on revenue. The challenges are how to kickstart the company, and how to grow fast enough to beat the competition.

(2) Company Business Models — The Full Picture

In the previous section, we described the Amazon loop, and generalized upon it. However, it’s an incomplete picture of Amazon’s story and of other businesses. Revenue alone did not solve for cash at critical junctures:

1. Amazon needed funds to get going in the first place. It needed those funds to hire employees who then built the initial product, in order to start getting revenue in the first place.
2. Furthermore, as it was growing, it was at risk of getting out-run by faster-moving competitors, so Amazon needed more funds to grow aggressively, and revenue alone was not enough.

What did it do? It issued more company stock, and sold that stock to investors for cash. It issued stock to address the two junctures above. First, to kickstart the business, Jeff Bezos sold some stock to friends and family. Second, when Amazon’s business was starting to get traction, Jeff Bezos raised money from VCs to grow faster.

Issuing stock is a superpower for businesses. It pulls capital from the future into the present, based on the premise that allocating it effectively will increase the value even more in the future. Individuals can’t do this, families can’t do this, and cities can’t do this. But businesses can, and do.

Issuing stock is useful for kickstarting businesses and for catalyzing growth. It has one more critical use: stock can rescue a business in pain. If the business is doing poorly, the company can issue a *lot* more stock (potentially at lower valuation) and then sell that stock, as a way to survive and see another day. In startup-land this is a “down round,” but the choice is either this or company death.

Stock is a tool to rescue larger businesses too, via bankruptcy proceedings. For example, General Motors (GM) went bankrupt during the 2008 financial crisis. GM had to issue a lot more stock to new investors. The old investors got a lot of their value wiped out, but GM the business kept going, the employees kept getting paid, and the cars kept getting built.

In short, stock issuance is a powerful tool. Below is the business machine, modified to show the full picture for a well-designed company. It’s modified to account for the role of $STOCK in addition to revenue. The company issues and sells stock (left). Companies work to grow revenue and $STOCK (middle right). The company’s products / services are designed such that as usage increases, $STOCK does too (top right). Finally, stocks give the company optionality to give shareholders some lower-bound of reward such as dividends or buybacks (bottom left). This helps keep investors happy over the longer term when there is less revenue growth.

Company business model including an “outer wrapper” that uses stock as a tool, in addition to revenue.

(3) Nation-level Sustainability / Growth Models

Let’s discuss dynamics of national economies. Nations take in revenue from taxes. They use that revenue to create and grow an ecosystem of laws, public infrastructure, defense, etc. so that citizens can thrive and conduct commerce. When citizen and business well-being goes up, tax revenues go up, and the nation becomes more successful. GDP measures the amount of commerce. And so the loop goes.

The image below illustrate, using the “machine” framing. In the center, government employees and citizens do *work*. This work the amount of revenue that individuals and companies earn (right). GDP is the sum of this revenue, and acts as a KPI for the nation [1]. That revenue is taxed, for National revenue (bottom right). The national government chooses (curates) how to allocate this revenue towards further improvements to drive the loop.

Nation-level sustainability/growth model with a focus on revenue. The challenge is how to have sufficient funding in emergency situations.

The picture assumes that the only source of funds is tax revenue. That’s how governments typically approach budgeting. To illustrate: when a bill for X is proposed, the question “where do you plan to get the tax revenue to pay for X?” will inevitably arise. However, this is an incomplete picture: we must account for printing fiat. The next section elaborates.

(4) Nation-level Sustainability / Growth Models — The Full Picture

Currencies significantly reduce the friction for commerce within an economic region by acting as a means of exchange and a unit of account. Governments, banks and private institutions can all issue currency but in the 20th Century, the primacy of government as the issuer of hard currency is the accepted norm.

The issuance of currency, “fiat” brings privileges and risks. In times of economic need, governments have the ability to “print more money” with the hope that the injection of cash into the economy helps to boost consumption with the goal to let the system heal itself and smooth out dips with economic downturns. After an economy has recovered, responsible governments slowly remove the excess printed money to restore equilibrium.

The act of “printing money” is rife with risks. If too much money is printed, supply can outstrip demand, leading to price inflation because the excess money needs to flow somewhere. Without measures to restore equilibrium, inflation can spiral out of control and lead to hyperinflation where money becomes essentially worthless. When printed money is poorly allocated, it can get hoarded, which in turn can lead to economic inequality, societal unrest and economic dislocation for the most vulnerable low- to mid-income workers.

Used sparingly and with good judgment, printing fiat is a tool in a nation’s toolbox to spur economic growth and improve citizen well-being.

In the spirit of legendary MIT professor Jay Forrester’s systems approach to model national economies, the following picture summarizes a “machine” for a well-designed national economy. It starts with the tax-powered revenue loop that we previously described; and adds fiat to the picture. The government prints $FIAT (left), which is then used as income alongside tax, to be curated and spent by the government. The nation performs *work* to grow not just GDP (and tax base) but also the value of $FIAT.

Nation-level sustainability/growth model including an “outer wrapper” that includes fiat as a tool, in addition to tax revenue.

(5) Web3 Sustainability / Growth Models

This article started with the question:

How do we grow the ecosystem and make it truly self-sustaining?

That’s the goal. How do Web3 projects actually do it? Here, we take a Token Engineering systems approach to modeling it. The image below illustrates for many Web3 projects. Founders generate tokens (left), get some initial cash by selling some tokens (middle-left), build the product (middle), then ship (middle-right) it to power a nascent ecosystem (right). Then the aim is to grow the $TOKEN value. To help this, the dynamics should be designed for $TOKEN to increase as usage goes up. The founding team sustains itself by selling down more tokens for fiat over time, as they do work to improve the product.

Web3 project without loops. The challenge is dwindling $TOKEN supply and no long-term sustainability.

The main problem with this is that the founding team needs to continually dip into its supply of tokens to fund itself. That supply continues to dwindle, especially if the project has to pivot towards hitting product-market fit. With each dilution event, the founders’ incentive to make the project succeed is further diminished. If the supply gets badly reduced, the team will need to sell company stock or a second token, which then risks misalignment of incentives.

Can we do better? The image below shows an improvement, which some Web3 projects are doing. Taking a cue from businesses and nations, it introduces revenue generation (bottom right). Revenue is then looped back to Workers, in a curated fashion (middle-left). Projects are chosen based on growth potential and alignment with the project’s mission. Funding can go to the founding team and other project teams. They all perform *work* to grow the $TOKEN value and network revenue. And the loop continues.

Web3 sustainability/growth model with a focus on revenue. The challenge is getting enough revenue soon enough, for teams to be able to keep contributing.

Revenue generation can draw on ideas from Web1 & Web2 businesses — but with less extractive rates. Importantly, the token must be designed such that its value rises as usage rises.

But there’s still one big problem: too little revenue, too late. I’ll elaborate.

• If rates are too high, it will either get forked and re-deployed with lower rates, or it won’t get adopted because it’s seen as too extractive.
• If rates are too low (and usage isn’t sufficient) then revenue is too low.

Either way, teams won’t have enough funding to keep growing the project. They will stoically or heroically keep going for a while, until they can’t feed their family. Some may pull through. And most will be forced to stop, at which point the project begins its fade into oblivion.

(6) Web3 Sustainability / Growth Models — A Fuller Picture

Good news! We can overcome the challenge of “too little revenue, too late”. It takes a key change: rather than disburse all the tokens at the beginning of the project, disburse a large fraction of tokens over a much longer period of time to the workers that are adding value to the project. This gives teams a longer runway to iterate towards product-market fit (PMF), and more funds to catalyze growth once PMF is achieved.

I call this the Web3 Sustainability Loop. The image below illustrates this. It has parallels to successful nations and successful businesses. At its heart is a loop, designed for “snowball effect” growth of the ecosystem. The Workers (center) do *work* to help grow the Web3 Project Ecosystem (right). Apps and services generate revenue, using the Web3 project’s tools. A non-extractive fraction of that revenue is looped back (arrow looping from right to left) as Network revenue to the Web3 community: to Buy & Burn $TOKEN (bottom left) and back to workers curated by the community according (center-left). To catalyze growth and ensure decent funding in early days, Network rewards (left) also feed to Workers.

Web3 sustainability/growth model including an “outer wrapper” that includes $TOKEN disbursement over time as a tool, in addition to network revenue.

Here’s the loop, in words:

1. Projects are proposed, and curated, by the community.
2. Projects are funded by Network revenue, and Network reward.
3. As projects do *work* and add value, network revenue goes up and $TOKEN goes up, and ever-more funding goes to the community.

The last step causes positive feedback loop (snowball effect) such that over time, more and more projects get funded. It implies more constraints:

• Each project must add sufficient value to the ecosystem (on average).
• Value added to the ecosystem needs to get reflected in the token price

Criteria: Return on Investment (ROI)

Let’s unpack “sufficient value.” When a given project gets funded, the people behind it will need to gradually sell tokens to feed themselves and complete the project. This causes downwards pressure on the token price. Therefore: on average, value added to the ecosystem from a project must exceed the value spent by the ecosystem.

Value added by a project is hard to know in advance. Some will fail; others will succeed and bring 10x value. But this must hold true on average across projects. This gives project selection criteria:

What is the project’s expected return on investment (ROI)?

Therefore, project proposals will need to include a model on ROI. Average ROI must be >1.0 for the ecosystem to grow.

Expected ROI can be lower for lower-risk projects, and needs to be higher for higher-risk projects. It has similarity to the traditional VC thought process.

From an ecosystem perspective, if a project gets funding from outside the ecosystem, then it counts towards the value-add number, not to the value-spent number. This incentivizes projects to seek external funding, such as matching investments or quadratic funding.

Value can only be added to an ecosystem if the core product being built (by core devs) has last-mile apps for users (by app devs), which users can discover and find useful (go-to-market work). It’s a chain going from core product → dapps → discovery & usage → actual value add.

Criteria: Mission & Values

There’s a second selection criterion for each proposed project looking for funding: it must help to promote the Web3 project’s mission & values (or at least not work against them). Without this, the proposed project might as well be a Web2 project. The point of Web3 is to help equalize opportunities for all people.

A recurring value is long-term thinking. Here are some approaches to help, using time-weighted voting power. In Conviction Voting, vote increases with the amount of stake and the time staked for the vote. In Arweave Profit Sharing Communities, votes are weighted by the number of tokens the voter holds, multiplied by the time they are willing to lock them. In Yearn.finance, weight is scaled by x/365, where x is days locked.

Many excellent Web3 projects implement some of the dynamics given above. The prequel to this essay surveys them.

(7) Application of Web3 Sustainability Loop: Ocean System

Ocean Protocol is a Web3 project that aims to spread the benefits of AI by equalizing the opportunity to access and monetize data. For Ocean, we have created a system-level design that follows the pattern of the Web3 Sustainability Loop.

The image below illustrates. It’s designed to achieve sustainability over decades via funding that goes to teams (Workers) that continually add value to the Data Ecosystem. In Ocean’s case, the Web3 ecosystem (right) is a Data Ecosystem of data marketplaces, data custodians, etc. powered by Ocean tools.

Ocean Protocol sustainability/growth model including an “outer wrapper” that leverages $OCEAN disbursement over decades, in addition to network revenue.

The funding $ gets curated against selection criteria of expected ROI > 1.0, and aligned with Ocean Mission and Values . There are two complementary vehicles: OceanDAO is subjective based on promise of value-add, the Data Farming is objective based on value already added.

• OceanDAO (middle-left) gives grants for the promise of future value-add. OCEAN holders vote on which projects get funding, based on their subjective assessments against the selection criteria and the track record of grantees. Grantees work on Ocean core software, build integrations / applications using Ocean, do outreach to spread awareness, grow data supply, and more. OceanDAO takes funding from OPF treasury, Ocean 51% Network Rewards, and Network Revenue. In the longer term, the bulk of revenue will be from Network Revenue.
• Data Farming rewards workers according to an objectively-defined measure, shortly after they’ve added value. This is akin to Bitcoin mining or liquidity mining. Data Farming optimizes for (e.g.) data consume volume — a proxy for value add to the Ocean ecosystem. Data Farming takes income from OPF treasury and Ocean 51% Network Rewards.

51% of the overall OCEAN token supply is dedicated to Network Rewards, which follow a Bitcoin-like disbursement schedule (but with a ramp-up period). Some of this goes to OceanDAO, and some to Data Farming.

Token Design. The Ocean token is designed such that as usage of Ocean grows, it grows $OCEAN.

• Here’s the loop: more usage of Ocean tools in the Data Ecosystem leads to more OCEAN being staked, leading to more OCEAN demand, growing $OCEAN.
• More usage also leads to more Network Revenue, which goes to (i) burning and (ii) OceanDAO. Burning OCEAN reduces supply, to grow $OCEAN. Funds go through OceanDAO to workers who have the mandate to grow usage of Ocean tools. And the loop repeats.

Verification. We have verified this design and tuned its parameters with the help of two independently-developed computer simulations. One model uses a spreadsheet. The other model uses an agent-based simulator written from scratch in Python specifically for this project called TokenSPICE [2]. The main result is that the computer models align with the theory, and each other; this bodes well for the future of Ocean Protocol and OCEAN.

Future publications will share this in more detail yet.

Conclusion

This post described the Web3 Sustainability Loop. It takes inspiration from both businesses/nations, which take as income both revenue and stock/fiat issuance.

The core idea of the loop is to direct both Network Revenue and Network Rewards to *work* that’s used for growth. Network Rewards help to kickstart the project and to ensure decent funding. Network Revenue can help to push growth further once the Web3 project achieves traction at scale.

This post described application of the loop to Ocean Protocol, and verification of that design.

Acknowledgements

Thanks to the very much to the following people: Bruce Pon, Julien Thevenard, Simon de la Rouviere, and Michael Zargham. You’ve each contributed immensely to the thinking that led to this article and related efforts; as well as excellent feedback on the article itself. Thanks also to Sarah Vallon and Monica Botez for your reviews!

Thanks to my excellent colleagues at Ocean Protocol for the collaboration in building towards this. Finally, thanks to the broader Ocean community for their ongoing support.

Further Reading

• Here’s the tweetstorm summarizing this post.
• “Ocean Protocol V3 Posts: Links to all V3-Related Stories” [link]

Notes

[1] I don’t claim that GDP is a great KPI, just that it is a commonly-used one. Here’s a starting point for further discussion.

[2] Update Nov 20, 2020: We have open-sourced TokenSPICE, here. For an agent-based simulator that is more general-purpose and more full-featured, I wholeheartedly recommend cadCAD.

[3] Update Oct 2, 2021: in Ocean’s sustainability loop, clarified where Data Farming fits, and relation to OceanDAO. “OceanDAO is subjective based on promise of value-add, the Data Farming is objective based on value already added.”

Appendix: Comparison to The Network Flywheel

The ideas for The Web3 Sustainability Loop started gestating in late 2019. I modeled them explicitly in TokenSPICE from Jan-Mar 2020.

Just as I was putting finishing touches on this piece, Ali Yahya posted a tweetstorm describing a Network Flywheel and a related video from May 2020. It was heartening to see the similarities:

• First, both start with perennial question of “what drives token value?”
• Second, and especially heartening, was the idea in both to use a positive feedback loop (in the control systems sense) to model dynamics of token value. Great!

There are a couple big differences that make each of these models unique. The first difference is the hypothesis of what actually drives token value.

• The Web3 Sustainability Loop focuses on (a) token dynamics such that token value goes up as volume goes up (top right); and (b) using Network Revenue to do *work* to grow volume further. As a bonus, some tokens get burned as function of volume, which drives token value further yet (bottom left). This model directly links usage to value, and is amenable to valuation approaches like Net Present Value.
• In the Network Flywheel, “Token Value” has two inputs: (a) Investors who “provide financial capital” to founders to “build the protocol and bootstrap some initial token value” [ref][and ref], and (b) Vision + Protocol: “the stronger the vision for the token value is, the more the value in the broader market” [ref] as the loop goes. This model relies more on investor sentiment, without strong connection between usage and token value.

The second big difference is degree of focus on sustainability.

• The Web3 Sustainability Loop has “sustainability” in its title. It’s all about how to create a web3 project that can live and grow sustainably over decades. The Loop solves this via token generation to fund teams that nurture the project over the long term.
• The Network Flywheel doesn’t focus on sustainability directly, though it does so indirectly through its emphasis of “business model” (in the tweet and video title) and pointing to a multi-sided market (a well-known business model). Good businesses are self-sustaining over time; so there can be sustainability if there’s a good business. The difference between the Loop and the Flywheel is in emphasis.

Overall, I view the Network Flywheel as a positive contribution. It clearly struck a nerve. In a complementary fashion, it’s my hope that the Web3 Sustainability Loop will be a useful tool for Web3 builders aiming to build systems that last the ages.

Follow Ocean Protocol via our Newsletter and Twitter; chat with us on Telegram or Discord; and build on Ocean starting at our docs.