Capturing Crypto Value (Part 3/3): Fattening the protocols & dApps

In my previous posts (part 1, part 2), I looked at various token designs that could be useful for capturing crypto value. Basically, the aim of a crypto asset should be to become a Store of Value, charge fees or confer control. I believe that whilst the SoV argument is fairly well known, the ability for a crypto system to charge fees or deliver valuable control is often disputed (“just fork it”).

Q: How can a crypto system sustainably charge fees in a world of interoperable & open-source tech?

A: The end-user is king. In this somewhat familiar B2C landscape, a focus on brand loyalty, switching costs, and network effects of scale could be key. For projects that don’t charge fees, governance can have a role in value creation.

Climbing the Stack

When thinking about where value may accrue across the crypto landscape, I found it helpful to think of the ‘web3.0’ tech stack and the type of user at each level.

Stephan Tual’s Web Stack

There has been an understandably large focus on the infrastructure level of the stack, with developers and investors working together to create potentially lucrative building blocks. However, if the technology becomes interoperable (the big assumption) then these building blocks become modular and interchangeable rather than ecosystem specific.

These modularised components begin to lose their ability to extract fees and instead, value is only found at the top of the stack where the system interacts with the end user.

This is an application of ‘aggregation theory’ first coined by Ben Thompson of Stratechery and later applied to crypto thinking here and here. With crypto, the differences between the users interacting with the technology is key. For example, a dev interacting with systems at the base/mid of the stack will be optimizing for ‘performance at a price’ and it’s their full-time focus to scour the landscape for this. Whereas at the top of the stack, if a ‘retail’ user of a fee charging dApp encountered a similar looking free version, would they bother to switch? How different is a retail user’s decision process compared to a professional developer’s? This is key to understanding the potential for sustainable crypto value capture. Hint: I believe the strength of the relationship between the end user and the crypto system will dictate this.

The dev team in actionAugur: dApp or Protocol?

How can a dApp or protocol strengthen the relationship with its end user? Which aspects of a UX will be important to generate loyalty? I find it helpful when thinking about this to consider the popular example of the decentralized prediction market, Augur. This project charges fees for resolving prediction markets and these fees are distributed to the participating reporters via the REP token.

Augur can be viewed as both a dApp and a protocol. When operating as a dApp, the Augur platform is facing the bet-placing end user. This is done through their proprietary web app. Whereas when operating as a protocol, Augur’s reporters and prediction marketplace provide a backend service for a competing 3rd party website.

How could the fee potential of Augur’s REP token vary under these differing scenarios?

Operating as a dApp: an exercise in consumer loyalty

The user interacts directly with Augur through a proprietary web interface. Frequent, favourable experiences will reinforce classic consumer behaviours such as familiarity (saving the website to favourites), word of mouth (desire to use a service recommended by a friend) and ironically for a decentralised system, brand loyalty and trust.

Why trust? Because when websites appeared, consumers were initially hesitant to enter their credit card details into these new systems. Likewise, it’s not unreasonable to expect similar scepticism from new crypto dApp users when presented with a new platform or forked ‘pirate’ version, if the user’s original crypto dApp is operating smoothly.

A familiar use-case for crypto?

And branding? Due to the complex nature of the service technology, mainstream users may be unwilling or unable to evaluate the potential pro/cons for a competing service, even if offered at a lower price. Instead of focussing on the ‘tough’ technical questions, the consumer may look for easier ways to resolve the consumption decision- a phenomenon referred to as ‘attribute substitution’. It’s possible that in this scenario, a strong dApp brand could dominate the decision process for a consumer.

Likewise, ‘crypto’ itself can be a powerful brand when competing against the centralised incumbents. The popular 'one liner' of the public is that a crypto system is ‘decentralised’. If a crypto project’s service is neither cheaper nor faster than the incumbent it may still attract users by offering something different. Through changing the conversation to one instead about ‘decentralisation’, a consumer loyalty could be developed.

The result of this could be that ‘lazy’ consumers stick with a service that is more expensive but perceived to be better (or different). This prevents the platform from leaking users to competitors and so maintaining its network effect of a critical operating size.

The power of successful branding

Operating as a protocol: the cost of becoming a module

The user interacts with a 3rd party application that is built upon Augur’s prediction market. For example, a website specialising in financial market bets. The potential for Augur to charge fees has now been reduced for two reasons.

Firstly, if there is another way for this financial prediction website to get the outcome data (e.g. conventional centralised service or an Augur competitor, Gnosis) then Augur could be modularised and replaced by the informed and fee conscious developer building the finance website. Secondly, if the Augur fees are excessive but there are no alternatives to its service, the 3rd party could consider forking the protocol. Kyle examines this scenario for ‘AugurCo’ here.

However, it’s worth noting that there are limitations to protocol forking. Firstly, the new fork must directly contend with the established original. As per above, the consumers may be brand conscious, technically unskilled and ill-informed, making them unaware or reluctant to try the cheaper fork. Secondly, due to this competition for users it may be hard to achieve the required network scale and so worsen the UX, especially if it’s a marketplace service. And third, the security of the forked protocol may suffer if insufficient token value is achieved.

To B2C?

I think this example shows that the end consumer has the potential to be less fee-sensitive than a professional developer. Given this, I think that if a project’s interactions drift from direct user contact, from dApp to a protocol, the potential to be modularised increases.

“To B2C…or not to B2C?”

This is a similar argument to the relative merits of a B2C vs B2B business model. Since I am imagining this debate to be taking place in a future blockchain world with interoperable and technically replicable protocols, a B2C model seems to be more lucrative. However, this is clearly a crucial assumption. If you have a strong view or insight into this, please comment!

Fattening the protocols

How can a dApp/protocol’s fee and value capture potential be increased? If it doesn’t charge fees, apart from a SoV, how else can its value capture be increased?

The ideas that I discuss above suggest that for a fee charging protocol, a first action may be to avoid providing mid/base level services and instead focus on the top of the stack, serving the more malleable consumer. The next action is to keep this user happy by i) satisfying competitive niches and maintaining a superior UX. This superior UX could be achieved by ii) generating switching costs for the providers of the platform’s service, making it harder for competitors to launch in a sufficient scale, and so concentrating the participants to one network. For protocols that do not charge fees, iii) governance functions may be able to increase value capture.

Lastly, all of these actions to fatten the protocol/dApp should hopefully be reinforced by the iv) size of the network required to operate the service.

i) Competitive niches

Here’s an example of how to proactively fill competitive niches. If Augur was to launch a dedicated web interface (using a unique brand?) for each of the key prediction markets, users may be less likely to switch to a specialist competitor- an approach known as ‘brand proliferation’. This classic case study was seen in the breakfast cereal market in the 1970s and studies have attempted to explain why we have such a huge choice of cereals (and often provided by only a few companies). A common theory is that it is a strategy to ‘cover all the bases’ in order to prevent a competitor from entering.

Bitflakes…coming to a store near youii) Switching costs

By introducing switching costs to providers of a protocol’s service, competitors or forks may find it harder to achieve the necessary operating scale for a good UX.

This is one of the bootstrapping benefits of ‘work tokens’ such as Augur, which operate like a taxi license for platform service providers (see here). Further to this, work projects could increase their supplier switching costs by taking a page from Uber’s book. Uber offer services to their drivers such as car financing and discounted insurance in an attempt to reduce churn. Similar to this, Augur could provide financing to new reporters, allowing them to pay for their required REP tokens over time. This becomes particularly effective when identity (and legality, see Mattereum) is added to the crypto system- making any default from this finance model increasingly costly.

A less conventional method for creating switching costs for service providers could lie within the popular dApp, FOMO3D. I am totally fascinated with the psychology and economic paradox behind this seemingly simple game (with a prize pot of 21.8k ETH and growing!). So simple that at first glance, I initially dismissed FOMO3D as an outright scam! What I find particularly neat is a) using perpetual dividends to entice the initial users. This leapfrogs the backward induction obstacle whereby it’s usually not logical to begin playing these types of games. And b) showing that it’s not a scam via open-source immutable smart contracts. This dApp is leveraging many blockchain powers…albeit for a fairly irrelevant purpose!

I think that transferring elements of this game to another dApp or protocol could harness its mechanisms in a more productive way. For example, Augur could integrate it in order to keep reporters loyal to the REP token system. Augur could have a mini version of the FOMO game, whereby a pot of ETH is awarded to the last reporter to have participated on the platform and so the lure of this pot is used to ‘jump start’ the reporting/betting. Forked versions of Augur would not have this prize pot of ETH available to reporters. These prize pots could even be partly funded by community resources eg from the Augur treasury, as it could be argued that it is enhancing overall platform liquidity and transaction fees.

‘The Donald’ distributing his prize pot to Puerto Rico

As a general counter argument to creating switching costs, a platform could attempt to reduce these frictions by removing the requirement to own a participatory work token. This ‘free to work’ system would require the service providers to stake a SoV coin such as ETH or BTC. It could reduce the overall cost of service provision by removing the upfront capital cost that a new provider would have to amortise.

However, although the service could be cheaper, without the community-coordinating tool of a work token the ability to provide a consistent service of similar quality/liquidity as before is unclear. If the service providers don’t have an incentive or coordination device to encourage them to return to the same platform (what the work token ensures), then their skills/liquidity could be fragmented across multiple competing platforms throughout the market, resulting in a poorer UX for all.

iii) Governance

The introduction of an on-chain governance function, to a network with a high portion of active participants, may help to fatten a protocol/dApp. I’m going to set aside the debate on the relative merits of on-chain governance and instead focus on the mechanical implication that this function could have upon a token’s value capture.

A system that introduces on-chain governance via coin voting (ie the more coins you hold, the more votes you get) permits a degree of control over the protocol. If there are valuable dApps which are generating fees, the protocol on which they are operating can be considered a piece of mission-critical infrastructure. By owning some of the voting power, the dApp can attempt to influence the evolution of the critical protocol to ensure that its fee generation is not inhibited.

“First comes the bitcoin, then comes the power”

However, what number of votes should the dApp acquire? It’s been suggested by Phil Bonello that the opportunity cost of a protocol change could be a logical amount to spend in acquiring 51% of a governance token. Apart from the noted logistical problem of doing this, in practice a dApp is not operating alone on top of a protocol. If several dApps coordinated their voting, they could share the cost of this control and so spend less than they would if acting alone. At a higher level, it’s suggested that a community of dApps and institutions that benefit from the protocol may wish to pay for this control and security certainty, in the form of a decentralization ‘tax’ perhaps.

This outcome may not be ideal, as it would mean returning to the conventional (off-chain) informal system of trust and politics to organize this. However, it gives a sense of the potential value that may lie in the governance function despite the difficulty in explicitly valuing it. This function may be an important source of value for protocols that don’t charge fees and don’t expect to become a SoV.

iv) Coordinating the critical size

For a rival network charging lower fees, in order to provide a compelling UX it must quickly bootstrap a critical number of users upon launch. The coordination required to bootstrap a network is a problem that crypto tokens are known to help solve. However, this ability may be lessened when it’s one crypto system vs another, especially if some of the earlier suggested defences have been actioned. Due to this difficulty, I believe it’s possible that the risks posed by fork networks can be overstated and that requiring a critical size can help reinforce protocol fattening.

Caveat Emptor

In order for these token mechanisms such as work or governance to release their powers, they must be owned by the network participants- not just by the investors. Although this is a common battle cry from the crypto community, by conducting the above thinking on how these systems can generate and sustain value, it helped me to better understand the importance of this.

Network participants need to own the majority of the tokens, not just to ‘show usage’ to the investors, but in order for the token incentives to operate. If successful, these incentives should reduce the threat of forks and hopefully allow for larger, more holistic networks to grow.

This happens when token investors HODL without active users?

This creates an interesting predicament for the token acquiring investor. One solution may be to develop a new type of investment strategy, with participation in addition to capital being contributed to these networks. Ben Sparango is calling these ‘delegated work entities’. Another solution, that I described earlier, could be for an investor to lease their portfolio tokens to active network participants. Both solutions attempt to enhance the incentives to participate and invest.

For fee-generating networks that don’t rely upon the token for coordinating the interactions, then the amount held by passive investors is less relevant. For example, see dividend distribution tokens like KuCoin Shares (KCS).

Conclusions from my 3-part value capture series

Over these three posts I’ve tried to outline some of my thinking around the potential for value capture to emerge within the crypto token universe. This was initially motivated by Pfeffer’s fantastic critique of the non-bitcoin space and the seemingly dire potential for tokens to charge fees or accumulate value.

I started by looking at the drawbacks of the popular native payment token. Then I looked at the broader token universe, highlighting which token mechanisms could be helpful for capturing value. Finally, and discussed here, I did some thinking around how fees and value could be sustainably generated by these token systems.

In a way, I find it somewhat reassuring that in a new and technically complex asset class an important driver of token value may be the familiar strategic challenges surrounding consumer behavior.

Taking measures to entice users onto a platform, create a sense of loyalty, and increase the cost of their departure, a service can command valuable fees despite the threat of competition. Although the distinction between a protocol or dApp can blur, if a service sits close to the end-user, it’s possible that these value-capturing measures will be easier to implement.

Perhaps less familiar, are some of the possible solutions that I think may be helpful to incentivise participants to remain on a platform such as token financing and FOMO-style games. And other solutions to overcome the double-edged sword that passive token investment can create, like token leasing and investors participating in the network.

I hope that this 3-part series has shed some light on the relevant drivers of crypto value capture. I found that through writing these posts, I was often forced to rethink ideas or concepts that I had previously assumed to be true. There are still many (many!) different ways to approach the topics that I’ve focused on, so please get in touch with your thoughts and feedback.

Many thanks to Nathaniel Whittemore, Joanna Hubbard & Arek for your inital feedback on this post!

// Follow me on Twitter @CryptoBonsai for more debate :)

Capturing Crypto Value (Part 3/3): Fattening the protocols & dApps was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.