This is really big, and really bad news. The essential point seems to be that there is an argument that they *could* have exerted control. Did they actually have backdoor keys into the smart contract after they wrote and deployed it? I can't remember a clarification on that crucial point. If they didn't, then this is even worse, because it means US LE are prepared to make *really* tortuous arguments to go after privacy software developers.

CoinCenter doesn't believe so:

Coin Center

New Tornado Cash indictments seem to run counter to FinCEN guidance

Our initial thoughts on a case that could potentially criminalize the publication of software code

(ht @Gigi )

Depends on what functions can be upgraded. Also there's a limit to how convoluted an argument they'll get away with. The Coin Center article suggests that the DoJ is being a bit handwavy here.

@waxwing @ODELL But yeah, if this case it not defeated, then it's not non-custodial privacy tools that are next. They might even try an all out attack on non-custodial wallets. Starting with the ones run by for profit companies. These currently enjoy protection in both the US and EU, for very different legal reasons. But as more people use them, they make sense as the next choke point.

I don’t think the essential point has anything to do with backdoors. It’s actually much worse than that. They’re arguing that since the devs 1) made the software and 2) knew it would be used for “illegal” things, and yet 3) did nothing to stop this, that they are complicit. What kinds of things could they have done to stop things? Not made the software in the first place. Attempted to take the software down after the fact. Or blocked certain inputs as Wasabi does. Scary precedent

Not necessarily. You can specify which functions can be upgraded and which can't. For example some functions could be hard-code in the main smart contract, whereas others delegate to another smart contract, the address of which is stored in a variable. Ideally then those variables can only be changed by token vote, but my guess is that initially there was an admin who could do that. However if "aspects of cryptography" could be changed, then most likely it would have been possible to brick the contract. But that would be destroying the company entirely, and so may not be an reasonable thing to demand. Plus it's rather pedantic, which itself doesn't always go well in court. But imo the admin override doesn't matter. If it was a pure DAO then you just say "criminal conspiracy" and now all the token holders and developer are liable for the whole thing. Then all you need to do is *not* arrest the token holders (including the VC) and only arrest the developers and presto.

That said, the DAO didn't control the core contract. So to the extend that the core contract was used *without* any of the ancillary tools (website, DAO controlled smart contracts) then you COULD still maintain you had no control over that activity. Unfortunately the DoJ probably just needs to prove *one* money launderer using the UI (based on CloudFlare records or something) for the money laundering charge to hold. So then the defense in the US would have to fall back on the non-custodial side of things. At minimum they didn't need a license.

And it's worse. IIUC the money laundering charge is *conspiracy*. So they needed to have the intention of someone using the UI to launder money, and take one concrete step towards it (like writing the code). If such a charge survives, even if a license wasn't needed, that's a problem. The Netherlands doesn't even have a license system for this, so it's really just about the question whether or not this was (actual, not conspiracy to) money laundering.

(where "intention" is a bar perhaps as low as "disregard for the risk of")