La corrección aplicada por Splash cerró la vulnerabilidad que permitió vaciar su pool ADA/OADA en Cardano, pero no resolvió el problema principal para los tenedores de OADA: la salida del activo sigue sin contar con la liquidez necesaria. El ataque dejó fuera del fondo 2.424.778 ADA, antes de descontar las comisiones de red, y 1.988.222 OADA.
El ataque dejó el pool sin una salida efectiva para OADA
Según el informe de Splash, un único actor ejecutó dos transacciones el 13 de septiembre para retirar 2.434.648 ADA y 1.988.222 OADA. De esa cantidad de ADA, 9.870 correspondían al depósito realizado por el atacante. Una vez descontado ese importe, el drenaje neto se situó en 2.424.778 ADA, sin incluir las comisiones de la red.
Tras el incidente, el pool conservaba apenas 10 ADA y alrededor de 1,44 millones de OADA. El saldo de tokens de proveedor de liquidez no había cambiado, pero la reserva de ADA considerada negociable por el contrato había pasado a ser negativa.
La situación resulta especialmente relevante porque, de acuerdo con la fotografía del protocolo tomada el 13 de septiembre, OADA no disponía de un mecanismo de canje directo a nivel de protocolo. En la práctica, los tenedores dependían de la liquidez disponible en los mercados para convertir el token en ADA.
El fallo estaba en la lógica de las reservas y las comisiones
El validador del pool calculaba la reserva “negociable” después de restar las comisiones acumuladas del protocolo a los saldos reales. Splash explicó que el código no exigía que esa reserva permaneciera en terreno positivo, limitaba los cambios en las comisiones únicamente en una dirección y tampoco comprobaba la dirección de la operación de intercambio.
La combinación de esas carencias permitió aceptar una transacción incluso después de que la reserva negociable de ADA hubiera caído por debajo de cero. Splash sostiene que cualquiera de dos controles habría bloqueado la vía del ataque reconstruida por el equipo: una comprobación que impidiera reservas fuera del rango permitido o un límite de las comisiones en ambos sentidos.
El parche corrige ese recorrido concreto de la vulnerabilidad. Sin embargo, no recupera los ADA que ya salieron del contrato. Esa diferencia explica por qué la actualización del código no equivale a una restauración de la liquidez.
La reapertura exigiría liquidez y resolver el inventario de OADA
El vaciado también generó una dificultad adicional en el mercado secundario. A las 14:53 UTC del 13 de septiembre, un pool de OADA/FLDT en Minswap V2 contaba con 1.763.923 OADA frente a solo 45.751 FLDT. Splash advirtió de que esa reserva podía arbitrar cualquier nueva liquidez en ADA que se añadiera a un pool reabierto, al competir con OADA ofrecido con descuento.
Por tanto, una eventual reactivación no dependería únicamente de desplegar el código corregido. También requeriría reponer la liquidez en ADA o habilitar un mecanismo de redención, además de abordar el volumen de OADA concentrado en ese mercado secundario de poca profundidad.
Optim Finance comunicó el 13 de septiembre que su protocolo había sido pausado, que la liquidez restante se había retirado y que los intercambios entre OADA y ADA no estaban disponibles. En una actualización del 15 de septiembre, la entidad indicó que estaba indexando la cadena y elaborando un registro completo de las direcciones y activos afectados mientras trabajaba en una solución. Esa comunicación no anunció la recuperación de la liquidez, la puesta en marcha de un sistema de redención ni la reanudación de las operaciones.
