by Bryan Ji and Jendrik Poloczek, November 22, 2023

The use case and added value of transaction privacy are obvious. Leveraging cryptographic proofs like ZKP preserves anonymity and confidentiality while making payments or transferring money on-chain. Without transaction privacy, everything on-chain is public. Users expose their information and metadata. Most users don’t want that – especially institutional ones. Nevertheless, it is by no means certain that transaction privacy will become an essential feature of public blockchains. On the compliance side, there is a lack of effective ways to stop malicious actors from abusing the system. On the user side, UX issues hinder broader adoption. This research effort discusses the most promising approaches and protocols to combat those challenges. It covers their basic ideas and trade-offs and suggests a categorization of the current landscape of transaction privacy.

TL;DR

• There are different layers of privacy. Transaction privacy specifically deals with how to preserve identity and value transferred.
• In the aftermath of Tornado Cash, there are many leftover problems in the scope of how to be compliant and provide a better user experience.
• To be compliant, protocols must ensure they are free from abuse by malicious actors (e.g., money laundering).
• To be user-friendly, low gas fees, compatibility with DeFi protocols, and better privacy guarantees are must-haves still under development
• We see the installment of a compliance committee as the most effective approach. It provides a plausible ground for authorities to identify malicious users while requiring no extra effort from innocent users.
• The UX front has seen a suite of new solutions, such as DeFi adapters, MASP, and account-based models, which either aim to increase the number of transaction privacy use cases or give users a better privacy guarantee.
• It will be a long battle between protecting privacy and providing options/ways for compliance to mitigate system abuses. There is further room for innovation, such as faster execution in identifying abuses or using an ensemble of different strategies/measures to increase overall system robustness.
• It is a fight worth fighting. If transaction privacy finally manages to satisfy regulators and users alike, it would also be a major victory for the long-term attractiveness and usability of public blockchains for a broader audience.

Locating transaction privacy

In the crypto space, we always advocate for the transparency benefits that blockchain enables, while we often neglect the other side of the coin. Public blockchains lack the privacy that people take for granted in real life. For example, when paying or wiring money via traditional rails, the sender can’t see the receiving end’s transaction history, and vice versa. On the blockchain, everything is publicly available by default, and companies like Arkstream and Chainalysis are instrumental in monitoring on-chain activities. If blockchains continue to lack privacy, institutional adoption will be tough as it will leave their proprietary data vulnerable to exposure. It is, therefore, not surprising that pioneers like Zcash and Monero, which enable anonymous payments and transactions, have quickly found adoption. However, this first wave came to an abrupt end in August 2022. The OFAC blacklisted the popular transaction privacy protocol Tornado Cash, sending the whole on-chain privacy market in agony. 

But now, there are promising signs of a second wave. Recently, we have seen several protocols and innovative approaches tackling application privacy that could win over both authorities and users.

Before we dive in, let’s briefly explore the different layers of privacy and where to locate transaction privacy:

• Network privacy ( NYM – backed by Greenfield – and Tor):
  Obfuscates metadata of network traffic and makes users’ IP addresses hidden.
• Data privacy (Mind Network, Filecoin):
  Preserves privacy in data sharing/storage, functioning as a data layer for computation.
• Compute privacy (Aleo, Aztec, Zama):
  Confidential computation on private datasets/states.
• Application privacy (Tornado Cash, Railgun, Firn | emerging players: Elusiv, Nocturne):
  Enables privacy on the application level, e.g. governance / private voting and transaction privacy.
• Full-stack privacy (DarkFi):
  Since the different layers of on-chain privacy are composable, some providers are building ecosystems where privacy is embedded from head to toe, including novel ideas such as anonymous engineering.

The following section discusses the problems preventing transaction privacy from being further adopted.

Transaction privacy –  the challenges

There are two kinds of problems in general: Compliance problems originate when protocols cannot meet the authority’s demand to prevent money laundering or terrorist funding. On the user side, issues such as high gas fees and a lack of composability with DeFi protocols hinder mass adoption. 

COMPLIANCE CHALLENGES

1. Preventing bad actors from abusing the system:
   In the architecture of a transaction privacy protocol, privacy is assured through a communal pool where users deposit funds. Linking a withdrawal back to its initial deposit becomes infeasible as all users’ funds merge within this shared pool. However, malicious actors’ money might also be in the pool. Once the pool is tainted, there is no way to prove and identify legit withdrawals. In the aftermath of Tornado Cash, a dusting attack sent funds to public addresses of public figures, who were later banned due to failure to prove non-association with the malicious deposits.
2. Navigating regulatory ambiguity:
   Travel rules are often applied to traditional payments/transfers. However, in the on-chain private payment setting, there is a lack of clarity on whether travel rules apply or not. If a protocol falls under the Travel Rule, it has to be able to report the originator’s and receiver’s name. This causes extra friction on the user side (KYC) and makes the protocol subject to the “honey pot” risk. Even higher requirements apply (more PII shared) when the amount transferred is above 1,000 USD/EUR, as suggested by the FATF.
3. Earning legitimacy for mainstream adoption:
   Legitimacy ensures that users can engage with protocols, confident that their assets will not be arbitrarily frozen nor that they will find themselves unexpectedly on a sanctions list. This trust is cultivated through proactive engagement with regulatory bodies, transparency in operations, and the visibility of those in leadership positions.

USAGE CHALLENGES

1. Charging for private transfers:
   Privacy comes with a price. For most protocols, such as Elusiv and Railgun, it consists of two parts:
   – A protocol fee is charged for using the privacy service, for each time shielding and unshielding tokens. It is based on transacted volume with a percentage or fixed fee depending on the protocol.
   – A relayer fee is charged to use a relayer service that breaks the linkage between sender and receiver. It executes the transaction on behalf of the users. It is usually required to pay this fee in a protocol token or stablecoin.The actual costs further depend on the network users operate on and the respective current gas fee. Arguably, this is the major reason hindering privacy from further adoption, especially on networks like Ethereum. Most transaction privacy protocols have adopted the UTXO model from Zcash (different from the account model used by chains like Ethereum, UTXO represents ownership of certain assets, which arguably are more suitable for payment use cases), and each time users interact with the protocol the Merkle tree that stores the UTXO needs to be updated and verified, being the main driver of costs, together with the proof verification.
   In addition, the concept of imposing an extra fee for privacy in the digital realm raises philosophical questions. It challenges the traditional notion that privacy is an inherent aspect of daily life, not a premium feature to be purchased.
2. Bootstraping the anonymity set:
   The anonymity set is a concept that is embedded in all privacy systems. It determines how private the system is. Suppose a system only supports a fixed number of specific tokens to be deposited/withdrawn by a few participants (low entropy). In that case, it can easily be de-anonymized using time/correlation attacks. The higher the entropy, which can be e.g. increased by adding users, funds, and different transaction amounts or multiple different asset types, the bigger the anonymity and the better the privacy. Young protocols without any significant adoption yet suffer from a small anonymity set. Hence, early adopters expect privacy mining incentives/airdrops for facing inferior privacy.
3. Integration with existing (DeFi) protocols:
   A deeply integrated transaction privacy protocol within a DeFi protocol such as Uniswap would allow a privacy toggle on swapping – without the need to interact with the privacy protocol themselves. A wallet backend integration of privacy protocols would also allow natural interaction with (DeFi) protocols. However, smart wallet standards, also known as account abstraction, will make integration even more complex (e.g., social recovery).
   Solving the abovementioned compliance problems is crucial. We believe that with a proper compliance approach to ensure legality and radiate legitimacy, users would flock to these protocols.

In the next section, we outline the different compliance measures that we have seen employed in privacy protocols.  

Approaches to solve compliance challenges

1. Deposit monitoring on smart contract level:
   Deposit monitoring happens when depositing addresses are cross-checked with sanctions lists and blocked if the address is on the list. The authoritative sanctions lists are maintained by governments, such as OFAC in the US, to keep track of individuals or entities that have conducted illegal business, such as international drug traffickers or terrorists. One infamous hacker group on the list: the Lazarus Group. The North Korean hackers have been accused of executing the largest crypto exploit to date – the Ronin Bridge hack ($624m). They used Tornado Cash to distribute stolen funds to other wallets and make them untraceable. Wallets flagged under the Lazarus Group have been blocked by parts of the Ethereum infrastructure, see dashboard.
   Deposit monitoring is easy to implement on the application level as relayers can choose not to process orders from addresses on the list. However, the list needs continuous, frequent updates. Malicious actors might front-run the protocol before they are added to the list.
2. Proof of innocence:
   Proof of innocence is a novel idea proposed by Ameen Soleimani, the originator of the privacy pool protocol. Vitalik also co-authored a paper that explains how it works together with compliance requests: instead of parking funds with everyone in a shared pool, one can choose to join a pool of many pools that is highly likely to be clean. Meanwhile, a zero-knowledge proof is generated to prove that the user’s funds come from an innocent pool without disclosing the deposit/withdrawal address. The advantage of this approach is that it fulfills the regulatory request to some extent that innocent users always mingle their funds with each other. They can do that by using the information of a trusted/authoritative third party that knows all the bad actors or by picking the set themselves. While this approach is permissionless in nature, it inherits a crucial drawback: Consider ten innocent users mingling their funds in a clean pool. One day, one of them decides to become a bad actor by using his private funds for terrorist financing. At the point of pool creation, all actors were innocent. However, later, the pool became tainted. A similar argument here is to consider the bad actor to be hidden at the point of pool creation and later revealed. Extra dependency on anonymity set providers is another drawback.
   On top of that, it also poses user friction, such as carefully choosing the anonymity set or generating additional proofs. Furthermore, it naturally poses a trade-off between selecting a larger anonymity set, which gives better privacy, and being more likely to be compliant. Because there is an incentive for users to pick the latter, we assume that the size of the anonymity can’t be large enough optimal as users would trade privacy for compliance.
3. KYC:
   One important reason for the adoption of KYC in a transaction privacy protocol is that the Travel Rule requires KYC on senders and receivers. An off-chain entity verifies user identities and an on-chain credential issuer gives users a credential to access the protocol. The disadvantage is that users have to trust that the credential issuer won’t collude with the KYC service provider to reveal their identities. User onboard is another friction. The benefit of this approach is that it bears no regulatory risks and users can be completely comfortable using it. Here, some protocols proactively require KYC so that they can comply with the Travel Rule if they become subject to it in the future. We see Hinkal and Panther Protocol taking this approach.
4. Frontend / RPC request monitoring:
   A protocol can use bad actor disallow lists on the application frontend to block requests from a specific source IP / range (i.e.geoblocking) or even wallet accounts. However, this can be easily circumvented by crafting your own transactions without the frontend. A different location for a blocking mechanism would be the RPC provider, such as Metamask’s backend Infura. Infura could block based on IP / range or wallet accounts. The protocol needs to collaborate with the RPC provider and process authority requests. However, the bad actor could easily swap out Infura for another RPC provider that is not blocking requests or could run its own full node. An alternative way to circumvent: If good/bad actors use a VPN they might be able to bypass the network-level blocking mechanism on both frontend and RPC provider. However, it might be the case that the frontend/RPC provider is blocking all known VPNs so that the bad actor can’t use the service through a VPN.
5. Viewing key:
   The Viewing key approach allows users to reveal a specific transaction or any transaction under a wallet to a third party, e.g., a tax office or a legal authority. It works well for innocent users as they are incentivized to comply with whatever the law requires. It may be insufficient regarding malicious users, as viewing keys are voluntary and malicious actors have authority over sharing the key or not.
6. Rate limits:
   Rate limits prevent users from depositing and shielding funds that exceed what protocols allow at a time. It was adopted in Aztec’s ZK.money (not operative anymore) and Light protocol. Rate limiting helps alleviate the risk of being abused by hackers who just stole a big bag of money.
7. Permissioned/permissionless compliance committee:
   The core of the compliance committee idea is a voting committee that decides collaboratively to reveal transactions. The permissioned version would only allow certain reputable players to join the committee, whereas the permissionless version would enable anyone to join to become a voting member. The latter could be realized by aligning incentives and penalties to conform to consensus. Naturally, a mixture of both is possible.
   We’ve seen two protocols exploring this concept. Silent protocol established a committee of recognized and reputable players in the space. They can decrypt one’s balance if multiple committee members approve. This approach enables involuntary disclosure but also carries the risk of abusing the system by collusion. Elusiv took the approach further by separating the governance from the revealing process. Whenever an authority request comes in, the protocol governance decides whether to reveal the transaction/wallet or not with the success of the protocol in mind. The actual revealing happens through an incentive/penalty-aligned MPC network. We believe this approach defends privacy while aiming to be as compliant & legitimate as possible.

In the table above, we suggest a comparison of the different approaches in three dimensions: 

• Compliance – the probable effectiveness of a compliance measure:
  KYC approach and compliance committee rank highest since both enable involuntary disclosure.

• Implementation – implementation difficulty of each approach:
  Deposit monitoring, viewing key, rate limits, and RPC requests can be implemented easily. The other three require additional work. For example, proof of innocence requires further development of ZK circuits.
• User Friction:
  For the deposit monitoring, frontend/RPC request monitoring, and compliance committee, users can use the protocol as is. Approaches like viewing key and proof of innocence demand users to interact with the protocol to be compliant post-deposit. The KYC approach has the highest friction since it has to be done pre-deposit.

The table below shows the different combinations of approaches that protocols use in the transaction privacy space. We have also clustered the approaches by what steps in the fund’s lifecycle they apply to.

Approaches to solving usage challenges

1. DeFi adapter:
   DeFi adapters allow one to use their private balance to interact with DeFi protocols natively. With the DeFi adapter, you can out-of-the-box use existing smart contracts with a private balance of a transaction privacy protocol. The basic workflow functions similar to making a private transfer but calling a smart contract function instead of calling a public externally owned account. In this way, pro traders can anonymously execute their strategy without the fear of somebody tracking their wallet address.
2. Stealth address:
   Compared to employing ZKP for transaction privacy, the stealth address technology is readily available to be implemented on the consensus layer and many have discussed the practicality of it. The basic idea is that the stealth address itself is a shared secret that only the sender and recipient know. Only the recipient can compute the spend key by combining the shared secret and his private key. It is very different from the ZKP approach, where there is a relayer between passing the message and obfuscating the linkage. Although easy to implement, stealth addresses are not perfect either. To receive assets, the recipient needs to scan all ephemeral public keys to find the stealth address that the user can consume. Since public keys are stored on-chain, it also poses overhead to blockspace. Vitalik’s main criticism of stealth address technology is that it is not compatible with social recovery.
3. Account-based model:
   Although most protocols inherit the UTXO model pioneered by Zcash, some protocols have explored the account-based model in recent years, with the main benefit of not having indefinitely growing UTXO sets. The account model is implemented as a smart contract that manages all encrypted account balances. A change of state overwrites these. Thus, it helps alleviate the wallet synchronization problem commonly seen in UTXO-based protocols. Zether is an account-based model implementation. It allows confidentiality, with an extension to enable anonymity.
4. MASP (Multi-Asset Shielded Pool):
   A MASP includes multiple arbitrary token types. Combining these volumes allows for a larger anonymity set.
5. L2s:
   L2s help solve the gas fee problem that Ethereum has by using validity or optimistic proofs. Protocols built on top of L2s can leverage the edge to reduce the cost of making private transactions.
6. Alignment with end users:
   At the end of the day, the Privacy Space still faces the problem that users have to pay for data protection in the first place, regardless of whether the costs are low or high. This stands in stark contrast to the traditional world, where such expenses for privacy are not typically encountered. Therefore, it’s essential to  align the strategies and solutions with the needs and expectations of users.

We see protocols experimenting with ideas from above, solving UX problems from different angles.  

Closing thoughts

1. On the compliance front, the discussed approaches are promising and proactive. But, there is still space to fine-tune. Whatever path, it’s essential to identify malicious actors as quickly as possible. Most of the time, malicious actors don’t optimize for 100% untraceability but speed to off-ramp. The execution to identify these bad actors would be crucial to stop them from cashing out. How do regulators and protocols identify anomalies faster, and how should the system be resistant to being abused by authorities? None of these approaches are silver bullets; thus, we’d like to see a combination to increase the robustness.
2. The scalability/agility of compliance approaches – can the measurements be extended to serve millions or even billions of users? Can these methods maintain their efficiency and accuracy in the face of rapidly evolving regulatory requirements?
3. How to price privacy? It is debatable whether on-chain privacy should be charged for given that it is free of charge to some extent in real life. Also, what level of privacy is the user willing to pay for?
4. Which part of transaction privacy is more important to you? Your identity (anonymity) or how much you are paying (confidentiality)? The latest upgrade of Solana proposes a confidential transfer token program that allows SPL token confidentiality (hiding the transfer balance).

We are aware that the transaction privacy space is evolving rapidly. We welcome comments and suggestions regarding which additional promising approach or protocol we should have a mentioned. Are you building a privacy solution yourself? Greenfield and the authors of this piece, Bryan and Jendrik, like to hear about it.

Finally, a special shoutout to Felix and Markus for their contribution to this piece!