Is it “real” or is it “virtual” currency?

Samuel M. Smith
SelfRule
Published in
28 min readFeb 21, 2019

Although the crypto-winter is upon us, with waning interest in building businesses using blockchain technology especially compared to its peak in early 2018, there is still significant value to be captured in the crypto space. If anything there may be greater opportunities in the aftermath of the crypto-bubble. Not the least are lessons learned of how not to do things. One of the lessons learned is that naive single tokenomics may not work so well. I addressed the problems of using a single token for both an appreciating store-of-value and a low friction medium-of-exchange in prior posts (see Part 1, Part 2, WP). One of the proposed options for a medium-of-exchange is just simply fiat (as in real money). But its not quite that simple. The legal landscape for using either fiat (real currency) or tokens (virtual currency) is filled with hazards resulting from anti-money laundering (AML) regulations.

DISCLAIMER: Although this post will cover in detail some of the salient issues associated with these regulations. I am not an attorney so do not consider anything is this post as legal advice. Get guidance from a competent attorney in this area before implementing any of the suggestions.

Why It Matters

Before we start crossing the legal landscape let’s examine why it matters. One of the reasons to use blockchain technology is that it may better enable some types of business models. One in particular is the class of business model called a Multi-Sided Platform (MSP). This class include business models based on two-sided networks, N-sided networks, and network markets. These are often simply referred to as platform business models (e.g. Airbnb or Uber). The primary advantage of a platform business model is that its network effects can capture value better than other types of business models. Arguably many of the most valuable enterprises in the world today rely on network effects.

Positive network effects drive platform business models.

In its simplest form a platform is a network that connects demand-side (buyers) with supply-side (sellers) of products and services. The primary role of the platform is to foster value transfer by connecting (filtering and matching) participants from both sides of the network and then facilitating transactions between them.

Platform Business Model: Participants may be demand side (consumers) or supply side (producers).

Feedback Loops

Connecting and facilitating create a virtuous positive feedback loop where more supply attracts more consumers which drives more demand which attracts more producers which drives more supply and so forth. This produces a “fly wheel” effect that quickly builds momentum as a function of how fast the feedback loop spins. A platform typically monetizes the facilitated transactions by charging fees, a subscription to participants, or by selling network behavioral data to third parties.

Two-sided network positive feedback loop.

As the platform grows, however, frictional effects can slow down the growth rate. These points of friction are called negative cross-side network effects. An apt analogy is the terminal velocity of a falling object. At a certain speed the air friction force equals the pull of gravity so that the object can’t fall any faster. Likewise, on a platform, friction effects may at some point nullify the attractiveness of the platform thereby stopping further growth (terminal size).

Two-sided network cross-side negative feedback loops.

Successful platforms figure out how to minimize the negative network effects and maximize the positive network effects. This is why understanding the regulatory landscape is so important because legal restrictions may induce overwhelming negative frictional effects that squelch futher growth.

Lowering Friction With Trustworthy Platforms

A significant frictional effect that may limit adoption at scale is a lack of trust by the participants in the platform administrator. As the platform grows and becomes dominant the entity controlling the platform (administrator) may have an irresistible temptation to extract higher and higher fees ( rent seek) while not commensurately improving the value proposition for participants. Exploitation or the fear of exploitation by a single controlling entity given platform lock-in is a good reason for participants to either leave or avoid a platform. The poster child of succumbing to this temptation is Uber with its resultant misbehavior negatively affecting the supply side (drivers) of its platform. This misalignment effect is explained in detail here. This is a weakness of centralized platforms.

In many contexts the words decentralized and distributed are synonymous but in a blockchain context we use the clarifying definitions as follows: By centralized we mean controlled by a single business entity. Whereas by decentralized we mean controlled by more than one business entity or controlled by a trustworthy computer algorithm hosted by multiple business entities. This is in contrast to distributed by which we mean that the computation happens at multiple sites and nondistributed by which we mean the computation happens at one site. Consequently an online platform may be some combination of centralized (decentralized) and distributed (nondistributed). Another complication is that decentralization is not necessarily a binary condition. More complex systems may be comprised from more-or-less decentralized components. Thus system decentralization lies on a spectrum of strongly decentralized to weakly decentralized. A system component that is controlled by thousands of entities is more decentralized than one that is controlled by a handful. This becomes relevant when interpreting regulations which, unfortunately for the most part, erroneously treat decentralization as a simple binary condition.

On a platform, governance matters. Virtuous governance resists the temptation to exploit participants. Blockchain technology includes mechanisms for building decentralized self-governing systems with checks and balances for more virtuous governance. This increases trust in the platform administration which may increase the attraction or pull of the platform. One advantage of platforms as a business model is that their positive network effects enable them to “eat” pipeline business models. Likewise the positive network effect of virtuous governance may enable decentralized platforms to “eat” centralized platforms. A major attraction of marrying blockchain technology with platform business models is to create more attractive platforms. Unfortunately the regulatory issues and associated negative friction effects associated with blockchain tokenomics may nullify this advantage.

Platform Medium-of-Exchange? Real or Virtual Currency?

An essential element of a platform business model is a medium-of-exchange (MoE) for payment. The salient features of a good medium-of-exchange (MoE) are stability, universality, and low friction. Given the dynamics of two-sided network effects, low friction is vitally important. On a centralized platform, an obvious choice is to use real money (fiat) for the MoE. On a decentralized platform, however, another choice is to use a crypto token for the MoE. This poses the question implied in the title of this post, that is, what medium-of-exchange to use; real (fiat) or virtual (crypto-token) currency?

A 2013 ruling by FinCEN (FIN-2013-G001) defines both real and virtual currency as follows:

FinCEN’s regulations define currency (also referred to as “real” currency) as “the coin and paper money of the United States or of any other country that [i] is designated as legal tender and that [ii] circulates and [iii] is customarily used and accepted as a medium of exchange in the country of issuance.” In contrast to real currency, “virtual” currency is a medium of exchange that operates like a currency in some environments, but does not have all the attributes of real currency. In particular, virtual currency does not have legal tender status in any jurisdiction.

The advent of crypto-currency has introduced digital currency that is not legal tender, i.e. virtual. But how does one tell if the digital currency, is real (albeit electronic) and not virtual. The definition above does little to help one identify when digital currency is real instead of virtual other than to say that virtual is not legal tender. So when I use an online accounting system where all the payments I receive or give are electronic how do I know that I am using real not virtual currency? The online accounting software is keeping a ledger. How is that different from say the ledger used by a crypto-currency. I have had knowledgeable people tell me, “well you’ll know virtual currency when you see it” or “if its on a distributed ledger it must be virtual”. Neither of these statement are necessarily true.

A more accurate criteria would be to assess if the funds are bank money, that is, the money is held in a deposit account at a depository institution (financial institution such as a savings bank, commercial bank, savings and loan or credit union). When using real money the online accounting software and associated ledger database is merely tracking the funds stored in deposit accounts and yet to be settled IOUs (credits and debits) owed. When I make a payment, I instruct my depository to electronically move money from my account to another. Likewise when I receive payment someone else instructs their depository to move money to my account. This movement is called settlement. The online database is tracking the accrued account balances of the real money that is stored in the depository institutions. (An exception is a stored value card where the electronic funds are stored on the card and may become lost if the card is lost).

Law of Conservation of Money

One property of depositories is that they neither create nor destroy currency. They must always balance their books as to the amount of real currency they hold. They are licensed regulated entities that are permitted to hold and transfer real money (fiat) in digital form. If they were to create more units of fiat they would be breaking the law. Likewise if they destroy currency they are also breaking the law. Only the Federal Government can create or destroy legal tender. One can say that they must follow the law of conservation of real digital currency. Evocative of the well know law of the conservation of energy, it may be stated thusly: Real digital currency can neither be created nor destroyed, it may only be transmitted from one deposit account to another.

One of the reasons regulations are somewhat confusing is that they do not always use a consistent definition of conversion and sometimes conflate conversion of value with conversion of form. If quantity is conserved then the value is also conserved. A transformation of units of a real currency that preserves the quantity is not a conversion into another currency real or virtual. It is merely a change in representation (form) but not value, such as, digital vs. material (paper or metallic) form. If quantity is conserved then absolute and relative (to other currencies) value are not changed as a result of the transformation. Conversely if quantity is not conserved then value may change. A consistent verifiable conservation of quantity through a transformation means that there was no conversion of value. Consequently if it started as real it should still be real after a quantity conserving transformation. I suggest this is a consistently applicable definition that would remove some of the confusion in the existing regulatory language. Unfortunately we are stuck with the existing regulatory language.

We can still apply, however, the conservation principle as a guide to interpreting the regulations. If an online system is creating or destroying units of a currency and that system is not run by a government then that the currency is most likely virtual. This is true of crypto-currencies in general. If that online system is merely keeping track of account balances denominated in real currency that are stored in depositories and final settlement only occurs when those depositories move funds between the associated accounts then those balances are most likely real currency. If final settlement can happen in the online system without the movement of funds between deposit accounts then most likely that currency is virtual even it it’s denominated in real currency. An exception to this would be if a group of depositories were to enter into a joint settlement agreement (with regulatory approval) where they accepted final settlement via the online balances. To restate, if the online account balances represent claims against real currency held in depositories then they likely represent real currency. Otherwise they likely represent virtual currency.

So what about digital currencies that are denominated in fiat, pegged to fiat (a type of stable coin ) with a one-to-one liquidity pool of fiat held in a depository? In this case the actual terms of the contract matter. Do holders of the digital currency have a direct claim on the funds in the depository or is there merely an agreement to convert or exchange the digital currency for the fiat funds? If its a direct claim then it may be that the digital currency in question is just tracking account balances and acts no differently than any other online accounting system. If its not a direct claim but merely a promise to convert or exchange then it may be virtual.

Distributed Ledger; Distributed Consensus

A common misconception is that if the MoE account balances are maintained in a blockchain distributed ledger then the MoE must be a virtual currency. The likely source of this misconception is a lack of understanding of distributed ledger technology. Distributed ledgers, blockchain or not, use algorithms that implement something called distributed consensus. With distributed consensus, a pool or cluster of computer servers cooperate over a network to ensure that they all have the same data in each of their own copy of the database. If the database is a ledger of transactions then the cluster is maintaining a distributed ledger. One compelling reason for distributed consensus is to provide high availability of some service which may be a distributed ledger. With distributed consensus, even though one or more of the servers fail for some period of time, the other servers keep the service up and running. There are many types of distributed consensus algorithms. One way they are characterized is by how they order the arrival of events and the shared state of the data. This is called consistency. For example with eventual consistency all the servers eventually come to consensus as to the shared state of the data. A stronger guarantee ensures causal consistency. Eventual or causal consistency may be good enough for databases but financial ledgers usually want to ensure that the events are always ordered the same on every server. This requires linear or total ordering. With total ordering the servers can implement a replicated state machine. This enables all the servers in the cluster to consistently ensure properties like no negative balances etc. Popular totally ordered distributed consensus algorithms include Paxos and RAFT.

An even more sophisticated type of distributed consensus algorithm ensures availability, consistency, and ordering despite malicious behavior of some of the servers. Suppose one of the servers were hacked, and the hackers replaced the server’s code with code meant to disrupt the distributed consensus algorithm. This would be a malicious or Byzantine fault. The term Byzantine Fault Tolerance (BFT) is used to characterized distributed consensus algorithms that can survive malicious behavior of some of the servers in the cluster. With BFT its practical to implement a decentralized distributed ledger. The servers may be under the control of multiple entities but they can still trust in the state of the data as long as a sufficient majority do not collude to defraud the others. BFT distributed consensus algorithms enable decentralized blockchains. The drawback of BFT algorithms is that they need more resources and hence are slower than non-BFT algorithms. Well known types of BFT algorithms include Proof-of-work (PoW), Proof-of-Stake (PoW), and Byzantine Agreement (BA). There are many variants and hybrids of these basic types.

Any online service of any importance, such as an online accounting program, is most likely using a distributed consensus algorithm. Financial institutions in general use distributed consensus to maintain their internal account balances. These algorithms are not usually BFT because of the associated resource demands but they are distributed consensus algorithms nonetheless. Merely tracking MoE account balances on a distributed ledger, centralized or decentralized, does not make that MoE a virtual currency or else all digital currency would be virtual.

Given the foregoing background we can now better explore the regulatory landscape. The next sections in turn look at the associated regulatory issues; first with real currency and second with virtual currency.

Using Real Currency as the Platform’s MoE

The main regulations for the use of currency stem from the Bank Secrecy Act whose purpose was to limit money laundering hence the term anti-money laundering (AML). The associated regulatory agency is FinCEN. In 2011 FinCEN released a final ruling on these regulations. FinCEN defines a money transmitter as follows (see FIN-2013-G001) :

FinCEN’s regulations define the term “money transmitter” as a person that provides money transmission services, or any other person engaged in the transfer of funds. The term “money transmission services” means “the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means.”

By location FinCEN means, at least for digitally represented funds, the person’s account at a location such as at bank.

By this definition of money transmitter almost any business that accepts payment from customers and then sends money to pay venders is a money transmitter. Non-exempt money transmitters or Money Services Businesses (MSBs) must register with the Federal Government and must be licensed in most states. The registration and reporting requirements are extensive and by themselves could make a given platform business model non-viable. Compliance would constitute a large source of friction. Fortunately, however, the ruling makes an exemption in Section (F) that covers most businesses.

Section F Exemption

From the FinCEN 2011 final ruling, the Section (F) exemption is as follows:

(F) Accepts and transmits funds only integral to the sale of goods or the provision of services, other than money transmission services, by the person who is accepting and transmitting the funds. … For example, brokering the sale of … is not money transmission notwithstanding the fact that the person brokering the sale may move funds back and forth between the buyer and seller to effect the transaction.

As long as the business is moving funds to serve an integral business purpose that is not money transmission itself, it may be exempt from regulation. The integral purpose of a platform business model is to connect participants and then facilitate a transaction between those participants. The platform acts as a broker or intermediary. Consequently as long as the platform’s facilitation function is integral to each sale, the resultant movement of money is likely exempt.

FinCEN publishes no-action rulings that clarify if a particular business model is exempt from regulation usually under section (F). For example, in this ruling FIN-2014-R004, FinCEN clarified that a company that offers escrow services to a buyer and seller in a given internet sale of goods or services is exempt as follows:

FinCEN finds that the Company’s money transmission activities are only necessary and integral to its provision of escrow services. In order to provide assurances to both buyer and seller that the buyer has enough resources to pay for the goods and services, on the one hand, and that those resources will not be released until the transaction is completed according to the purchase agreement, on the other, the Company needs to take possession of the funds and hold them in escrow until the pre-established conditions for the funds to be paid to the seller or returned to the buyer are met, then release those funds appropriately. The acceptance and transmission of funds do not constitute a separate and discrete service provided in addition to the underlying service of transaction management. They are a necessary and integral part of the service itself. Therefore, the Company would not be a money transmitter as that term is defined in our regulations.

In sharp contrast, in this ruling FIN-2008-R007, FinCEN clarified that a company that would allow consumers to protect their identities, including personal credit card information, when making on-line purchases of consumer merchandise is NOT exempt as follows:

This company … accepted any consumer and any merchant willing to use its confidential process, and played no active part in arranging, monitoring, verifying or endorsing the transactions that it processed. As a result, FinCEN concluded that this company did not provide a service independent of money transmission, notwithstanding its claim that it provided the service of security, but instead merely offered a secure method of money transmission.

In conclusion, in order to be exempt under Section (F) the platform must play an integral role in arranging transactions for which it is accepting and transmitting money.

Decentralization and Privacy for Section (F) Exemptions

In order to have a Section (F) exemption the payment component of the platform will most likely be centralized or at best only somewhat decentralized. This is the tradeoff for a Section (F) exemption. It is possible, however, to use a somewhat more decentralized approach where more than one provider of the facilitation component (which includes payment) are integrated with a much more decentralized algorithm for matching and filtering. Because real currency is being used, the funds must be transmitted through some entity’s deposit account to be disbursed at the conclusion of the transaction. Decentralization of the entities providing facilitation (payment) is limited to segmentation of the transaction flow across multiple entities that each control their own deposit account for their segment. In contrast to the direct facilitation component, the governance of the facilitation component, however, may use a much more decentralized process for selecting the entities that provide the facilitation component.

With regards privacy, because the entity controlling the facilitation (payment) component is integral to the transaction, that entity knows the parties on both sides of the transaction. The parties are therefore not private from the payment component entity. Depending on how transactions are booked in a distributed ledger the details of the transaction might be kept confidential with regards third parties and the participants might also be kept private from third parties but not from each other. A malicious facilitator could therefore expose the transaction details. This risk can be mitigated by careful permissioning of the facilitator(s) with transaction terms that hold the facilitator liable in the event of disclosure.

Prepaid Access Program Exemption

The 2011 FinCEN ruling makes another exemption to the money transmitter regulations for what it calls prepaid access programs. The most useful for platforms is a closed-loop prepaid access program. One type of closed-loop prepaid access program is commonly known as a merchant gift card. Clarifying details of prepaid access programs are provided in Definitions and Other Regulations Relating to Prepaid Access and FIN-2016-G002 Frequently Asked Questions regarding Prepaid Access. Without going into more detail, using a prepaid access program as the MoE for a platform may provide higher degrees of privacy and decentralization than using a Section (F) exemption. Prepaid access exemptions come with constraints on the daily dollar amounts for buyers and users of prepaid access. I have spent a lot of time recently investigating how to design and build prepaid access programs for the MoE of decentralized platform business models. Based on these efforts I have come to the conclusion that in many cases prepaid access might be at the sweet spot in terms of tradeoffs. Using real currency via a prepaid access as the medium of exchange gives stability, low friction/high velocity, widespread access, and if batched, low average settlement costs all with a meaningful degree of privacy and decentralization. Businesses that raised funds on an ICO with a single utility token and have come to realize the inherent flaws in that approach might find relief by moving to a dual model where prepaid access fiat is the MoE and their token is the appreciating SoV.

Using Virtual Currency as the Platform’s MoE

The 2013 ruling by FinCEN (FIN-2013-G001) previously mentioned above provides regulatory guidance for the use of virtual currency. In summary the ruling defines the following:

open (convertible) virtual currency: Virtual currency that may be converted from/to real currency and used as a medium of exchange with an unrestricted set of entities (open). Crypto currencies such as Bitcoin, Ether, and associated tokens are typically considered open virtual currencies.

The 2013 virtual currency ruling also defines three types of participants (user, exchanger, administrator) in a virtual currency platform as follows:

user: A user is a person that obtains virtual currency to purchase goods or services.

exchanger: An exchanger is a person engaged as a business in the exchange of virtual currency for real currency, funds, or other virtual currency.

administrator: An administrator is a person engaged as a business in issuing (putting into circulation) a virtual currency, and who also has the authority to redeem (to withdraw from circulation) such virtual currency.

Recall the definition of money transmitter above (FIN-2013-G001):

FinCEN’s regulations define the term “money transmitter” as a person that provides money transmission services, or any other person engaged in the transfer of funds. The term “money transmission services” means “the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means.”

This is a very general definition as it includes any other value the substitutes for currency as money transmission. Therefore using points or some other construct does not provide an exemption from regulation. Furthermore the regulation (FIN-2013-G001) breaks money transmission into three scenarios as follows:

The definition of a money transmitter does not differentiate between real currencies and convertible virtual currencies. Accepting and transmitting anything of value that substitutes for currency makes a person a money transmitter under the regulations implementing the BSA. FinCEN has reviewed different activities involving virtual currency and has made determinations regarding the appropriate regulatory treatment of administrators and exchangers under three scenarios: brokers and dealers of e-currencies and e-precious metals; centralized convertible virtual currencies; and de-centralized convertible virtual currencies.

The relevant scenarios for platform business models are the second and third ones: centralized convertible virtual currencies and decentralized convertible virtual currencies.

Centralized Convertible Virtual Currency

With a centralized convertible virtual currency there is an administrator. The rulings for the three participants with a centralized open (convertible) virtual currency are as follows:

A user is exempt; is not a money transmitter, nor an MSB, and has no compliance requirements.

An exchanger is not exempt; An exchanger is a money transmitter, is an MSB, and must be compliant.

An administrator is not exempt by default; An administrator is a money transmitter, is an MSB, and must be compliant unless the administrator qualifies for an exemption.

In general virtual currency exchangers are regulated money transmitters without exception. Likewise virtual currency administrators are regulated money transmitters but may have an exemption (see FIN-2013-G001):

An administrator or exchanger that (1) accepts and transmits a convertible virtual currency or (2) buys or sells convertible virtual currency for any reason is a money transmitter under FinCEN’s regulations, unless a limitation to or exemption from the definition applies to the person.

One possible exemption is Section (F) where the administrator provides some other business purpose integral to the transaction besides money transmission. This defeats some of the reasons to use a virtual currency in the first place, that is, to have higher levels of privacy and decentralization.

Decentralized Convertible Virtual Currency

FinCEN defines a decentralized convertible currency when there is no administrator to issue or redeem currency (FIN-2013-G001).

A final type of convertible virtual currency activity involves a de-centralized convertible virtual currency (1) that has no central repository and no single administrator, and (2) that persons may obtain by their own computing or manufacturing effort.

With a decentralized convertible virtual currency there is NOT a centralized administrator to issue currency but it is assumed that there is some decentralized mechanism such as an algorithm whereby currency is issued. It is assumed that users can obtain currency by working for it. Issuance when there is no central administrator is typically performed by some decentralized algorithm where special users such as miners are authorized by the algorithm to issue new currency units as a result of mining work. In general users of a decentralized virtual currency are exempt from regulation. This definition of user seems to have been extended to include the creators of a virtual currency who obtain currency in return for their efforts to create or program the code running the platform. In general creators of a decentralized virtual currency are exempt from regulation when they only use the currency they create to buy products and services (see FIN-2013-G001).

A person that creates units of this convertible virtual currency and uses it to purchase real or virtual goods and services is a user of the convertible virtual currency and not subject to regulation as a money transmitter.

The problem with the regulation is that it assumes that decentralization is a binary condition. As I explained above, decentralization may be graded. Essentially, the FinCEN language above redefines creators (issuers) of the currency to be a new type of user instead of an administrator. This is IMHO a faulty redefinition. It makes it much more difficult characterize graded decentralization with regards to compliance. Better would be to admit that with a decentralized convertible currency the administrative functions of issuance and redemption may be decentralized and then delineate when issuance or redemption uses are exempt instead of redefining the creators of a virtual currency as a new class of exempt user.

The ruling further delimits when creators (issuers) are not exempt (see FIN-2013-G001).

By contrast, a person that creates units of convertible virtual currency and sells those units to another person for real currency or its equivalent is engaged in transmission to another location and is a money transmitter. In addition, a person is an exchanger and a money transmitter if the person accepts such de-centralized convertible virtual currency from one person and transmits it to another person as part of the acceptance and transfer of currency, funds, or other value that substitutes for currency.

To recapitulate, FinCEN redefines an issuer (not redeemer) of a decentralized open virtual currency as another type of user. Thus on a decentralized open virtual currency, a user may not be merely someone who obtains virtual currency but may be also someone who issues the virtual currency. An issuer of a decentralized open virtual currency is classified as a user and is exempt from money transmitter compliance requirements when they use the virtual currency they create to buy products or services.

The ruling makes the assumption that in a decentralized open virtual currency this no equivalent of administrator redemption of currency. This is an oversight because a decentralized algorithm could algorithmically perform redemption like functions such as burning if not true redemption. Thus it is an open question as to whether or not a decentralized algorithmic redemption process is exempt.

Moreover the 2013 ruling by FinCEN (FIN-2013-G001) also excludes virtual currency from prepaid access programs as follows:

A person’s acceptance and/or transmission of convertible virtual currency cannot be characterized as providing or selling prepaid access because prepaid access is limited to real currencies.

This means the privacy advantages of prepaid access are not available to a virtual currency.

Tax Issues

The final regulatory issue with virtual currency (in contrast to real currency) is the tax status of virtual currency conversion. This is relevant to platform business models (2-sided networks) that use a virtual currency for the MoE. Practically speaking, no virtual currency has yet achieved sufficient universality that a platform with real products and services can function solely using the virtual currency. There needs to be both a real (fiat) currency on-ramp and a real currency off-ramp. An on-ramp allows someone to exchange real currency for the virtual currency and an off-ramp allows someone to exchange virtual currency for real currency. In order to spin up the platform flywheel consumers need to be able to pay for goods on the platform using resources they bring from elsewhere. Producers need to be able to receive payment on the platform and then cash out to be able to pay for their costs of production incurred elsewhere. As discussed above, there are exemptions that allows users to obtain (by earning it) virtual currency without going through an exchange on-ramp. This may not be a viable path for a platform that depends on the network effects of broad and rapid adoption. Anyone should be able to obtain the virtual currency without having to work for it by merely exchanging another currency for it. There are no similar exemptions for the off-ramp. The only off-ramp for a convertible virtual currency is through an exchange.

In general, an exchanger is a regulated money transmitter. An exception may be a decentralized exchange (DEX). The regulatory issues with DEXs are not clear.

An exchange as an off-ramp may impose four negative frictional network effects on the platform. The first is centralization, if indeed the exchanger is a centralized entity. The second is privacy. The exchange knows both sides of the transaction and compliant exchanges must identify their users. The third is inconvenience, going through an exchange may be an additional complex step preceded by an initial on-boarding and identity verification process. The fourth is tax liability. The IRS treats virtual currency as property for tax purposes. The conversion of a virtual currency to either another virtual currency or a real currency is a capital gain/loss transaction. This is in contradistinction to the gains and losses from real currency conversion transactions, i.e., real currency to real currency conversion such as foreign exchange is exempt under Section 988. This exemption allows real currency conversion transactions to be grouped together and treated as ordinary income.

The specific Section 988 exemption (see also IRS Code 26–988) is as follows:

Under IRC 988(a)(1)(A), the foreign currency exchange gain or loss attributable to a Section 988 transaction is generally ordinary income.

Except as otherwise provided in this section, any foreign currency gain or loss attributable to a section 988 transaction shall be computed separately and treated as ordinary income or loss (as the case may be).

To restate, conversion of a virtual currency to some other real or virtual currency is a taxable event (sale of property) and is taxed as a capital gain (loss). Each conversion transaction is a separate taxable event that must be documented separately on the appropriate tax form as a capital gain. See for example R-2018–71, March 23, 2018 as follows:

Notice 2014–21 provides that virtual currency is treated as property for U.S. federal tax purposes. General tax principles that apply to property transactions apply to transactions using virtual currency.

In Notice 2014–21 it states:

Q-2: Is virtual currency treated as currency for purposes of determining whether a transaction results in foreign currency gain or loss under U.S. federal tax laws?

A-2: No. Under currently applicable law, virtual currency is not treated as currency that could generate foreign currency gain or loss for U.S. federal tax purposes.

This tax treatment of virtual currency off-ramp transactions may induce a large enough frictional effect that by itself may make many virtual curreny MoE platforms nonviable. For example, a few crypto exchanges are now offering bitcoin debit cards that allow, at the point of sale, the exchange or bitcoin for fiat. This allows one to pay vendors in fiat but hold the funds in bitcoin. On the surface this appears to minimize some of the friction of using an exchange as an off-ramp. In the USA, however, because of the IRS ruling, each purchase may induce a conversion transaction from bitcoin (virtual) to dollars (real) which therefore may be a taxable event. I am not so sure that I want to add several lines to my tax form every time I buy lunch.

Tradeoffs

Despite the appeal of virtual currency as a frictionless MoE, actual regulatory compliance add significant points of friction. Likewise despite the appeal of decentralized virtual currency as a more trustworthy and private MoE, actual regulatory compliance makes it less private and adds points of centralization. Specifically exchangers must be regulated money transmitters. This adds friction that limits broad adoption at the on-ramp and especially at the off-ramp. One way to reduce the friction is embed the exchange function into the platform. This means partnering with an already compliant exchange(s) or incurring the costs of building a compliant exchange. If the exchange function is embedded then the friction of exchange can be reduced or made more transparent to the users of the platform except for the tax treatment. The tax treatment as property makes small dollar amount conversions very costly due to the added burden of documenting each transaction separately. Moreover, embedding an exchange function that is transparent to the platform users means tightly integrated APIs that add centralization to that single exchange or set of exchanges with supported APIs. Because the exchange(s) sees both sides of the transaction it is a potential source of privacy exploits.

Given that many of the potential decentralization advantages of a virtual currency are nullified by the FinCEN AML regulations it may make sense to just use real currency as the MoE. Its a trade-off between rapidity of adoption for real currency at the cost of more centralization for the payment facilitation component. My other tokenomics posts (see Part 1, Part 2, WP) explain a dual model where a decentralized virtual currency is used as a store of value (SoV) to incentivize participation on a platform but the MoE is fiat. This provides a mix of centralization and decentralization that may be the most beneficial overall for a given platform.

Big Picture

I started this post by explaining why the choice of real or virtual currency matters. It matters because platform business models matter and making them work requires careful design to maximize positive network effects and minimize negative network effects. The drivers of network effects can be reframed as transaction costs. The economist Michael C. Munger in his recent book Tomorrow 3.0 makes a cogent argument that the primary function of platform business models is to sell reductions in transactions costs, (One can get the gist of his analysis in this early blog post here). Transaction costs can be broken up into three categories. These are: triangulation, transfer, and trust.

Transactions Costs: Triangulation, Transfer, Trust

The main value of a platform such as Uber or AirBNB is that it reduces these three transactions costs for participants that use their network. In terms of the earlier description of a platform business model; triangulation is another word for connecting (filtering and matching), transfer includes transport and payment and is another word for facilitation, and trust includes credibility, privacy, and the alignment of interests between parties and is therefore also a part of facilitation. I discussed at length above how decentralization can improve trust.

Blockchain technology has the potential to reduce transaction costs especially for transfer and most importantly trust through algorithmic decentralized governance and decentralized distributed consensus. But and its a big but, regulatory compliance for payment adds significant transfer cost especially when using virtual currency for decentralized payment. The important takeaway is not that blockchain and decentralization are vital components of a platform but that reducing total transaction costs (triangulation, transfer, and trust) is the vital activity of any platform. Rigid adherence to some theoretical ideal with regards the use of a given type of virtual currency or blockchain may not result in the best overall reductions in total transaction costs. Making the tradeoffs in the platform design that will reduce total transaction costs by the best available means is what will result in the most valuable platform.

Future

I sometimes get really annoyed when irrational constraints prevent me from solving problems. Most regulations in this space may be characterized as irrational. The IRS ruling that virtual currency is property may be the most irrational because it is the easiest to fix. Likewise, the 2013 FinCEN ruling reflects a limited early view of decentralization and needs to be updated. The 2011 FinCEN final ruling is even more so. There is a legitimate public interest in limiting illicit activity that is funded via money laundering. On the other hand, reducing transaction costs benefits broadly all consumers. In my opinion, the trade-off between transaction costs and money laundering is not well balanced and is only getting worse. This hurts the USA’s competitiveness. There are better ways to regulate. One of those is using modern crypto to provide group privacy via attribute based identity. A simple example is when a driver’s license is used to proof whether or not someone is of drinking age. All that needs to be proven is that the person is 21 or older but the driver’s license discloses much more information. The group defined by the attribute in this case is 21 or older. AML regulation compliance is like using a driver’s license when a group identity would do. In the case of money laundering the group attribute is illicit activity. All the regulators need to know is if the transaction is in the illicit group. The characteristics of illicit activity can be defined and an algorithm used to make attribution. This can be done in a more decentralized privacy preserving way. This would provide a more comprehensive approach but at much lower transaction costs. Several groups including the W3C, the DIF (Decentralized Identity Foundation, the Sovrin Foundation, and uPort among others are building standards for decentralized identity that allow group privacy. I am an active participant in these activities (see one of my early white papers here and others here).

Please comment and subscribe below. You can view other whitepapers and presentations at my github site.

--

--

Samuel M. Smith
SelfRule

Samuel M. Smith Ph.D. Is a pioneering technologist in multiple fields including automated reasoning, distributed systems, autonomous vehicles, and blockchain.