Por:angelilu, Foresight News
A las 6:18 a.m. del 25 de junio de 2026, una propuesta de gobernanza numerada como 67 apareció en la página de votación del DAO de Tornado Cash.
El título era muy formal: "Establecimiento de una tarifa estándar del 0,5% y un esquema de deflación dinámica del 90%". El cuerpo del texto, extenso y florido, afirmaba querer actualizar el registro de relayers a una arquitectura "V5 Strategy A", quemar permanentemente el 90% de las comisiones del protocolo, distribuir el 10% a los stakers, e incluía un modelo económico de "ciclo virtuoso de riqueza".
El proponente también solicitaba 50 TORN del tesoro para compensar el Gas prepago al desplegar el contrato, un detalle que hacía que toda la propuesta pareciera escrita por un contribuyente comunitario serio y responsable que ponía dinero de su bolsillo.
Pero el código del contrato de esta propuesta no había sido verificado en absoluto. Es decir, la lógica de ejecución de la propuesta (Calldata) no había sido verificada en exploradores de bloques como Etherscan. Sin verificación, la comunidad solo veía un montón de código máquina, imposible de revisar directamente. Las propuestas normales en la historia de Tornado Cash siempre incluían este paso; esta propuesta lo omitió.
El investigador de L2BEAT, Sergey Shemyakov, fue el primero en notarlo. Aproximadamente 8 horas después de que la propuesta fuera publicada, etiquetó al investigador de seguridad Pascal Caversaccio diciendo: "La lógica de esta propuesta es anormalmente compleja, por favor ayúdame a revisarla de forma independiente."
Pascal Caversaccio, investigador de Security Alliance, pronto llegó a una conclusión.
El propósito real de la propuesta: cambiar subrepticiamente la dirección del administrador del protocolo
Caversaccio utilizó herramientas de desensamblaje para revertir el bytecode del contrato de la propuesta y determinó que esta era maliciosa.
El código contenía una función llamada "governance (gobernador)", con una única funcionalidad: devolver una dirección que le dice al protocolo "quién es el administrador". Y la dirección codificada en esta función era la cartera del atacante.
En la arquitectura de Tornado Cash, las diferentes partes del protocolo llaman a esta función para confirmar a quién pertenece la autoridad máxima. Si la propuesta se aprobaba y ejecutaba, la dirección que originalmente apuntaba al contrato de gobernanza comunitaria sería silenciosamente reemplazada por esta dirección del atacante.
La dirección de gobernanza real es 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce;
La dirección falsificada del atacante es 0x5efda50f22d34f272c7077689d6abc42f15e285f.
Las primeras 15 letras de ambas direcciones eran idénticas; la diferencia comenzaba a partir del carácter 16. Es muy difícil notarlo a simple vista.
Si esta propuesta se aprobaba, la consecuencia sería: la dirección del "administrador máximo" reconocida por el protocolo sería cambiada subrepticiamente por la del atacante. En ese momento, el atacante podría usar esta identidad para retirar aproximadamente 23 millones de dólares en tokens TORN actualmente bloqueados en el contrato de gobernanza, dinero que los miembros de la comunidad habían apostado para participar en las votaciones. Además, el atacante podría forzar el saldo de todos los relayer (proveedores de servicios que ayudan a los usuarios a reenviar transacciones) dentro del protocolo a cero, paralizando todo el protocolo.
Quién es el atacante y de dónde viene el dinero
La dirección de la cartera del creador de la propuesta es 0xd4eca8c9242b9f9faa3cf19a78defc21dc97a925.
Caversaccio rastreó el origen de los fondos de esta dirección y descubrió que apenas 4 días antes de presentar la propuesta había recibido una transferencia. El remitente era Railgun, otro protocolo de privacidad y mezcla de criptomonedas en cadena, y competidor directo de Tornado Cash. Una transferencia a través de Railgun significa que el origen de los fondos queda ofuscado, imposibilitando su trazabilidad hasta una identidad real.
Situación de la votación después de que la comunidad lo descubriera
Hasta el momento, el resultado de la votación de esta propuesta es: 0 votos a favor, 27.163 TORN en contra, representando el 100%. La votación cierra el 30 de junio.
Las reglas de gobernanza de Tornado Cash requieren al menos 100.000 TORN participando en la votación para alcanzar el quórum; actualmente solo se ha llegado al 27%. A menos que en los próximos 4 días aparezcan votos a favor anormalmente masivos que empujen el quórum y reviertan el resultado, esta propuesta caducará y el resultado de ser rechazada será su no ejecución. Pero el efecto advertencia de este incidente es mayor.
Este ya es el segundo ataque de este tipo que enfrenta Tornado Cash. En mayo de 2023, un atacante obtuvo 1,2 millones de votos de control de gobernanza a través de una propuesta que contenía una función de autodestrucción oculta, mientras que todo el DAO tenía solo 70.000 votos legítimos en ese momento. En ese ataque, el atacante retiró aproximadamente 2,17 millones de dólares en TORN, utilizando el propio Tornado Cash como herramienta para lavar el dinero, luego presentó una propuesta para "restaurar la gobernanza" y se retiró con una ganancia neta de unos 900.000 dólares. Después de eso, nadie reparó fundamentalmente esta estructura de gobernanza.
Ataques de gobernanza en DAOs, ¿cómo protegerse para el usuario común?
Los ataques de gobernanza ya son un riesgo común en Web3, no una excepción de un protocolo particular. En abril de 2022, Beanstalk fue atacado por un atacante que usó un préstamo flash para tomar prestados 1.000 millones de dólares en poder de voto temporal, aprobó una propuesta, transfirió 182 millones de dólares y pagó el préstamo en la misma transacción, todo en menos de un minuto. En febrero del mismo año, Build Finance DAO fue atacado por un atacante que obtuvo control falsificando tokens de gobernanza, vaciando un tesoro de 11 millones de dólares.
Las formas de ataque evolucionan: desde préstamos flash para acaparar votos, hasta funciones de autodestrucción ocultas, hasta el reemplazo de caracteres en direcciones como en esta ocasión. Pero la lógica subyacente sigue siendo la misma: el poder de un DAO proviene de los tokens, y los tokens se pueden prestar, falsificar u ofuscar. Cualquier mecanismo de gobernanza que pueda ser manipulado por código puede ser atacado.
Para los usuarios comunes que poseen tokens de gobernanza, hay algunas vías prácticas disponibles. Primero, prestar atención a las alertas en tiempo real de investigadores de seguridad; este ataque fue alertado primero por un investigador de L2BEAT. Segundo, las propuestas que apuntan a contratos no verificados probablemente requieran un voto en contra directo. Tercero, si posees tokens de gobernanza de un protocolo pero no planeas participar activamente, delegar tu poder de voto a miembros activos de la comunidad es más seguro que dejar los tokens inactivos en tu cartera; los tokens silenciosos solo dificultan alcanzar el quórum.
Para los desarrolladores de protocolos, una defensa más fundamental es introducir un tiempo de bloqueo (timelock) en la capa de gobernanza: una propuesta aprobada no se ejecuta inmediatamente, dejando una ventana de 48 a 72 horas para que la comunidad y los investigadores de seguridad tengan la oportunidad de revisarla y activar una pausa de emergencia. Protocolos como Compound y Aave ya tienen este mecanismo como estándar; Tornado Cash todavía no lo tiene, lo que también es una elección extrema suya en cuanto a cumplimiento normativo y resistencia a la censura.
