1 de abril de 2026, 16:05:18 UTC, un atacante envió una transacción al Drift Protocol. Un segundo después, otra transacción la aprobó.
Doce minutos después, desaparecieron 285 millones de dólares. Diecisiete días más tarde, un validador comprometido en el puente de KelpDAO acuñó por sí solo 292 millones de dólares en tokens sin respaldo, desencadenando en 48 horas una salida de fondos de unos 8,500 millones de dólares de Aave y alrededor de 4,500 millones de dólares de otros protocolos DeFi.
Otros doce días después, un atacante con la clave privada de un implementador robado extrajo 4.5 millones de dólares del Wasabi Protocol a través de cuatro cadenas.
Ninguno de estos incidentes se debió a la explotación de una vulnerabilidad de contrato inteligente.
Durante más de medio decenio, la DeFi ha creído firmemente que la seguridad es un problema de código. Auditorías, verificación formal, programas de recompensas por fallos: toda la industria se ha organizado en torno a una premisa: si la lógica del contrato inteligente es rigurosa, el protocolo es seguro. Las matemáticas son la ley. Abril de 2026 fue el mes en que esa premisa se derrumbó públicamente.
En un solo mes, más de 625 millones de dólares robados acumulados en unos 30 incidentes –según datos de DefiLlama, el mes con más hackeos en la historia de las criptomonedas por número de incidentes– y cada pérdida importante se remontó a claves privadas de administradores, validadores de puentes, puntos ciegos de oráculos o ataques de ingeniería social, todos ellos componentes operativos que las auditorías nunca fueron diseñadas para cubrir.
Este artículo trata de esa migración. Descompondremos tres grandes hackeos de abril en las tres caras de un mismo fracaso subyacente, repasaremos cómo una configuración errónea de puente en un protocolo desencadenó una salida de 13.2 mil millones de dólares en un protocolo 25 veces más grande, y examinaremos con franqueza lo que realmente es la DeFi hoy: una infraestructura abierta con palancas operativas de confianza, incluso si su narrativa de marketing dice lo contrario. El problema no está en las matemáticas.
El problema está en el modelo mental que rodea a las matemáticas.
Las matemáticas no están rotas. Lo que está roto es el modelo mental que las envuelve, y el costo de este desajuste está obligando a la industria a replantearse lo que realmente significa descentralización.
La brecha del modelo mental
En gran parte de la historia de la DeFi, la cultura de seguridad predominante ha estado basada en Solidity. Las auditorías revisan la lógica del contrato. Los programas de recompensas pagan por reentradas, desbordamientos de enteros, errores en modificadores de acceso. La verificación formal prueba invariantes para el código en cadena. El supuesto implícito era: todo lo que está fuera del contrato—multifirmas, claves privadas de implementadores, validadores de puentes, infraestructura de relayers, canales de comunicación del equipo— o bien no estaba dentro del alcance, o era problema de otro.
Ese supuesto solo se sostenía mientras los atacantes explotaban vulnerabilidades de Solidity.
Los hackeos de abril de 2026 tienen una característica estructural que un informe de auditoría no puede describir: los contratos inteligentes en sí no tenían vulnerabilidades. Según análisis de investigadores independientes de on-chain, el código de Drift fue auditado una vez por Trail of Bits en 2022 y otra por ClawSecure en febrero de 2026; ambas pasaron.
Ninguna de las dos auditorías cubrió la configuración de multifirma de Drift, la lógica de manejo de durable nonces, ni la superficie de ataque de ingeniería social alrededor de su Consejo de Seguridad. El adaptador de LayerZero de KelpDAO era código estándar de la plantilla OFT; el contrato en sí no tenía ningún problema. El error estuvo en la configuración de implementación, lo cual típicamente no está dentro del alcance habitual de una auditoría de Solidity.
El contrato de bóveda de Wasabi era actualizable por diseño; el diseño en sí era la vulnerabilidad.
Lo que colapsó en abril no fueron las matemáticas, sino los cimientos operativos sobre los que éstas se ejecutan.
Tres disecciones: tres caras del mismo fracaso
Los tres grandes hackeos de abril de 2026 –Drift, KelpDAO, Wasabi– representan tres tipos distintos de "fallo no-código".
Juntos abarcan gran parte de las nuevas superficies de ataque y comparten una característica estructural: en cada incidente, uno o dos individuos o componentes de infraestructura comprometidos desencadenaron un efecto dominó sobre todo el protocolo.
Drift: Multifirma humana (285M USD)
El hackeo de Drift fue una operación de inteligencia, no una explotación de vulnerabilidad. El atacante, atribuido tras análisis de TRM Labs, Elliptic y del propio Drift con ayuda de SEAL 911 al grupo norcoreano Lazarus, concretamente al subgrupo UNC4736, previamente vinculado por Mandiant al ataque de Radiant Capital de octubre de 2024.
El atacante pasó aproximadamente medio año planificando la operación. La ingeniería social comenzó en conferencias de la industria en otoño de 2025; la preparación on-chain no se inició hasta tres semanas antes del incidente.
El 11 de marzo de 2026, la operación arrancó con 10 ETH depositados desde Tornado Cash. Al día siguiente, aproximadamente a las 9:00 hora de Pyongyang, esos fondos desplegaron el token CarbonVote (CVT) en Solana. El atacante creó un pequeño pool de liquidez en Raydium, hizo trading lavado del CVT para anclar su precio de mercado alrededor de $1, y luego configuró un oráculo de precios bajo su control para alimentar ese precio artificial a Drift.
El trading lavado existía para que la salida del oráculo "pareciera legítima" —cualquiera que lo comprobara al azar encontraría que el precio de mercado coincidía con el precio reportado por el oráculo.
Mientras tanto, el atacante, haciéndose pasar por una firma de trading cuantitativo, pasó semanas estableciendo relaciones con colaboradores de Drift. El objetivo no era extraer información, sino acumular confianza por adelantado para un momento específico.
Ese momento dependía de una característica de Solana llamada durable nonces (nonces duraderos): un mecanismo legítimo que permite "firmar hoy, ejecutar más tarde". Entre el 23 y el 30 de marzo, el atacante obtuvo firmas de durable nonces de al menos dos de los cinco miembros del Consejo de Seguridad de Drift.
Desde la perspectiva del firmante, estaban aprobando transacciones rutinarias. Desde la perspectiva de la red, esas firmas eran credenciales de autorización válidas, en estado dormido pero efectivo.
El 26 de marzo, Drift tomó una decisión que en retrospectiva fue desastrosa: migrar a un nuevo multifirma 2-de-5 para el Consejo de Seguridad, con timelock cero. Esta migración eliminó la ventana de demora que podría haber detectado o intervenido en el ataque.
El 1 de abril a las 16:05:18 UTC, el atacante envió la primera transacción pre-firmada con durable nonce —una propuesta para transferir el control administrativo a la dirección H7PiGqqUaanBovwKgEtreJbKmQe6dbq6VTrw6guy7ZgL. Un segundo después, a las 16:05:19 UTC, una segunda transacción pre-firmada la aprobó y ejecutó. El atacante tomó control de Drift.
Lo que siguió tomó solo doce minutos. El atacante listó el CVT sin valor como colateral con límites de préstamo casi infinitos, depositó 500 millones de CVT al precio manipulado del oráculo, y luego retiró 285 millones de dólares en activos reales de tres bóvedas principales—JLP, USDC, SOL, cbBTC, wBTC, ETH. El TVL de Drift colapsó de 550 millones de dólares a unos 250 millones. Dos firmantes, un protocolo, los contratos inteligentes funcionando exactamente como fueron diseñados. La vulnerabilidad estaba en las personas.
Hay un punto en la respuesta posterior de Drift que merece mención, porque establece el estándar que los protocolos víctimas de la próxima ronda deberían alcanzar: la propia divulgación post-mortem del equipo de Drift fue inusualmente franca.
En los cinco días posteriores a la exposición de la vulnerabilidad, el equipo publicó un análisis detallado del ataque de ingeniería social —incluyendo los hechos de que los colaboradores fueron contactados múltiples veces durante medio año; que al menos dos colaboradores pudieron haber sido comprometidos a través de clones de repositorios de código y una versión beta de cartera en TestFlight; que los chats de Telegram con el atacante fueron borrados alrededor del momento del ataque; y que la decisión de migrar a un multifirma con timelock cero seis días antes del incidente eliminó la última ventana de detección.
El equipo también hizo pública la atribución del ataque con un nivel de confianza medio (UNC4736 / Citrine Sleet), coordinó con SEAL 911, y compartió detalles operativos que podrían ayudar a otros protocolos a identificar las mismas tácticas.
Los protocolos víctimas a menudo retroceden hacia la cautela legal y la redacción vaga; Drift optó por publicar una narrativa con un carácter forense que puede convertir un evento singular en inteligencia de amenazas para toda la industria. El incidente en sí sigue siendo un hackeo, la vulnerabilidad de gobernanza subyacente sigue siendo una vulnerabilidad. Pero la voluntad de hacer público 'cómo funcionó la ingeniería social' es precisamente lo que distingue a los protocolos que contribuyen al aprendizaje colectivo de la industria de aquellos que simplemente absorben las pérdidas en silencio.
KelpDAO: Un solo validador (292M USD)
Diecisiete días después, el 18 de abril, un perfil de amenaza similar produjo un ataque estructuralmente completamente diferente. KelpDAO es un protocolo de re-staking de liquidez, que emite rsETH—un token que representa los depósitos de los usuarios, enrutados a través de EigenLayer para obtener rendimientos adicionales.
Para abril de 2026, el TVL de rsETH superaba los 1,000 millones de dólares y se había desplegado en más de 20 cadenas a través del estándar OFT (Omnichain Fungible Token) de LayerZero.
El contrato no tenía problemas. La configuración sí.
El puente de KelpDAO funcionaba con una DVN (Decentralized Verifier Network, Red de Verificadores Descentralizada) 1-de-1 —es decir, con un solo validador. Un solo nodo era suficiente para aprobar un mensaje cross-chain. "Descentralizada" era una palabra, no una arquitectura.
El ataque fue por fases. El atacante primero comprometió el nodo RPC interno del que el validador dependía para leer el estado de la cadena fuente, luego lanzó un ataque DDoS coordinado contra nodos externos, forzando al sistema a recurrir a la infraestructura contaminada. Con las fuentes de datos bajo su control, falsificaron un mensaje cross-chain, instruyendo al contrato de KelpDAO en Ethereum mainnet a acuñar rsETH contra una "quema que nunca ocurrió en ninguna cadena fuente".
A las 17:35 UTC, el contrato liberó 116,500 rsETH —valorados en unos 292 millones de dólares, aproximadamente el 18% de la oferta circulante del token— a una dirección controlada por el atacante. En minutos, estos rsETH fueron depositados como colateral en Aave, cada uno valorado en aproximadamente $2,500.
El atacante tomó préstamos de WETH, USDC, wBTC reales contra el colateral sin respaldo, extrayendo finalmente más de 82,600 ETH (unos 191 millones de dólares) antes de que KelpDAO pausara el contrato a las 18:21 UTC.
Dos intentos posteriores a las 18:26 y 18:28 UTC, cada uno buscando extraer otros 40,000 rsETH, fueron revertidos. La pausa detuvo mayores pérdidas, pero no la primera extracción.
No hubo vulnerabilidad de reentrada, ni falta de controles de acceso, ni manipulación del oráculo dentro de la lógica de Kelp. El invariante contable que define un puente —los activos liberados en la cadena de destino deben igualar los activos quemados en la cadena fuente— fue violado a nivel del sistema, no a nivel de transacción. Un nodo, cientos de millones en pérdidas.
Lo que siguió fue una disputa pública: ¿sobre quién recae realmente la responsabilidad? El informe post-mortem inicial de LayerZero atribuyó directamente la culpa a Kelp, argumentando que Kelp había violado las guías al elegir una DVN 1-de-1. El memorándum de réplica de Kelp del 5 de mayo pintó un cuadro diferente: en ese momento, el 47% de los contratos OApp activos de LayerZero —aproximadamente 1,250 aplicaciones con un valor combinado de más de 4,500 millones de dólares— ejecutaban la misma configuración de validador único.
Kelp argumentó: el OFT Quickstart de LayerZero, los ejemplos de GitHub y las plantillas para desarrolladores venían de fábrica con la propia DVN de LayerZero Labs como validador obligatorio, y sin un segundo; y presentó capturas de pantalla de Telegram de empleados de LayerZero diciendo al equipo de Kelp en ocho discusiones de integración a lo largo de dos años y medio que "usar los valores por defecto está bien".
El investigador de seguridad Sujith Somraaj (ex-auditor de LayerZero) había presentado anteriormente un informe de recompensa por fallo en Immunefi describiendo precisamente este patrón de ataque, que fue rechazado por LayerZero con el argumento de que "la selección de la red de validadores pertenece a la configuración de la capa de aplicación".
La respuesta de LayerZero al memorándum de Kelp fue: esta caracterización es engañosa. Excluir la "configuración de la capa de aplicación" de los programas de recompensas por fallos es un límite estándar "plataforma/aplicación" (un portavoz de LayerZero señaló que de otra manera, "cualquier aplicación podría configurarse a sí misma como la única DVN y reclamar recompensas maliciosamente"); los valores por defecto del protocolo en casi todas las rutas son de hecho múltiples DVNs; y en cuanto a esas plantillas que mostraban 1-de-1, el único DVN apuntaba a un contrato placeholder llamado "DeadDVN" que rechazaría todos los mensajes, obligando a los desarrolladores a configurar su propia pila de seguridad antes de lanzar.
Respecto a Kelp, LayerZero afirmó que Kelp inicialmente desplegó múltiples DVNs, y posteriormente degradó manualmente a 1-de-1 —no "usó los valores por defecto".
El límite plataforma vs. aplicación es ciertamente un punto de disputa real, donde ingenieros racionales podrían discrepar sobre si una plataforma cuyas plantillas pueden configurarse de manera peligrosa es responsable de las configuraciones que los usuarios realmente implementan.
Lo que es menos disputable es la segunda parte de la respuesta final de LayerZero. El 8 de mayo, tres semanas después del primer informe post-mortem, LayerZero revirtió su postura y se disculpó: "Cometimos un error al permitir que nuestra DVN funcionara como una DVN 1-de-1 para transacciones de alto valor. No impusimos restricciones a para qué podía nuestra DVN ofrecer protección."
El protocolo dejó de admitir configuraciones 1-de-1 dentro de su sistema DVN, movió los valores por defecto a 5-de-5, aumentó los umbrales de su propia multifirma de 3-de-5 a 7-de-10, y anunció una nueva plataforma de monitoreo para emisores (Console).
Sea que la configuración subyacente fue culpa de Kelp, de LayerZero, o —lo más probable— un fracaso compartido entre una plataforma que salía de fábrica pudiendo configurarse peligrosamente y un integrador que activamente degradó, la respuesta final de ambas partes converge en la misma conclusión: la validación 1-de-1 no es segura a escala, y la industria no debería haber necesitado 292 millones de dólares para aprenderlo.
Wasabi: Clave privada de administrador (4.5M USD)
El incidente de Wasabi del 30 de abril fue un orden de magnitud menor que los otros dos, y por eso quizás más bochornoso. Fue un "hackeo aburrido".
Una EOA (Cuenta Externa Propietada) de implementador —la dirección 0x5c629f8c0b5368f523c85bfe79d2a8efb64fb0c8— mantenía el ADMIN_ROLE en los gestores de contratos perpetuos de Wasabi desplegados en Ethereum, Base, Blast y Bera. Sin multifirma. El framework de contratos admitía timelock, pero el valor configurado era cero.
El atacante obtuvo esa clave privada —phishing, compromiso de dispositivo, ataque a la cadena de suministro siguen siendo posibilidades, Wasabi no dio una conclusión definitiva. Con el ADMIN_ROLE, se otorgaron a sí mismos el mismo rol a un contrato auxiliar malicioso, actualizaron el contrato de bóveda vía proxy UUPS, y barrieron colaterales y saldos del pool. Pérdida total cross-chain: 4.5–5.5 millones de dólares.
Wasabi no usó ninguna técnica nueva. Esta vulnerabilidad como anti-patrón de DeFi ha sido advertida durante años: excesiva concentración de poder administrativo, falta de separación de poderes, ausencia de ventanas de retraso. Es el mismo tipo de vulnerabilidad contra la que la DeFi ha estado recibiendo golpes y escribiendo informes post-mortem desde 2020, sin llegar a corregirla en la práctica.
Conectando los tres: en última instancia, son el mismo tipo de hackeo. Ya sea que el acceso privilegiado se obtenga manipulando firmantes, comprometiendo un nodo validador, o robando una clave privada de implementador, la superficie de ataque es la misma —concentración de poder más allá de la capa de contrato inteligente, con protección insuficiente. Este patrón también es una advertencia: en cada incidente, una o dos entidades comprometidas desencadenaron una cadena de dominó que ningún endurecimiento de Solidity podría haber detenido.
El dominó asimétrico
El incidente de KelpDAO es significativo más allá de su monto en dólares por lo que ocurrió después —esta fue la primera prueba de estrés real de la composibilidad de la DeFi frente a un fallo operativo— y también es, hasta ahora, el caso más ilustrativo de lo absurdamente asimétrica que puede ser la matemática de la propagación (contagion).
Pongamos la escala en contexto: en el momento del incidente, el TVL de rsETH de KelpDAO era de unos 10,000 millones de dólares; los AUM de Aave a través de todas las cadenas superaban los 25,000 millones. Un protocolo aproximadamente el 4% del tamaño de Aave, solo con un incidente, extrajo 8,450 millones de dólares de Aave en 48 horas —cifra que creció a 15,100 millones en tres días y medio— mientras que el TVL total de la DeFi en esa ventana de 48 horas cayó 13,210 millones de dólares. La asimetría es la verdadera historia.
Un pequeño protocolo con una mala configuración de puente, desencadenó una corrida bancaria en un protocolo mucho más grande que, según todas sus métricas de contrato, estaba "funcionando según lo especificado".
Cuando el atacante acuñó y depositó el rsETH sin respaldo en Aave, los contratos de Aave estaban ejecutándose exactamente según su especificación. Sus oráculos, durante la breve ventana en que el atacante tomó préstamos, todavía leían el rsETH cercano a 1:1. Los pools de préstamo liberaron WETH real contra un colateral que, para todos los sistemas en cadena, parecía "válido".
La reacción del mercado fue inmediata. El rsETH comenzó a operar con un descuento profundo en DEXs en cuestión de horas, reflejando una incertidumbre real: ¿estaba el 82% restante de la oferta todavía totalmente respaldado? Aave V3 y V4 congelaron los mercados de rsETH; Fluid, Compound, Euler, Morpho siguieron el paso en horas (SparkLend había dado de baja el rsETH en enero).
Los tenedores de rsETH en Arbitrum, Base, Mantle, Linea, Blast, Scroll ahora tenían tokens que no podían estar seguros de canjear 1:1 de vuelta a la custodia en Ethereum mainnet.
La posterior salida de fondos no ocurrió porque Aave fuera hackeado, sino porque los depositantes no podían estar seguros de si el colateral que respaldaba sus préstamos seguía siendo solvente.
En las semanas previas al incidente, Aave ya había acumulado una exposición significativa al rsETH, ya que los usuarios apalancaban operaciones de re-staking; el protocolo ganaba comisiones y no había establecido un límite superior para esta exposición. Así que esta propagación no fue una lógica pura de "espectador inocente" —Aave eligió asumir el riesgo de contraparte— pero el evento desencadenante estaba fuera de sus propios contratos, y fuera del alcance detectable de su propia gobernanza.
La respuesta de Aave a este incidente merece una mención aparte, porque establece un estándar contra el que se medirán otros grandes protocolos de préstamo. En horas posteriores a la exposición del incidente, el administrador de emergencia del protocolo congeló los mercados de rsETH en todas las cadenas afectadas en V3 y V4, estableciendo el LTV (Loan-to-Value) en cero, conteniendo así pérdidas posteriores.
En 48 horas, el proveedor de servicios de Aave publicó un informe detallado del incidente en el foro de gobernanza, modelando públicamente dos escenarios diferentes de deuda incobrable —si Kelp socializaba la pérdida entre todos los tenedores de rsETH, 123.7 millones en deuda incobrable; si la pérdida se aislaba a los despliegues en L2, 230.1 millones— incluyendo un desglose por cadena de qué mercados asumirían qué parte del déficit.
El fundador de Aave, Stani Kulechov, se comprometió personalmente con 5,000 ETH para la recuperación; la alianza DeFi United, liderada por el proveedor de servicios de Aave e incorporando a Lido, EtherFi, LayerZero, Mantle, entre otros, reunió compromisos por más de 300 millones de dólares para cubrir el déficit de rsETH. Este es el rescate inter-protocolo más grande de la industria hasta la fecha.
La parte crítica es más específica y debe separarse de la respuesta: la postura de Aave mostró un desplazamiento a medida que se clarificaba el rango de deuda incobrable. El compromiso inicial de que sus reservas Umbrella cubrirían el déficit se suavizó en días a "explorar vías para cubrir el déficit". Un desplazamiento narrativo menor pero notable —el seguro a nivel de protocolo que suena inequívoco en abstracto, se convierte en algo negociable una vez que los números se concretan.
Que Aave manejara bien la operación no cambia el hecho estructural: los depositantes que pusieron USDC en el protocolo asumieron riesgo de contraparte contra un token cuya existencia quizás ni siquiera conocían, y cuyo mecanismo de seguro resultó estar mucho menos vinculante de lo que la documentación sugería.
Este es el problema estructural más profundo. El diseño de pool único que da a Aave liquidez profunda y una experiencia sencilla, también significa que una mala inclusión de colateral tiene un radio de explosión a nivel de todo el protocolo. Incluso con una gobernanza diligente y contratos robustos, el protocolo está aguas abajo del fallo de seguridad de una contraparte mucho más pequeña —y esa exposición aguas abajo es suficiente para poner bajo presión los fondos de depositantes por nueve cifras y desencadenar la congelación de mercados en nueve protocolos.
La composibilidad que impulsó el crecimiento de la DeFi es también su canal de propagación, y abril de 2026 fue la primera vez que esta factura se cobró a escala. La corrección no es sutil. La composibilidad que una vez impulsó el crecimiento de la DeFi, ahora se convierte en el canal a través del cual el fallo operativo de un protocolo se convierte en la corrida bancaria de otro.
La verdad del OpenFi
Hemos llegado a una conversación que la industria ha estado evitando.
Llamémoslo OpenFi: infraestructura financiera de acceso sin permiso, auditables on-chain, pero que operativamente todavía depende de terceros de confianza en puntos críticos donde la tesis de descentralización original decía que los intermediarios deberían eliminarse. Por esta definición, la mayoría de lo que hoy se comercializa como DeFi es OpenFi. Un Consejo de Seguridad con poder para transferir el control administrativo.
Un puente con solo un validador 1-de-1. Una EOA de implementador con ADMIN_ROLE cross-chain. Un token de gobernanza tan concentrado que una minoría paciente puede capturar el tesoro, como Nouns. Cada uno es una "costura privilegiada" parcheada en un sistema que se anuncia como perfecto.
Vale la pena recordar lo que realmente decía la tesis original. La computación de "mínima confianza" de Szabo, la infraestructura "neutral y confiable" de Buterin, la insistencia cypherpunk de que "la privacidad y la libertad requieren eliminar, no auditar, intermediarios" —esto no era sobre "transparencia". La transparencia es necesaria y fácil. La afirmación realmente difícil —la que justifica toda la fricción de ejecutar una máquina de estado global en decenas de miles de nodos redundantes— es que "ninguna parte dentro del sistema puede ser coaccionada, capturada, sobornada o comprometida para cambiar las reglas".
Un libro público que puedes inspeccionar pero no influenciar, y un libro público cuya clave de administrador está en una billetera de hardware en la caja fuerte de alguien, son dos cosas diferentes. El OpenFi cumple la primera parte del trato, y silenciosamente abandona la segunda.
Diferentes protocolos dependen de diferentes tipos de confianza, y sus modos de fallo difieren.
Nombrarlos es útil: confianza de custodia (alguien guarda el activo real, tú negocias un derecho sobre él —puentes, tokens envueltos); confianza de actualización (alguien puede cambiar el comportamiento del contrato después de que depositas —administradores de proxy, Consejos de Seguridad); confianza en el oráculo (alguien proporciona datos que el contrato no puede generar por sí mismo —feed de precios); confianza de actividad (el funcionamiento normal del sistema depende de que alguien opere continuamente —secuenciadores, relayers, keepers); confianza en la gobernanza (tenedores de tokens, o la pequeña porción que puede alcanzar el quórum en votaciones disputadas).
La mayoría de los protocolos dependen de tres o cuatro de estos simultáneamente. La mayoría del material de marketing los colapsa a todos en la palabra "descentralizado", dejando que el lector adivine el resto.
El problema mayor es que algunos de estos supuestos están completamente ocultos. LayerZero admitió en su disculpa de mayo que, tres años y medio atrás, uno de sus firmantes de multifirma había realizado una transacción personal usando una billetera de hardware del entorno de producción. Este error fue corregido internamente y nunca se divulgó a los usuarios, emergiendo finalmente como parte de un anuncio de fortalecimiento, enmarcado como una rutina, no como una admisión. Los usuarios del sistema de confianza no tenían forma de saber esto, ni de poner precio al riesgo de que "realmente ocurrió".
La industria tiene un eufemismo para esta brecha: "ruedas de entrenamiento". La venta es que las claves de administrador y los Consejos de Seguridad son transitorios —existen hoy, se eliminarán cuando el protocolo madure lo suficiente para caminar solo. En la práctica, las ruedas de entrenamiento casi nunca se quitan. Se renombran, se reempaquetan, se prorrogan o se transfieren silenciosamente a una fundación.
El marco Stage 0 / Stage 1 / Stage 2 de L2Beat es la excepción más clara, una prueba de existencia de que "esta industria puede, si quiere, describir honestamente sus supuestos de confianza reales". Que casi ningún protocolo adopte este lenguaje en su marketing es, en sí mismo, evidencia de que la deshonestidad es estructural, no accidental.
Esta es la realidad de ingeniería, y está moldeada por los incentivos que enfrentan los constructores en cada capa. Si quieres lanzar un producto complejo rápidamente, poder responder a vulnerabilidades sin bifurcar el protocolo, admitir nuevos tipos de colateral e integrarte con el resto del ecosistema, necesitas palancas operativas.
Los contratos completamente inmutables, sin acceso privilegiado, son robustos pero frágiles —cualquier cambio requiere una migración total, cualquier vulnerabilidad se vuelve permanente, cualquier nueva funcionalidad exige que los usuarios adopten una nueva implementación. Más allá de los factores técnicos, está la realidad: las agendas de los VC no permiten ciclos de verificación formal de tres años, y el protocolo que llega primero captura la liquidez.
La composibilidad amplifica el problema: un protocolo inmutable no puede integrar un nuevo oráculo, admitir una nueva cadena o parchear una vulnerabilidad descubierta sin forzar a todos los usuarios e integradores a migrar.
El resultado: para cualquier equipo individual, la elección racional es "lanzar con claves de administrador, prometer eliminarlas en el futuro"; para cualquier usuario individual, la elección racional es aceptar este trade-off porque el protocolo alternativo o no existe o no tiene liquidez. OpenFi no es un fracaso moral de constructores individuales. Es el equilibrio de Nash de este espacio.
La formulación honesta es: la DeFi casi universalmente ha elegido intercambiar una parte de la descentralización por viabilidad operativa. Esta elección es defendible. Lo que no es honesto es no nombrar el trade-off, y seguir comercializando los protocolos como "descentralizados" cuando sus modelos de seguridad reales dependen de un puñado de firmantes, un validador, o una multifirma susceptible a ingeniería social.
El camino a seguir se acerca más a la "divulgación" que a la "revolución": etiquetado obligatorio de supuestos de confianza al estilo L2Beat; delays temporales lo suficientemente largos para que los usuarios puedan salir antes de que se ejecuten operaciones privilegiadas; mercados de seguros que pongan precio al "riesgo operativo" y no a un ficticio "riesgo puro de código"; y un corte de caja honesto entre "qué partes del sistema realmente necesitan un camino de actualización" y "qué partes son simplemente mutables por hábito arquitectónico". Abril de 2026 no demostró que el OpenFi no sea viable.
Demostró que: comercializar un sistema OpenFi como DeFi, deja a sus usuarios completamente desprevenidos sobre sus modos de fallo reales. Para hacer seguros estos sistemas, el primer paso es admitir honestamente que esto es lo que estamos construyendo.
La moneda de dos caras de la centralización
El trade-off central del OpenFi se hizo visible en el evento de congelación de Arbitrum. Tres días después de la explotación de la vulnerabilidad de KelpDAO, el Consejo de Seguridad de Arbitrum votó para congelar 30,766 ETH —unos 71 millones de dólares— que el atacante ya había trasladado a Arbitrum One. La congelación se coordinó con autoridades, y por la mayoría de los estándares fue un buen resultado: los fondos robados fueron detenidos para su lavado, se cerraron los canales posteriores del atacante, y parte de las pérdidas de los usuarios quizás puedan recuperarse.
Pero nótese lo que hizo posible esta congelación: Arbitrum tiene un Consejo de Seguridad con la autoridad para "alcanzar dentro de la cadena y transferir fondos". Esta no es una característica de la infraestructura descentralizada. Es un interruptor de apagado centralizado por diseño —defendible bajo el argumento de "respuesta de emergencia", utilizado de la manera que los críticos siempre temieron— no necesariamente malo, pero ciertamente con consecuencias.
El mismo tipo de mecanismo que permitió a Arbitrum ser el "bueno" después de Kelp, es exactamente la misma forma del mecanismo que permitió el compromiso de Drift —un pequeño grupo de firmantes confiables, con poder para ejecutar operaciones a nivel de protocolo, diferenciándose solo en cuán fuertemente está restringido ese poder. Una vez, ese poder se usó legítimamente para congelar fondos robados; otra, fue secuestrado mediante ingeniería social para drenar depósitos de usuarios. Palanca, corta por ambos lados.
Los "interruptores de apagado" han fallado a través de al menos cinco canales distintos —ingeniería social (Ronin, Drift), personal interno comprometido (Multichain), coacción soberana, obligación legal (Tornado Cash, USDC) y captura de gobernanza (Beanstalk, Mango Markets). Cada uno es un ataque diferente, con defensas diferentes, y la frase "el Consejo falló" los oscurece a todos. Señalar el canal específico de fallo es el primer paso para empezar a defenderlo.
Esta es la "moneda de dos caras de la centralización" en DeFi, y lo más importante sobre el estado actual de la industria: cada palanca operativa que puede producir un "buen resultado" en una emergencia, es simultáneamente una superficie de ataque —que producirá un mal resultado en otro incidente.
El problema más profundo es: en el caso de Arbitrum, la palabra "buen resultado" carga con demasiado peso. La legitimidad es una construcción social, y palancas de la misma forma se han activado en contextos donde el consenso es mucho menos claro. El fork de The DAO de Ethereum en 2016 sigue siendo el caso clásico: la mitad de la comunidad insistió en que revertir esa vulnerabilidad de 60 millones era el uso más obvio y legítimo del consenso social; la otra mitad insistió en que era una traición fatal al "código es ley", y se bifurcó, continuando la cadena original como Ethereum Classic.
Circle y Tether congelan rutinariamente direcciones de USDC y USDT, a veces en respuesta a sanciones de la OFAC, a veces por mera sospecha, sin que los usuarios afectados tengan un canal de apelación —la congelación se enmarca como cumplimiento, pero en esencia es discrecionalidad. La congelación de Arbitrum funcionó. El fork de The DAO, en cierto sentido, también funcionó.
Las congelaciones de USDC funcionan a diario. La pregunta honesta no es "¿puede un interruptor de apagado producir un buen resultado?", sino "¿quién decide lo que cuenta como un buen resultado?" —y qué se les ha dicho a los usuarios del protocolo sobre ese proceso de decisión.
No hay ninguna versión de este trade-off que pueda "tomar solo una parte". O tienes un interruptor de apagado, y entonces tienes algo que puede ser capturado, manipulado o atacado con ingeniería social; o no lo tienes, y entonces debes aceptar que algunos eventos serán permanentes, irrevocables.
Estas palancas tampoco son intercambiables. El Consejo de Seguridad de Arbitrum puede, a través de un proceso de emergencia de bajo umbral, transferir fondos rápidamente —la combinación de "velocidad + alcance" es lo que hace posible la congelación, pero la misma combinación hace que el modo de fallo cuando el propio Consejo es comprometido sea catastrófico.
La palanca de THORChain es más estrecha: puede pausar y recapitalizar a través de la emisión de RUNE, pero no tiene autoridad para incautar o redirigir activos de usuarios. El administrador de emergencia de Aave puede congelar mercados, ajustar parámetros de riesgo, pero no puede transferir saldos de usuarios. El cierre de emergencia de MakerDAO es una salida unidireccional, no una herramienta de incautación. Las formas difieren, los trade-offs difieren, y todas se engloban bajo la misma abreviatura "interruptor de apagado". Un protocolo dispuesto a ser honesto sobre su modelo de confianza le debe a sus usuarios no una categoría, sino una forma específica.
La industria también tiende a evitar otra distinción: la diferencia entre la "palanca que se acciona solo en circunstancias extremas" y la "palanca que opera en ritmos regulares".
Bitcoin y Ethereum en principio tienen interruptores de apagado —una coordinación suficientemente grande entre nodos, mineros, validadores y exchanges podría bifurcar cualquiera de las dos cadenas mañana. La razón por la que estas cadenas todavía se consideran creíblemente de mínima confianza es que esta palanca casi nunca se ha accionado, y el costo cada vez que se acciona es una división permanente de la comunidad.
Han pasado diez años del fork de The DAO, y sigue siendo el evento más controvertido en la historia de Ethereum. Bitcoin nunca ha experimentado un fork similar.
La palanca existe, pero está creíblemente comprometida a "no usarse" en asuntos rutinarios, y es esta historia de prolongada contención la que otorga a los sistemas subyacentes una confiabilidad que ninguna característica de diseño por sí sola podría otorgar.
En contraste, el Consejo de Seguridad de Arbitrum opera en un ritmo regular. Vota periódicamente actualizaciones. Ejecutó acciones de emergencia antes de la congelación de Kelp, y ejecutará más después. No es una capacidad de reserva inactiva, sino un órgano de gobernanza activo. La crítica del OpenFi se aplica con mucha más fuerza a las "palancas activas" que a las "palancas inactivas", porque la contención de una palanca inactiva es en sí misma una señal —la confianza que ganan los operadores que tienen un umbral de uso muy alto, es una que la palanca misma no puede otorgar. Las palancas activas no tienen esa señal. Solo pueden evaluarse por sus controles, y esos controles han demostrado repetidamente ser insuficientes.
THORChain, después de sufrir vulnerabilidades en 2021, adoptó la ruta "sin palanca", y fue criticado por no tener medios de intervención. Arbitrum tomó la ruta del "interruptor de apagado" y recibió elogios. Ambas opciones son defendibles. Ninguna es gratis. La industria debe dejar de fingir que puede tener ambas —y debe decir honestamente a los usuarios cuál de estos trade-offs ha hecho cada protocolo concreto.
Un giro final: este trade-off con el tiempo solo empeora en una dirección. Una vez que un protocolo puede congelar, reguladores y tribunales están cada vez más inclinados a dictaminar que "debe" congelar. La capacidad de congelación de USDC comenzó como una herramienta de cumplimiento de emergencia; hoy es una respuesta de facto a notificaciones de la OFAC y a una lista en expansión de acciones estatales.
La decisión de "lanzar con un interruptor de apagado" es también la decisión de "heredar una lista de usos obligatorios que crecerá durante la vida útil del protocolo", muchos de los cuales no se alinearán con las direcciones que su propia comunidad apoyaría. La postura "sin palanca" de THORChain, por tanto, no es solo una elección de ingeniería, sino también una postura regulatoria —al excluir de antemano la "posibilidad de cumplir", excluye de antemano la "obligación de cumplir".
Si esta postura puede sobrevivir a la presión sostenida de las autoridades es una pregunta abierta, pero la asimetría es real: los protocolos con palanca pueden verse obligados a usarla; los que no tienen, no pueden.
Para las instituciones que observan desde fuera, esta honestidad es más importante que el marketing. Un interruptor de apagado operativo con divulgación clara, acompañado de una gobernanza documentada, gestión de claves y respuesta a incidentes —es algo que un equipo de gestión de fondos o una aseguradora podría suscribir. Un protocolo que se comercializa como de mínima confianza pero que se ejecuta sobre una multifirma 2-de-5 con timelock cero, no lo es. Lo primero es una elección de ingeniería legítima. Lo segundo es un riesgo que nadie puede poner precio.
Lo que viene después
El hábito de los ciclos de la industria es el olvido. Cada ciclo de cuatro años reinventa las instituciones que la DeFi originalmente iba a reemplazar, por lo tanto recibe golpes, recuerda brevemente por qué existían los principios, y luego vuelve a olvidar. Todo lo ocurrido en abril no es inaudito. Es el estado final predecible de una industria que intercambia conveniencia por principios, sin nombrar el trade-off.
Tres decisiones están ahora ante la industria, ninguna puede posponerse más.
Divulgación. Cada protocolo debe elegir públicamente qué palancas operativas mantiene, y explicar esa elección a sus usuarios. La versión honesta de la DeFi no es la que se autopromociona como "descentralizada" mientras se ejecuta sobre una multifirma 2-de-5 con timelock cero, sino la que divulga públicamente la composición de la multifirma, los umbrales, los timelocks y las condiciones para activar cada palanca. Nombrar el trade-off es lo que hace que el trade-off sea viable.
Seguridad. Las auditorías no son la línea fronteriza. Los protocolos que sobrevivan al próximo ciclo tratarán la seguridad operativa —claves, firmantes, puentes, configuración, respuesta a incidentes— como una disciplina de primera clase, tan importante como la revisión de Solidity. La mayoría de los equipos todavía la tratan como trabajo logístico. Esta actitud dejará de funcionar en el momento en que los asignadores de capital comiencen a hacer las preguntas que ahora hacen.
Asignación de capital. El capital que definirá el próximo ciclo está sentado en fondos de pensiones, asignadores soberanos, tesorerías corporativas y balances de aseguradoras —y está observando. No necesitan una confianza mínima pura. Necesitan un riesgo operativo que pueda ser asegurado. Los protocolos que se parezcan más a infraestructura crítica que a experimentos, absorberán este flujo de capital. Los otros protocolos seguirán con el capital minorista que siempre han tenido, viendo cómo la ola institucional pasa de largo.
Abril de 2026 no fue una crisis de seguridad. Fue el momento en que el modelo mental de la industria se rompió por completo, y el momento en que los protocolos que pueden sobrevivir comenzaron a separarse de los que no.
