The difference between App Coins and Protocol Tokens
The Ethereum blockchain is a primordial soup of smart contract bytecode undergoing constant mutation and reconfiguration. When the ERC20 Token was conceived, this small but useful building block was immediately replicated and assembled into crude systems that have steadily increased in complexity and utility over time. Each additional building block that is added to our communal tool set will accelerate innovation, leading to new applications for Ethereum smart contracts. To develop these building blocks faster we must embrace a philosophy of standardization and decoupling. Unfortunately, the current culture surrounding token sales has created incentives that do not align with these beneficial practices. This is because token sales are being used to drive network effects around specific applications (dApps) rather than the common building blocks (protocols) that make applications possible.
Protocols
Cryptoeconomic Protocols
When discussing blockchains, the term “protocol” is typically used to refer to the set of cryptoeconomic rules that maintain distributed consensus across a peer-to-peer network. In this sense of the term, there is one protocol per blockchain and one native token per protocol (with a few exceptions). However, blockchain consensus isn’t the only use case for cryptoeconomic protocols.
More generally, cryptoeconomic protocols create financial incentives that drive a network of rational economic agents to coordinate their behavior towards the completion of a process. A native token or protocol token is used as “the carrot and stick” to drive behavior. Active participation in the protocol may be optional, however, the process that is driven affects the entire network (in the context of a proof-of-work blockchain: miners are responsible for securing the entire network, only a subset of nodes are miners, the entire network subsidizes miners through inflation).
Network Protocols
Facilitate communication between nodes. The value of the network protocol is in the interoperability it provides and artificial financial incentives are not needed for each node to derive value.
Protocols embedded within Smart Contracts
Ethereum smart contracts are an ideal conduit for both cryptoeconomic and network protocols. These statically typed chunks of logic are deployed to an environment where network and consensus mechanisms are already handled by the Ethereum client and where Ethereum’s global peer-to-peer network can immediately tap into a contract’s functionality. By exposing a public interface (contract ABI), they can be designed to serve as public infrastructure that other smart contracts hook into. Smart contracts are also capable of controlling digital assets and implementing their own monetary policies, allowing developers to create complex financial incentives that may be used to drive cryptoeconomic protocols. In fact, Ethereum’s upcoming proof-of-stake consensus mechanism Casper will be implemented within a smart contract.
If smart contracts can serve as protocols on top of the Ethereum blockchain then we must adopt more specific terminology to describe them. Perhaps “non-native” cryptoeconomic and network protocols. So what do non-native protocols look like, and how are they different from decentralized applications? This is perhaps best illustrated with an example.
Applications vs. Protocols
Augur is a decentralized prediction markets application that is built on top of two protocols: a decentralized oracle protocol and an exchange protocol. The decentralized oracle protocol is a non-native cryptoeconomic protocol used to coordinate a network of nodes to form consensus around the outcomes of real-world events by providing the nodes with financial incentives via reputation tokens (REP). The exchange protocol is a non-native network protocol that facilitates signalling between buyers and sellers, allowing them to move tokens between each other and gain exposure to prediction market outcomes. Notice that
- the functionality of each protocol is independent of the other,
- the sets of nodes utilizing each protocol don’t necessarily overlap, and
- each protocol could be used for a variety of applications unrelated to prediction markets.
These characteristics allow the protocols to be decoupled from each other and from any particular application or use case.
App Coins
Decentralized applications (dApps) generally don’t require a native token to function in the same sense that a cryptoeconomic protocol does. Instead, dApps create value by facilitating access to protocols and end users pay transaction fees for this convenience. A reasonable app coin incentive structure might resemble
- a digital subscription or membership that is sold to end users in exchange for reduced or zero transaction fees (see Decentralized Capital’s DVIP token), or more preferably
- digital shares of equity that are sold to investors in exchange for a portion of the dApp’s future profits (may be codified into smart contracts or a legally binding agreement).
Unfortunately due to securities regulations it is difficult for dApp developers to raise money on the blockchain through a public sale of unregistered securities. So while equity app coins might provide the most logical incentives for both dApp developers and investors alike, it is currently too risky to structure app coins in this way.
That being said, public crowd sales are an irresistible source of funding for dApp developers and with traditional venture capital firms just starting to dip their feet into the world of digital assets, there aren’t many reliable alternatives. The logical next step for a dApp developer is to figure out a way to tap into public crowd sale ether by selling a token that is carefully structured to avoid classification as a security. Coinbase’s Securities Law Framework for Blockchain Tokens attempts to formalize some of the differences between “blockchain tokens” (which I believe to mean non-native cryptoeconomic protocol tokens) and securities. Functionality or utility seem to be key characteristics that distinguish a “blockchain token” from a financial security:
A token which has a specific function that is only available to token holders is more likely to be purchased in order to access that function and less likely to be purchased with an expectation of profit.
An Over Constrained Problem
After traveling this winding path of incentives, opportunities and constraints, dApp developers end up creating app coins that are directly coupled into their dApp’s underlying system of smart contracts in the name of “functionality” or “utility” but that don’t actually serve a functional purpose other than to facilitate fundraising while avoiding securities regulations.
Herein lies the problem. App coins that are directly coupled into a dApp’s system of smart contracts are the antithesis of standardization: many custom and incompatible contracts with varying levels of quality and security, all implementing the same functionality. What do end users get out of it? A larger attack surface, multiple configuration processes, app coins and learning curves to deal with.
Network Effects
Shared protocols promote standardization, decoupling and interoperability; characteristics that reinforce network effects and provide mutual benefits for both dApps and their end users. App coins align dApp developer and investor incentives, but ultimately impose a net cost on the network by fragmenting users according to the particular application that each user happens to be using. This fragmentation destroys valuable network effects and everyone is worse off for it. This may be demonstrated with Metcalfe’s Law (an admittedly naive model):
- Metcalfe’s Law states V ∝ N² where V is the value or utility of a network and N is the total number of nodes within that network. In our case N represents the total number of end users accessing a protocol through one or more dApps.
- For a set of dApps numbered i = {0, 1, 2…} that share a common protocol, the total number of end users is given by N = ∑ Nᵢ . It follows that the total value of the protocol is V = ∑ Vᵢ ∝ ( ∑ Nᵢ )².
- For a similar set of dApps, each implementing their own proprietary protocol, end users are fragmented into separate sub-networks. Therefore, the total number of end users for each sub-network is Nᵢ and the combined value of the sub-networks is V = ∑ Vᵢ ∝ ∑( Nᵢ² ).
- ( ∑ Nᵢ )² ≥ ∑( Nᵢ² )
Redundancy
A common argument is that the marginal cost of dealing with an unnecessary app coin will inevitably result in the app coin being forked out of existence. At a deeper level, this is an argument against the redundancy of parallel implementations of a single type of smart contract. Parallel redundancy can exist in the absence of app coins; parallel smart contracts that only touch ETH and which require end users to “opt-in” in other ways. Standardization of shared protocols can eliminate parallel redundancy.
Sequential redundancy is another source of inefficiency that is introduced when a protocol is forked to include new features over time, fragmenting the network of end users according to the particular version of the protocol they happen to be using. There haven’t been too many discussions in the Ethereum community about sequential redundancy or how it may be minimized, but this will become increasingly important as we design more complex systems of smart contracts that must be future-proof. In my next article I will discuss decentralized update mechanisms for non-native protocols (smart contracts) and argue that an optimal solution might incorporate a protocol token.
Conclusions
App coins and protocol tokens are two completely separate classes of digital assets. Protocol tokens provide the financial incentives needed to drive a cryptoeconomic protocol which may or may not be implemented within an Ethereum smart contract. Decentralized applications merely facilitate access to protocols for a particular use case and have no cryptoeconomic mechanisms. The current trend of coupling dApps to their underlying protocols leads to redundant smart contracts that impose unnecessary costs on end users. For non-native protocols to be standardized and future-proof they must incorporate a decentralized update mechanism; such an update mechanism is likely cryptoeconomic in nature.
See Also:
- The Blockchain Application Stack, Joel Monegro
- Fat Protocols, Joel Monegro
- Value of the Token Model, Fred Ehrsam
- App Coins and the dawn of the Decentralized Business Model, Fred Ehrsam
- How to Raise Money on a Blockchain with a Token, Fred Ehrsam
- Crypto Tokens and the Coming Age of Protocol Innovation, USV
Standardization is the process of implementing and developing technical standards based on the consensus of different parties… to maximize compatibility, interoperability, safety, repeatability, or quality.
This article is an accumulation of various thoughts developed over the last six months; a byproduct of conversations with Amir Bandeali, Fred Ehrsam, Joey Krug, Linda Xie and others.
