a16z: Achieving Cryptographic Privacy and Regulatory Compliance with Zero-Knowledge Proofs

Original Title: “Privacy-Protecting Regulatory Solutions Using Zero-Knowledge Proofs: Full Paper”

Authors: Joseph Burleson & Michele Korver & Dan Boneh, a16z

Compiled by: The Way of DeFi

Introduction

As of now, among all the utilities provided by programmable blockchains—such as security, predictability, interoperability, and autonomous economies—the most widely used blockchains do not offer privacy, which remains a key barrier to their widespread adoption. While not all cryptocurrencies are purely financial instruments and can be used for various purposes in the growing web3 ecosystem, blockchain users do engage in trading digital assets on the blockchain. The current architecture of most existing blockchains relies on transaction transparency to facilitate trust, but this default transparency and lack of privacy increase the risk of consumer harm, as it allows other blockchain users to view the transaction history and holdings of any wallet holder. The anonymity of blockchains serves as a protection against bad actors, but it can be easily overcome. Modern blockchain analysis practices indicate that heuristic analysis of user interactions can penetrate this privacy, allowing anyone who transacts with a wallet holder to effectively see their entire financial situation. Therefore, while it aids in tracking illegal financial activities, transaction transparency makes users of blockchain technology particularly vulnerable to fraud, social engineering, and asset theft by bad actors, as well as the risks associated with disclosing sensitive financial data to third parties.

The transparency of public ledgers on blockchains sharply contrasts with the default privacy of traditional financial systems, which arise from transaction records on private ledgers maintained by financial intermediaries, supported by statutory rights to financial privacy and human control over access to sensitive financial information. In fact, regulations and guidelines issued by the Office of Foreign Assets Control (OFAC), which oversees the U.S. financial sanctions regime, and the Financial Crimes Enforcement Network (FinCEN), which is responsible for U.S. anti-money laundering regulations and oversight, are designed to enforce transparency to overcome the inherent opacity of the traditional financial system and the privacy it offers. The record-keeping and reporting requirements generated by these regulations compel financial intermediaries to maintain and disclose information to the government (and take other actions, such as blocking access to assets) to support law enforcement investigations, prevent terrorism financing, and advance national security policies, among other matters. Importantly, these measures create exceptions for protected privacy rights, representing a balance between privacy rights and compliance requirements—albeit an imperfect balance.

For users on public blockchains, these protections do not exist—neither the actual privacy protection provided by the inherent opacity of private ledgers nor the explicit legal recognition of financial privacy rights. Moreover, attempts to introduce measures (such as customer identification and due diligence, commonly known as "KYC" requirements) may even undermine the minimum level of privacy provided by anonymity, as they create "honeypot" information that attracts malicious attacks and insider threats. While the disclosure of such information can harm consumers in traditional financial systems, it exacerbates the already high risks of theft, fraud, and even personal harm that arise from complete financial transparency.

Although some newer, narrowly focused first-layer blockchains primarily address privacy issues, users of blockchains that are inherently non-private must rely on a multitude of smart contract protocols and second-layer blockchains to anonymize transaction data, many of which utilize zero-knowledge proofs and privacy-preserving cryptographic techniques. These protocols and blockchains are often accused of having malicious intent (including being labeled as "mixers"), but it is undeniable that advancing privacy-protecting technologies for legitimate purposes has undeniable value. In fact, this technology can allow legitimate consumers to benefit from levels of financial privacy and consumer protection that exceed those enjoyed by consumers of traditional financial services. However, the same solutions that maximize privacy may hinder the government's ability to investigate, combat illegal financial activities, or recover stolen assets for the sake of promoting law enforcement and national security objectives. So, does this mean that blockchain technology will inevitably force people to choose between compliance with the detection, prevention, and disruption of illegal financial activities and privacy and consumer protection?

This article argues that the answer is no. Using modern cryptographic techniques to resolve this contradiction—unlike existing frameworks that rely on human control—is not necessarily a zero-sum game. It is both possible and necessary to reconcile users' privacy needs with the information and national security needs of regulators and law enforcement. This article presents potential use cases for zero-knowledge proofs in blockchain protocols to achieve both sets of goals. First, we will describe the basic principles of zero-knowledge proof technology, followed by an overview of relevant legal and regulatory frameworks that may apply. Then, using Tornado Cash as an example, we will outline some high-level solutions that developers and policymakers can consider.

In writing this article, the author affirms an important premise: "Regulate applications, not protocols." In the U.S., it is common practice for the application layer to use geofencing technology for sanctions screening and to restrict user access through various measures. While these restrictions are helpful, they are not foolproof, and bad actors may still circumvent these controls. Therefore, certain privacy-preserving technologies that may be easily exploited by sanctioned parties have already been incorporated into restrictions at the protocol level to address national security concerns. The author does not believe that all privacy-preserving technologies should make the same decision; developers should have the freedom to choose whether to adopt protocol-level restrictions to prevent misuse by illicit actors and potential regulatory liability. For those who choose to take protective measures, we merely provide potential alternatives for consideration that may make these solutions more effective while also limiting their potential for censorship.

Background

Achieving Privacy with Zero-Knowledge Proofs

Without ensuring privacy, blockchain technology cannot achieve mainstream adoption. For instance, when it comes to financial infrastructure, if users' salaries or other sensitive financial information, including payments for services such as healthcare, can be publicly viewed, potential users of blockchain-based payment systems may be very reluctant to use these systems. The same applies to social networking services, decentralized lending protocols, charitable platforms, and any other use cases where users value their information privacy.

Data supports this position. As of April 29, 2022, the 30-day moving average of the on-chain privacy-preserving services or protocols received a market value of $52 million, nearly a 200% increase from the previous 12 months. To understand the situation, many privacy-preserving protocols use algorithmic cryptographic techniques to facilitate blockchain addresses depositing digital assets into similar fungible asset pools, from which another blockchain address controlled by the same user can later withdraw the same amount and type of assets, effectively breaking the regulatory chain and suppressing the traceability of transactions. Some of these protocols and several second-layer blockchains use an algorithm known as zero-knowledge proofs to anonymize transactions without exposing sensitive user information on-chain.

Zero-knowledge proofs enable private transactions on public blockchains. At its core, a zero-knowledge proof allows one party (the "prover") to convince another party (the "verifier") that a statement is true without revealing any underlying data that makes the statement true. For example, the verifier can prove knowledge of the solution to a Sudoku puzzle without revealing any information about the answer. More interestingly, a person can prove that their age meets the threshold for purchasing alcohol or voting without disclosing their name and date of birth on their driver's license. (Technically, they would prove in zero-knowledge that they have a government-issued document, and the birth date on that document establishes the person's age.) This proof allows the verifier to believe that the fact is true without disclosing any other information.

People can leverage zero-knowledge tools to establish various privacy mechanisms. For example, Alice can send funds to a service that keeps transaction details confidential, and that service will provide Alice with a deposit receipt. Both the service and the public know that Alice has sent funds. Later, when Alice wants to withdraw funds from that service, she constructs a zero-knowledge proof to demonstrate that she has a valid receipt and that she has not withdrawn funds associated with that receipt. The proof does not reveal any information about Alice's identity but assures the service that it is interacting with someone qualified to withdraw those funds. Here, zero-knowledge proofs are used to assure the service that the withdrawal request is valid while keeping the identity of the withdrawer confidential.

Importantly, zero-knowledge proofs protect privacy by allowing selective disclosure of information necessary to assess compliance with policies without exposing all underlying information. Zero-knowledge proofs can achieve varying degrees of privacy, including complete privacy where no one can trace transactions, or privacy for everyone except a few specific parties. People may need strong privacy protections for many legitimate reasons, but these technologies can also attract bad actors. As the overall use of privacy-preserving protocols peaked in 2022, the relative proportion of value received from illegal sources also increased; by the second quarter of this year, illegal blockchain addresses accounted for approximately 23% of all funds sent to such protocols. Although these protocols employ privacy-preserving technologies, blockchain analysis firms, such as Chainalysis and TRM Labs, are sometimes able to trace illicit funds flowing through these protocols because they do not have sufficient amounts to obscure these activities, or they lack sufficient diversification. Furthermore, even if illicit actors utilize privacy-preserving technologies, they still face challenges in moving their assets off-chain, as in most cases, inflows and outflows are regulated by financial institutions in major global financial centers and other jurisdictions, thus needing to comply with anti-money laundering/counter-terrorism requirements. Therefore, while privacy-preserving protocols are crucial for maintaining the confidentiality of legitimate user information, they do create vulnerabilities in the blockchain ecosystem that illicit actors can exploit. It is certain that compliance with international laws and regulatory frameworks is complex, but implementing standardized and compliant zero-knowledge proofs in decentralized blockchain protocols can address some key vulnerabilities while benefiting web3 participants.

Applicable Regulatory Frameworks

To understand how zero-knowledge proofs can overcome the apparent dichotomy between compliance and privacy, it is essential to understand the specific judicial regulatory requirements related to combating illegal financial activities. In the U.S., the regulations most likely to affect privacy-preserving protocols can be divided into two main legal frameworks: (A) a series of federal laws and regulations commonly referred to as the Bank Secrecy Act (BSA)—(i) customer identification program and customer due diligence requirements (commonly known as "KYC" standards) and (ii) transaction monitoring and other record-keeping and reporting requirements; (B) U.S. sanctions programs under presidential wartime and national emergency powers. Web3 market participants must navigate the legal requirements of both regimes to minimize the risk of enforcement for non-compliance and mitigate the illegal use of protocols and platforms. Additionally, any violations can lead to severe consequences, including civil penalties and criminal prosecution.

The BSA requires certain financial institutions and other relevant entities to comply with a series of monitoring, record-keeping, and reporting obligations. The purpose of these obligations is to assist FinCEN, OFAC, and law enforcement in identifying, preventing, and prosecuting money laundering, terrorism financing, and fraud activities, as well as identifying and blocking assets belonging to sanctioned parties in the U.S. financial system based on national security and foreign policy objectives. Full compliance with the BSA and sanctions regimes can provide regulators and law enforcement with clear and auditable documentation of illegal activities, which is crucial for their successful enforcement.

Entities covered by or obligated under the BSA include traditional financial institutions, such as banks, as well as money services businesses (MSBs), such as currency dealers, exchangers, and remitters, among others. Furthermore, FinCEN has further clarified that individuals and entities that issue, manage, or exchange convertible virtual currency (CVC) or alternative currency value are also considered MSBs and must comply with all applicable compliance obligations set forth by the BSA. This is because certain mixing services can facilitate the transfer of alternative currency value from wallets within the platform to wallets outside the platform. In contrast, privacy-preserving decentralized blockchains may not involve currency transmission. As FinCEN explicitly pointed out in its latest guidance issued in 2019, non-custodial, self-executing code or software, even if executing mixing functions, does not currently trigger BSA obligations.

In contrast, the application of sanctions compliance requirements is less clear. The sanctions regime administered by the Office of Foreign Assets Control (OFAC) applies to all U.S. persons, including individuals and entities, regardless of where they reside, and requires them to identify, block, and isolate transactions involving sanctioned parties' property. Although OFAC states that the sanctions regime itself does not apply to the release of software and privacy-preserving technologies, if measures are not taken to prevent sanctioned parties from abusing these technologies—as discussed below—OFAC's response could undermine the viability of these technologies, as seen in the recent case of Tornado Cash.

KYC Standards and Transaction Monitoring

Individuals or entities whose business models are classified as MSBs must meet certain information collection and transaction monitoring requirements to fulfill their obligations under the BSA. MSBs must obtain KYC information from individuals using their services to verify their identities. As part of the KYC program, MSBs must at least obtain the user's name, address, and tax identification number.

Additionally, MSBs must monitor transactions conducted through their platforms and report any suspicious activities that may indicate illegal behavior by submitting suspicious activity reports (SARs). The BSA requires MSBs to submit SARs within 30 days if they know or suspect that a transaction on their platform may involve illegal activity, provided that the total amount of the transfer involved is at least $2,000. To encourage timely reporting, correctly reporting an SAR for a transaction will exempt the MSB from all civil liability related to that transaction.

While the BSA also imposes other record-keeping and reporting requirements on MSBs, such as submitting currency transaction reports (CTRs), this requirement currently does not apply to digital assets, thus having no direct relevance to current purposes.

Sanctions

FinCEN has full authority to manage the BSA, promulgate rules, and take enforcement actions against violations of the BSA, but OFAC has broader judicial authority. Most economic sanctions stem from the powers granted to the president under the International Emergency Economic Powers Act (IEEPA) and the National Emergencies Act (NEA). Therefore, sanctions are established through executive orders related to wartime and national security powers. OFAC oversees all financial transactions in the U.S. and can sanction any individual, entity, or country that poses a threat to national security. If an individual or entity designated by OFAC has an interest in any transaction or property processed by any U.S. person or entity (including but not limited to MSBs and banks, which are BSA obligated entities), U.S. persons or entities will be required to (i) block (freeze) the prohibited transaction and any accounts or property related to the designated person, and/or (ii) deposit any funds received related to such transactions into a segregated, frozen account, and (iii) submit certain reports to OFAC. In any case, no U.S. person or entity may process such transactions and/or release such funds until OFAC removes the relevant individual or entity from the sanctions list, the applicable sanctions program is lifted, or OFAC explicitly authorizes the release of the withheld funds through a license.

For sanctions related to cryptocurrency transactions, authority typically stems from EO 13694, which focuses on "significant malicious cyber activities." Individuals violating economic sanctions may face civil or criminal penalties. It should be noted that the standard for administrative or civil liability for violating sanctions is strict liability, meaning that even if done unintentionally, one may be held liable for sending or receiving transactions or failing to freeze property related to sanctioned individuals, entities, or countries. This effectively imposes a due diligence requirement to inquire about the source of funds when engaging in financial or commercial activities. On the other hand, criminal liability requires a showing of intent, meaning that the person violating sanctions did so knowingly. The Department of Justice prosecutes violations of sanctions under IEEPA or the money laundering statutes codified in Title 18 of the U.S. Code. However, an important conclusion regarding sanctions liability and OFAC compliance requirements is that these obligations apply to all individuals and entities operating in the U.S. or doing business in the U.S., regardless of whether the individual or entity falls under the BSA's coverage.

Optimizing Privacy Protocols to Reduce Illegal Financial Risks

The enhanced privacy potential offered by zero-knowledge proofs conflicts with the regulatory framework outlined above. The technology can obscure transaction details, meaning it may not easily comply with regulations such as the BSA—although whether smart contracts and code are subject to the aforementioned regulatory requirements remains an open question. As noted above, FinCEN explicitly exempted software code from the scope of the BSA in its 2019 guidance, so a truly decentralized protocol does not need to—even it is unclear how it could—collect and retain users' KYC information or file SARs. Similarly, the authorized regulations and cybersecurity executive orders governing the implementation of any sanctions refer to the "property and interests in property" of designated individuals and entities, indicating that software and computer code itself are not within the scope of sanctions. Recent guidance from OFAC seems to suggest that the release of software itself is not a sanctionable activity. However, this conclusion is far from clear based on OFAC's designation of certain smart contract addresses related to Tornado Cash.

Nevertheless, zero-knowledge proofs can be designed to mitigate some of the risks of exposure to illegal financial activities and economic sanctions liability through privacy-enhancing protocols, including mitigating the national security risks that OFAC sanctions aim to address. In particular, privacy-focused protocols can implement various measures to better manage these risks without undermining their effectiveness. Below, we summarize three feasible measures, each evaluated in the context of the privacy-preserving protocol Tornado Cash.

The Example of Tornado Cash

One way to demonstrate the potential of zero-knowledge proofs to overcome the existing dichotomy of potential liabilities under the current sanctions regime caused by privacy-enhancing technologies is through the lens of Tornado Cash, a recently sanctioned privacy-enhancing protocol approved by OFAC. Tornado Cash is a protocol deployed on the Ethereum blockchain designed to anonymize user assets to protect their privacy. Anyone can send funds from their Ethereum address to the Tornado Cash smart contract, where the funds will remain until the owner chooses to withdraw them. Typically, users wait weeks, months, or even years before withdrawing, as the intervening period (during which other users deposit and withdraw) may increase or decrease the effectiveness of Tornado Cash's privacy-preserving features. Upon withdrawal, the protocol utilizes zero-knowledge proof technology to transfer funds to a new Ethereum address, breaking the link between the address from which the funds were initially deposited into Tornado and the new address from which the funds are later withdrawn. The Tornado Cash protocol is immutable, trustless, and fully automated. The anonymity provided by Tornado Cash relies on multiple users simultaneously using the service to disconnect the connections between the wallet addresses used for deposits and withdrawals. Additionally, users retain a certificate that only they can disclose to prove their ownership of the deposited tokens. Consistent with the recent trend of rising usage of illicit mixers, the Tornado Cash platform has also been frequently used for money laundering. For example, in the April 2022 hack of the Ronin Bridge, approximately $600 million was stolen from the bridge and transferred to Ethereum addresses owned by the attackers. Days later, the hackers transferred part of the stolen funds to Tornado Cash. On August 8, 2022, OFAC designated the tornado.cash website and several Ethereum addresses associated with the service, many of which are smart contract addresses with no identifiable key holders. The Treasury noted in its announcement of this sanction that over $7 billion in illicit proceeds had been laundered through Tornado Cash, including $455 million laundered by the North Korean state-sponsored hacker group Lazarus Group, as well as substantial amounts related to the Harmony Bridge and Nomad Heists. The Treasury chose to take action against the protocol and its smart contracts, despite the significant collateral impact on innocent third parties, including blocking non-sanctioned individuals from withdrawing completely legitimate funds deposited using the protocol. This issue stems from the decentralized and non-custodial nature of Tornado Cash, making it difficult to identify organizations or individuals responsible for its activities. Therefore, in this case, applying traditional sanctions enforcement techniques and blocking property interests may pose technical legal challenges. While such protocols are sometimes viewed as attempts to evade regulatory requirements, from a cybersecurity perspective, the technical architecture of Tornado Cash can also represent robust privacy-preserving technology to prevent unauthorized third parties and malicious actors from accessing sensitive information about individuals and businesses conducting on-chain operations. This approach is preferred and may technically far exceed traditional operational controls that restrict access to information imposed on more centralized regulatory systems, which have proven increasingly susceptible to malicious attacks and insider threats.

In a press release accompanying OFAC's statement, the Treasury stated, "Despite public assurances to the contrary, Tornado Cash has repeatedly failed to implement effective controls designed to prevent it from being used to launder money for malicious cyber actors." In fact, as described in more detail below, Tornado Cash does have some technical controls in place to prevent the platform from being used for illegal financial activities. The question is—are there more effective technical controls, such as those utilizing zero-knowledge proofs, that Tornado Cash could implement to persuade the Treasury not to take the actions it has already taken? Let us consider those zero-knowledge proof solutions, including some solutions implemented by Tornado Cash, as well as other potentially efficiency-enhancing solutions. While none of these methods alone is a panacea, combining them can enhance the ability to detect, prevent, and disrupt illegal financial activities and the use of privacy protocols by sanctioned state actors. They are: (i) deposit screening—checking wallets for inbound transactions against blacklists and whitelists; (ii) withdrawal screening—checking wallets requesting the return of funds against blacklists and whitelists; and (iii) selective de-anonymization—this feature provides access to transaction information for federal regulators and law enforcement.

Deposit Screening

Digital assets native to the Ethereum blockchain or bridged from another chain can be exchanged for ETH and deposited into Tornado Cash in an attempt to protect the privacy of user transactions. To prevent assets from coming from sanctioned individuals or wallets associated with attacks or hacks, Tornado Cash employs deposit screening that relies on a designated address "blacklist." However, the additional use of a "whitelist" can address national security concerns while also minimizing the risks faced by legitimate users of the protocol, as further outlined below.

Blacklist

Tornado Cash's deposit screening enables it to automatically restrict who can use the protocol by blocking any proposed deposits from addresses that are sanctioned or otherwise blocked by the U.S. government. Tornado Cash tests whether an address is currently designated on various economic or trade embargo lists (or "blacklists") maintained by entities such as the U.S., EU, or UN through the use of on-chain oracles provided by blockchain analysis companies. Tornado Cash's smart contracts "call" the analysis company's contract before accepting funds into one of its pools. If the funds come from one of the addresses blocked on the specially designated nationals (SDN) list, the deposit request will fail.

While using blacklist screening for deposits is a good first step, this mechanism has several practical issues. First, when cybercriminals steal funds from victims, they can immediately transfer the funds into Tornado Cash, even before the victim realizes that the funds are missing, of course, also before the analysis company marks the funds as stolen or adds them to their software's SDN list. Second, if a cybercriminal's address is added to the SDN list before depositing into Tornado Cash, the thief can simply transfer the funds to a new address and immediately deposit the funds into Tornado Cash from the new address before that new address is added to the sanctions list. Sophisticated hacker groups, such as North Korea's Lazarus Group, effectively use these techniques to avoid detection. However, blockchain analysis companies attempt to overcome this limitation by using change address analysis and heuristic methods to identify non-designated wallets controlled by the same designated group. Finally, relying on non-government entities as truth arbiters regarding individuals or entities on the sanctions list may create accuracy issues that are difficult to identify and correct. For example, an analysis company may mistakenly blacklist an address, and it is currently unclear whether the owner of that address has any recourse to correct the error (unlike traditional financial institutions that can handle customer complaints). Additionally, since all sanctions represent government policy decisions, there is also the question of which sanctions list to add.

Whitelist

To mitigate the risk that analysis companies or government entities may unfairly scrutinize compliant users by utilizing blacklists, privacy-preserving protocols may consider a more robust form of deposit screening that also relies on a "whitelist" of wallet addresses to which deposit screening restrictions do not apply. This whitelist would include wallet addresses associated with regulated financial intermediaries—such as fiat on-ramps like Coinbase—that conduct comprehensive KYC screening as part of their onboarding process, thus eliminating the need for privacy-preserving protocols to screen these addresses, as outlined below.

Withdrawal Screening

For wallet addresses not included in the above whitelist, an additional deposit screening method is to check the oracle at the time of withdrawal and block any withdrawals requested from sanctioned addresses or addresses identified as being associated with illegal activities. For example, suppose an illicit actor immediately sends funds from an address to Tornado Cash after a hack. At the time of deposit, that address is not on the whitelist and has not been identified as being related to stolen funds or sanctioned individuals or entities, and the deposit is successfully completed. However, if the illicit actor attempts to withdraw funds later, and in the intervening period, that address is marked as being associated with stolen funds or is on the sanctions list, then the withdrawal request will fail. The funds will remain frozen, and the thief will be unable to withdraw. This method has many benefits. First, it can prevent thieves from using the Tornado Cash protocol to launder money. Second, Tornado Cash's implementation of withdrawal checkpoints serves as a deterrent, making it clear to wrongdoers that if they send stolen funds to Tornado Cash, those funds may be indefinitely frozen by the smart contract, preventing them from reaping their rewards. Such deterrence would only affect cybercriminals and would not impact compliant users of Tornado Cash. In fact, considering the characteristics of the deposit time period discussed above, and the likelihood that illicit actors may leave funds in Tornado Cash longer to most effectively anonymize their sources, this withdrawal screening feature would be very useful, as it could screen against the constantly updated Treasury sanctions list.

Although withdrawal screening can address many of the shortcomings of deposit screening, like deposit screening, it is powerless against any necessary risk assessments. Additionally, it would keep Tornado Cash reliant on the faithful operation of blockchain analysis companies regarding sanctions oracles. Furthermore, as with deposit screening, there is the issue of government scrutiny—only in the case of withdrawal screening could government abuse of sanctions lists lead to users losing funds.

This method allows users to deposit funds into the privacy-preserving protocol only when the deposit address (i) is not on the applicable analysis company's SDN list (i.e., the address is not on the blacklist) or (ii) has received the above funds from a regulated financial intermediary (i.e., the address is on the whitelist). This whitelist can be managed and updated over time by a decentralized autonomous organization (DAO) controlling the protocol or can come from on-chain address oracles associated with regulated financial intermediaries (similar to the blacklist oracles operated by Chainalysis). Certain privacy-preserving technologies can further advance this concept by directly connecting their protocols to regulated financial intermediaries, allowing users to deposit funds directly from these intermediaries into the protocol without first transferring funds to a separate wallet address.

Using both blacklists and whitelists as part of the deposit screening process has several clear advantages over using only blacklists. First, legitimate users who are wrongly or maliciously added to the blacklist can avoid scrutiny simply by utilizing regulated financial intermediaries to deposit funds into the protocol. Since most illicit actors should not be able to open accounts with regulated financial intermediaries, they cannot leverage the whitelist and will continue to be scrutinized, thus addressing national security concerns. Additionally, the whitelist will enhance the privacy of all customers of regulated financial intermediaries, as it will ensure they can enjoy the benefits of privacy-preserving protocols without worrying about scrutiny.

Ultimately, while deposit screening helps Tornado Cash fulfill its obligation to block prohibited transactions, it will not enhance the ability of other privacy service providers that may be viewed as MSBs and bound by the BSA, or individuals or entities that may be required to conduct sanctions-related risk assessments of their business activities, to monitor transactions for risk assessment purposes. Deposit screening is a good first step, but it is unlikely to fully reduce the illegal use of the protocol.

Selective De-Anonymization

Selective de-anonymization is the third method for meeting potential regulatory requirements, which can take two forms: voluntary and involuntary.

Voluntary Selective De-Anonymization

Through its deposit receipt feature, Tornado Cash implements a form of voluntary selective de-anonymization that provides individuals who believe they have been wrongly added to the sanctions list with the option to de-anonymize their transaction details to selected or designated parties. If a similar voluntary de-anonymization feature is combined with withdrawal screening for wallets not on the whitelist, users can choose to de-anonymize their transactions, and the Tornado contract responsible for withdrawals will remove any impediments arising from the aforementioned withdrawal screening process. Thus, users will receive their funds, but they will not benefit from Tornado's privacy-preserving technology, as their withdrawal address will clearly be linked to the deposit address. Voluntary de-anonymization would allow protocols like Tornado Cash to address some of the shortcomings of withdrawal screening (e.g., innocent users would not face the risk of having their funds frozen), but it would also reduce the effectiveness of withdrawal screening as a deterrent, as malicious actors would be able to withdraw funds from Tornado simply by opting out of transaction anonymity. In this case, illicit users would not gain any benefits from using privacy-enhancing services.

Involuntary Selective De-Anonymization

Involuntary selective de-anonymization is an additional measure that could be integrated into Tornado Cash's smart contracts to enable the government to trace and track illicit proceeds. While the BSA requirements are unlikely to apply to non-custodial web3 services, the traceability associated with blockchain protocols represents a key control measure that can more broadly prevent illegal financial activities, including those involving sanctioned parties. Involuntary selective de-anonymization represents a powerful tool for maintaining traceability for authorized purposes while protecting privacy from malicious actors and unauthorized third parties. The key question is, who will maintain the private keys that unlock the traceability?

One solution might involve providing the private keys to a neutral gatekeeping organization or a similar trusted entity, while providing another private key to government authorities. If a withdrawal transaction does not originate from a wallet address on the whitelist, both private keys would need to be used to de-anonymize, and the details of such transactions would only be disclosed to the law enforcement agency requesting de-anonymization. The role of the gatekeeping organization would be to resist de-anonymization until law enforcement first obtains and submits valid de-anonymization authorization or a court order. This would not only allow law enforcement to determine the source address providing funds for Tornado Cash withdrawals, thereby enabling the government to carry out its law enforcement and national security missions, but it would also alleviate the burden of holding the keys from the government, which is a suboptimal choice for both the government and Tornado Cash users.

This approach presents some challenges. First, it is unclear which entities would have access to the private keys. Currently, there is no known operational gatekeeping organization established to manage such a process. Additionally, there are many jurisdictional issues. Would each country—even authoritarian regimes—have its own private key that allows them to access transaction data? If so, how can it be ensured that these regimes do not de-anonymize transactions of U.S. citizens? Furthermore, how would the gatekeeping organization and government authorities manage their keys to ensure they are not stolen? These questions are not new. They arise every time key custody is discussed, which is the essence of involuntary selective de-anonymization. This solution has been unpopular and fraught with operational challenges—namely, the concept of "backdoors." Nevertheless, to meet regulatory requirements or reduce the use of the platform for illegal purposes, this is an option developers may consider.

One possible solution to the challenges outlined above is to allow users to choose which public key they want to use to encrypt addresses during withdrawals. Tornado Cash contracts could have multiple law enforcement public keys, one for each country. During withdrawals, users could choose which public key to use for encryption based on their jurisdiction. Users might need to provide evidence of their jurisdiction, which would determine which public key is used for encryption. This evidence could be hidden under a zero-knowledge proof, so that no one except the relevant government agency would know the jurisdiction of the withdrawal. Theoretically, this would address the issue of authoritarian regimes obtaining transaction keys, but it does not resolve the possibility of malicious governments requesting the key holders to provide private keys under the guise of good faith (but dishonest) legal processes.

For those entities with BSA obligations, selective de-anonymization would benefit the regulatory viability of maintaining withdrawal screening, including the ability to conduct OFAC-mandated sanctions screening, as well as the ability to collect KYC information and transaction data, and potentially submit SARs. Additionally, the aforementioned involuntary selective de-anonymization methods could be modified so that both key holders only possess private keys for information specifically required to be collected, retained, and reported under the BSA (e.g., KYC information and SARs), and can only submit these keys to FinCEN and OFAC, or to law enforcement upon providing valid legal process. This approach would help ensure the privacy of user data while allowing government agencies to fulfill their regulatory responsibilities.

Conclusion

For Web3 technology to thrive in the U.S., the development of privacy-protecting regulatory solutions is crucial. In crafting these methods, zero-knowledge proofs can provide a powerful tool to prevent cybercriminals and hostile state actors from using blockchain technology for illicit purposes while still protecting users' personal information, data, and financial activities. Depending on the operational and economic models of specific protocols or platforms, as well as regulatory compliance obligations, the use of zero-knowledge proofs can meet these obligations through deposit screening, withdrawal screening, and selective de-anonymization, better protecting the ecosystem from illegal use and preventing harm to national security. The diversity of activities in the blockchain space may require developers and founders to consider multiple approaches, including those proposed in this article, to address illegal financial risks.

Reiterating the previously discussed principle that protocols should not be regulated and that developers must have complete freedom to choose whether to adopt protocol-level restrictions to mitigate these significant risks, the author hopes these ideas spark creative discussions among builders and policymakers and further research and development around the possibilities of zero-knowledge proofs.