Tornado Cash Relayers and the Operator Question

Prepared by the editorial team. Updated August 31, 2026.

Tornado Cash is usually explained through its cryptography, but a much less glamorous component turned out to matter more to the legal argument. Relayers were third parties who submitted withdrawal transactions and took a fee, and their existence introduced identifiable humans into a system otherwise described as autonomous. This article explains what the role did and why it proved consequential.

What is a relayer and why did the design need one?

A relayer is a third party that submits a user’s withdrawal transaction to the network and pays the gas fee, taking a portion of the withdrawn amount as payment. The design needed one because a freshly created recipient address holds no ether, and funding it from the depositor’s own address would recreate exactly the link the pool exists to break.

The problem is easy to state and hard to avoid. Ethereum requires every transaction to pay a fee from the account that sends it. Someone withdrawing to a new address therefore faces a contradiction: the new address cannot pay for its own withdrawal, and any obvious source of funding points straight back to them. Sending a small amount of ether from the original address would hand an analyst the connection immediately.

A relayer resolves this by paying the fee from its own balance and deducting compensation from the amount being withdrawn. The recipient address never needs prior funding and never touches the depositor’s other addresses. It is a workaround for an accounting constraint rather than a privacy mechanism in its own right, and the cryptographic guarantee comes from the proof, not from the relayer.

Crucially the relayer cannot cheat. The recipient address and the fee are committed inside the zero-knowledge proof, so a relayer attempting to redirect funds or inflate its cut produces a transaction the contract simply rejects. Its only meaningful discretion was whether to submit a transaction at all.

Why does the relayer role complicate who operates the system?

Because relayers were identifiable people running services for a fee. A legal question about whether a business is being operated looks for parties performing functions and receiving compensation. Autonomous code offers no such party, but a network of fee-taking intermediaries offers many, and that changes what a prosecutor can point to.

Treasury’s August 2022 designation notice described the project as a service that had been used to launder funds, a characterization that reads naturally against a fee-taking intermediary layer and awkwardly against ownerless code. The contrast is stark within a single system. The pool contracts have no owner, no administrator and no revenue. A relayer, by comparison, is a person or company running software on a server, choosing which requests to accept, charging a price and earning income. Nearly every element that a regulator associates with a money services business appears at the relayer layer and nowhere else.

This is why arguments that focus only on contract immutability tend to sit awkwardly against the government’s framing. Both descriptions can be accurate simultaneously. The contracts really are autonomous, and there really were people providing paid services around them, and the legal dispute concerns which of those two facts governs the statutory question.

Were relayers part of the protocol or independent of it?

Both descriptions have support, which is precisely why the point is contested. Anyone could submit their own withdrawal transaction without a relayer, so the role was formally optional and permissionless. In practice a registry and a fee mechanism surrounded the role, and most users relied on it, which makes it look less like an external accident.

The case for independence is straightforward. Relayers were operated by unrelated parties who set their own fees and made their own choices, the core contracts did not require any particular relayer, and a determined user could bypass the layer entirely by paying gas themselves. On that account relayers are a service built on top of a protocol rather than a component of it.

The case for integration is equally concrete. Discovery mechanisms and a staking arrangement tied to the project’s token gave the role formal structure, and the interface presented relaying as the ordinary path. When a design channels nearly all real usage through one component, describing that component as incidental becomes difficult to sustain, whatever the formal position.

These competing characterizations of the same facts are why relayer evidence has featured repeatedly in the litigation, including in reporting on scheduling disputes ahead of the retrial. How a factfinder characterizes the layer influences how the operating question is answered.

How can you evaluate a claim that a system is decentralized?

You list every component separately, ask who can change each one, test whether the system works without it, separate formal design from actual usage, and state your conclusion with its scope attached. This is an analytical procedure for reading technical claims and is not instruction for interacting with any service.

Step 1: List every component separately

Break the system into its distinct parts such as contracts, interfaces, indexers and off-chain services, because a decentralization claim almost always applies to some components and not to others. Writing the list out is usually enough to reveal that a single label was covering several different situations.

Step 2: Ask who can change each part

For each component ask which party could alter, pause or withdraw it, since the existence of any such party identifies a point of control that a claim of full decentralization would have to account for. Control is the operative question, not whether the software is open source.

Step 3: Test whether the system works without each part

Consider whether the system still functions if a given component disappears, because a part that everyone depends on in practice is a real dependency even when it is formally optional. A theoretical alternative that requires expertise most users lack is not a substitute.

Step 4: Separate formal design from actual usage

Compare how the design says the system may be used against how participants actually use it, because a permissionless alternative that almost nobody chooses does not describe the real operating picture. Regulators and courts consistently attend to observed behavior rather than to documented possibilities.

Step 5: State the claim with its scope attached

Write the conclusion as a scoped statement naming which components are decentralized and which are not, because an unqualified label conceals exactly the distinctions that matter to a technical or legal reader. A scoped claim is also far harder to contradict.

Does running a relayer make someone an operator?

There is no settled answer, and that uncertainty is the practical situation participants face. Relaying involves accepting a request, submitting a transaction and taking a fee, which resembles a service business. It also involves never holding or controlling the funds, since the proof fixes the destination, which resembles a network participant instead.

Custody is the usual dividing line in financial regulation, and relaying sits uncomfortably across it. A relayer cannot redirect, withhold or seize the assets it helps move, and in that respect it behaves more like a postal service than a bank. Yet it selects which requests to process, charges for the service and can decline, which are the discretionary features that regulation typically attaches to.

Different jurisdictions have drawn this line differently, and no single ruling has resolved it internationally. Anyone considering operating infrastructure of this kind is in a genuinely unsettled area of law where the answer depends on jurisdiction, on the specific functions performed and on facts that a court would weigh individually. That is a question for qualified counsel rather than for a general article.

Participants in the system compared

The debate becomes clearer when the participants are separated by what each can actually do. The table describes the roles at a conceptual level and does not characterize the legal status of any of them.

Participant	Holds user funds?	Can refuse service?	Earns a fee?
Core pool contract	Holds deposits under fixed rules, no discretion	No	No
Relayer	No, destination fixed by the proof	Yes	Yes
Front-end interface	No	Yes, can restrict access	Varies by operator
Ethereum validator	No	Can exclude from its own blocks only	Yes, protocol rewards
Custodial exchange	Yes	Yes	Yes

Reading down the columns shows why relayers resist easy classification. They share the fee and refusal characteristics of a service business while sharing the lack of custody with pure infrastructure, and existing categories were not written with that combination in mind.

Frequently asked questions

Could a relayer steal the funds it was submitting?

No. The withdrawal recipient and the fee are fixed inside the zero-knowledge proof, so a relayer that altered either would produce a transaction the contract rejects. The relayer’s only real power was to decline to submit a transaction at all.

Is a relayer the same thing as an Ethereum validator?

No. A validator proposes and attests to blocks as part of network consensus, while a relayer is an ordinary user account that submits someone else’s prepared transaction and pays its gas. The roles sit at different layers and involve different participants.

Do other privacy systems have the same dependency?

Most systems that let users receive funds at a fresh address face the same problem, because an empty address cannot pay its own transaction fee. Approaches differ, including relayer networks, account abstraction and fee sponsorship, but the underlying gap is common to the design pattern.

Why do courts care about a technical detail like this?

Legal tests about operating a business turn on who does what, so the identity and role of every participant matters. A component involving identifiable people performing a service for a fee attracts far more legal attention than autonomous code does.