Why Enterprise Blockchains Fail: No Economic Incentives

Stephanie Hurder, a CoinDesk columnist, is a Founding Economist at Prysm Group, an economic advisory focused on the implementation of emerging technologies, and an academic contributor to the World Economic Forum. She has a PhD in Business Economics from Harvard.  

Is enterprise blockchain over? Not necessarily. Blockchain is hardly the first emerging technology to struggle to move from inflated expectations to reliable commercial viability.  But, if it is to have any chance of delivering on its initial promise, the approach that teams take when designing and launching products needs to change.

What’s gone wrong so far?

First and foremost, firms have been putting technical design ahead of economic design. They prioritize hiring technical teams and developing code, and then delay important discussions about the value that the product delivers and users’ incentives to adopt it. By the time the team addresses incentive design, teams have boxed themselves in to a narrow set of economic design options that are compatible with the existing code, or face deleting and rewriting huge chunks of the platform.

Blockchain platforms are economic systems.

Blockchain platforms are economic systems. Blockchain-based consortia allow enterprises to share, buy, and sell valuable data and to use that pooled data to create new goods and services, which can then be monetized. Their economic design is just as important as their technical design, and this must be reflected in the development process.

Second, teams are choosing the wrong initial use cases and founding members, typically based on the following questions:

Firms want to make a return on their investments, and these questions reflect that desire. However, they betray a fundamental misunderstanding of the economics of blockchain networks and the path to creating long-term monetization.  

Like social networks, blockchain consortia derive much of their value from network effects: that the value of the network to each participant increases with each additional participant. Many teams are familiar with this concept, which was popularized by Google’s Chief Economist Hal Varian and UC Berkeley Professor Carl Shapiro in the late 1990s. But few projects understand that different use cases have different types of network effects, and the dynamics of these network effects impact how each use case develops.  

When launching a network, bigger is not always better. Securing, say, Walmart as a founding member does not ensure a network will succeed. Instead, it is important to understand the network effects of potential early use cases and align them with the initial user base.

How should firms and projects approach this?

First, any consortium project must select an initial use case that can deliver value for a new, sparsely populated network. All other elements equal, use cases that require bilateral interactions (with two participants) are easier to bootstrap than use cases requiring multilateral (multi-participant) interactions.  A use case that facilitates data sharing between a doctor and a patient, for example, will be able to deliver value earlier than a product that requires the doctor, the patient, and the insurance company all to join. 

Second, select founding members that will be able to generate value immediately through interactions with each other. For example, social networks such as Facebook exhibit local network effects. Users benefit when other users join who are in their existing, underlying social or business networks. Use cases with local network effects may want to follow Facebook’s lead and launch with a small, highly connected subset of the underlying network (in Facebook’s case, Harvard undergraduates) to demonstrate value in the short term.   

Use cases that require bilateral interactions (with two participants) are easier to bootstrap.

Once the network has launched, the set of use cases and the network membership must grow hand in hand. The optimal growth path for each depends on a number of factors, including the network effects of each use case, the level of market penetration the network has achieved, and overlap in resource contributions and participants among different use cases.  A healthcare-focused network that launches with a product for doctors and patients, followed immediately by a product connecting insurance companies with each other, is making life hard for itself. The second product has a different user base than the first and must effectively be “re-bootstrapped” from scratch. If the network instead rolls out multiple products that serve doctors and patients, or products that connect doctors and patients with insurance companies, it can build on its existing user base and data contributions and make the most of its initial groundwork.   

With the initial use cases up and running, projects are tempted to move straight to maximizing revenues. They want to recoup their investments and demonstrate to their sponsors that their new endeavor is succeeding by achieving early monetization.  

As difficult as it is, teams need to be willing to focus on promoting adoption in the short term and postpone the focus on revenues until later. Products with network effects deliver more value as they grow, and users will be willing to pay more to use the network when there is widespread market penetration. The bulk of financial reward will come in this stage.  

A well-developed monetization plan needs to take this into account. Charging early users too much, too soon, or imposing too high up-front costs, will stunt the growth of the network and prevent the network from ever reaching market penetration. Offering early adopters discounted fees, or even subsidies for significant adoption costs, will pay off in the long term and allow the network to achieve the yet elusive holy grail of monetization.