This is the first in a series of essays that are the product of the continued work and collaboration between Sibylline, Ali Khan, and Flavia Kenyon. . We specifically chose to start this series here and on this thesis as it represents the fruits of months of thinking and development. In light of recent reports coming from the Dutch court – the guilty verdict of Tornado Cash developer Alexey Pertsev – it is now, more than ever, pertinent.

Background 

Tornado Cash is what we call a “mixer”. A special type of privacy-preserving tool that runs on permissionless, decentralised blockchains. That’s a lot of words to the uninitiated, so let’s break them down.

A blockchain is an immutable ledger (read: database) of who sent what tokens to who, and when. Some fancy cryptography ensures that this ledger cannot be tampered with, and thus is always valid. This is the power and simplicity of a blockchain. This fundamental design means that we can always trace where money or on-chain assets originated from, and who they’re going to, a sort of directed graph that shows us where money started and every step it took to get to the other end. A mixer is a simple smart contract (read: program) that runs on these chains that accepts deposits from anyone, and “mixes” it all together in a way that makes whoever redeems a deposit impossible to distinguish from the depositor themselves by breaking the observable link between a deposit and a withdrawal address.It proves – very simply – a mechanism for creating on-chain privacy for transactions.

Permissionless is a term we use to describe the fact that no-one needs to grant permission or access to these blockchains or tools. Literally anyone can create an account on these chains and start using both them, and the smart contracts on them.

Decentralised is a term you’ll hear thrown around an ever increasing amount, though with each actor using it differently to suit their needs and interpretations. We’ll be describing it simply as “neither governed nor controlled by a single defined actor”.

So Tornado Cash was, put quite simply, a tool that anyone could use to preserve the privacy of their on-chain transactions.

The Foundations of the West

Like so many of our peers, we are  firm believers that the principles and ideas of Western liberalism are the correct ones.

Freedom, your basic rights as an individual to speak, transact, and live without fear of unjust persecution, arbitrary interference, or subject to inspection by some authoritarian body.

We have written previously here about how we believe your digital identity and your financial one – are in our modern age – one and the same. As the frontiers of technology continue to move forwards, particularly in the realms of financial payments, settlement, and digital identities, this truth will only become more apparent.

Since the dawn of democracy, it has been made abundantly clear that a healthy and functional courts system is essential in ensuring these rights are upheld and not abused by those we elect to positions of authority. As the markets that formed in these democracies evolved, so too did the essential role of the regulator to ensure consumer protection and fair play in the market.

It should come as a stark warning then, that one of these democracies has gone so far as to pass a verdict of guilt for a crime that has not been committed, but for one that may be committed in the future.

The Dutch court was of the opinion that it should have been ‘foreseeable’ to the software developers when they were writing the Tornado Cash open source code that, at some unspecified date in the future, money originating from crime could be deposited into the smart contracts, taking advantage of the concealing effect of the tool. It was on this basis of “foreseeability” - that these immutable contracts might one day be used by a sanctioned entity  to launder money - that Alexey was found guilty. 

The court viewed Tornado’s privacy protection function as a function to conceal - which amounted to conspiracy to money laundering under Dutch law. By doing so, the judges assumed there was no legitimate use case for privacy and treated the developers as responsible for the creation of a tool of potential misuse. 

One doesn’t need to be a Dutch legal practitioner to realise the profound misapplication and contortion of the law in order to secure a conviction. 

In a case of this nature under English law, in order to prove conspiracy to commit money laundering, the prosecution must prove that the defendant: (1) agreed to conduct, or to attempt to conduct, a financial transaction; (2) knew (suspicion is not enough as a state of mind) that the property involved in the transaction represents the proceeds of crime, and (3) proof of intent to conceal the proceeds. 

None of these elements exist in the case of software developers who create and deploy immutable smart contract protocols, and none of them were proven in this case.

Never in the history of liberalism has anyone ever been found guilty of a crime  that could potentially be committed by another, third party, at some time in the future. A truly terrifying precedent to be set by the court.  This conviction grants a government unlimited power to prosecute any software developer who writes code that is later used by a third party for nefarious purposes, merely because the developer becomes aware of that later use. With no limiting principle in place, nearly all developers who create open-source software would be exposed to criminal liability for activity outside of their control years or decades later. Put simply, the Dutch court’s theory of liability has the chilling effect of rejecting core principles of due process and the rule of law.

Building for new Precedents

With the precedent now set that you can be imprisoned for writing and releasing code that could be used by a sanctioned entity, all the builders of the world should be taking heed of the warning.

Whilst the current target – privacy preserving tooling – may fall outside the scope of what you are working on, given the gravitas of the ruling, we don’t expect the contagion to stay there. Anything from DeFi apps to SocialFi that “may” be used by sanctioned entities is now on the table for the court, and you should consider yourself at risk.

With all that being said, we do believe there is sufficient clarity for a robust direction forwards. This essay will outline some of this thinking, though it is not to be treated as any official kind of counsel, or legal advice. If you do feel in-need of official guidance, please don’t hesitate to reach out to us.

The basis of our thinking builds upon a handful of main factors;

• That the regulatory outlines and requirements for compliance are increasingly clear;
• In our (widely shared) opinion, the correct way to build on-chain is permissionless and immutable;
• That privacy is an important individual right that needs protection; and
• That there is clear precedent set for this.

Regulatory Clarity

Albeit far from where we’d really like to be in terms of absolute clarity – as expected in maturing market sectors – we are slowly arriving at clarity on the regulatory and compliance requirements for crypto and virtual asset providers. For the builders in some jurisdictions, for the better. In others, the worse.

The requirements for sanctions and AML screening, the restrictions and controls necessary to be in-place to achieve minimum standards for certain types of digital assets, and general diligence necessary to be taken seriously, are broadly speaking becoming defined. Regardless of your personal ideology and views of the sector, this is a good thing.

The irony of writing these paragraphs given the ruling we’re discussing as the centre-point of this essay is not lost on us; simultaneously the ruling itself sets a degree of clarity. It’s now clear that any privacy preserving software, on-chain or not, is now within scope for legal persecution on the European continent. Risk models should be updated accordingly.

Technical Precedent

It is true that no smart contract deployed to a blockchain can be modified. Once deployed the contract itself is immutable. That being said, it is in fact possible to change the behaviour of a protocol through various technical mechanisms that are outside the scope of this essay. just take our word for it (lookup upgradable contracts if you’re really that interested)

It has been an open debate for some time as to whether this approach should be endorsed – particularly for certain types of protocols – as the right way forwards.

The benefits are obvious: the ability to upgrade and improve the behaviour of a protocol with what would be a seamless experience for users. The contracts are “upgraded” (technical implementation notwithstanding) and the users benefit.

If smart contracts can be “upgraded” to improve the protocol, it stands to reason that they can be changed to enact behaviour to the owners’ own benefit only – a compromise of the protocol if you will. The idea that protocols should be immutable on-chain - i.e. being able to be trustedabsolutely such that we can read the code,in-perpetuity, in the knowledge they cannot be changed - is compelling. Uniswap as a protocol is a clear and established demonstration of this.

The Uniswap Precedent

There are now 4 versions of the Uniswap protocol available. Each one a wholly new deployment of smart contracts with no association to the previous. This was by design. The contracts could not be “upgraded” to automatically distribute these new features or ideas to users. Each user of the protocol – both sides of the transaction – had to select which version(s) of the protocol they wanted to use. To this day, there are many newly released tokens that are distributed on older versions of Uniswap for various reasons.

What this does mean however is that as time moves forwards, the trust we can place in the contracts to always behave in that manner, and not have security risks increases. Indeed, if there was a critical flaw in the protocol that a threat actor could exploit, it almost certainly would have by now.

It also provides the creators of Uniswap with a very powerful defence against the rising tide of regulation and scrutiny. Uniswap have reasonable neutrality as simply creators of “lower level” parts of the system.

It’s that “lower level” aspect that is quite critical. Even the most technically literate and crypto-native of readers of this essay have likely never actually interacted with Uniswap directly at the protocol level. They’ll have almost certainly used the Uniswap UI – the officially endorsed product implementation – to perform whatever action they were trying to.

Layer 8 Problems

There is a model we use in computer science called the “OSI Model”; a dated, albeit effective tool for understanding how our interconnected digital world works, each “layer” in the model a different position in the card stack of abstractions we use to connect systems, one on top of another until we arrive at what you experience as the modern internet.

A better view of what this means in practice would be the above – an evergreen xkcd comic – about the handful of developers who (thanklessly) continue to develop and support critical “low level” packages and libraries we use in our daily lives.

There’s that “low level” denomination again.

If Alexey is guilty of writing code that “foreseeably” could be used by sanctioned entities, then so are the developers of the encryption, networking, and browser libraries we all – even more so the government – use daily to protect our digital activities; from not just authoritarian inspection, but from the general malice that permeates the world.

The courts would never come after developers of anything lower down in the OSI stack; a model that we feel that today, does no longer accurately encapsulate the evolved complexity and abstractions that come with blockchains. In any other “traditional” system, implementing the relevant controls and regulations at the top of the stack was deemed sufficient. We don’t feel that there is any substantial reason for this to change.

The design and development of immutable, composable protocols – financial or otherwise – specifically where they are to be used on decentralised, permissionless blockchains, is no different from developing any other “low level” protocol. These protocols must be immutable for any credible level of trust to be placed in them, and thus are impossible to comply with evolving regulatory requirements.

Assuming the same set of developers who would likely go on to build a high-level, user facing application that simply leverages this and potentially other protocols, go on to implement any and all pertinent regulatory requirements and controls, there is no reason to believe that these developers had any intention of sanctions busting or non-compliance.

Close

We should be thankful that there will be a second court case, that for Tornado Cash co-author Roman Storm, held in the US; due instead this time for a jury trial, and not a Dutch three-judge-court. We shall be keeping a close eye on how that unfolds, what evidence the US prosecutor can actually bring to bear to prove the charges, and how the jury interprets each position. It is our deep personal hope that sanity prevails, and that the US maintains its foundational commitment to individual liberties, in a time when  its democracy remains again tested.

We live in truly unprecedented times; where the idea of something that isn’t a person can be subject to sanctions, and that a person can be found guilty of something that may or may not happen in the future. We champion and support anyone standing against the alarming rise of illiberalism wherever it can be found, and look forwards to a future where personal and financial freedom for everyone is attainable in any format, private, or otherwise.