Thoughts on Privacy Pools and the law

Here's my quick first-pass take on Privacy Pools, the heir apparent to privacy tool Tornado Cash. My comments are on the legal side, and less so the technical side, although the two aren't mutually exclusive. 

I've already written a bunch of times about Tornado Cash on this blog. Financial privacy is an important topic. 

The quick story is that after attracting a few billion in criminal funds, the Tornado Cash "stack" was sanctioned by the Office of Foreign Assets Control (or OFAC, the U.S.'s sanctioning authority). Privacy Pools is the Ethereum community's attempt to offer up an olive branch to OFAC. "We know you didn't like the last attempt, but we're going to make some changes. What do you think?"

I'm fascinated with the Privacy Pools idea, which will allow users to pick and choose who they associate with, thus excluding potentially bad actors. With fewer bad actors, OFAC may be less hasty to sanction the tool. 

While in theory that sounds great, here's my worry. Privacy Pools still relies on an old Tornado Cash feature: relayers. (For this observation, I'm indebted to Jon Reiter, who wrote a useful article on Privacy Pools for Blockhead.) It also relies on a new type of third-party: association set providers or ASPs.

Relayers and association set providers are a problem, as I'll show below. And the reason has nothing to do with OFAC or sanctions law, but a set of Federal statutes against racketeering found in Chapter 95 of the U.S. criminal code.

Let's assume that Privacy Pools gets deployed and begins to successfully screen out bad actors. That'll make it an even more tempting target for dirty money seeking redemption, bad actors devoting ever more resources to sneak into the mix. Inevitably, some of them will get through and when they do, the authorities will have to find an actor in the Privacy Pools stack to blame. I suspect they'll target relayers and ASPs.

Let's start with relayers. It's likely that the authorities can show that relayers are engaged in an activity defined under a key section of U.S. racketeering law, § 1960, as "money transmission." To avoid breaking this law, relayers will need to register with the Financial Crimes Enforcement Network, or FinCEN, the U.S. government's money laundering watchdog. Registration will obligate relayers to set up an iron-clad customer identification program, which involves collecting and verifying user ID cards, as well as filing Suspicious Activity Reports (SARs) with FinCEN, thus undoing much of Privacy Pools' stated benefits.

Let's back up a sec. Who are relayers?

Doing stuff on the Ethereum blockchain requires paying a small processing fee, and these fees are visible to everyone. When a privacy seeker withdraws from Privacy Pools or Tornado Cash, this fee payment effectively reveals who the user is. To solve this problem, both systems rely on a group of third-party individuals or entities – relayers – to pay this fee on behalf of users, thus restoring privacy, an effort they are remunerated for. But this sounds to me like "transferring funds on behalf of the public," which is Chapter 95's definition of money transmission, which leads me to suspect that relayers can be drawn into said law's licensing and registration requirements.*

Now, I'm just a maritime lawyer, so if I suspect that relayers are money transmitters, who really cares, right? But it's not just me who is making this claim. In its recent indictment of individuals involved in the Tornado Cash stack, the Department of Justice named relayers as engaging in money transmission.

I can sympathize with the argument that the DoJ is overreaching by charging Tornado Cash frontend owners & token holders with money laundering (and failure to register as a money transmitter), but I think the DoJ nailed it 100% when it accused relayers of those same crimes. pic.twitter.com/uzJI9AC7g9

— John Paul Koning (@jp_koning) August 29, 2023

Let's move on to ASPs. With Privacy Pools, users can build unique association sets that allow them to dissociate from potential bad actors. In a recent paper, the Privacy Pools designers suggest that in practice, professional intermediaries – association set providers – will emerge to set up and curate these sets. Users will in turn subscribe to whatever ASP-provided sets meet their needs.

It's inevitable that ASPs will make mistakes and let bad actors into their sets, resulting in illicit money being laundered through Privacy Pools. In response, the authorities may try to follow the same script they used for relayers and accuse a faulty ASP of being an unlicensed money transmitter. But that may not stick; unlike a relayer, an ASP doesn't actually transfer any money. The Department of Justice has more up its sleeve than that, though. They can charge faulty ASPs with breaking other laws in Chapter 95, specifically the money laundering statutes §1956 and 1957.

To avoid a potential money laundering indictment, the intermediaries that curate association sets will have to make a good faith effort to exclude bad actors. Simple blacklists derived from chain tracing tools provided by companies like Chainalysis probably won't cut it. ASPs will have to undertake the same level of customer due diligence as banks and other financial institution. That means painstakingly collecting ID, doing background checks, and more. As before, that may unravel some of the purported anonymity of the Privacy Pools system.

The fact that relayers and ASPs may face FinCEN registration requirements and/or other anti-money laundering obligations isn't necessarily a death knell for projects like Privacy Pools, but it may pose some challenges.

1) Relayers and ASPs may try to sidestep U.S. law by operating outside the U.S. and, if possible, set up their operations to exclude Americans. That means cutting off a big chunk of the world from using the tool. With fewer users, the ability of Privacy Pools to obfuscate the tracks of all its non-U.S. users will be limited.

2) Some relayers and ASPs may choose to accept American customers in a compliant way. They'll verify their users, submit reports to FinCEN, and more. But at that point an American will probably be roughly indifferent between getting privacy from Privacy Pools or Coinbase, a centralized exchange that already complies with the requirements. Any U.S. user who becomes a customer of Coinbase can deposit ether and withdraw it to a new address, thus removing the outside world's ability to track the transaction, albeit at the expense of disclosing their personal information to Coinbase. Privacy Pools would afford this same level of privacy. It would offer U.S. users privacy from the broader community, but not from the employees of a relayer or ASP.**

If Privacy Pools is only providing Coinbase-levels of privacy to Americans, what's the point?

3) Lastly, perhaps the developers can figure out now – before Privacy Pools is even deployed – how to do away with relayers while still preserving privacy, thus entirely bypassing Federal racketeering law's definition of money transmission. Or maybe they can figure out how to design the relaying system such that it falls out of the definition. 

Whether that's even possible is a technical issue that goes waaay beyond my abilities.

---

* Why can't other elements of the Privacy Pools stack, including the core smart contracts and the people who develop them, be pulled into being defined as money transmitters? My assumption in this post is that if the smart contracts are: 1) non-upgradeable, that is, they are set in stone from the moment they are published, 2) the developer no longer has any association with the "stack" after publishing the contracts; 3) the system is not governed by a DAO; 4) there is no stream of profits thrown off by the system; and 4) there is no token (as was the case with Tornado Cash's TORN), then it is probably less likely that the smart contracts and/or their designers would fall under the definition of a money transmitter. But I could be wrong.

** Mind you, Coinbase and a fully-compliant Privacy Pools wouldn't be perfect substitutes. Whereas Coinbase takes ownership of one's ether, thus subjecting privacy seekers to the risk of Coinbase going bankrupt, Privacy Pools is just a smart contract, and not subject to that same risk. For a sub-group of privacy seekers who worry about Coinbase going bust, FinCEN-compliant relayers and ASPs may be strictly superior to Coinbase.  

Coinbase: "What if we call them rewards instead of interest payments?"

Here's a question for you: which U.S. financial institutions are legally permitted to pay interest to retail customers?

We can get an answer by canvassing the range of entities currently offering interest-paying dollar accounts to U.S. retail customers. It pretty much boils down to two sorts of institutions:

• Banks
• SEC-regulated providers like money market funds.

There seem to be a few exceptions. Fintechs like PayPal and Wise are neither of the above, and yet they offer interest-yielding accounts to retail customers. But if you dig under the hood, they do so through a partnership with a bank, in Wise's case JP Morgan and in PayPal's case Synchrony Bank. (Back in the 2000s, PayPal used a money market mutual fund to pay interest). So we're back to banks and SEC-regulated entities.

And then you have Coinbase.

Coinbase will pay 5% APY to anyone who holds USD Coins (USDC), a dollar stablecoin, on its platform. (Coinbase co-created USDC with Circle, and shares in the revenues generated by the assets backing USD Coin.) The rate that Coinbase pays to its customers who hold USDC-denominated balances has steadily tracked the general rise in broader interest rates over the last year or so, rising from 0.15% to 1.5% in October 2022, then to 4% this June, 4.6% in August, and now 5%.

Coinbase isn't a bank, nor is it an SEC-approved money market mutual fund. And unlike Wise and PayPal, Coinbase's interest payments aren't powered under the hood by a bank.

So how does Coinbase pull this off?

In short, Coinbase seems to have seized on a third-path to paying interest. It cleverly describes the ability to receive interest as a "loyalty program", which puts it in the same bucket as Starbucks Rewards or Delta's air miles program. The program itself is dubbed USDC Rewards, and in its FAQ, customers are consistently described as "earning rewards" rather than "earning interest."

This strategy of describing what otherwise appears to be interest as rewards extends to Coinbase's financial accounting. The operating expenses that Coinbase incurs making payments on USDC balances held on its platform is categorized under sales and marketing, not interest expense. 

Oddly, this key datapoint isn't disclosed in Coinbase's financial statements. Instead, we get this information from a conference call with analysts last year, in which the company's CFO described its reasoning for treating USDC payouts as rewards:

Source: Coinbase Q4 2022 conference call

 

The flow of "rewards" that Coinbase is currently paying out is quite substantial. Combing through its recent financials, Coinbase discloses in its shareholder letter that it had $1.8 billion of USDC on its platform at the end of Q2. Of that, $300 million is Coinbase's corporate holdings, as disclosed on its balance sheet. So that means customers have $1.5 billion worth of USDC-denominated balances on Coinbase's platform.

At a rewards rate of 5%, that works out to $75 million in annual marketing expenses. (Mind you, not everyone gets 5%. We know that MakerDAO, a decentralized bank, is only earning 3.5% on the $500 million worth of USDC it stashes at Coinbase). In any case, the point here is that the amounts being rewarded are not immaterial.

Interestingly, Coinbase does not pay rewards on regular dollar balances held on its platform. It only provides a reward on USDC-denominated balances. This gives rise to a yield differential that seems to have inspired a degree of migration among Coinbase's customer base from regular dollar balances to USDC balances. 

For instance, at the end of Q1 2023, Coinbase held $5.4 billion in U.S. dollar balances, or what it calls customer custodial accounts or fiat balances. (See below). By Q2 2023 this had shrunk to $3.8 billion. Meanwhile, USDC-on-platform rose from $0.9 billion (see below) to $1.5 billion.

Source: Coinbase Q1 2023 shareholder letter

As the above screenshot shows, Coinbase has tried to encourage this migration by offering free conversions into USDC at a one-to-one rate. It has also extended the program to non-retail users like MakerDAO, although its non-retail posted rates are (oddly) much lower than its retail rates. Institutional customers usually get better rates than retail.

Incidentally, Coinbase isn't the only company to have approached MakerDAO to sign up for its fee-paying loyalty program. Gemini currently pays MakerDAO monthly payments to the tune of around $7 million a year, but calls them "marketing incentives." Paxos has floated the same idea, referring to the payments as "marketing fees" that would be linked to the going Federal Funds rate. The aversion to describing these payments as a form of interest is seemingly widespread.

There's two ways to look at Coinbase's USDC rewards program. The positive take is that in a world where financial institutions like Bank of America continue to screw their customers over by paying a lame 0.01% APY on deposits when the risk-free rate is 5.5%, Coinbase should be applauded for finding a way to offer its retail clientele 5%.

The less positive take is that USDC Rewards appear to be a form of regulatory arbitrage. Given that Coinbase uses terms like "APY" and "rate increase" to describe the program, it sure looks like it is trying to squeeze an interest-yielding financial product into a loyalty points framework, which is probably cheaper from a compliance perspective. If Coinbase was just selling coffee, and the rewards were linked to that product, then it might deserve the benefit of the doubt. But Coinbase describes itself as on a mission to "build an open financial system," which suggests that these aren't just loyalty points. They're a financial product. And financial products are generally held to strict regulatory standards in the name of protecting consumers.

We've already seen hints of regulatory push back against the rewards-not-interest gambit so popular with crypto companies. In the SEC's lawsuit against Binance, it named Binance's BUSD Rewards program as a key element in Binance's alleged effort to offer BUSD as a security, putting it in violation of Federal securities registration requirements. Like Coinbase's USDC Rewards program, BUSD Rewards offered payments to Binance customers who held BUSD-denominated balances at Binance. BUSD is a stablecoin that Binance offered in conjunction with Paxos.

Coinbase's lawyers seem to have anticipated this argument and have already prepared the legal groundwork to rebut it. The SEC sent a letter to Coinbase in 2021 that asked why USDC Rewards was not subject to SEC regulation. In its response, Coinbase had the following to say:

Here's an interesting bit in which Coinbase goes into some detail why it believes USDC Rewards isn't a security: https://t.co/ZzXxvNkBsv I think it bears out the idea that once a firm starts offering a return, it risks straying into other regulatory frameworks. pic.twitter.com/DMC7l3Et33

— John Paul Koning (@jp_koning) August 4, 2022

Now, I have no idea whether this is a good argument or not. Having observed securities law from afar over the last few years, I'm always a bit flummoxed by the degree of latitude it offers. It seems as if a good lawyer could convincingly argue why my Grandma's couch is a security, or that Microsoft shares aren't securities.

If you think about it more abstractly though, loyalty points and interest are kind of the same thing, no? In an economic sense, they're both a way to share a piece of the company's revenue pie with customers. Viewed in that light, why shouldn't a program like USDC Rewards inherit the same legal status as Starbucks Rewards or air miles?

If Coinbase's effort to shape its USDC payouts as rewards ends up surviving, others will no doubt copy it. Wise and PayPal might very well stop using a bank intermediary to offer interest-paying accounts, setting up their own loyalty programs instead. A whole new range of investment opportunities marketed as loyalty programs might pop up, all to avoid regulatory requirements.

But it's possible to imagine the opposite, too. In a column for Atlantic, Ganesh Sitaraman recently described airlines as "financial institutions that happen to fly planes on the side." If loyalty points and interest are really just different names for the same economic phenomena, then maybe airline points, Starbucks Rewards, and USDC Rewards should all be flushed out of the loyalty program bucket and into stricter regulatory frameworks befitting financial institutions.

How did Zcash avoid getting OFAC'ed?

The 2022 sanctioning of privacy tool Tornado Cash by the Office of Foreign Assets Control (or OFAC, the U.S.'s sanctioning authority) has inspired a new privacy idea: Privacy Pools. 

An olive branch to OFAC, Privacy Pools will let users choose who they associate with, the idea being that proactive filtering will quickly expose bad actors who try to use the tool, and so OFAC may be less hasty to apply sanctions to Privacy Pools smart contracts. I think it's a neat idea. We'll see where it goes.

Zooko Wilcox, the creator of the original anonymous cryptocurrency, Zcash, doesn't like the notion of bending a knee to OFAC. In an interesting conversation with Vitalik Buterin, one of the creators of Privacy Pools, Wilcox argues that the Privacy Pools regulatory dance is "unnecessary" because OFAC simply doesn't have the authority to sanction a protocol to death. And he puts forward Zcash as an example of a privacy technology that coexists peacefully with OFAC. Which is a fair point. Zcash has been around for seven years now, and OFAC hasn't shut it down.

This piqued Vitalik's interest, who later on in the podcast goes on to ask Zooko why Zcash hasn't been OFAC'ed, given that it does exactly what Tornado Cash does: provide privacy.

I don't think it's a great idea for folks like Vitalik who are designing tools like Tornado Cash and Privacy Pools to take lessons from Zcash's experience with OFAC. And that's because Zcash is a very different beast than Tornado Cash/Privacy Pools. The two just don't land in the same regulatory bucket.

If you've been watching OFAC's dealings with crypto over the years, you'll notice that Zcash falls in the same OFAC bucket as other base layers like Bitcoin, Ethereum, Monero, Ripple, and more. When OFAC catches a sanctioned actor who controls an address on one of these base chains, it updates its list of sanctioned entities with the relevant address. This is how things have worked since 2018, when the first two bitcoin addresses were added to OFAC's list. But OFAC has always left the functionality of the chain itself unhindered, nor does it impinge on the ability of the chain developers to do their job by sanctioning them.

In fact, I've found a handful of Zcash addresses designated by OFAC, including one associated with the disinformation campaigns set up by recently-deceased Russian mercenary leader/oligarch Yevgeniy Prigozhin:

Source: OFAC

Here are a few more blocked addresses. But that's it. Zcash still works fine.

With the arrival of Tornado Cash/Privacy Pools, we've entered into completely new territory of smart contract-based tools built on programmable chains. How OFAC deals with these tools is going to be much more complex and tricky than how it deals with base chain addresses controlled by sanctioned entities. The Tornado Cash sanctions represent OFAC's first attempt, perhaps a clumsy one. Privacy Pools is a riposte from developers that, after being eyeballed by OFAC, might end up at a different equilibrium.

Zcash's regulatory experience just doesn't translate over to the sorts of things Vitalik is working on. It's in smart contact-space where the current evolution of OFAC's prodding of crypto is occurring, but Zcash doesn't have smart contract-based tools.

So from the perspective of a Zcasher like Zooko, it's just not necessary for him to play games with OFAC. The last five years of OFAC behavior suggests that OFAC can't and/or won't sanction Zcash-the-protocol to death, nor Bitcoin-the-protocl or Ethereum-the-protocl. 

But the fact remains that the sanctioning of Tornado Cash (which has already survived one court challenge) suggests that OFAC does seem to have the authority to enact such a ban at the emerging smart contract level. That may not be concerning to Zooko now, but one day it might be possible to build all sorts of automated tools on top of Zcash. And at that point Zcash developers may have to play the same "unnecessary" olive branch game with OFAC that Ethereum smart contract developers like Vitalik are engaged in now.

There are now two types of PayPal dollars, and one is better than the other

PayPal now offers its customers two types of U.S. dollars. In addition to having the option of opening a traditional PayPal account to maintain a balance of dollars, PayPal customers can now hold something new called PayPal USD, a crypto version of a dollar. Whereas PayPal USD uses a crypto database, Ethereum, to host U.S. dollar balances (which in industry-speak is sometimes known as a stablecoin), the first sort of dollar relies on a conventional database.

There are currently around $45 million worth of PayPal USD in circulation, as the chart below illustrates:

Source: CoinMarketCap

Which type of PayPal dollar is safer for the public to use?

If you listen to Congresswoman Maxine Waters, who in response to PayPal's announcement fretted that PayPal's crypto-based dollars would not able to "guarantee consumer protections," you'd assume the traditional non-crypto version is the safer one. And I think that fits with most peoples' preconceptions of crypto.

Not so, oddly enough. It's the PayPal dollars hosted on crypto databases that are the safer of the two, if not along every dimension, at least in terms of the degree to which customers are protected by: 1) the quality of underlying assets; 2) their seniority (or ranking relative to other creditors); and 3) transparency.

Here is a bit of commentary on each factor:

The quality of underlying assets

PayPal's crypto dollars, which are managed by a third-party called Paxos, are 100% backed by the safest sorts of short-term collateral: U.S. Treasury-bills, reverse repo (backed by U.S. government securities), and commercial bank deposits. In finance lingo, these assets are known as cash and cash equivalents. A big reason for this conservative investment approach is that Paxos is subject to a set of strict investment limits as determined by its regulator, the New York State Department of Financial Services (NYDFS). You can read about the NYDFS's stablecoin regulatory framework here.

By contrast, PayPal's regular dollars, which are regulated piecemeal under each U.S. states' own peculiar version of a money transmitter license, can almost always be legally backed by riskier assets. (Here is PayPal's list of state-issued licenses.)

For instance, if you comb through the fine print at the back of PayPal's annual report, the total amount of customer funds held in the form of regular PayPal dollars comes out to $36 billion at year-end 2022. Of this $36 billion, PayPal has invested $11 billion in "cash & cash equivalents." Put differently, just 30% of its dollars are backed by top notch assets, far less than the 100% ratio for PayPal's crypto dollars. PayPal invests another $17 billion of its customer's billions in something called available-for-sale debt securities which, if you dig further, is made up of stuff like government bonds, commercial paper, corporate debt securities, and more. See the list below:

Source: PayPal 2022 annual report

These available-for-sale securities assets are not as reliable as cash and cash equivalents, particularly treasury bills. First, they have riskier issuers, as is the case with commercial paper and corporate debt, both of which are emitted by companies. Second, they are characterized by longer terms-to-maturity, as is the case with government bonds and corporate debt securities. Prices of long-term debt are much more volatile than short term debt. 

It would be illegal for PayPal to back its new crypto-based dollars with the assets listed above, yet for some reason it is fine if it backs its traditional dollars with them.

Customer's ranking relative to other creditors

The second drawback of PayPal's regular dollars is that the assets underlying them don't really "belong" to customers in any strong sense of the word. They belong to PayPal.

To understand what this means, let's say that PayPal goes bankrupt. You, a long time PayPal customer, hold $1000 worth of PayPal dollars. You might think that you are guaranteed to be made whole because there exists a corresponding set of underlying customer assets that has been specially earmarked for you and other PayPal customers. But that's not the case. Customers are what is referred to in finance as an unsecured creditor of PayPal, which means you'd be relegated to having to fight with PayPal's other creditors (banks, bond holders, etc) to get a piece of the pie, and that's only after PayPal's secured creditors – those highest in the pecking order – get first dibs. That could potentially mean getting maybe $600 or $700 instead of your original $1000.

The reason for this, as explained here by Dan Awrey, is the fairly lax state-by-state regulatory frameworks under which PayPal's regular dollars are issued, which "often do not require that permissible investments be held in trust for the benefit of customers—thus potentially forcing customers to compete with an [money services business]’s other unsecured creditors in the event that it is forced into bankruptcy."

By contrast, the regulator of PayPal's crypto-based dollars, the NYDFS, specifies that the reserves backing any crypto-based dollar "shall be held at these depository institutions and custodians for the benefit of the holders of the stablecoin, with appropriate titling of accounts." To translate, the assets underlying your $1000 in PayPal USD cryptodollars are not PayPal's assets. Nor are they Paxos's. They are yours. No need to squabble with competing vultures for what's left.

But oddly, PayPal is under no legal obligation to extend these very sensible protections to all of its regular PayPal dollars.  

Degree of transparency

The last big difference between the two types of PayPal dollars is that the crypto version offers far more transparency to customers. If you want to get current information about the assets underlying your crypto PayPal dollars, all you need to do is open up one of PayPal USD's soon-to-be published attestation reports. Published monthly, these reports must include market values of the assets backing PayPal USD's, both in total and broken down by asset class. These values must be recorded on two separate days each month, or 24 times per year. Furthermore, these attestation reports must be prepared by an independent auditor.

By contrast, the only way to get vetted financial information about the assets backing traditional PayPal dollars is to read its audited financial statements, which come out just once a year. For the rest of the twelve months, customers are left in the dark.

So where am I going with all of this?

This illustrates the absurdity of some of the rules we've created surrounding monetary instruments. The fact that one type of PayPal dollar has robust protections while the other is only haphazardly protected, and only because the first is managed with a crypto database and not a traditional database, seems incredibly arbitrary to me. 

Financial regulations exist, in part, to protect retail customers against shoddy financial providers. Shouldn't all PayPal customers, no matter what database technology they select, get to benefit from the same standard protections? What's the logic behind stipulating that one type of PayPal customer is to have the benefit of monthly attestation reports, for instance, while limiting the other type of customer to a black void of information? 

The problem here isn't just one of having a few bad standards. Doesn't having multiple standards add to people's confusion about how they are protected?

Just to make things even more absurd, there's actually a third type of PayPal dollar. It comes in the form of balances held in a PayPal Savings accounts. 

Now you can save for rainy days and getaways with 0.85% APY*. No fees. No minimum balance. So hit the auto-save and achieve those savings #goals. https://t.co/orHIhRlKX2 pic.twitter.com/lxivOjqMoT

— PayPal (@PayPal) June 9, 2022

Unlike the two types of PayPal dollar described above, the third type is insured by the government up to $250,000. PayPal Savings dollars also pay interest, whereas the first two don't, or are prohibited from doing so. PayPal offers this product in conjunction with a bank, Synchrony Bank, which means this third type of PayPal dollar conforms to an entirely different set or rules than the other two: Federal banking law.

But this only reinforces what a Frankenstein of a monetary system we've created. Why are only PayPal Savings dollars protected by deposit insurance, whereas the other two types of PayPal dollars aren't? How does this cacophony of features (or lack of features) help retail customers who, amidst all their other duties in life, simply don't have time to peruse the fine print of each different dollar emitted into the economy?

Circle says its USDC stablecoin was as diversified as possible. Is that accurate?

There's a good article by Leo Schwartz on stablecoin issuer Circle, which provides some clarity into last March's big depegging of the USDC stablecoin, and Circle's subsequent bailout by the government.

I wrote about the whole thing here, but the short version is that a handful of banks collapsed earlier this year, one of which was Silicon Valley Bank (SVB). Circle kept $3.3 billion at SVB, almost all of which was uninsured, which amounted to 8% of the assets keeping USDC stablecoins pegged to $1. When news of SVB's collapse hit on Friday, March 10, a weekend run began on Circle, the price of USDC collapsing to below 90 cents.

Luckily for Circle, it would get a bailout. That weekend, the FDIC announced that the $250,000 limit on government deposit insurance would be waived for SVB. Circle's $3.3 billion was saved. As SVB's biggest depositor, Circle was the single largest beneficiary of the bailout.

According to the article, Circle has "no remorse" over its decision to hold $3.3B at SVB. It was "as diversified as possible" and blames banking for its woes, which is "extremely difficult" for crypto firms.

I just don't buy this argument.

Circle's stablecoin competitor, Paxos, didn't have single-bank exposure. As the screenshot below shows, $185.5 million worth of deposits held to back Paxos's USDP stablecoin were spread over thousands of banks using deposit placement networks like IntraFi, and were thus insured by the government. For the remainder, Paxos obtained $72 million worth private insurance. Only $10.9 million in deposits were effectively unprotected, a small 1.3% sliver of USDP's total assets.

Source: Paxos

Rather than keeping 8% of its assets lodged at a second tier bank without insurance, why didn't Circle follow Paxos's risk reduction strategy?

There are 4,333 FDIC-insured banks and 4,760 NCUA-insured credit unions. The ability to invest $250,000 in each one offers theoretical headroom for around $2.3 billion worth of government insurance. The actual ceiling is much lower, since many banks and credit unions don't participate in deposit placement networks. But that's where private insurance comes in. How much private insurance could Circle have managed to secure? Paxos once again provides a hint. Last year it obtained a hefty $1.5 billion in private insurance for deposits backing BUSD, its largest stablecoin product. 

Combine these two options, and Circle could have easily avoided hyper-exposure to SVB. But it didn't go down that route.

In the article, Circle derides concerns over its deposit holdings as bordering on "risk reduction to absurdity," but the real absurdity here seems to be that Circle didn't engage in the same risk reduction as one of its competitors. Instead of angrily blaming others for what happened to it last March, Circle should probably accept some of the blame itself, and then very humbly thank American taxpayers for the bailout.

Who are the money launderers in the Tornado Cash stack?

Over the last few years I've written a bunch of posts about Tornado Cash, an Ethereum-based mixing service, because I find it to be a fascinating tool. With the recent indictment of two people involved in the Tornado Cash "stack" for money laundering, here's another post to add to the list.

Let's get this clear from the outset. Somewhere in the Tornado Cash stack, someone is committing the crime of money laundering. That's been the case since at least mid-2020 or so, the moment that crooks started to send their criminally-derived ether proceeds to Tornado Cash for cleansing.

I'm going to repeat that. One of the parties (or groups of parties) woven together via the Tornado Cash apparatus has been knowingly acting as a financial counterparty to criminals, helping to "conduct" transactions that obfuscate dirty ether.

The question always was: who in the stack is guilty of money laundering? Is it the developers who are  laundering money? Miners? TORN token holders? Relayers? Licit users who engage with the smart contracts? And if so, are all licit users guilty, or just some users? Are the operators of the popular user interface the guilty parties?

A recent indictment from the U.S. Department of Justice claims to have figured out who the money launderers are.
 
Before getting to the indictment, let's tally up all the actors involved in the Tornado Cash stack. To begin with there are the users and developers. The central element of the Tornado Cash stack is a set of smart contracts, or pools, where users – both crooks and non-crooks – can send their easily-traced ether to be mixed, getting it back anonymized and untraceable. These core smart contracts were originally coded by three developers in 2019. In mid-2020, the developers removed the core contracts' upgradability, in effect "throwing away the keys" and ending their influence over them.

The next key set of actors are the relayers. Doing stuff on the Ethereum blockchain requires paying a fee to validators. The visibility of these fee payments effectively unwinds Tornado Cash's anonymity and reveals who Tornado Cash's users are. A group of third-party individuals, the relayers, are recruited to handle fees on behalf of users, thus restoring privacy.

The Tornado Cash stack also includes a popular user interface that acts as an overlay over the smart contracts, making them easier to interact with. Control over the user interface is delegated to individuals who own TORN tokens. TORN allows its owners to vote on how the front-end functions, in addition to earning profits from it. TORN holders have no influence over the core smart contracts.

Of these many actors, the DoJ has singled out Roman Storm and Roman Semenov, along with "others known and unknown," as the putative money launderers. (The government also accuses the two of failing to register as a money transmitter, but I'll set that aside.)

Storm and Semenov were the original developers of the core smart contracts, but that doesn't seem to be the nub of the DoJ's money laundering case. Rather, it is the accused's ongoing control over the user interface, exercised through their ownership of a large block of TORN tokens, that seems to have implicated them. Despite knowing that the Tornado Cash stack had become popular with criminals, the owners/operators of the user interface did nothing to screen bad actors from accessing said interface. On the contrary, they made efforts to both improve the interface and increase the profits they made from it.

The government's illustrates this by explaining the involvement of Storm and Semenov in managing the list of relayers that appear on the user interface, as well as in crafting the system for rewarding and levying fees on these relayers. The indictment cites a vote made by TORN holders in early 2022 that led to an update of the user interface's mechanism for listing relayers. The change allowed anyone to appear on the list, as long as they could stake a certain quantity of TORN tokens. The DoJ alleges that this decision improved anonymity by lengthening the user interface's list of relayers.  

The indictment further alleges that Storm and Semenov, through their ownership of TORN, profited financially from the user interface's new method of listing relayers. To get on the user interface list, a relayer had to buy TORN, which pushed up TORN's price. In addition, whenever a relayer that appeared on the user interface's list was selected, a portion of that relayer's staked TORN was "slashed," or reduced, forcing relayers to top up with additional TORN purchases in order to continue to qualify for the list. This added more upward pressure on TORN's price to the benefit of holders like Storm and Semenov.
 
In the government's view, the totality of these actions constitute money laundering, specifically a violation of  18 USC § 1956. The DoJ believes that the two defendants "conducted" transactions, a key element of money laundering, via their ongoing control over the user interface, along with other TORN owners. The indictment also shows that a large portion of Tornado Cash transactions were in fact criminal proceeds, including those made by the Lazarus Group. (I mean, we all knew that already.) Lastly, they show that the accused were aware that the funds coursing through the Tornado Cash stack were dirty, a mental state of knowing being a key plank in charging someone for money laundering.

It seems to me like the DoJ has a solid case, although we can debate whether operating the Tornado Cash user interface and its relayer list is tantamount to "conducting" transactions. The legal definition of conducts is a broad one, including "participating in initiating, or concluding a transaction." While the user interface, and thus those who operated it, never directly initiate transfers of ether to the underlying Tornado smart contracts, it doesn't seem a stretch to describe them as participating in the initiation of those transfers. We'll have to see what the judge says.

Counterintuitively, the indictment seems like a win, if only a lukewarm one, for fans of decentralized finance, or DeFi.

Proponents of DeFi have long worried that developers of autonomous smart contracts might be held liable in court for crimes. In this case, however, the same actors who happen to be the developers of Tornado's core smart contracts also built a complex and centralized business structure around those same contracts, and it is this tertiary apparatus that is serving as the basis for a money laundering charge, not the original coding of the core smart contracts.

It's a useful thought experiment to imagine how things might have played out if Storm and Semenov had acted differently. Let's imagine that the two coders hadn't created a profitable apparatus around the original smart contracts. Once the core smart contracts were up and running, they ceased to associate in any way with the Tornado Cash stack. Secondly, imagine there was no user interface. To deposit or withdraw funds, users had to interact directly with the smart contracts. Lastly, let's assume that TORN tokens had never been issued, so there was nothing to govern (or govern with), and thus no basis for the government to use "operating control" as a lever for a money laundering prosecution.

Given a very slimmed-down Tornado Cash stack, who does the DoJ now accuse of money laundering? Because they have to accuse someone. Crooks depositing dirty ether are still ending up with laundered ether, so there is by definition a "someone" in the stack who is providing laundering services to them.

In our story, Storm and Semenov aren't the money launderers, and the thrust of the DoJ's indictment confirms this. The two developers created software with presumably noble intentions: to provide regular folks with privacy from the panopticon that is Ethereum. Then they walked away, leaving the tool indelibly etched on the blockchain. It was only then that people started to interact with the tool, some of them to carry out illegal activity. It's this latter group who constitutes the guilty party.

Relayers are excellent candidates for a money laundering charge, a point I made last year. Because they process withdrawals on behalf of users, it would likely be a cinch to pin them for "conducting" transactions. Showing that relayers do this despite knowing that criminals may be their counterparties shouldn't be difficult for prosecutors to establish. And indeed, the DoJ's actual indictment is going in the right direction when it says that Storm and Semenov, along with "others involved in the Tornado Cash service, including the relayers," were engaged in the business of transferring funds, and goes on to accuse these "others," presumably relayers, of engaging in money laundering.

The second logical target for a money laundering charge is the licit users of Tornado Cash, in particular the large and savvy ones who used the tool regularly. A person who is aware that criminals are depositing dirty money into Tornado Cash smart contracts, yet decides to deposit their own funds into those same smart contracts, knowing that their effort will help these criminals conclude transactions that disguise the source of their funds, ticks all the boxes for a money laundering charge.

A licit user of Tornado Cash accused of money laundering might try to wiggle out of the charge by saying: "Sure, I knew crooks were using Tornado, and I know my efforts helped them. But I was only using it for legal reasons. I wanted to get privacy for myself." But that's not a very good defence against a money laundering charge, for the same reason that someone who tries to make a profit from obfuscating criminal funds can't evade a money laundering charge by saying they were only motivated by profit, and profits are legal. The desire to improve one's position, whether that be to get privacy or profits, isn't an excuse to launder money for crooks.

To sum up, the task of any prosecutor trying to bring money laundering charges against the Tornado Cash stack is to find the actual third-parties who misuse the platform for laundering. In a slimmed-down Tornado, that means chasing down relayers and savvy licit users. In the DoJ's actual indictment, it's also trying to show that owners/operators of user interfaces qualify, and while it's not a bad theory, we'll have to wait for the court date to see if it gets confirmed.

Who should pay for scams? Victims or their banks?

Scam call centre on CCTV, via BBC.

Here's a question for you. Should banks be required to reimburse customers who have been scammed?

I was recently reading a CBC article about a 63-year old Toronto man who responded to a phone call from a scammer claiming to be a Bank of Montreal employee, warning him that fraudsters had accessed his bank account. He was soon cajoled into paying out $16,000 to the scammer. Not only did the Bank of Montreal not reimburse the victim the full amount. It continued to charge him interest on the stolen funds.

Which isn't surprising. As the law currently stands, Canadian banks don't have to reimburse their customers who fall prey to authorized push payment (APP) fraud, a range of scams that includes calls from impersonated bank employees, RCMP scams, and fake Revenue Canada refunds.

So why not flip the whole system on its head? Why not require the Bank of Montreal to fully reimburse victims of these sorts of scams? The idea isn't without precedent. In 2024, UK will require that most victims of APP fraud be reimbursed within five business days by their bank.

There are some good arguments in favor of this policy. 

As it currently stands, individuals and their families, friends, and support systems are the main lines of defence for detecting scams. But there are big gaps in these lines of defence. Everyone has vulnerabilities, which scammers skillfully exploit to induce panic. Once in a panic, the victim's ability to think clearly is short-circuited, opening them up to being exploited by the scammer. A victim's second line of defence is to seek a second opinion from a sibling or spouse, but these third-parties may not always be available to help out the scam target.

Banks, by contrast, don't panic. Like scammers, they are cold rational machines. In addition, bank computers never turn off, which means they are available 24/7 to detect fraud. They also have a vast amount of knowledge about their clients' financial lives. Combine this data with technology like AI, and banks are in prime position to intervene in the crucial panic stage of the scam process, thus scuttling the scam.

Banks already do plenty of fraud detection. But imagine how much more vigilant they will be if their profits are at stake because they must reimburse scams.

None of this would be free, though.

Making Canadian banks liable for scams will inevitably mean higher fees and more banking frictions for everyone else. After all, reimbursing victims adds a new cost item to bank operating expenses. To recoup these costs, banks will hike fees on a range of banking products. Bankers will also want to reduce costs by catching scams in progress, which means extra checks when any irregular payment occurs, thus slowing down everyone's economic lives.

While no one likes extra bank fees and delays, think of these burdens as an alternative to the implicit costs that families, friends, communities, and civil society are already absorbing due to APP fraud. For instance, to prevent his elderly parents from being scammed, Jack tries to vet all of his parents' bank transactions. If banks are obliged to reimburse victims, Jack no longer needs to burden himself by monitoring his parents transactions; the bank will now take on that responsibility. The cost of this bank-provided anti-scam insurance comes in the form of Jack, and everyone else, paying higher fees and dealing with the odd delayed transaction.

This isn't a net loss, but a swap of one burden for another. Which is the better option for Jack and his parents? Is it more cost effective for him to monitor his parents transactions, or to pay his bank to do the job?

This gets into the problem of moral hazard. If banks insure customers against scams, then folks like Jack and his parents will become less vigilant, which means the public will be more susceptible to scam calls. However, as long as the additional vigilance brought to bear by banks more than compensates for the lost vigilance of individuals and communities, and does so at lower cost, the policy probably makes sense.

Beware, though. The policy could backfire it it unintentionally unbanks the vulnerable.

Victims of scams are vulnerable. They may be elderly, lonely, have low income, are weighed down by debt, or are working multiple energy-sapping jobs. Requiring Canadian banks to reimburse scams will make it more costly for them to service these groups. In response, banks may close the accounts of those they deem most likely to be tricked by scams. And so one of the unfortunate side effects of trying to protect the vulnerable from scams may be to actually burden them with a worse problem, no bank account.

There may be a fix for to this. Legislators may need to add a companion rule prohibiting banks from discriminating against customers on the basis of "scammability." However, keep in mind that this new rule will go on to have its own round of unintended consequences, which one hopes doesn't necessite a third rule, and a fourth one, and a...

Let's not forget the scammers, by the way, who won't sit idly by. 

Scam call centres will incorporate the new policy as a way to make their attacks even more effective. Imagine a panicked customer who is on the verge of transferring funds to the scammer. She suddenly blurts out loud: "Wait, is this a scam?" The scammer, reading off his script, pounces. "This is not a scam, ma'am, and even if it was, you live in the Canada. Your bank will cover it." The victim's worries allayed, the money is transferred, whereas without a policy of reimbursement the alarm bells in the victim's head might have been sufficient to get her to call a level-headed friend or family member for advice, likely putting an end to the scam.

In response to these tactics, banks will have to roll out their own information campaigns. Thus begins a cat and mouse game, whereby scammers adapt to banks and banks adapt to scammers, who in turn adapt to banks. But this is a cat and mouse game that has always existed, albeit with a different cast of characters, that is, scammers being pitted against individuals and communities. By changing the status quo and pitting scammers against a group that is more well-equipped for the game, bankers, we may all come out ahead.

Central bank digital currencies and the fallacy of immaculate adoption

I recently noticed that the Bank of Jamaica, Jamaica's central bank, has implemented two new marketing strategies to drive adoption of its new central bank digital currency, Jam-Dex. Jam-Dex is one of only four operational central bank digital currencies (CBDCs) in the world, having been introduced to Jamaicans in July 2022.

Now, I have no idea if these efforts will get Jam-Dex to succeed. In 2022, the system processed just J$357 million (or $2 million U.S. dollars.), but that comprised just six months of operations, so that's probably not enough time to judge it. What particularly interests me is how Jamaica's strategy of offering incentives to businesses and consumers serves as advance warning to other central bankers that one of the key tenets of the CBDC intellectual enterprise, what I call the immaculate adoption doctrine, is wrong.

In their white papers on CBDC, central bankers generally assume that the product will be immaculately adopted. The thinking goes like this: "We don't have to worry about devising a marketing plan for our new digital currency, nor think about incentives to promote usage, or the possibility that the product fails. All we've got to do is design it, put it out there, and – presto! – the public will instantly flock to it."

But as I've been saying for a while now the immaculate adoption doctrine is wrong. CBDC will probably just be a middling payments product. Existing options like cash, insured deposits and fintech balances work just fine for most folks, CBDC adding no extra features to the mix. It's just not possible to take a middling payments product and launch it, effortlessly and immaculately, into wide adoption. A big and expensive marketing push from central banks will be required if CBDC is to ever be adopted, Jamaica's Jam-Dex being a good example. And even then there's no guarantee of success.

The immaculate adoption doctrine gets even worse, though. Supremely confident in the success of their product, many central bankers fret that it will be too popular, hurting the banking system by stealing their deposits. To prevent this, they are building flaws into the product, effectively turning a middling product into a crappy one. A crappy product is even less likely to succeed.

Dirk Niepelt and Cyril Monnet recently make this same point with respect to a euro CBDC. In order to protect the business models of European commercial banks, the ECB wants to "trim the digital euro's attractiveness," the authors say, by adding holding limits for consumers and merchants. However, given the fact that European private sector payment options are already quite convenient, Niepelt and Monnet worry that the imposition of these hurdles condemns the ECB's CBDC to death on arrival.

The immaculate adoption doctrine of CBDC needs to be replaced by the it'll-be-a-hard-and-dirty-slog doctrine of CBDC. First, if they are to flourish, CBDCs can't just be carbon copies of existing private payments options. They need to offer something unique. Figuring out what these features are will take years of trial and error. Second, central banks will have to resort to dirty marketing tricks, incentives, bribes, arm twisting – all usually the domain of the private sector – to kickstart their CBDCs. Lastly, central banks need to stop deluding themselves that they can simultaneously launch a decent CBDC while also preserving the banking status quo. Those two things aren't possible! Stop pussy-footing around and admit that the whole effort will involve breaking a few banks.

Given that CBDC will be a hard and dirty slog, and not an immaculate ascendance, central banks need to think deeply about whether they truly want to undergo the pain of issuing a CBDC, which means being sure that society really needs one. Otherwise, they shouldn't get into the game.

UK's core payments settlement system fails... again. Some thoughts

As they increasingly forsake cash, regular folks are making dozens of digital payments every month. What they don't realize is how this growing reliance on digital payments increasingly yokes their commercial lives to the fate of a single piece of infrastructure: their central bank's large-value settlement system. When that system experiences a glitch, everyone's financial life gets put on hold.

In the United Kingdom's case, it is the Bank of England's RTGS settlement system that lies at the core of the economy. RTGS's centrality is highlighted by the fact that all the arrows in the chart below converge on it: every payment in the UK, big or small (except for cash), ultimately gets finalized using RTGS.

Alas, RTGS failed this Monday for six hours. No reasons were given, although I can't help wonder if it is was due to a software glitch stemming from Bank of England staff having been recently upgraded RTGS to the ISO 20022 payments language, rather than something like a cyberattack.

RTGS's centrality illustrated. Source: Bank of England

This isn't RTGS's first long failure. Back in 2014, a poorly-managed software update caused RTGS to shut down for 9 hours, leading to a revealing independent review.

The failure of the nation's key piece of payments infrastructure, even for just a few hours, is not a good thing. During those hours of unavailability, costly delays are imposed on day-to-day commerce as well as financial markets. Even when a buggy system is up and running, the uncertainty of another potential long failure acts as a pervasive cost on commercial society. 

To reduce these costs, central bank large value payments systems are typically built with multiple layers of redundancy. In RTGS's case, the hardware is hosted at two different sites, so that if the primary site goes down, the other one can quickly kick in. Presumably whatever knocked RTGS down last Monday was fierce  enough to incapacitate both sites.

A third layer of redundancy comes in the form of the Bank of England's Market Infrastructure Resiliency Service, or MIRS. With RTGS's two sites incapacitated, the Bank can "fail over" to MIRS, payments recommencing. MIRS uses different software, programming, and hardware, as well as being  hosted in a geographical remote location with a separate group of staff. This is achieved by an outsourcing arrangement with SWIFT, the same folks who run the global SWIFT messaging system.

There's no indication that the Bank of England failed over to MIRS earlier this week, staff preferring to focus on fixing RTGS instead. Alas, this choice subjected the UK economy to a long settlement delay. Why no fail-over to MIRS? Why choose such a long period of settlement deprivation?

A reading of the inquiry into the 2014 failure gives some clues into what may have happened two days ago. When RTGS failed on Monday, October 20, 2014, the Bank of England likewise chose not to fail over to MIRS. Why? The inquiry pointed to the fact that it would haven taken 2-2.5 hours to get MIRS up and running. Given this length of time, it made sense to try to fix RTGS instead, an inherently-preferable system because of features like the ability to save on liquidity, which the back-up system MIRS lacked.

Management was also reticent to switch on MIRS because they weren't sure if, after having activated it on Monday, they could turn it off on Tuesday night and manually return to a now-repaired RTGS without making a mistake. Bank officials only felt comfortable doing this manual switch back to RTGS on a weekend, because it afforded them much more time than a weeknight.

And thus trepidation about switching on the back up system led to it never being activated in 2014, which forced 9 hours of settlement deprivation on the UK economy.

Among its suggestions, the 2014 inquiry called for an upgrade to the MIRS back up option in order to make it a less anxiety-inducing option to turn to. The passage is worth reading in full:

Work should be undertaken to remove or reduce the barriers to invocation of MIRS so that
the Bank can "switch and fix" in parallel and in confidence. This should focus on testing the process to fail-back to RTGS intraweek (which is the primary barrier to invocation). If it is not possible to reduce this barrier, consideration should be given to enhancing the resilience and functionality within MIRS. In addition the Bank may wish to consider other back-up options for RTGS.

These were all good ideas. They would have reduced the hassle of resorting to the backup option by either improving the switching experience, or by upgrading MIRS's features so that being stuck on it for a few days posed less of a nuissance.

Which brings us back to 2023. If there is an inquiry into Monday's RTGS outage, investigators will need to explore why a multi-hour delay was once again imposed on UK citizens. Was it because, once again, the costs of using the back up system were deemed too high relative to the benefits? If so, were the costs deemed too high because none of the improvements suggested back in 2014 were adopted?

Failure to learn from the past would be unfortunate. These issues are especially salient because the Bank of England will introduce the next version of RTGS in 2024. Given that the updated RTGS will be built with more modern technology, it will (hopefully) fail less often than the older version. But it will still fail. What will the updated back up scheme look like? Will RTGS quickly switch over to tertiary site, or will the economy be forced to endure multi-hour settlement failure as a fix is pursued?

These are not just questions for the UK, but for every nation, since we all have large value payments systems on which commercial society is entirely dependent. It seems to me that if you have designed and built a back up system, that back up system should be, ya know, used. Those who operate them, usually central banks, should not be afraid to switch over. In the UK's case, that means that the decision to turn on MIRS (or whatever back up system the updated RTGS will use after 2024) should always be an easy decision for the Bank of England to make, not a gut-wrenching one.