Is Tornado Cash’s Roman Storm Running An Unlicensed Money Transmitter While Out On Bail?
Roman Storm, one of the developers of Tornado Cash charged with conspiring to operate a money transmitter, facilitating money laundering and sanctions evasion, is currently out on bail and awaiting trial.
But it looks as though a company Storm is associated with is currently running a closed-source cryptocurrency transmitter service.
One would imagine Storm’s operation of a cryptocurrency transmitter service while out on bail is both a violation of his bail conditions and could possibly also heap an additional 10 years in prison on top of his existing charges.
Multisender’s Owners
Multisender is a self-described dApp that “helps to send tokens to multiple recipients with one simple transaction.”
While most may question the purpose of such a dApp, it is possible, in theory, Mutltisender provides a valuable service for someone out there.
Once you understand how Multisender works it is harder to puzzle this one out because there is unnecessary complexity and obfuscation and even by crypto standards, these measures are strange.
Anyway Multisender’s terms make clear who is in charge when it states
“We,” “us”, or “Company” refer to Shultzprime Solutions, Inc., and its successors, assigns, and affiliates.
Shultzprime Solutions’ corporate details are available from Washington State here where you find:
There is widespread reporting Roman Storm is based in Washington State and the company referenced in the Tornado Cash docs, PepperSec, shows something similar:
The company is also mentioned in Storm’s bail conditions:
So Multisender is this Roman Storm.
Multisender Is Closed-Source
Multisender implies it is open source when it writes:
If you click on that Etherscan link indeed you see verified source for a contract.
As we will now demonstrate this is, to be blunt, is horseshit.
A thin veneer of code wrapping Multisender is open source.
But the important code is closed-source and Multisender has an owner with the power to arbitrarily change that code at any time.
And the owner is identifiable.
So let’s do this.
First, when you go to Etherscan there is a warning associated with Mutlisender’s code:
But if you try to follow those instructions it generates this error:
At a high level we are now done here.
Etherscan is confirming the implementation behind the proxy is closed-source.
But let’s go deeper.
First, take a look at the code for the proxy:
The Contract Name is, literally, AdminUpgradeableProxy.
This strongly suggests the contract has an admin and can be upgraded.
Presumably by that admin.
We will get there but first go ahead and check the given 0x37e contract.
It is closed-source:
And we can see the same address, 0xcCbeA2bB50aEC5854280ED0C0583846166ff9A96, published the proxy and implementation contracts.
So this is not some complex scheme with many players.
Probably it is a single team or even a single person.
Now let’s look inside a Multisend transaction.
This is a recent one and it looks as expected with, well, multiple sends:
But remember, as we have discussed many times before, Etherscan hides information from you.
Let’s look inside this call to see what the open-source proxy does and what the closed-source implementation does:
The AdminUpgradeableProxy delegates everything to the closed-source contract at 0x37ea7a843d24bfc59c254a32b9a6cb087d2514ef.
We can see a little bit of what happens in there:
But we cannot read the code.
Yes we can trace in a binary dump.
No that doesn’t render the code open source.
Or, rather, if that does then Microsoft Windows and Office are open-source.
Also Oracle.
And everything else distributed in a non-tamper-proof form.
We can see a little of what happened for the flow-of-control path taken by historical transactions.
We cannot predict what might happen for new ones. There might be logic we cannot read or conditions we do not know about.
This is why open source matters.
If you cannot read the code what are we even doing here?
What we can see here is that the closed-source contract interacts with a GnosisSafe at 0xE104DB1807ae47De57EC86885AFa8D39421394eE.
And then, plus or minus a few logical operations, the “multisending” begins.
So?
The first problem here is that Multisender requires us to trust the operator completely.
Why?
Because the proxy has this function:
There is a flow of control beginning with this function:
that ends in _upgradeTo() both running immediately and only being callable by the admin.
So the admin can change the code freely at any time.
Also notice there is a facility for the admin to change the admin.
So who is the admin?
Well there was a change effected on 23 November 2024.
This is an ongoing operation.
Here is the transaction:
The previous admin was an EOA.
The new admin is another closed source contract deployed September 8th, 2024 by the same deployer as above:
Game over.
The implementation contract is closed-source.
The admin is closed-source.
The previous admin was just an EOA.
The “governor” of the company named in the terms as operating this is out on bail awaiting trial for “money laundering and sanctions violations” and this is processing real volume:
Multisender is not plausibly covered by any exemption discussed in FIT21 or in this paper or by any of the DeFi advocates in this hearing.
Anyone that believes this is somehow acceptable because a blockchain is involved somewhere — they’re a bad-faith actor.
No good faith crypto advocate, advocacy group or organization could possibly support this.
This is an excellent litmus test.