DeFi development and deployment: Are the coders regulated, are they liable, or are they even criminals?

This is Part 3 of our series on the regulation of DeFi. Part 1 provides the overarching framework for assessing when DeFi protocols fall within financial law. Part 2 examines the legal position of frontend operators.

What This Article Covers

DeFi developer liability is a topic that generates significant uncertainty among protocol teams. If you are building a DeFi protocol, you face a fundamental question: Does the act of writing and deploying smart contract code expose you to financial regulation, civil liability, or criminal sanctions? This article addresses all three dimensions. First, it explains why development and deployment, by themselves, do not typically make you the “operator” of a regulated financial service. Second, it examines the civil liability landscape, including the evolving treatment of software under product liability law. Third, it explains why the absence of financial regulation does not eliminate all legal risk: criminal law operates independently and can reach developers in certain circumstances. The article examines these questions under common legal principles before providing a jurisdictional overview across the EU, the United States, and Switzerland.

The Developer’s Dilemma: Building Tools That Others May Misuse

The question of when a tool creator bears responsibility for how others use the tool is not unique to DeFi. Legal systems have grappled with this problem for decades, from the manufacturers of video recording equipment to the designers of algorithmic trading systems.

In 1984, the U.S. Supreme Court established in Sony Corp. v. Universal City Studios (the “Betamax case”) that the manufacturer of a device capable of “substantial noninfringing uses” cannot be held liable merely because some users employ the device for unlawful purposes.¹ Two decades later, in MGM Studios v. Grokster (2005), the Court refined this principle: even where a technology has substantial lawful uses, its creator can be liable if they actively induce or promote its use for unlawful purposes.² The distinction draws a line between building a general-purpose tool and promoting a product designed to facilitate specific illegal conduct.

The same principle surfaces in algorithmic trading enforcement. In the Sarao case (2015–2020), the U.S. Department of Justice prosecuted a trader who designed and deployed an automated spoofing algorithm that contributed to the 2010 “Flash Crash.”³ Critically, U.S. authorities also pursued Jitesh Thakkar, the developer who built the spoofing tool for Sarao, on the basis that he knew the tool was designed for market manipulation.⁴ The principle: automating unlawful conduct through software does not sever the chain of liability.

These cases establish a framework that applies directly to DeFi protocol development. A protocol with legitimate uses should not, by itself, create liability for its developer. However, if a developer creates or deploys a protocol knowing it will be used for unlawful purposes, criminal liability may follow regardless of the protocol’s other capabilities.

Development and Deployment Are Not “Operation”

Financial market regulation across jurisdictions is built around a central concept: the operator. Whether under Swiss, EU, or U.S. law, regulatory obligations attach to the entity that operates a financial service – not to the person who built the underlying technology.

This is not a novel insight for traditional finance. Companies that develop and license core banking software are not regulated as banks. Firms that build payment processing platforms are not themselves payment service providers unless they operate the platform. The act of creating a tool is legally distinct from operating the resulting service. The same logic applies to DeFi: writing code and deploying it to a public blockchain is, in regulatory terms, akin to developing and publishing software. It is distinct from operating a financial service.

This distinction holds particular weight where the protocol is genuinely decentralised after deployment. If no individual or group retains meaningful control over the protocol’s operation post-deployment, the regulatory hook – the identifiable operator – is absent. As explored in Part 1 of this series, the critical question in DeFi regulation is always whether there is a personal point of attribution – that is, an identifiable person or entity to whom regulatory obligations can be assigned. A developer who deploys code and relinquishes control does not meet this threshold.

But Development and Deployment Are Not Risk-Free

The absence of financial market regulation does not create a legal vacuum. Both civil liability and criminal law operate on different principles and with different thresholds.

On the civil liability side, the treatment of software under product liability law is evolving rapidly. As discussed in the jurisdictional overview below, software is increasingly treated as a “product” subject to strict (no-fault) liability for defects. The practical relevance for DeFi developers depends in part on whether the software is provided commercially – a question that is not yet settled for open-source protocols with embedded fee mechanisms.

The criminal law analysis is more consequential for most developers. A developer who deploys a protocol with the knowledge or intent that it will facilitate criminal activity – most commonly money laundering – may face criminal liability even if no financial market licence was required. At the same time, the mere fact that a protocol could be misused does not, by itself, establish criminal liability. Virtually every technology – from encrypted messaging to file-sharing to the internet itself – can be misused. The decisive factor is the developer’s state of mind: what they knew, what they intended, and what they should have known given the circumstances.

This is where the legislative framework around DeFi provides important guidance. Where legislators have explicitly defined the boundaries of when a DeFi protocol falls within or outside financial regulation – as Switzerland has done with respect to the Anti-Money Laundering Act – those boundaries inform the criminal law analysis as well. A developer who builds a protocol that the legislator has expressly recognised as falling outside the scope of AML regulation cannot reasonably be said to have acted with criminal intent merely by deploying that protocol. The legislative guardrails establish a framework within which developers can operate with a degree of legal certainty. Criminal liability arises not from building within those guardrails, but from deliberately stepping outside them – for instance, by knowingly facilitating the processing of criminal proceeds or deliberately designing a protocol to circumvent regulatory safeguards.

Key Cases on Developer and Tool Creator Liability

The following table summarises the most relevant cases and enforcement actions that have shaped the current legal landscape for developer liability:

Case / Action	Jurisdiction	What Happened	Key Takeaway
MGM v. Grokster (2005)	US	Peer-to-peer software maker held liable despite substantial lawful uses, because it actively promoted infringing use.	A dual-use tool does not shield its creator if the creator induces illegal use.
United States v. Sarao (2015–2020)	US	Trader designed and deployed automated spoofing algorithm contributing to the 2010 Flash Crash. Convicted of spoofing and wire fraud.	Automating illegal conduct through software does not sever the liability chain.
CFTC v. Thakkar / Edge Financial (2018)	US	Developer who built the spoofing tool for Sarao was charged for knowingly creating software designed for market manipulation.	Even the person who builds the tool for someone else can be liable if they know the purpose.
Netherlands v. Pertsev (2024)	NL / EU	Tornado Cash developer convicted of money laundering (64 months). Court-based findings on continued development despite awareness of criminal use, not on initial code writing.	Ongoing involvement and wilful blindness, not mere development, grounded the conviction. Appeal pending.
United States v. Storm (2025–2026)	US	Tornado Cash co-founder convicted of operating unlicensed money transmitting business. Jury deadlocked on money laundering and sanctions charges. Retrial requested for October 2026.	Mixed verdict. Prosecution rested on totality of conduct (UI changes, knowledge of criminal use, failure to act), not code writing alone.
Operation Olympia / Cryptomixer (2025)	CH / DE	Swiss and German authorities seized servers in Zurich and EUR 25 million in Bitcoin from a centralised mixing service that had laundered EUR 1.3 billion.	Centralised mixer with identifiable operator and clear criminal purpose.

Jurisdictional Overview

European Union

Under MiCA, regulatory obligations attach to crypto-asset service providers (CASPs) – entities providing specific services such as custody, exchange, or execution of orders.⁵ The development and publication of open-source software does not, by itself, constitute a crypto-asset service. MiCA’s Recital 22 further provides that services provided “in a fully decentralised manner without any intermediary” should not fall within its scope.⁶ However, the same recital clarifies that where only part of the activities or services is performed in a decentralised manner, MiCA obligations remain applicable. The carve-out is therefore limited to services that are fully decentralised – a threshold that many protocols may not meet in practice.

From a civil liability perspective, the new EU Product Liability Directive (2024/2853) is significant. For the first time, the Directive explicitly includes software within the definition of “product,” subjecting it to strict (no-fault) liability for defects.⁷ However, it carves out open-source software that is not supplied in the course of a commercial activity.⁸ The practical reach of this carve-out for DeFi protocols that generate revenue through embedded smart contract fees is not yet settled – a question protocol teams should monitor closely as Member States transpose the Directive by December 2026.

On the criminal side, the conviction of Tornado Cash developer Alexey Pertsev by a Dutch court in May 2024 represents the most significant European precedent.⁹ Tornado Cash is a decentralised protocol on Ethereum that allowed users to conduct anonymous cryptocurrency transactions.

Importantly, the conviction did not rest on the initial act of writing code alone. The court based its findings on the totality of Pertsev’s conduct: he continued to develop and enhance Tornado Cash’s privacy features despite awareness of criminal use, was part of chat groups where hacking proceeds were discussed, failed to act when victims and investigative authorities contacted him, and implemented no meaningful safeguards against misuse. The court stated that Pertsev “chose to look away from the abuse and did not take any responsibility.” It was this pattern of continued involvement and wilful blindness – not the act of writing code – that grounded the 64-month prison sentence. Pertsev is currently appealing the conviction.

The EU’s forthcoming Anti-Money Laundering Regulation (2024/1624), effective from July 2027, will impose enhanced due diligence requirements on CASPs interacting with privacy-enhancing technologies, including mixers and tumblers.¹⁰ While this regulation targets service providers rather than developers directly, it signals a regulatory environment that treats anonymisation capabilities as a high-risk factor.

United States

The U.S. legal landscape has shifted significantly since 2025. The Department of Justice’s April 2025 memorandum “Ending Regulation by Prosecution” instructed federal prosecutors to stop “superimposing regulatory frameworks on digital assets” through criminal enforcement.¹¹ In August 2025, Acting Assistant Attorney General Matthew Galeotti stated explicitly that “writing code, without ill intent, is not a crime” and that “developers of neutral tools, with no criminal intent, should not be held responsible for someone else’s misuse of those tools.”¹²

These statements reflect a shift in prosecutorial policy, but they do not eliminate criminal liability. The DOJ continues to pursue developers who knowingly facilitate criminal activity. The prosecution of Tornado Cash co-founder Roman Storm illustrates the boundaries: in August 2025, a jury convicted Storm of conspiring to operate an unlicensed money-transmitting business but could not reach a unanimous verdict on the more serious charges of conspiracy to commit money laundering and conspiracy to violate sanctions.¹³

As with the Pertsev case, the prosecution was not based on the act of writing code alone. Prosecutors presented evidence that Storm and his co-founders made approximately 250 changes to the Tornado Cash user interface, profited through TORN token sales, had knowledge of criminal use by the Lazarus Group, and chose not to implement measures to reduce that use. Storm’s defence also raised First Amendment arguments – contending that publishing open-source code constitutes protected speech – though the trial court excluded this line of argument, and the question remains unsettled. The DOJ has requested a retrial on the unresolved charges for October 2026.¹⁴

It is worth noting that CFTC Commissioner Brian Quintenz proposed over seven years ago that smart contract developers could be held liable for aiding and abetting CFTC violations if it was “reasonably foreseeable” that U.S. persons would use the code to violate regulations.¹⁵ While this was one commissioner’s position rather than official CFTC policy, it signalled a line of thinking that remains relevant.

Switzerland

Swiss financial market law does not regulate the development and deployment of DeFi protocols as such. The Swiss Blockchain Federation’s DeFi Circular states this directly: “The development and deployment of genuine DeFi protocols are generally not regulated by existing financial market law.”¹⁶ FINMA’s supervisory approach focuses on operational control, and the Swiss legislator has explicitly addressed when decentralised platforms fall within the scope of anti-money laundering obligations – distinguishing between platforms where an operator has access to and influence over transactions, and smart contracts that process transactions autonomously without such access.

This legislative framework carries weight beyond financial regulation. Where the legislator has deliberately placed genuinely decentralised protocols outside the scope of AML regulation, it would be difficult to sustain the argument that a developer who builds within those parameters has the criminal intent required under Swiss law. Criminal aiding and abetting under Article 25 of the Swiss Criminal Code requires Doppelvorsatz – dual intent: the developer must intend or at least accept that their conduct contributes to a specific criminal act, and they must know or at least accept that this act constitutes a crime.¹⁷ A wholly unspecified awareness that a protocol could, in theory, be misused does not meet this threshold.

This does not mean Swiss criminal law is irrelevant for DeFi developers. Money laundering under Art. 305bis of the Swiss Criminal Code captures any act “apt to frustrate” the identification or confiscation of criminal proceeds, where the person “knows or must assume” that the assets derive from a crime.¹⁸ The “must assume” standard is lower than full knowledge. A developer who has specific reasons to believe their protocol is being used to launder criminal proceeds – and continues to develop or promote it – faces genuine exposure.

Swiss authorities actively enforce these provisions in the crypto space. In November 2025, Swiss and German authorities seized servers in Zurich and over EUR 25 million in Bitcoin from Cryptomixer, a centralised cryptocurrency mixing service that had laundered over EUR 1.3 billion since 2016.¹⁹ The Cryptomixer case involved a centralised service with an identifiable operator and presumably clear criminal intent, making the enforcement case straightforward. It should be distinguished from the more nuanced question facing developers of decentralised, general-purpose protocols with legitimate uses.

The Commerciality Question: A Civil Liability Consideration

One practical question that protocol developers should consider from a civil liability perspective is whether their activity qualifies as “commercial.” This question is primarily relevant for product liability and tortious liability frameworks, rather than for criminal law. The EU Product Liability Directive’s open-source carve-out, the Swiss Produktehaftpflichtgesetz (PrHG, the Swiss Product Liability Act) exemption for non-commercial production, and certain commerciality thresholds in financial market law all turn on this distinction.

Where a protocol is fully open source and generates no revenue for the developer, the non-commercial classification is straightforward. The analysis becomes less clear where the developer earns ongoing revenue – for instance, through fees embedded in the smart contract that flow to the developer, a treasury, or token holders. The EU Product Liability Directive’s recitals indicate that software provided in exchange for a price revives the commercial character. Whether an embedded protocol fee constitutes a “price” within this meaning is not yet settled.

From a practical standpoint, developers seeking to benefit from the non-commercial carve-outs should consider open-sourcing the protocol code and avoiding the embedding of direct revenue streams at the protocol level that flow to an identifiable developer entity. This does not mean that all commercialisation is foreclosed – but structuring fee arrangements so that protocol-level revenue does not flow directly to the developer reduces civil liability exposure under the evolving product liability frameworks.

Key Takeaways and Best Practices for DeFi Developer Liability

The development and deployment of DeFi protocols occupy a distinct legal position from their operation. Financial market regulation typically attaches to the operator of a service, not to its creator. A developer who writes code, deploys it, and relinquishes control does not become a regulated entity under current law in the EU, the United States, or Switzerland.

However, the absence of financial regulatory obligations does not mean the absence of all legal risk. Criminal law can reach developers who deploy protocols with knowledge or intent that they will facilitate criminal activity – and the Tornado Cash cases in both the Netherlands and the United States demonstrate that it is the totality of conduct, including actions taken after initial deployment, that determines criminal exposure.

For protocol developers, the following best practices emerge from the current legal landscape:

1. Do not develop tools for criminal purposes and rely on decentralisation as a defence. Coding software for criminal purposes is a crime in itself. The fact that the resulting protocol operates in a decentralised manner does not shield the developer from criminal liability if the purpose of the development was to facilitate illegal activity.

2. For dual-use tools – which include virtually every piece of software – take two concrete steps:

a) Promote the protocol exclusively for its legitimate use cases. Never implicitly or explicitly promote or condone criminal use. Internal communications, marketing materials, and public statements should consistently reflect a commitment to lawful purposes.

b) Implement reasonable safeguards against criminal use at the design level. This may include embedding blacklist functionality in the smart contract code, integrating compliance tools, or building in mechanisms that allow the protocol to respond to identified criminal use. The absence of any safeguards, particularly where the developer is aware of criminal use, significantly increases criminal exposure – as the Tornado Cash prosecutions have shown.

3. From a civil liability perspective, consider open-sourcing the protocol code and avoiding direct revenue streams to the developer at the protocol level. Both the EU Product Liability Directive and the Swiss PrHG provide carve-outs for non-commercial, open-source software. Embedding fee mechanisms that direct revenue to an identifiable developer entity may revive the commercial character of the software and eliminate the protection of these carve-outs. This question is not yet settled, but protocol teams should structure their arrangements with this risk in mind.

4. Where legislators have provided explicit guidance on when DeFi protocols fall within or outside regulatory frameworks, build within those parameters. Developers who structure their protocols in accordance with legislative guardrails – such as the Swiss legislator’s distinction between decentralised platforms without operator access and platforms with operator control – have a strong basis for concluding that their activity does not carry criminal risk.

This article is part of LEXR’s series on DeFi regulation. For a DeFi decentralisation assessment or developer liability analysis tailored to your protocol, contact the LEXR blockchain and DeFi team:

---

Footnotes:

1. Sony Corp. of America v. Universal City Studios, Inc., 464 U.S. 417 (1984). ↩︎
2. Metro-Goldwyn-Mayer Studios Inc. v. Grokster, Ltd., 545 U.S. 913 (2005). ↩︎
3. United States v. Sarao, No. 15-cr-00075 (N.D. Ill.); CFTC v. Nav Sarao Futures Limited PLC. ↩︎
4. CFTC enforcement action against Jitesh Thakkar / Edge Financial Technologies. ↩︎
5. MiCA, Regulation (EU) 2023/1114, Articles 3 and 59 et seq. ↩︎
6. MiCA, Regulation (EU) 2023/1114, Recital 22. ↩︎
7. EU Product Liability Directive 2024/2853, Article 4 read with Recital 13. ↩︎
8. EU Product Liability Directive 2024/2853, Article 2(2); Recital 14 ↩︎
9. Netherlands v. Alexey Pertsev, East Brabant District Court, No. 82/198261-22, May 14, 2024. ↩︎
10. EU Anti-Money Laundering Regulation (EU) 2024/1624, applicable from July 10, 2027. ↩︎
11. Deputy Attorney General Todd Blanche, Memorandum: “Ending Regulation by Prosecution,” April 7, 2025. ↩︎
12. Matthew J. Galeotti, Remarks at the American Innovation Project Summit, Jackson, Wyoming, August 21, 2025. ↩︎
13. United States v. Roman Storm, No. 23-cr-430 (S.D.N.Y.); verdict of August 6, 2025. ↩︎
14. DOJ letter to Judge Katherine Polk Failla requesting retrial, filed March 10, 2026. ↩︎
15. Commissioner Brian Quintenz, CFTC, Remarks at the 38th Annual GITEX Technology Week Conference, Dubai, October 16, 2018. ↩︎
16. Swiss Blockchain Federation, DeFi Circular, Regulation of DeFi Related Activities, para. 2: Development, Deployment & Updates (2025). ↩︎
17. Art. 25 Swiss Criminal Code; BGE 128 IV 53, E. 5f/cc; BGer 7B_284/2022 of February 8, 2024. ↩︎
18. Art. 305bis para. 1 Swiss Criminal Code. ↩︎
19. Europol, Press Release: “Europol and partners shut down ‘Cryptomixer,’” December 5, 2025; Operation Olympia, Zurich, November 24–28, 2025. ↩︎