TORN Cash Governance: What a Vote Could Not Change

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

TORN Cash is a search phrase rather than a project name, combining a governance token ticker with the name of the Tornado Cash contracts. Readers who arrive with it and then ask about voting are asking a genuinely interesting question, because governance here had real powers over some parts of the system and no power at all over the most important ones. This article maps that boundary and explains why it carried legal weight.

What could a governance vote actually decide?

Governance decided matters the code deliberately left adjustable: how a shared treasury was spent, what parameters of surrounding components were set to, and how the governance process itself operated. Those powers were real, exercised through on-chain proposals and executed by contract rather than by anyone’s discretion, and they stopped exactly where the code stopped exposing controls.

An on-chain governance system is essentially a contract that holds authority over other contracts. A proposal is an encoded function call that the governance contract will make if the vote succeeds. That structure means governance power is enumerable: whatever calls the governance contract is permitted to make is the complete list of what a vote can do, and nothing outside that list is reachable by any majority.

Peripheral components are where such systems have their reach. Registries, fee parameters, treasury disbursements, contributor funding and upgrades to governance itself are all things a project can choose to place under a vote. These are consequential, because they determine what a project funds and how it presents itself, and they are also entirely separable from whether a deployed pool contract keeps working.

The corollary is worth stating directly. A governance system’s scope is a design decision made when the contracts were written, not a claim a project can make afterward. If a component was deployed without an owner or an administrative hook, then governance never had authority over it, regardless of what any document or vote asserts.

Why could no vote reach the core pools?

Because the core pool contracts were deployed as immutable code with no owner, no pause function and no upgrade path. There was no privileged address for governance to hold and no administrative function for a proposal to call, so the contracts responded identically to every caller and would continue running regardless of any vote.

Immutability of this kind is not a policy that can be revoked. On Ethereum, deployed bytecode cannot be edited, so alterability has to be built in ahead of time, usually through a proxy that forwards calls to a replaceable implementation, or through functions that a designated role may call. A contract deployed without those affordances is fixed permanently, including against its own authors.

The design intent was to remove the operator. A pool with a pause switch has someone who can be compelled to use it, which makes that person a control point for pressure of every kind. Removing the switch removes the control point. It also removes any ability to correct a mistake or respond to misuse, which is the cost that comes with the property, and the record shows that cost being paid.

How did a proposal move from idea to execution?

Typically through four stages: discussion in a public forum, submission of an encoded proposal on chain, a voting period measured in days, and then execution as a separate transaction, often after a mandatory delay. Each stage is recorded, so the history of a governance system can be reconstructed by anyone without permission.

The delay between a successful vote and execution is deliberate. Known as a timelock, it gives anyone affected a window to see what is coming and react before it takes effect, which limits the damage a rushed or hostile proposal can cause. It also creates a public record of intent that exists before the change happens rather than only afterward.

Voting power in most designs derives from token balance, sometimes with delegation so that holders can assign their weight to someone who follows proposals closely. This is one-token-one-vote rather than one-person-one-vote, and the difference matters: influence is proportional to holdings, so a concentrated distribution produces a concentrated governance system no matter how open the process appears.

How can you research the record of a past governance proposal?

You research it by starting from the governance contract’s event history, matching any written discussion to the numbered proposal it concerns, reading the encoded call the proposal would execute, confirming both the vote outcome and whether execution followed, and recording what the chain cannot show. This is a documentary procedure only.

Step 1: Start from the governance contract

Identify the governance contract itself and read its event history, because the contract is where proposals were created, voted on and executed, while a forum only records what people said about them. Explorer interfaces expose these events without requiring any special tooling.

Step 2: Match the discussion to a proposal number

Tie any written discussion you find to the numbered proposal it refers to, since forum threads are often edited or renamed while the on-chain proposal identifier stays fixed. Where a forum has gone offline, archived captures can still supply the mapping.

Step 3: Read the calldata the proposal would run

Examine the encoded call the proposal was set to execute, including the target address and the function selected, because that payload is the actual content of a proposal and a title can describe it loosely. A mismatch between a friendly title and an unexpected target is exactly what this step exists to catch.

Step 4: Confirm the outcome and the execution

Check both whether the vote passed and whether an execution transaction followed, because a proposal can reach a passing tally and still never be executed within its window. Secondary write-ups frequently report the vote and omit whether anything actually happened.

Step 5: Write down the limits of the record

Note what the on-chain record cannot show, such as who was behind a voting address or what was agreed privately, because the chain captures actions rather than intentions. Stating those gaps explicitly is what separates a documented reconstruction from an inference.

Why did the boundary matter in court?

Because sanctions and liability arguments turn on whether someone controlled a thing. The Fifth Circuit held in Van Loon v. Department of the Treasury in November 2024 that immutable smart contracts were not property capable of being designated, reasoning that no one could own, exclude others from, or alter them.

That reasoning depends on the boundary this article describes. If a vote had been able to change the pools, an argument that someone exercised control would have been considerably stronger, and the property analysis would have looked different. The absence of any administrative hook was not a rhetorical point but a verifiable property of deployed code, which is why it could carry that much weight.

The limits of the ruling are as important as its holding. It addressed the immutable contracts specifically rather than every component of the project, and it answered a question about the scope of the executive sanctions authority invoked in the August 2022 OFAC action notice, not about whether any conduct was lawful. Governance over peripheral components sat outside its reasoning entirely.

Criminal law asks different questions again. The prosecution of Roman Storm in New York, where a jury convicted on one count of conspiracy to operate an unlicensed money transmitting business in August 2025 and deadlocked on two others, concerned conduct by people rather than the status of contracts. A hung count is not an acquittal, and a retrial is scheduled for April 26, 2027 before Judge Katherine Polk Failla in the Southern District of New York. Immutability was never a defense to those questions.

Governance scope at a glance

The table below separates the kinds of decision an on-chain governance system of this shape could reach from those it could not, using general categories rather than any specific proposal. It illustrates a structural pattern and is not a description of any particular vote.

Decision	Within governance scope?
Spending from a treasury the governance contract controls	Yes, by a passing proposal that then executes
Changing parameters of a component with an admin hook	Yes, where the code exposes that control
Altering the governance rules themselves	Yes, if the governance contract is upgradeable
Pausing or modifying an immutable pool contract	No, because no such function exists to call
Reversing a completed transaction on chain	No, at any scope, for any contract

Reading the two halves together explains why coverage of this project often seems contradictory. Statements about an active governance process and statements about an unstoppable protocol were both accurate, because they described different parts of the same system.

Frequently asked questions

Can a court treat a DAO as a legal entity?

Courts in several jurisdictions have been willing to look past the label and ask who actually acted, and some have treated participants in an unincorporated collective as bearing individual responsibility. The area is unsettled and varies widely by jurisdiction, so anyone with a live concern should consult qualified counsel.

What happens when most token holders stop voting?

Turnout falls until proposals struggle to reach quorum, and decision-making concentrates among the few addresses that still participate. Low turnout is a common condition in on-chain governance rather than an exception, and it means the influence attached to any active holder rises without any change in their balance.

Does delegating a vote transfer the tokens themselves?

No. Delegation assigns voting power to another address while the tokens remain in the holder’s own account, and the delegation can usually be changed at any time. The delegate can vote but cannot move or spend the balance behind that voting power.

Why do some proposals pass and then never take effect?

Execution is a separate transaction that someone has to submit, usually within a time window and often after a mandatory delay. If nobody executes in time, or if the encoded call reverts when it runs, the proposal expires or fails despite having won its vote.