By Chris Ahn

There are two mechanisms we know of where a business becomes more effective with greater scale. The first is network effects, and the second is economies of scale.

A social network is the classic example of a network effect in action. If I am the only person in the network, it is not very useful; if 10 of my friends are in the network, it is more useful; and if all of my current and potential friends are in the network, it is very useful.

Network effects are powerful because each incremental user makes the network marginally more effective in acquiring and retaining users. This means that the cost to acquire and retain one more user decreases as the network grows [1]. Becoming more effective with more scale is the ultimate form of defensibility.

Most crypto projects we know strive to achieve network effects, primarily in the form of liquidity network effects. AMMs, lending protocols, and NFT marketplaces all chase it. The theory is that more liquidity begets better pricing; better pricing begets more users; more users beget more fees; and more fees beget more liquidity.

Unfortunately, network effects are rare, and most businesses we know don’t have one. Instead, most businesses we know exhibit economies of scale, the other mechanism in which a business becomes more effective with greater scale.

Amazon’s fulfillment centers are a great example of economies of scale in action. If I’m the only Amazon customer in my town, the cost of delivering my package is significantly higher than if everyone in my town is an Amazon user. This is because Amazon can spread the fixed cost of delivery – warehouse facilities, delivery vans, and labor – across a greater number of users to drive down the delivery cost per customer [2].

Like network effects, economies of scale allows the product to become marginally more effective with each incremental user. Unlike network effects, economies of scale exist all around us.

Unfortunately, blockchains typically exhibit dis-economies of scale, where incremental usage makes the network marginally more expensive to use. Because blockchains have competitive fee markets for blockspace, more usage drives up the cost of blockspace.

One hypothesis I have is that we need to introduce economies of scale into blockchains to crack open a diversity of crypto applications. It’s hard to know why most crypto applications are variations of marketplaces that chase network effects. But only having access to network effects and not having access to economies of scale severely limits the types of defensible businesses that can be built onchain.

The big question is how we will achieve economies of scale. It will take creativity and tradeoffs between onchain and offchain components. For example, we created rollups to amortize blockspace across more transactions, but we still need to post all the data onchain. Is there a design where all data does not need to be onchain? To make tradeoffs, we will need to be thoughtful about what needs to be posted onchain, with what levels of verifiability, and with what levels of guarantees. Financial use cases, the current showcases of crypto applications, may not make sense to take these tradeoffs. But for web3 applications in social, gaming, and other verticals, economies of scale might be what we need to unleash their potential.

—

[1] Here’s an illustrative example of how this happens:

• If a startup social network wants to grow from 1 user to 10 users (10x), it needs to invest in marketing to generate awareness and educate potential users about the benefits of joining.
• Let’s assume the cost of marketing to acquire a user is $10. To grow by 9 users, the social network needs to spend $90, and the total customer acquisition cost per user is $10.
• Now let’s assume that over the next few years, the social network has successfully grown larger. It now wants to grow from 1m users to 10m users (10x).
• Let’s assume the cost of marketing to acquire a user remains $10. This time, let’s also assume that the 1m users manage to convince one other friend to join the social network so they can be on it together.
• Because 1m users were acquired for free via word of mouth, the social network only needs to market to 8m users and spend $80m. The total customer acquisition cost per user is $8.89 ($80m marketing spend / 9m user growth).
• Customer acquisition cost decreased from $10 / user to $8.89 / user as the network grew.

[2] Illustrative example #2 for economies of scale:

• Let’s assume Amazon buys 1 warehouse, 1 delivery van, and employs 1 delivery person to service 100 package deliveries per day in a town.
• Let’s also assume each user has 1 package delivered per day, and that Amazon operates at breakeven (i.e. zero profit).
• If there is one Amazon user in this town, that user bears the entire cost of the 1 warehouse, 1 delivery van, and 1 delivery person.
• If there are 100 Amazon users in this town, the cost of the 1 warehouse, 1 delivery van, and 1 delivery person are spread across 100 users, and the cost per user is 1/100.

This piece was also published here.

By Chris Ahn

Startups obsess over how to achieve product-market fit and business model fit, but they rarely discuss business-governance fit. Web3 has brought renewed attention to this formerly overlooked concept that certain governance models are better suited for specific projects.

Choosing the right governance model is relatively straightforward for non-crypto-native projects because the tradeoffs are well known. Even a non expert can answer whether a project would benefit from being public or private, or for-profit or non-profit. For crypto-native projects, the decision is more complex because they must consider a new axis: decentralization.

Decentralized governance allows anyone to contribute without securing permission from a central authority. Like historical governance parameters, decentralization has distinct tradeoffs. Contrary to common belief, it’s a tool that can benefit some–but not all–web3 projects. Web3 founders should weigh whether their project might benefit from decentralized governance.

Historical governance models

Historically, governance decisions were based on two considerations: for-profit vs. non-profit and public vs. private.

• Public for-profit companies like Apple have a distributed shareholder base that elects a board of directors by which it is governed.
• Private for-profit companies like Fidelity have a concentrated shareholder base and are historically family owned.
• Public non-profit entities like public universities and hospitals are governed by a board in which more than 50% of its directors must be unaffiliated with the organization. In addition, profits cannot be distributed outside of the organization.
• Private non-profit entities like the Gates Foundation usually have a limited number of donors and need not have outside board directors.

The most notable feature of these historical governance models is that people can only contribute with the proper permissions, typically via employment. Apart from open source projects (which generally do not operate as formal organizations), it’s not possible for someone to simply contribute to a project. To contribute to (aka work for) Apple, Fidelity, a university, or the Gates Foundation, you must first make a serious effort to be trusted by becoming an employee.

When MakerDAO decided to hold its first ever public MKR vote in 2018, it kicked off an experiment in decentralized governance. Since then, some of the most prominent projects in web3 have adopted decentralized governance, including Uniswap ($7.4 billion), Compound ($521 million), Aave ($1.4 billion), Curve ($4.1 billion), and dYdX ($2.0 billion). These five projects alone account for over $15 billion in fully diluted market cap (as of July 25, 2022), and many more valuable decentralized projects will emerge.

The significance of business-governance fit

Choosing the right governance model is a critical decision for founders because the proper fit can act as a strategic advantage. Governance communicates two key signals about an organization:

• Commitment. When a business chooses a governance model, it conveys the objective of the organization. Consider the difference between Facebook Messenger and Signal. Signal’s status as a non-profit strengthens its value proposition as a user-first, privacy-preserving service because it’s clear that it serves no ulterior motive. Many users trust and are loyal to Signal for this reason. Even with feature parity and strong network effects, one dimension on which Facebook Messenger can’t compete with Signal is mission.
• Decision-making. Each governance model comes with its own decision-making framework that determines who makes decisions at every level. For example, public organizations ultimately answer to a board of directors that represent a broader shareholder base, while private ones answer to its majority owners. The decisions made at board meetings tend to be high level, and strategic and tactical decisions to execute on high-level direction set by the board are left to employees.

Why decentralize?

Decentralization is a unique governance mechanism because it invites anyone to contribute without permission. So why would an organization want more proverbial cooks in the kitchen when that can slow down and sometimes paralyze it from moving forward? Using the same framework as above, decentralization communicates the following:

• Commitment. It signals the desire for maximum alignment with an organization’s community of users. In historical governance structures, the maximum a user can contribute to a project without becoming an employee is by providing product feedback in designated channels or by voting on specific shareholder resolutions. Because decentralized governance invites anyone to contribute, decentralized projects make a concerted effort to directly involve their communities in what and how they develop.
• Decision-making. Decentralized governance hands over decision-making and execution powers to its community at every level. The community decides on which changes to implement by voting on proposals. It can also propose and execute improvements, including detailed product enhancements that would otherwise lie in the hands of employees.

In many ways, the case for decentralized governance is similar to the case for a public permissionless database (e.g., the blockchain). Although the latter is slower and more costly than its centralized counterpart, there is one aspect—permissionless participation—that is uniquely different, and that unlocks a net new value proposition that wasn’t previously possible.

The most common criticism of decentralized governance is that more participants mean a less efficient organization. This criticism is undoubtedly true. An organization with five decision makers has 10 possible communication channels, while an organization with 100 decision makers (20x increase) has 4,950 (495x increase). Getting people aligned becomes exponentially more burdensome with more people––hence why in politics, dictatorships make decisions more quickly than democracies, and in business, private companies are more nimble than public ones.

One way to justify decentralized governance is to answer the question: do organizations that optimize for a diversity of perspectives deserve to compete alongside organizations that optimize for fast decision-making? For those fortunate to live in democracies, the analogy should resonate. Sometimes the axis to optimize for is not speed or cost, but broad representation. Doing so can produce results that are far more durable and valuable than projects built for speed alone.

Choosing decentralized governance

Just as not every for-profit organization aspires to be public, not every web3 project needs to be decentralized. The organizations for which this governance mechanism would represent a strategic advantage are protocols. Protocols are credibly neutral projects that aspire to solve the same needs for its users for as long as possible. Three characteristics about protocols stand out:

1. Dependability. When products look to leverage protocols, the most important consideration is dependability. Will the protocol credibly serve the purpose I need it to 100 years from now as it does today? Will I have any input into potential changes? For a protocol, choosing decentralized governance shows it intends to be maximally aligned with those who are looking to build products on top of them and provides a direct path for these builders to have a say in the protocol’s development.
2. Small product surface area. Protocols are designed to be lowest-common-denominator abstractions that other products can leverage. As a result, they tend to have small product surface areas. This is desirable for decentralized governance because such decision-making is already complex with only a single product feature; additional product surface area makes decision-making exponentially more complicated.
3. Standardization. A successful state for a protocol is to become a standard with network effects. Every incremental product that builds on a protocol makes the value of doing so more compelling for the next one. Decentralized governance helps protocols become standards by providing products with skin in the game to convince others to join.

In addition, decentralization is not a binary choice, but rather, a sliding scale. Protocols should choose how much decentralization is strategically the right amount for them since it comes with clear trade-offs in execution complexity. This can be done by deciding what level of decision making will live with the community versus a pre-defined (sometimes elected) team.

It may be controversial, but non-protocol web3 projects may find decentralized governance unhelpful. As a non-protocol, the project’s objective is growth. Growth occurs by servicing more users and different use cases with additional product functionality. As a result, the product surface area will become larger and eventually unreasonable to govern across many decision makers.

Towards a Lego block future

Choosing the right governance mechanism is a strategic advantage for any organization, and deciding to decentralize is no different. Today, protocols represent the best type of project to take advantage of the strengths of decentralized governance.

It’s possible to imagine a world where modular Lego blocks of decentralized protocols built on one another will exist alongside monolithic apps. This alternative universe will be difficult to create and riddled with failed prototypes . But, it’s an exciting experiment in which to participate – an alternative built for the community, by the community, and maximally aligned with the interests of users.

By Chris Ahn and Breck Stodghill

Developer interest in web3 has grown massively over the last few years. Web3 monthly active developers are at an all time high with more joining in 2021 than any year prior. This level of developer interest has grown through multiple cycles, bringing with it innovation across numerous ecosystems and use cases. New blockchains like Polygon, Solana, NEAR, and Aptos have emerged alongside new use cases like DeFi, NFTs, and gaming.

New networks and use cases inject vibrancy into the web3 ecosystem. However, they also introduce greater complexity for builders in the form of new virtual machines, programming languages, standards, and best practices to consider. In just a few years, new programming languages like Rust and Move have emerged alongside Solidity, and new techniques like gasless minting have become best practice. We anticipate that as innovation and developer interest in web3 continues to grow, so will this complexity.

As a result, developer tools that simplify this complexity will be immensely important in bringing the next million developers into the ecosystem. Thirdweb offers a full stack of useful developer tools including pre-built and audited smart contracts, SDKs, and dashboards to help developers create, deploy, and manage their web3 apps. Thirdweb already supports six different blockchains (with more coming soon) across multiple programming languages. In addition, thirdweb offers a comprehensive UI component library and auth solution to make it simple for front end developers to build beautiful user experiences on their smart contracts. Once contracts are deployed, thirdweb’s dashboards and analytics tools ensure that every developer can monitor their smart contract’s onchain activity. By offering an end-to-end solution from creation to post-deploy management, thirdweb saves developers time and costly errors.

Great developer tooling is nuanced and requires an experienced and thoughtful team to get right. Furqan and Steven are an exceptional duo with the right track record to tackle this problem. Furqan has prior, proven experience building a developer platform as the former co-founder and CTO of AppLovin. His approach and passion to building product is evident; in deciding which initial features to build into thirdweb, he spoke with 500 potential customers to fully internalize their needs. Steven is an expert in community building as the former founder and CEO of Social Chain. The thirdweb community truly shines as an authentic and passionate place for builders to share ideas and help each other. In fact, the result of this community-first ethos is the reason why the platform is open source, 100% on-chain, and every smart contract deployed using thirdweb is 100% owned by the creator’s wallet.

Today, we’re proud to announce that Haun Ventures is leading the Series A in thirdweb with participation from other investors including Coinbase Ventures, Shopify, Protocol Labs, Polygon, and other strategic angels. We’re long term supporters of the web3 developer ecosystem and are excited for thirdweb to make web3 development more accessible. Welcome thirdweb!

This post is for informational purposes only, and does not constitute a recommendation to buy or sell securities or to pursue any particular investment strategy. This post should not be relied upon in evaluating the merits of any investment or any particular investment strategy. You should consult your own advisers as to business, financial, tax, legal, and all other related matters concerning any investment. The views expressed in this post reflect the current opinions of the authors and do not necessarily represent the opinions of Haun Ventures Management LP or its affiliates. Certain information in this post may have been obtained from third-party sources, including portfolio companies of Haun Ventures. While taken from sources that the authors believe to be reliable, Haun Ventures has not independently verified the accuracy of such information. Content is as of the date posted and subject to change without notice. Haun Ventures makes no representations about the enduring accuracy of information or its appropriateness for any given situation. Please see https://www.haun.co/disclosures for additional important information.

‍