El hack de The DAO de 2016 explicado

El escenario: un DAO con 150M y una base de código conocidamente frágil

Un DAO — organización autónoma descentralizada — es una entidad on-chain que mantiene fondos y actúa por lógica de smart contracts y votos de tenedores de tokens. The DAO (T mayúscula, D mayúscula) fue el ejemplo temprano más ambicioso. Fue construido por slock.it y lanzado en Ethereum en abril de 2016 mediante una venta abierta de tokens que recaudó más de 11,5 millones de ETH — unos 150M USD en su momento y cerca del 14% de todo el ETH existente entonces. Los tenedores podían votar qué propuestas financiar, asumiendo que los retornos volverían a ellos.

El smart contract de The DAO era complejo. Varios investigadores habían planteado en público preocupaciones sobre patrones específicos — sobre todo en la función que permitía a los tenedores escindir su parte en un DAO hijo. La ruta de código relevante hacía una llamada externa antes de actualizar el balance interno, un patrón ahora-de-libro-peligroso: reentrancy. Se propusieron arreglos pero no se desplegaron antes del exploit.

Esto es educativo, no consejo financiero. El hack de The DAO importa porque las decisiones tomadas como respuesta moldearon para siempre el significado de "inmutable" en Ethereum.

Qué pasó realmente: el drenaje y el fork

El exploit y la respuesta se desplegaron a lo largo de semanas.

• 17 de junio de 2016. Un atacante empezó a explotar el bug de reentrancy. El ataque llamó recursivamente a la función split de The DAO antes de que el contrato actualizara el balance interno del atacante, permitiendo retiros repetidos contra el mismo balance. Unos 3,6 millones de ETH fueron drenados a un DAO hijo controlado por el atacante.
• La peculiaridad de los 28 días. La estructura de The DAO exigía que los fondos drenados permanecieran en el DAO hijo durante 28 días antes de poder moverse fuera. Esto dio a la comunidad de Ethereum una ventana para responder antes de que el atacante pudiera gastar los fondos.
• Finales de junio de 2016: debate. Se debatieron dos respuestas. La primera, un soft fork: cambio de reglas de red que bloquearía transacciones que involucraran los fondos drenados, congelando al atacante. La segunda, un hard fork: cambio de reglas que movería los fondos a un contrato de reembolso del que los tenedores podían retirar su ETH original.
• Intento de soft fork y retirada. Se halló que la propuesta de soft fork tenía una vulnerabilidad que permitía un ataque DoS a los mineros de Ethereum. Se retiró.
• 20 de julio de 2016: hard fork ejecutado. La comunidad ejecutó un hard fork en el bloque 1.920.000. El fork movió el ETH drenado a un contrato de reembolso, permitiendo a los tenedores retirar su ETH original a tasa fija.
• La división. Una minoría de mineros y usuarios rechazó el fork, argumentando que la inmutabilidad era la promesa central de una blockchain y que intervenir para revertir un exploit sentaba un precedente peligroso. Siguieron minando y usando la cadena original. Esa cadena pasó a llamarse Ethereum Classic (ETC). La cadena forked — la del reembolso — conservó el nombre Ethereum (ETH) y el apoyo de la Ethereum Foundation.

El atacante, cuya identidad permanece formalmente no confirmada pese a varias afirmaciones de investigaciones, terminó con el ETH drenado en la cadena Ethereum Classic, que no había reembolsado. El fork no deshizo el exploit en ETC; solo dejó indemnes a los tenedores de tokens DAO en ETH.

Quién estuvo involucrado

• Contribuyentes de The DAO y slock.it. El equipo que construyó y promocionó The DAO. No eran los atacantes on-chain, pero el bug estaba en su código.
• Vitalik Buterin y la Ethereum Foundation. Argumentaron a favor del hard fork como respuesta que protegía al mayor número de usuarios. Su postura pública fijó de hecho la dirección de la cadena Ethereum.
• El atacante. Identidad formalmente no confirmada. Un artículo investigativo de Forbes en 2022 nombró a un individuo como sospechoso, pero la afirmación es disputada y no ha habido condena penal.
• La minoría que pasó a Ethereum Classic. Un grupo de mineros, desarrolladores y usuarios que rechazó el fork porque la inmutabilidad importa más que cualquier recuperación. Incluye desarrolladores que construyeron y mantuvieron Ethereum Classic como cadena separada.
• Tenedores de tokens DAO. Unas 11.000 carteras tenían tokens DAO. Tras el hard fork pudieron retirar su ETH original del contrato de reembolso en ETH.

El después: dos cadenas, un vocabulario y un campo de investigación

El impacto del hack se extendió mucho más allá de junio de 2016.

• Dos cadenas. Ethereum (ETH) y Ethereum Classic (ETC) siguen operando desde 2016. Sus valoraciones y ecosistemas divergieron drásticamente — Ethereum es cientos de veces mayor por capitalización en 2026 — pero ETC sigue existiendo como experimento continuo de inmutabilidad estricta.
• Un campo de seguridad de smart contracts. La reentrancy se convirtió en ejemplo fundacional en educación sobre seguridad de smart contracts. Los patrones de contratos de OpenZeppelin, los reentrancy guards de Solidity, las herramientas de verificación formal y los bug bounties tienen un nexo conceptual con el incidente DAO.
• El debate sobre la inmutabilidad. El hard fork hizo explícito lo que era implícito: con consecuencia suficiente, la comunidad podía cambiar la cadena por consideraciones off-chain. Eso es una característica (la red puede recuperarse de desastres) o un bug (la red no es realmente inmutable), según la perspectiva.
• El Informe DAO de la SEC (julio 2017). La SEC publicó un Informe Section 21(a) concluyendo que los tokens DAO eran valores según el Howey Test. Ese informe definió de hecho el marco regulatorio del boom ICO 2017.
• Experimentos posteriores de gobernanza on-chain. Todo intento posterior — MakerDAO, gobernanza de Compound, OlympusDAO, Gitcoin, el Optimism Collective moderno — ha tenido que navegar la misma tensión entre código inmutable, juicio humano y protección a stakeholders que el incidente DAO sacó a la luz.

Las lecciones

El hack DAO es uno de los incidentes más estudiados en cripto. Lecciones honestas:

• Los smart contracts son programas, y los programas tienen bugs. The DAO tenía más valor que la mayoría del software financiero de producción, escrito por un equipo pequeño bajo presión, auditado pero no verificado formalmente. El bug específico (reentrancy) estaba descrito en literatura de seguridad; usar patrones conocidamente peligrosos a escala hizo posible la pérdida.
• La inmutabilidad es una elección de la comunidad, no una propiedad del sustrato. El hard fork demostró que, con consecuencia suficiente, la red intervendría. Cadenas posteriores varían en cuánta estrictitud aplican. Ethereum Classic existe en parte para mantener que la inmutabilidad no es negociable.
• Las decisiones de recuperación crean precedentes. El fork DAO se ha citado en crisis posteriores — recuperaciones tras hacks, exploits de bridges, despegues de stablecoins — como precedente de intervención comunitaria. Algunas cadenas lo han rechazado; otras lo han adoptado; casi todas han tenido que razonarlo.
• Las auditorías son necesarias pero no suficientes. The DAO había sido auditado. Los auditores habían planteado dudas. El exploit ocurrió igualmente. La seguridad real depende de varias defensas — verificación formal, bug bounties, procesos conservadores de actualización, controles con time-lock — no de una sola auditoría.
• La gobernanza es una capa que requiere diseño. La gobernanza por tenedores de The DAO era novedosa e infraespecificada. Toda DAO seria posterior ha tenido que diseñar gobernanza con mucho más cuidado: quórum, ponderaciones, periodos de espera, procedimientos de emergencia. The DAO es el caso que hizo concretas estas preocupaciones.

Conviene aclarar lo que el hack DAO no prueba. No prueba que todos los smart contracts sean inseguros o que las organizaciones on-chain no funcionen. Prueba que los smart contracts que custodian valor grande deben diseñarse y auditarse con la seriedad de software financiero de producción — y que la comunidad debe haber pensado, por adelantado, qué hará cuando algo vaya mal.

Vigila dónde empiezan los próximos incidentes de smart contracts

Los incidentes de smart contracts continúan cada ciclo — exploits de bridges, drenajes de protocolos de préstamo, ataques de gobernanza. Los patrones — rutas de código conocidamente peligrosas, despliegues bajo presión, respuesta disputada — se repiten. Zippfeed sigue titulares de seguridad DeFi y de smart contracts en muchas fuentes con puntuación de sentimiento e importancia, para que veas incidentes y respuestas — y aprendas antes de que la exposición se convierta en pérdida. Esto es educativo, no consejo financiero.