Many Web3 privacy technologies do not facilitate compliance, and conventional compliance approaches typically compromise decentralization – the foundation of all of blockchain’s benefits over Web2 and TradFi systems. Soda Labs’ solution is the ideal way to square the circle with Decentralized Compliant Privacy.

At least two trends are now clear in the blockchain space. Firstly, robust privacy is necessary for Web3 technologies to gain widespread traction.

Secondly, compliance is no longer optional. With recent regulatory developments, AML/CFT (Anti-Money Laundering and Counter Financing of Terrorism) compliance are a priority for asset issuers and crypto services – which means they need to be a priority for users, too. Those who do not maintain compliance will find themselves excluded from mainstream crypto financial services.

In this blog, we introduce the idea of Decentralized Compliant Privacy (DCP): a concept that encompasses key needs for both the blockchain space and the TradFi systems with which Web3 is increasingly integrating. We’ll explore the different elements of DCP – out of order, since it makes sense to set the scene before exploring why Soda Labs’ garbled circuits-based MPC is the ideal solution for this application.

1. Privacy

Firstly, it is now well established that privacy is the critical blocker for large scale adoption of Web3 technologies, especially by institutions.

Without privacy, organizations cannot maintain compliance with data protection laws, including Europe’s GDPR, HIPAA in the US, and various other frameworks. It is legally unacceptable for businesses to place customers’ sensitive data on transparent public blockchains.

Additionally, there are significant personal costs and risks from MEV exploits, phishing, and even physical attacks. The downsides of full and unmitigated blockchain transparency have been extensively catalogued elsewhere, including in our own blog.

Privacy solutions, of course, come in many forms, thanks to the experimentation for which the blockchain space is well-known. While we will look further at different technical approaches below, at this point we can say it’s vital that privacy is not only robust, but seamless. It must not impose unnecessary friction or costs on the user, or on businesses and builders.

Fix privacy, and you open the door to institutional usage of public blockchains – allowing potentially trillions of dollars of capital to move on-chain in the coming decade.

2. Decentralization

Secondly, the nature of both the privacy and compliance that we integrate into blockchain services must respect Web3’s ethos of decentralization.

This should not be controversial, because all of blockchain’s benefits come from decentralization. Bitcoin is a peer-to-peer system: it has no centralized intermediaries. Satoshi Nakamoto’s key innovation in launching Bitcoin (and with it, the first instance of a blockchain) was decentralization.

Implemented properly, decentralization brings a list of desirable properties to Web3 systems:

• Security, through elimination of single points of failure
• Openness, allowing anyone to use these systems
• Efficiency, through the removal of middlemen fees
• Transparency, allowing auditability and trust

Note that transparency is still possible when transactions are private (i.e. encrypted). Encryption does not impact consensus, since validators can still agree on the contents of the transaction, even if they cannot decrypt it. They can also agree on the validity of any cryptographic proofs included in the transaction, which do not need to leak any information about the underlying transaction. For example, a proof may demonstrate that a sender’s balance is greater than the number of tokens they send to a recipient, without revealing the actual amount.

In short, Web3 is not Web3 without decentralization. Any privacy solution should also be as decentralized as possible, to avoid compromising Web3’s unique benefits over Web2/TradFi systems.

For this reason, we avoid approaches that introduce unnecessary elements of centralization and single points of failure, such as Trusted Execution Environments (TEEs). These are secure hardware enclaves, where data is processed in isolation from the wider system. History has shown that TEEs are vulnerable to various types of attack, including supply chain attacks and side channel attacks.

3. Compliance

Another non-negotiable criterion for any privacy solution is compliance. There are many approaches to decentralized confidential computing (DeCC) in the blockchain world: fully homomorphic encryption (FHE), ZK proofs (ZKP), TEEs, trusted and trustless mixers like Tornado Cash, and more.

While FHE is an intriguing and promising approach, it is not ready for high-scale applications due to its significant computational and storage overheads, which make it relatively slow and expensive for on-chain use. ZKPs lack the flexibility required for complex applications where computation on shared state is required, including trading and lending dApps, while TEEs fail the centralization test.

Mixers bring another problem. These platforms pool funds from many users, then allow users to withdraw their balance to a new address, obscuring the link between sender and recipient. Some of the parties involved may have obtained their tokens illegally, often through hacking or extortion. By mingling one user’s tokens with those from many other parties, mixers implicate that user in the process of money laundering. It is hard to know whether tokens withdrawn from a mixer have been acquired fraudulently or not.

Many exchanges use blockchain analytics tools from firms like Chainalysis or Elliptic to monitor transaction histories. Deposits from addresses associated with mixers, such as Tornado Cash’s smart contracts, are often flagged as high-risk.

Soda Labs’ garbled circuits-based MPC solution avoids all of these problems. A private token transfer using a GC is essentially as straightforward as a regular transparent token transfer. The sender updates the token contract’s record to debit their token balance and credit the recipient’s. The difference is that the transaction information is end-to-end encrypted, and therefore not publicly visible in plaintext on the blockchain.

If a user wants or needs to prove the provenance of any funds they transfer to compliance services, they can do so providing a cryptographic proof – without exposing that information to the wider public.

In this way, the conditions of privacy, decentralization, and compliance are all met, without compromising on performance or user experience. No other DeCC solution currently offers this combination of benefits.

Follow Us!

To learn more about Soda Labs’ MPC solution, based on an on-chain implementation of garbled circuits, explore our documentation, join the gcEVM Onchain Compliant Privacy Telegram group, or stay up to date with the latest developments by following the project on X.