Alpen Labs afirma que sus agentes de inteligencia artificial identificaron y reprodujeron en aproximadamente una hora el fallo que permitió extraer unos 3.996 BTC de Liquid, valorados en cerca de 320 millones de dólares en el momento del ataque. La demostración fue posterior al incidente y no prueba que un sistema de vigilancia permanente hubiera detectado el problema antes de que se produjera.
Un error en la caché permitió aceptar una prueba inválida
Liquid es una cadena lateral de Bitcoin en la que los L-BTC deberían estar respaldados uno a uno por bitcoins custodiados en una reserva de la federación. El 6 de septiembre de 2026, la red aceptó L-BTC que carecían de ese respaldo. Una retirada autorizada convirtió después ese estado inválido en un pago real desde la reserva de Bitcoin.
El software de Liquid, basado en Elements, almacenaba en una caché los resultados correctos de determinadas comprobaciones criptográficas asociadas a transacciones confidenciales. Un cambio de código introducido el 1 de septiembre intentó vincular cada resultado almacenado a todo el contexto relevante para la verificación, incluidos el generador del activo y el script de salida.
Según Alpen, esos campos se unieron como bytes sin codificar los límites entre ellos. Como resultado, una prueba válida utilizada como “semilla” y otra solicitud distinta, pero inválida, podían generar exactamente la misma entrada para la caché. Si la prueba válida había llenado antes la caché, una consulta posterior podía recuperar ese resultado y evitar la comprobación que debía rechazar la operación.
En la reproducción local de Alpen, la verificación desde cero rechazó el objetivo inválido. Sin embargo, el envoltorio afectado de la caché lo aceptó después de que la prueba válida hubiera preparado el registro. La compañía considera que este comportamiento reproduce el fallo de consenso sospechado en la red.
La retirada superó varios controles operativos
El incidente no terminó con la aceptación del L-BTC inválido. Según el relato de SideSwap, el atacante envió 4.000 L-BTC a su servicio de conversión el 6 de septiembre a las 14:05 UTC. SideSwap quemó los tokens un minuto después con una autorización válida, pero la orden superaba los fondos disponibles en su cartera. Dos intentos de pago fallaron antes de que los firmantes de la federación liberaran 3.996 BTC a las 14:28.
SideSwap asegura que remitió 3.995,99999857 BTC a la dirección del cliente en el mismo bloque de Bitcoin. Su clave de autorización estaba conectada, los pagos se ejecutaban automáticamente y el servicio no contaba con límites por tamaño o velocidad, controles relativos a la oferta, revisión del historial de la cartera ni aprobación humana. La federación también firmó una solicitud excepcional después de los dos intentos fallidos.
Un límite de pago aplicado antes de la autorización o de la firma podría haber interrumpido esa vía concreta, incluso después de que Liquid hubiera aceptado un estado inválido. Una clave fuera de línea habría introducido una pausa antes de la aprobación de SideSwap. Una remisión manual y diferida habría actuado más tarde y podría haber mantenido los bitcoins pagados bajo control de SideSwap, aunque la transferencia desde la reserva de la federación ya se habría producido.
La corrección llegó después del ataque
El consejero delegado de Alpen Labs, Simanta Gautam, comenzó la investigación tras conocer el ataque y publicó su explicación junto con un informe técnico el 22 de septiembre. No obstante, la compañía no tuvo acceso a los binarios exactos de los validadores en producción ni al contenido histórico de sus cachés. Su reconstrucción se apoya en el código disponible y en las pruebas observadas en la cadena, por lo que algunos detalles sobre la ruta exacta de preparación de la caché siguen siendo inferidos.
SideSwap sí ha señalado que una versión privada de seguridad instalada en su nodo en agosto aceptaba la transacción del ataque. Ese dato acota la cuestión para ese operador, pero no permite determinar qué versión utilizaba cada integrante de la federación.
El 8 de septiembre, Elements modificó las claves de la caché para codificar la longitud de los campos, añadió pruebas centradas en detectar colisiones e incorporó una opción para desactivar la caché de las pruebas de rango. La versión 23.3.4 se publicó al día siguiente. Liquid comunicó el 17 de septiembre que las transacciones ordinarias habían reanudado su funcionamiento, aunque las retiradas seguían suspendidas hasta confirmar la cobertura íntegra de los BTC, completar las actualizaciones y realizar pruebas y revisiones independientes.
El caso deja dos problemas distintos. Un validador corregido puede impedir que una transacción inválida entre en el estado de la cadena; un límite de pago independiente puede contener las pérdidas si otro fallo vuelve a superar esa barrera. La cuestión operativa pendiente es si la reapertura de las retiradas incorporará un control capaz de detener una solicitud autorizada de tamaño excepcional antes de que los bitcoins abandonen la custodia de la federación.
