This op-ed originally appeared in The Block
Lately, there’ve been days when crypto trading volume through decentralized exchanges (DEX) has outstripped volume on major centralized exchanges. Last year in Coin Center’s report on constitutional law and decentralized exchange, we foreshadowed this shift and the effect it could have on regulations:
“Regulators have come to expect that any exchange from one cryptocurrency to another will — by necessity — occur through trusted third parties … While this is unlikely to change with regard to exchanges between sovereign currencies and cryptocurrencies (due to the need for a trusted legal entity to maintain banking relationships in order to deal in sovereign currencies), it will soon no longer be the case for exchanges between cryptocurrencies and any other assets that are similarly blockchain-based”.
Thanks in large part to enthusiasm for new, Ethereum-based decentralized finance (DeFi) projects , the shift is happening even more rapidly than we thought. What should you know about the intersection of decentralized exchange and US regulatory policy?
First, if a decentralized exchange is truly decentralized (and I can’t stress that caveat enough), then grammatically it’s an action not a thing, a verb and not a noun: I make a decentralized exchange; not, I use a decentralized exchange.
When I use free software and an open blockchain network to trade one token for another directly with another trader, then I am engaged in decentralized exchange — an action, just as I might engage in running or paying. We have this habit of saying that a DEX is a thing rather than an action because we are stuck in a centralized services frame of mind. Coinbase is a thing, a business, a corporation. But if the trade is actually happening peer-to-peer, then the “DEX” being “used” is just software and an internet connection. In that case, there isn’t a thing called a DEX. There are no DEXs; there is just decentralized exchange, the action, taking place using software tools, open blockchains, and the internet.
Calling those tools “a DEX” and referring to “DEXs” as a category of things that exist in the world (rather than actions) does the entire technology a disservice: it wrongly portrays software tools as persons or businesses with agency and legal obligations. Corporations and persons — legal or natural — definitely have agency and obligations; software tools do not. Corporations and persons can be held responsible for their actions, software tools cannot.
That doesn’t mean that people won’t be obligated to use or not use those tools in certain ways, and that does not mean that people or businesses will not be liable for facilitating illegal activities merely because they built those tools or broadcast tool-related messages over the internet. But it does mean that the tool itself can’t be treated as a target of regulation any more than we could place legal obligations on hammers instead of carpenters, or automobiles instead of drivers.
If a “decentralized exchange” isn’t made with free software and an open blockchain alone, and if there is also a critical middleman of some sort, then it’s not really a DEX at all. Long story short, we probably shouldn’t use the term DEX to describe any service or thing. It’s either an action or it’s a thing that has been misnamed.
Second, you should know that there are three distinct areas of policy that are particularly relevant to decentralized exchange: financial surveillance (also known as anti-money-laundering), securities regulation, and constitutional law (First and Fourth Amendment, free speech rights and search and seizure rights respectively).
The first two categories, surveillance and securities, are regulatory structures that may or may not apply to persons developing, implementing, hosting, or using decentralized exchange infrastructure. The third, constitutional law, can be a shield for those people from regulatory application in certain circumstances. We’ll go through each now briefly, but Coin Center also has long-form reports on each subject for anyone who is especially curious.
Financial surveillance and DEX
Since the 1970s, the Bank Secrecy Act (BSA) — a federal law — has obligated financial institutions serving U.S. persons to collect and report certain information about their customers’ identities and transactions to a bureau of the Treasury Department, the Financial Crimes Enforcement Network or FinCEN for short. This category of obligated businesses, financial institutions, originally included only those who were obviously engaged in traditional financial services, such as insured banks, but grew to include a variety of finance-adjacent businesses like pawn shops, casinos, and, yes, cryptocurrency custodians and exchanges. This is the law that obligates exchanges to do “know your customer” checks, and to report suspicious transactions to law enforcement in so-called Suspicious Activity Reports or SARs. As we’ll address at the end of this article, it’s worth noting that all of this data collection, retention, and reporting (arguably a search and seizure of sensitive customer data) takes place entirely without warrants or any particularized suspicion on the part of law enforcement. It’s a warrantless dragnet. That aside, how do these financial surveillance laws apply to decentralized exchange?
Since Coin Center’s inception in 2014, we’ve made the narrow application of the BSA a priority. We have argued repeatedly that the only activities performed using cryptocurrency that should trigger surveillance obligations are those in which a person or business has actual control over the cryptocurrency of another person (their customer) and acts on their behalf. This mirrors traditional financial services — we expect that banks (who hold people’s dollar accounts) will be subject to the BSA, but we don’t expect safe manufacturers (who simply build tools that allow persons to hold their own cash or valuables) to be subject to the Act.
The same should be true with respect to cryptocurrency business: only custodial wallet and exchange providers like Kraken and Coinbase should be required to comply with the BSA, and entities that are not third-party custodians, such as individual holders, software developers, miners, full nodes, and multi-sig providers (assuming they don’t have sufficient keys to transact) should never be subject to the BSA.
Working alongside the Uniform Law Commission, we developed model language to define the custodial act specifically so that there is no confusion over to whom regulations should apply. Only those with “the ability to unilaterally execute or indefinitely prevent a cryptocurrency transaction on behalf of a customer” should be regulated. While that model language was intended for consumer protection, it works in any context where defining custody and control is relevant.
Thus far, such efforts have paid off. FinCEN has offered clear guidance explaining that persons who don’t have “independent control” over customer funds will not be subject to the registration and surveillance requirements of the BSA. That guidance came in May of 2019, and we believe it is excellent. In it, FinCEN lays down the basic principle: you must have independent control over customer funds to be subject to the law, and FinCEN offers specifics for various activity fact patterns, including decentralized exchange tools:
“Under FinCEN regulations, a person is exempt from money transmitter status if the person only provides the delivery, communication, or network access services used by a money transmitter to support money transmission services. Consistent with this exemption, if a [convertible virtual currency] trading platform only provides a forum where buyers and sellers of [convertible virtual currency] post their bids and offers (with or without automatic matching of counterparties), and the parties themselves settle any matched transactions through an outside venue (either through individual wallets or other wallets not hosted by the trading platform), the trading platform does not qualify as a money transmitter under FinCEN regulations.”
So, at least with respect to financial surveillance regulations, if software facilitating a decentralized exchange is designed—as the name implies—to never give some third party custody over the cryptocurrency, and to simply match persons who will settle trades peer-to-peer, then the developers of that software are not regulated under the BSA. Neither are the users of that software regulated under the BSA if they are simply trading on their own behalf, as FinCEN has stated in guidance as early as 2013
Securities regulation and DEX
The BSA analysis alone, however, does not mean that decentralized exchange is never regulated. Securities regulations may apply to some activities that some people might perform using decentralized exchange.
The object of securities regulation is to protect investors from fraud and misrepresentation; that’s distinct from financial surveillance laws like the BSA where they object is to collect information that can be used to stop money laundering. As such, securities laws only apply when the asset being traded is, you guessed it, a security. The definition of a “security” is complex and flexible, and since 2015 we’ve been developing policy research on the question of whether and when a cryptocurrency will qualify as a security.
The short answer is that tokens that do not have an issuer upon whom token-holders rely for an expectation of future profits are not securities, and those that do are securities. In practice, that means that Bitcoin and cryptocurrencies like it are not securities because there is no central issuer who manages the network and promotes and sells some initial offering of tokens. Meanwhile, promises of future tokens will be securities because we rely on the developer of that future network to deliver on her promises. Finally, new tokens that travel on decentralized networks but that were initially sold in a presale as a promise of the developer are a grey area: the initial sale was a security offering, but if the network today is truly decentralized then the resultant token on a running network may not be a security. See EOS, for example, the promoters of which settled with the SEC over their pre-sale—admitting that the presale token was a security, but the current network token is not regulated as a security.
Regardless, if a token is a security then it cannot legally trade on exchanges that are not SEC-regulated as registered National Security Exchanges or Alternative Trading Systems. The definition of an exchange in the securities laws is broader and more flexible than the definition in the BSA: it does not rely on the concept of third party custody and could extend to persons who don’t have custody but merely match buyers and sellers or facilitate settlement. Therefore, if you are developing or implementing a tool for decentralized exchange and if some of the tokens that are trading with that tool are securities, then you may be liable for facilitating or operating an unregistered securities exchange.
In 2018, the SEC accused Zachary Coburn, the original developer of EtherDelta, of operating an unregistered securities exchange, and they ultimately settled out of court. EtherDelta was an Ethereum-based DEX platform and was used to trade several tokens that the SEC had already found to be securities (and several other tokens that likely would be found to be securities if the SEC took a hard look at them). So, even though EtherDelta never had any third party custodian (and therefore would not have been subject to the BSA and associated financial surveillance obligations) it still may have been an illegal securities exchange under U.S. securities laws.
In theory, a DEX platform that only facilitates the exchange of non-security tokens like Bitcoin would not be subject to either the BSA or securities laws. In practice, developers build tools that can be used for trading any token, security or non-security. Whether a developer who intended her tools to be used only for non-securities exchange could be liable if those tools were eventually used by others to trade securities is an untested question. Part of the answer will depend on what the developer did and whether her actions can be construed as protected speech under the U.S. Constitution, our final topic.
Constitutional law and DEX
If someone developing or implementing tools related to decentralized exchange was ever charged with violating securities laws (because people were trading securities tokens using the tool) or financial surveillance laws (if those laws were ever changed to expand their coverage to non-custodial entities) then they may be able to use constitutional law as an affirmative defense. Two promising defenses that we’ve written extensively on are our First Amendment freedom of speech rights and our Fourth Amendment right against warrantless search and seizure.
If a developer is creating and releasing versions of decentralized exchange software to the general public, and if that developer is not also advocating the illegal usage of that software, collecting fees from person’s use of the software, or maintaining a website through which people might access and use the software, then there is a strong case that this software publishing activity alone is constitutionally protected expression.
That doesn’t necessarily mean that the government can never regulate that activity. But it does mean that any regulation curtailing the otherwise free expression will face strict scrutiny from the courts, which means that the government will have to prove both that (a) the regulation furthers a compelling state interest, and (b) that no less-speech-restrictive means could achieve that interest. In practice this level of scrutiny forbids the state from passing laws that would ban the publication based on content or viewpoint.
Open-source decentralized exchange software is a particular type of content that advocates a strongly held political viewpoint: that we should be able to engage in payments and transactions free of middlemen and censorship. In practice, strict scrutiny forbids the state from passing laws that create a “prior restraint” on speech, that is to say a ban on speech that is in place before the speech is actually made. In other words a punishment for saying something defamatory after the fact is not a prior restraint, but a law that says “no one shall be allowed to say anything untrue about the President’s character” is a prior restraint. Any law that attempts to ban the publication of decentralized exchange software or make publication illegal without a license or some other precondition would be a prior restraint. In practice, courts always find these forms of regulation to be unconstitutional.
If a developer is told that she must include a surveillance or “know your customer” tool (or backdoor) in her decentralized exchange software, this could be challenged as unconstitutional compelled speech. Regulations compelling speech, especially if the speech in question concerns non-commercial expressive content, also face strict scrutiny review.
Finally, if a developer is compelled to include surveillance tools in her decentralized exchange software, that mandate can be challenged as an unconstitutional warrantless search in contravention of the Fourth Amendment’s warrant requirement. As described earlier, the Bank Secrecy Act already mandates massive warrantless data collection from centralized exchanges and other financial institutions. The only reason this dragnet is constitutional is because the subjects of the search (individual users of the exchange) willingly provide their information to a third-party. Since the 1970s, courts have held that when the subject of the search voluntarily hands information over to a third party — and that third party retains the information for legitimate business purposes — then the subject loses her reasonable expectation of privacy over the information. With no reasonable expectation of privacy, the government need not get a warrant to search or seize the information in question.
However, if the user is buying or selling in a decentralized exchange, then there is no third-party to whom the user has handed over the information. This third-party carve-out to the warrant requirement would not apply. The bulk of the Bank Secrecy Act’s data collection and reporting obligations (e.g. SARs) are warrantless, and therefore these could not be used to gather information that has not been voluntarily revealed to a third party; that data remains subject to a warrant requirement.