Web3 network effects: Designing for forkability

Exploring the interplay of composability and forkability in web3 strategy

Composability and forkability are two sides of the Web3 competitive strategy coin. On the face of it, they seem directly opposed.

Composability – the ability for Web3 building blocks to be combined and assembled in different combinations and configurations – enables greater innovation around your protocol, allowing more value to accrue to your protocol as more innovation happens around it.

On the other hand, forkability siphons value away from your protocol by enabling competition with minimal switching costs.

Traditional competitive strategy would recommend that projects embrace composability and design against forkability.

It’s tempting to jump to that conclusion.

Instead, I believe that Web3 platforms need to actively design for both composability and forkability in order to create enduring competitive advantage.

Designing for composability is obvious. Designing for forkability is counter-intuitive.

But that’s where this gets interesting!

Let’s dig in!

Rethinking competitive advantage

Web3 ecosystems are naturally geared towards high competition. Forking is easy and inevitable. A project that validates an opportunity creates an ever growing incentive for competition.

Forking, interoperability, and the possibility of vampire attacks create an entirely new competitive landscape in Web3.

While the innovation possible through composability will drive most of the value accrual to the protocol layer, the competition possible through forkability will fragment this value across multiple competing protocols, preventing outsized value accrual to any single protocol.

Overtly defensive strategies work very well in resource-based competition, where access to scarce resources forms the basis of competition.

Traditional scarcity revolved around asset control (e.g. oil fields) and distribution control (e.g. vertically integrating into a distribution network).

With Web2, what was traditionally scarce (distribution) became abundant, and scarcity shifted to data ownership and harvesting.

In open web3 ecosystems where most, if not all, resources can be replicated (even more so than ever before with forking), applying defensive strategies predicated on scarce resources will likely prove counter-productive.

Web3 communities which disagree with the project’s roadmap can easily fork the project code and shift their liquidity to competing protocols. Vampire attacks enable the financial incentives to do this as well.

Instead, web3 competitive strategy must rely on embracing this lack of scarcity and assuming the inevitability of forking.

The user experience fallacy

In the early days of Web2, software creators who had not yet seen the power of network effects often argued that the best user experience would win. While user experience on traditional products is delivered largely through product design, user experience on platforms is dependent on network effects. Improvements in the user interface and workflow proved insufficient in competing with platforms with well established network effects.

All this seems fairly obvious in hindsight. Except that when strategizing against forking, many Web3 projects still believe that they can outcompete new competitors who fork their code base by delivering a superior user experience that better retains their users or adding features and functionality faster than competing forks.

These moves may work in a few instances but are unlikely to deliver a source of sustainable competitive advantage.

Instead, I believe that actively designing for forkability and embracing new forks back to the parent project will create sustainable competitive advantage for Web3 protocols.

Web3 competitive advantage: Designing for composability

Scalable competitive advantage in Web3 is built through enabling composability and encouraging integrations across a larger ecosystem of partner protocols and applications.

Composability and allowing a larger developer ecosystem to innovate on top of your protocol enables this competitive advantage. The more the value built on top of the protocol (complements to the protocol), the greater the value in using the protocol. The larger the value created through integrations the more difficult is it for a new fork to replicate the value proposition of the original protocol. To dig deeper here, check out my essay on developer ecosystems.

Web2 banking-as-a-service (BAAS) platforms illustrate the value of integrations. BAAS platforms integrate with financial services APIs on the supply side and a wide range of fintechs and ecommerce APIs on the demand side. Replicating this requires significant investment. Integrations are built one by one and require investment and effort.

To insure against forking, ensure composability of your assets. Encourage usage of your assets across other top projects, such that your assets are critical drivers of network effects on other top projects. If usage of your protocol drives value across a larger partner ecosystem and contributes to their individual network effects, these partner projects have higher incentive to keep co-innovating. Conversely, if partner integrations create greater value for your protocol users, their incentive to switch to a fork is minimized.

Integrations and partnerships also provide further insurance against forking. A protocol with a large number of integrations and partnerships in place can organize innovation across its partner ecosystem to rapidly co-innvoate new propositions and  integrations across multiple protocols to compete with the fork. Unilateral innovation may not scale against an ever increasing number of forks but organising a larger ecosystem to co-innovate affords a more compelling response to new forks.

As an example, Boson Protocol engages in integrations across a diverse range of Web3 gaming worlds to drive greater innovation around the protocol and encourage adoption of the core protocol for transactions in these worlds.

Web3 provides a unique opportunity to strategize for composability not just at the level of protocols and ecosystems but also at the level of investment funds. Today’s most prominent Web3 funds – a16z, Outlier, and others – increasingly invest across a larger composable stack and encourage greater integrations and interoperability across investee companies, driving higher value creation for the overall fund.

For a deep-dive on composability, get your own copy of the fully illustrated Building Blocks Thesis.

Download The Building Block Thesis 

Feel Free to Share

Web3 competitive advantage: Designing for forkability

As I mentioned further up, designing for composability is obvious. Designing for forkability is counter-intuitive.

However, once you assume the inevitability of forking, designing for forkability is essentially an extension of designing for composability.

Designing for forkability turns future forks into collaboration opportunities, instead of viewing them as competitive threats. This isn’t achieved by merely embracing some fuzzy collective value / sharing economy ethos. To ensure that forking works in your favour, you need to strategically design for forkability.

The following are some considerations involved in designing for forkability.

Tools to design for forkability

Designing for forkability requires proactive planning to ensure that enough incentives are created for new forks to integrate back to the original protocol.

One-time incentives: The simplest (but expensive and hence less scalable) way to achieve this is to structure incentives for new forks to backward-integrate with your protocol.

Growth and integration fund: While a start, incentives for one-time integration can lead to perverse effects and unintended consequences. A better approach instead might be to set up a growth and integration fund (allocating tokens towards it) to support the growth and integration of new forks back to the original protocol. This may also be set up as part of a broader innovation fund which scouts for new growth opportunities and evaluates new forks as independent growth opportunities.

Growth and integration playbook: Forking the codebase doesn’t guarantee developer innovation. Every forked protocol will continue to require ongoing developer innovation to accrue value to the new protocol. Develop superior developer resources upfront, including libraries, documentation, testing engines etc. and offer this to new forks to help them bootstrap innovation. In return, require that the forks integrate back with your protocol. This may also be combined with allocation of financial incentives (as already discussed) to be offered as developer bounties to protocols that agree to the integration. 

Liquidity: The final tool in your arsenal while designing for forkability is the liquidity you have as an established protocol. Designing for forkability can involve proactively encouraging the use of your protocol’s token to help bootstrap new forks. Forks benefit from your liquidity while increasing activity on the fork increases the use of your token, driving further value back to your protocol. This may be combined with any of the other tools above to encourage new forks to integrate back with the protocol.

Designing for forkability is a radically new idea and we don’t have a lot of Web3 startups yet deliberately designing for forkability

Fork that DAO

DAO forkability involves making available the governance templates, roadmapping frameworks, and other DAO infrastructure to all members. Opening DAO documentation ensures that members who want to pursue a different direction can leverage documentation and knowhow around onboarding, bootstrapping, governance, compensation design, and project management, to kickstart a forked DAO.

In exchange for this (and possibly also growth capital), the original DAO may set up mechanisms for value accrual back to itself. One possibility is a token swap between the original and the forked DAO. Another possibility involves investment through the growth and integration fund or allowing members of the original DAO preferred terms in making angel investments in the forked DAO.

Collective action in Web3

One way to counter this is for partner projects to work together in setting up an ecosystem ‘forking’ fund, which individual projects contribute to as a collective insurance. Whenever a member protocol gets forked, the fund manages the investment needed to encourage backward integration. More importantly, the ecosystem fund provides an additional tool to encourage such integration – the possibility for the new fork to gain integrations not just with the original protocol but with all relevant member protocols, thereby driving significant value in the new protocol.

Such collective action could also be managed at the level of the investment fund. Web3 funds could benefit from actively setting up a portion of their funds towards driving growth and integration back to investee companies.

The new scarcity

Web3 turns our traditional assumptions on scarcity on its head. As I mentioned in an earlier essay, the only value driving lever that is really scarce is developer engagement. Much as traditional competition relies on acquiring and managing scarce resources to your advantage, competing in Web3 ecosystems relies on acquiring and managing developer engagement around your protocol. 

Web3 ecosystems that design for composability and forkability will be the ones best positioned to harness that developer participation

This is part of a series of articles leading up to the launch of the Web3 Bootstrapping Playbook.

Get the Web3 Builders Playbook