Detailed Analysis of the Tornado Cash Governance Attack and Smart‑Contract Exploitation

The article begins with an event recap of the May 20 2023 attack on Tornado.Cash, where the attacker stole 473,000 TORN tokens, sold a large portion, and profited in ETH, illustrating the severe financial impact of the breach.

Background knowledge explains Tornado Cash as a privacy‑preserving protocol built on zk‑SNARKs, its governance model that requires locking TORN tokens to propose and vote, and the mechanics of token locking, voting power, and vote‑locking periods.

function _transferTokens(address owner, uint256 amount) internal virtual override { require(torn.transferFrom(owner, address(userVault), amount), "TORN: transferFrom failed"); lockedBalance[owner] = lockedBalance[owner].add(amount); }

The voting process is described, including the requirement of a 3‑day voting period, a minimum of 25,000 total votes, and the conditions for proposal execution.

Step 1 – Proposal Publication: The attacker creates a seemingly benign proposal contract, locks the required 1,000 TORN (funded via Tornado Cash and DEX swaps), and submits the proposal with a malicious self‑destruct function function emergencyStop() public onlyOwner { selfdestruct(payable(0)); } .

Step 2 – Creation of 100 Zombie Accounts: The attacker registers 100 accounts with zero TORN locked, populating the governance storage with controllable addresses for later vote manipulation.

Step 3 – Self‑Destruct of the Proposal: After gathering sufficient votes, the attacker triggers emergencyStop() to destroy the original proposal contract.

Step 4 – Re‑Deployment of the Proposal: Using create2 the attacker redeploys a contract at the same address, then uses create to deploy a new malicious proposal, allowing the bytecode to be swapped while preserving the address.

Step 5 – Execution of the Proposal: The governance contract calls execute() , which delegatecalls the malicious proposal’s executeProposal() . This delegatecall lets the attacker inflate the balances of the 100 zombie accounts to 10,000 votes each, granting over 1,000,000 votes and full control of the DAO.

function execute(uint256 proposalId) external payable virtual { require(state(proposalId) == ProposalState.AwaitingExecution, "Governance::execute: invalid proposal state"); Proposal storage proposal = proposals[proposalId]; proposal.executed = true; address target = proposal.target; require(Address.isContract(target), "Governance::execute: not a contract"); (bool success, bytes memory data) = target.delegatecall(abi.encodeWithSignature("executeProposal()")); if (!success) { if (data.length > 0) { revert(string(data)); } else { revert("Proposal execution failed"); } } emit ProposalExecuted(proposalId); }

Step 6 – Token Withdrawal: With the inflated votes, the attacker unlocks the tokens from the governance vault and transfers 473,000 TORN to their own address, effectively draining the community’s funds.

The article concludes with post‑attack analysis, noting a subsequent proposal that returned some funds to the governance vault, and discusses why the DAO’s treasury was the source of the stolen tokens.

Finally, the author reflects on the lessons learned: governance proposals containing self‑destruct functions are high‑risk, DAO participants often lack the expertise to audit complex contracts, and decentralized voting can be subverted by sophisticated on‑chain attacks.