Token Function: The Value-Transfer Family and 'Payment Tokens'
Token function is a major component of cryptoeconomic design, an approach to building new token-based incentive systems. One class of functionality is value-transfer, and a particularly popular variant are application-specific currencies, also called “app-coins” or “payment tokens.” These should be implemented and analyzed with caution due to the magnitude of tradeoffs projects face.
- Value transfers is extremely common among SCI Signals projects (and the industry more generally), yet these can be subdivided into a broad range of functions including cryptocurrency, payment tokens, and discount payments.
- The payment token has been a predominant token design, and most conversations about utility token value proposition and valuation methodologies concern token payment functions, in which the token operates like an application-specific currency.
- A token with sole payment functionality is typically tasked with two features in tension: value capture for underlying platform and facilitating payments on a platform. This tension has not been elegantly reconciled today.
Value Transfer Functionality
Value-transfer functionality, where a cryptoasset is the only or a uniquely privileged method of making payments or transferring value on the host platform, is the prevalent function designed for among SCI tracked Signals projects. This functionality, relative to other functions, uniquely involves a holder spending it in exchange for goods or services.
There are several variations among cryptoassets with value transfer functions. Note that functions are non-exclusive.
Payment Functionality: Cryptoassets with payment functionality are the exclusive means of paying for goods and services on a platform. They are typically distinguished by existing as a meta-token on another consensus layer, being linked to one particular application or dApp, and being theoretically unnecessary since the consensus layer token could serve as a means of payment. Examples: include: 0x, Raiden, BAT.
Cryptocurrencies: Cryptoassets with cryptocurrency functionality are intended to act as general purpose money. Many cryptoassets are cryptocurrencies by design, rather than function; they are intended by a project to function as currency and (debatably) have a viable route to becoming one.1 Some cryptoassets are even cryptocurrencies by use; they were not designed as cryptocurrencies, but users have in practice used the asset as such, and the project has a (debatably) viable route to sustaining that functionality. Examples: bitcoin, DAI.
Discount Functionality: Cryptoassets with discount functionality influence how goods or services are priced for the buyer, functioning a bit like coupons. They are distinguished from payment functionality because they are not strictly required for usage. Examples: Binance, LEO, Caspian. likely Shapeshift’s proposed FOX token.
Transaction Fee Functionality: Cryptoassets with gas functionality are proprietary currency used to participate in a block-inclusion-auction. In contrast with payment functionality, which could easily use another mechanism of payment, many “gas” or “fee tokens” really cannot; there is no Ethereum without ETH. Some of the distinctions between payment and gas functionality are more fully elaborated later in this report. Examples: ether, bitcoin, Dash.
Each of these variations share a common property: users spend them. These specific functions were identified as separate from each other for a variety of reasons that are useful to anyone conducting crypto economic design.
- Impact on issuer: certain token function variants require new infrastructure, governance considerations, and business model impacts. Payment token functionality, for example, depends on certain businesses continuing to accept it as a means of payment. General purpose cryptocurrency aspirations would suggest a less centralized form of governance and decision-making about key token parameters.
- Usability implications: tokens themselves confront users with new incentives and decision spaces. Host platforms must take into account new burdens this places on users. Do they *need* these tokens to use the platform? How do they acquire them? What if they can’t get them? How does this impact pricing? What infrastructure might be necessary to account for usability impacts of volatility?
- Stakeholder incentives OR Source of value to the user: do users have an incentive to hold this token? Are they likely to see themselves as stakeholders? Are they driven out of the market or enticed into it if the token changes in value?
- Value capture OR Source of value to a market speculator: as we have noted elsewhere, price discovery–and hence, the existence of secondary markets–is often necessary in decentralized incentive systems. This means actors might speculate on the token, and if they do, they will make different assumptions about its target market and its value capture properties.
Sub-categorizing value-transfer functionality in this manner also enables a more fine-grained landscape of value transfer design and their relative prominence.
Categorizing assets with value-transfer functionality by these variants helps bring out some design trends and nuances in classification:
- Tokens with transaction fee functionality—the most prevalent function utilized—are typically designed either as part of a ‘smart contract platform’ more generally, or as a consensus layer cryptocurrency. The two main design paradigms for cryptocurrencies are stablecoins—DAI, Gemini, Tera, etc—and unpegged cryptocurrencies, like Bitcoin, which are also built with some form of gas or transaction fee functionality.
- Actual token functionality is often a (messy) product of project design intent, user behavior, and infrastructure. Cryptoassets not designed for a specific function may nevertheless end up used for that function. For example, while ETH was not necessarily designed as a general purpose cryptocurrency, in practice many have used it as such—it was a major currency used to invest in projects in the so called ICO era. Ultimate classification as a cryptocurrency looks beyond design intentions, and considers factors such as end user behavior and viable paths to full functionality.
- While a cryptoasset’s functionality is often the intended product of the issuer’s business model, some functionality can arise from or depend other sources as well, such that full-out token functionality depends on factors not wholly within a project’s control. For example, technical limitations could mean that ETH functionally is the only means of paying for certain dApp service, giving the token unplanned payment functionality. In this respect, some payment and perhaps discount functionality is derivative of the independent practices or business models of other ecosystem actors. Similarly, some of a token’s payment and discount functionality may also occur due to cooperation among ecosystem participants, or through deliberate efforts to attract adoption from platforms with a high user base. (The above survey does not attempt to take into account these sources of functionality.) Likewise, legal or technical infrastructure beyond what a project or designers alone can achieve may be necessary for full-out functionality, especially in the case of cryptocurrencies—like how cars don’t ‘work’ as a mode of transportation without a system of roads and rules of traffic, even if there is no flaw in their manufacturing. These factors serve to illustrate some of the aforementioned messiness in designing fully functional tokens, and acknowledge limits to even the best planned cryptoeconomic design.
The further variants and design tradeoffs within these sub-categories will be of interest to anyone desiring a richer understanding of their design implications. This report focuses on payment functionality, with other value-transfer subcategories being possible subjects for future releases.
A token with payment functionality enables holders to pay for goods and services on the platform. Tokens with such a function are generally the exclusive or highly privileged accepted platform currency. A payment token design is the origin of the term “App-coin” and “Utility token.” Smith + Crown has called these tokens “payment tokens.” The payment token has been a predominant token design in dApps and other application-focused token economies, and most conversations about utility token value proposition and valuation methodologies concern token payment functions, in which the token operates like a currency specific to a platform or market.
Tokens whose primary purpose is to facilitate payments on a platform, broadly can be understood as a platform-specific digital decentralized currency.
|Physical||Digital (centralized)||Digital (decentralized)|
|Platform-Specific||• Fair Tickets|
• Dave-and-Buster’s Tokens (Historically)
|• World of Warcraft Gold|
• Linden Dollars (Second Life)
|General-Purpose||• US Dollars|
• Gold Coins
• Cell-phone minutes
• JPM Coin
Historically, the payment function grew in popularity for a variety of reasons, not the least of which was the ease of implementation following the release of the ERC-20 standard.2 Relative to launching and supporting a new cryptocurrency protocol, launching an ERC20 token was quite easy. The payment function also required no fundamental change to the application: instead of using fiat currencies or ETH, the issuer used its own currency. Finally, metaphors abounded in the industry to help justify the design. The most prominent of which were comparing tokens to tickets to a ride, or ‘fuel,’ as if the platform were an engine that needed a special resource in order to run. While these metaphors emerged primarily to discuss the legal classification of ETH, they were applied to a wide range of tokens.
Gas is a necessary function
Smith + Crown intentionally excludes cryptoassets with solely gas or transaction fee functionality as having payment functions. While, conceptually, gas and transaction fee functionality is a subtype of payment functionality—tokens with gas functionality are the exclusive means of paying for a certain good or service—there are good reasons to distinguish the two cases. In contrast with payment tokens, where the platform could easily use another mechanism of payment but choose not to, “gas” or “transaction fee tokens” cannot. The exclusive use of ETH as payment for smart contract execution is central to the cryptoeconomic design and the Ethereum network’s game theory.
Crucially, the service purchased through transaction or gas tokens is also unique; a transaction being recorded on the Bitcoin ledger is canonical unlike Bitcoin-deposits exchanged on, for example, the Bitfinex internal ledger; it is not a ledger for bitcoin transactions but the ledger for bitcoin transactions. Similarly, from a design perspective, transaction and gas functionality typically interact with the core protocol’s mechanism design. Choices impacting a gas economy influence user and miner behaviors, and are typically made at the protocol level, meaning often changed slowly, if at all, by forking or through chain governance mechanisms.
Case Studies: Payment Functionality
Designs with payment functionality have many variants. Some ways projects utilize payment functionality include:
- Brave, a privacy-oriented web browser with tokenized rewards for advertisement engagement, has supported payments in Basic Attention Token (BAT) since May 2018. Prior versions utilized Bitcoin as a means of payment within the ecosystem, with the pivot occurring due to Bitcoin scalability concerns and the desired flexibility to seed an initial BAT ecosystem through user and developer growth pools. BAT is an ERC20 payment token with an embedded wallet in the Brave browser, giving users the ability to earn for viewing ads, automatically contribute a monthly allowance to whitelisted websites in proportion to time spent, and directly tip content creators. Brave has also offered a variety of grants and promotions to individual content creators, in pursuit of a robust token-based advertising ecosystem. Across the many payment tokens issued by industry projects, BATs have gained the most traction, with over 340k publishers registered to receive BAT across over 10m Brave users.
- LeverJ utilizes a multi-token model where one token with a payment function can be generated by locking a secondary token. For LeverJ, the first token, LEV, confers holders membership rights, allowing them to freely transact on the platform in proportion to the percent of total token supply owned. LEV can also be locked into a smart contract so to generate FEE, a secondary tradable token used to pay fees, effectively allowing LEV holders to transfer and monetize their rights to platform use.
- Bluzelle also uses a multi-token model, however, its dual token model was developed in light of the Ethereum network’s scaling limitations and the network’s inability to process payments rapidly enough to handle the range of microtransactions required for Bluzelle’s use case—users and producers continuously earn and spend small amounts of BNT tokens within the network. Specifically, the Bluzelle Network Token (BNT) is an internal token spent by consumers and earned by producers within the network, while BLZ is an ERC-20 token that can be exchanged on a 1:1 basis with BNT to enable the external trading of BNT upon other exchanges. This dual-token design allows BNT to be redeemable for a consistent amount of data storage services without being exposed to external price fluctuations.
- 0x utilizes the ZRX token, which has a variety of functionality including relayer fee payment, voting in decentralized governance, and a staking mechanism for market makers to earn a portion of protocol fees. As a payment token, it will be used relayers who charge fees for their order matching services offered to end users who thereby avoid grappling with the protocol directly and avoid sourcing counterparties to fill their orders. However, relayers are not required to use ZRX as payment for fees and in practice have adopted a wide variety of approaches including accepting fees in ETH. The extent to which payment functionality (in any token) will come to be realised in actual usage of the protocol is unclear, since payment can be implemented by relayers in other ways, such as taking a portion of the spread, if they so choose due to the inherently arbitrary nature of the off-chain order matching.
- Raiden utilizes the RDN token as a payment mechanism for routing and transaction fees on its payment channel network, which is broadly similar to Bitcoin’s Lightning Network. In contrast to Lightning, where routing fees are paid in BTC for transfers of the same, Raiden requires use of RDN to pay for transfers of any supported ERC-20 token. Though such a design arguably introduces a degree of friction for end users, who must hold (or acquire on-the-fly) RDN, it does offer a single currency for RDN routing node operators to earn fees for their work.
Two Properties in Tension
Unfortunately, a contradiction lies at the heart of the payment functionality that the industry is still grappling with today. The payment functionality, as practiced by the vast majority of tokenized protocols and applications, is tasked a token with two desirable properties that fundamentally conflict.
- First, the token was given the people with the tacit promise that it would increase in value if the platform did well, or at least its design was intended to have a ‘value capture’ property.
- Second, the token was intended as a currency for the platform, meaning it would perform best as a unit of account when it was stable i.e. did not change (including increase) in value. Increasing in value is perhaps even worse than decreasing, because it discourages people from spending it. (c.f. The ‘Bitcoin Pizza.’)
If the first property holds true (debatable, discussed below), the second appears under pressure. In addition, if the first property is seen to be true, by market speculators, then its price might move in tandem with external perception of the platform’s future growth, exacerbating short-term volatility and putting greater pressure on the second property.
In addition, the fundamental structure of a token with a limited transparent supply (most payment tokens), unbounded future demand, and a significant amount of sector-wide and project-specific hype is a recipe for chronic volatility. Volatility poses extreme challenges to users because it prevents the payment instrument from becoming a functional unit of account. If goods and services are priced on the platform in native tokens, then the relative value, denominated in a more stable unit of account, will fluctuate greatly, creating a pricing nightmare for both buyers and sellers.
This seems to be born out in practice amount tokens intending to serve as currencies.
Faced with this, projects have two choices. First, they can attempt to stabilize the currency itself. Many projects in the early ICO days recognized this challenge and made claims to do so, though few offered concrete plans for how they intended to stabilize the currency: most abandoned such claims when the industry broadly realized the challenges of this approach. For fiat money, many central bank researchers today emphasize their ability to expand and contract supply in response to demand. This is usually not possible in tokenized projects (Ampleforth and Metronome are two unique counter-examples) and if implemented, might threaten the first property of value capture, which is predicated on a limited supply of tokens and growing demand for them.
For centralized digital currencies, like World of Warcraft Gold, platforms have the ability to arbitrarily introduce new items or experiences to influence supply and new in-game issuance mechanisms (called ‘sinks’ and ‘sources’ within the industry). In addition, they can centrally fix the fiat-currency exchange rate, because they control the official and predominantly used market, in ways that decentralized token projects cannot. This approach would be theoretically attractive to token projects, but it also threatens the first property of value capture in a new way. If the central issuer can arbitrarily control price, then the case for the token being a speculative instrument weakens.
Finally, projects could instead abandon the second property of a stable unit of account, move the token’s existence into the background, and price goods and services in fiat (or ETH or BTC). The token would then become a simple settlement currency, which users acquire on the fly at whatever exchange rates happen to prevail at the time. This addresses some aspects of usability (assuming secure, functional on-the-fly conversion infrastructure), but then also leaves the question of why have the token at all. In addition, such a dynamic of on-the-fly conversion raises questions about value capture if users have no incentive to hold onto tokens. This idea became incarnated in the intuitive but deeply troubled “velocity problem” (discussed below), though certainly introduced earlier to the industry in less extreme language by CoinFund, some of the pioneers of thinking on cryptoeconomic design.
In short, launching tokens with payment functionality was perilously easy, and many projects did not appreciate the task that lay before them. For most tokens issued through ICOs, the allure of the first property of value capture was too strong. Unfortunately, it is unclear whether this property will hold at a theoretical level.
One of the propellants of payment functions for tokens was the belief that limited supply and growing demand would cause more value to accrue in the token. This seems an intuitive application of basic economic principles for pricing goods. The “official” position of the economic field on the topic seems to suggest this relationship: the Quantity Theory of Money, MV = PQ, which holds that the supply and value of money is equal to the total market it serves (that is sum of transactions using this money). This discussion cannot do justice to the complexity of this theory and does not purport to be an exhaustive treatment. For a deeper discussion of this topic, please see our report on Cryptofinancial Valuation.
Chris Burniske was the first to apply the Quantity Theory of Money to the crypto industry by proposing it as a way to estimate a fundamental value for Bitcoin. He then introduced the INET model as a means of valuing utility tokens.
In short, the use of this equation for payment tokens suggested that the price of an individual token is a function of its total market size divided by its supply. If supply was fixed and the market grew, the token value must surely grow as well. Several important developments in the debates on valuation have changed prevailing thinking on this.
- Some thinkers, most prominently Professor Warren Weber in early 2018, have pointed out that the original use of units in the MV = PQ application were incorrect, and presented an alternate equation to describe token value. This did not fundamentally challenge the idea that MV = PQ, in concept, could describe the evolution of token economies and token price, but it did highlight the assumptions one needed to make in order to start using it as a valuation tool.
- Kyle Samani of MultiCoin Capital introduced the concept of the “Velocity Problem,” arguing that velocity could approach infinite, driving the token price to zero (unlikely and technically impossible but the hyperbole helped disseminate the idea). It did take hold in the industry and led to, among other things, identity platform Civic in 2018 introducing a radically new staking-based token model (a contribution function) to replace its former payment functionality.
- An alternate approach to valuation of virtual currencies, highlighted in a little acknowledged paper on the BAT token economy, took into account forward-looking speculators of virtual currencies and merited discussion but has not been incorporated into mainstream crypto valuation discussion.
- It is worth noting that the entire premise of the Quantity Theory of Money (as used in monetary policy for fiscal stimulus) is being challenged from a sociological and historical perspective. At heart is the criticism that money supply could be responsive to demand, rather than the other way around, in the form of credit expansion when the economy grows, and the observation that the distribution and usage of newly new money greatly matters in ways economists have not appreciated. This would undercut the idea that supply controls are a meaningful independent input into either economic activity or potentially the effective exchange rate. It is worth noting that the critiques of David Graeber, author of Debt, are farther reaching than QTM, and this summary does not do justice to his ideas.
It is unclear where this broadly leaves the industry other than to point out that one of the key benefits of payment functionality is actually an ongoing debate. Chris Burniske himself acknowledges this and has been tireless in engaging with both critics and proponents, and has introduced distinctions to his original thesis that are important but beyond the bounds of this report.
When a payment token is required to operate another smart contract, it also introduces the threat of being “forked” away in an identical version of the original smart contract sans the token-for-payment requirement. 0x, which launched with only payment functionality before integrating governance functions and more recently, staking, experienced this when the Hydro Protocol used many of 0x’s smart contract functionality but, among other things, removed the ZRX requirements, “because fee-based tokens create unnecessary friction.” Any project whose core innovation is a smart contract cannot easily prevent such “forks” because smart contract code is open and available to anyone.
When a payment token is part of an application, whose core value lies in proprietary off-chain software, it runs the risk of being threatened by a competitor product whose primary innovation is not having a payment token. This would fix usability issues payment tokens present and free the project from the burden of management.
Business Model Impacts
Another oft-overlooked implication of payment tokens is that platforms must accept tokens in lieu of other forms of payment, whether fait or ETH, to continue operating. Any sellers or recipients on the platform must do so as well. This presents both accounting challenges for operating businesses (calculating value for each received token for purposes of auditing, taxes, and financial reporting) and capital management responsibilities small companies are ill-equipped for. If their costs are denominated in fiat, then they must sell their received tokens into (often thin) markets to cover their costs, creating both selling pressure and a legitimate business risk that must be managed. Any entity accepting tokens as payments leading up to and during Crypto Winter would surely empathize with this dilemma.
In addition, there are a suite of virtual currency laws that current (centralized) virtual currency issuers must respect, many relating to money transmission, and games that issue in-app currencies must abide by them. It is one (of several) reasons why open third-party markets for things like World of Warcraft Gold do not exist. Legal experts are both more informed and appropriate guides to these challenges. An appreciation of the scale of these can be found in high-level and citation-rich articles here, here, and in this CoinCenter report.
The Case for Payment Functionality
This is not to say that payment functionality is never justified. It must be reiterated that relative to other token functions, payments are quite easy to implement and require no change in the underlying business model. Users generally need to make payments. They don’t, unless otherwise required, need to stake resources to contribute work, hold resources to get platform benefits, or participate in distributed decision-making–the three other dominant “utility” token functions. Combined with the other tools that tokens give to platforms, including bounties or rewards engines to subsidize platform activity, compensation to employees, or use in attracting users, these benefits make a strong case for tokenizing in general and with payment function if other routes are undesirable. One must acknowledge that these benefits come with complex on-going responsibilities.
There are several situations that could hypothetically warrant assuming the responsibilities of launching an application-specific currency. First, a project could bet that their token will become a full-fledged P2P cryptocurrency within a larger ecosystem, on the scale of World of Warcraft and Second Life. The project would then need to take a position on how its token satisfies either or both of the two properties typically saddled onto tokens with payment functions. This, accompanied by other token functions or a set of cryptoeconomic mechanisms, like a rewards engine to accelerate growth or a distributed governance infrastructure to invite more third-party participation, could justify the burden of payment functionality. This theoretically might be preferred if one believes that core consensus tokens, like ETH, might never stabilize and will also present volatility challenges that projects have little influence over. Existing stablecoins, as meta-tokens, present similar technical usability challenges to platform-specific ones, that is, users must acquire both meta-tokens and ETH to fund their transactions, and they must be purchased one-for-one instead of being issued from scratch.
Second, tokens with payment functionality can be instrumental in building community. Outlier Ventures first put forward a thesis about Community Token Economies in 2017, and it remains a broader argument in favor of tokens in general that applies to payment functions because such functions require all users to interact with the token. This general argument (not Outlier Venture’s specifically) rests on the observation that platform-specific resources function like accoutrements for members of the platform. Reddit Coins both give Reddit users both an avenue for funding Reddit and an instrument to help curate content and reward contributions. World of Warcraft gold hoards were points of pride for many avid users. Such a community-building benefit does not address any of the challenges highlighted above about application-specific currencies but it does provide insight into why else token payment functionality might benefit users.
Payment Function Tradeoffs
Integrating payment tokens is easy, and demand for available goods and services seemingly should drive token demand. The host network need not fundamentally change its architecture, network configuration, or business model: where once users needed a digital payment mechanism, now they need the token. Implementing such a function is simple relative to other functions. For platforms spanning multiple jurisdictions, choosing to use a payment token privileges no particular foreign currency, so it’s a safe, ‘neutral’ decision that addresses foreign currency concerns. It also generally involves lower per-transaction fees than digital fiat payments. Some projects also claim that having a native token makes accounting easier, since all relevant transactions are publicly auditable on one ledger. Using a special token could enable monetary policy that insulates the token from a more volatile or less controlled cryptocurrency. While theoretical, this doesn’t match most payment token functionality as observed. Using a special token for payments could better enable community formation around a project, particularly if the token is akin to a tipping token (of relatively little value) or if acquiring it is partially a function of reputation or community contribution.
Mainstream cryptocurrencies, such as BTC or ETH, share payment token’s advantages as a ‘neutral’, easily accountable currency while additionally providing an auditable distributed ledger of transactions. Many payment tokens already require ETH for gas costs, as they are hosted on Ethereum. BTC and ETH also have greater adoption and stability relative to most other tokens. A payment token introduces usability hurdles. If the company enables ‘on-the-fly’ purchasing such that holding the token is unnecessary or that the token is effectively invisible to users, then the host platform is stuck supporting an awkward payment rail, especially when the token is a metatoken dependent on an underlying network like ETH. Price volatility creates challenges for both buyers and sellers of platform goods and services, who must constantly adjust token prices if fiat-prices prove uncomfortably volatile. A platform host can mitigate this by relying on price oracles to dynamically re-adjust prices based on fiat, but this makes the payment token seem even more redundant. Users lack reasons to hold onto tokens. Just as few citizens hold large balances of foreign currencies or stockpile fuel for future use, it is unlikely that a user will intentionally maintain a large balance, especially if the token price is volatile. Users more likely would acquire tokens on-the-fly, via an instant converter such as ShapeShift or a decentralized exchange. Similarly, those accepting tokens as payment are likely to promptly resell, preferring to hold a more stable asset instead. The industry broadly is still grappling with how to value an application-specific currency. This market-driven price discovery is often necessary for platform functioning (e.g. pricing goods and services) but a market uncertain about fundamental value introduces unpredictable speculative swings.
- Needless to say, such considerations make classifying cryptoassets as cryptocurrencies contentious. In a similar vein, cryptoassets designed to serve as currency can vary greatly in how well and for whom they serve as mediums of exchange, stores of value, or units of accounts, with different projects giving different weight to what aspects an ideal currency would realize. Smith+Crown’s own attempts aspire to not to lean too heavily into any particular outlook on what serviceability an ideal currency would display, be too dogmatic or skeptical with regards to a given project’s prospects for realizing certain functionality, and not use ‘cryptocurrency’ so loosely as to lose its utility in demarcating a special class of cryptoassets.
- This functionality predated Ethereum’s metatokens: Bitcoin supported metatokens before Ethereum came along and several (now defunct) applications used colored coins or Omni Protocol (formerly Mastercoin) tokens as payment tokens.