# Ankr pierde 303.000 dólares al reutilizar un depósito de Optimism

> Cinco retiradas en tres minutos vaciaron el puente de Ankr en Ethereum usando un depósito de 0,004 ankrETH ya canjeado. La bandera de pausa seguía en falso.
> Por José Maldonado · DeFi · 2026-11-10

El puente de Ankr entre Optimism y Ethereum perdió más de 303.000 dólares en cinco retiradas ejecutadas entre las 3:09 y las 3:12 de la madrugada del 9 de noviembre, hora de la costa este de Estados Unidos. El atacante no necesitó una vulnerabilidad nueva en un contrato: reutilizó un depósito legítimo de 0,0044024803 ankrETH hecho el 3 de noviembre y ya canjeado ese mismo día.

La [crónica del depósito reutilizado en Ankr](https://x.com/blockaid_/status/2119712260184527262) reconstruye el método. Cada una de las cinco solicitudes llevaba información de recibo modificada: un destinatario distinto, importes mayores y tokens diferentes de los de la transferencia original. Todas pasaron los controles del puente.

Blockaid alertó del ataque a las 08:42 UTC, unos treinta minutos después de que las retiradas se registraran. Su estimación inicial fue de 292.000 dólares; el análisis posterior de los tokens sustraídos elevó la cifra por encima de 303.000, y otras dos firmas de análisis llegaron a cifras ligeramente distintas porque asignaron precios diferentes a cada token.

De hecho, el contrato público seguía sin pausar cuando se publicaron las primeras crónicas. Cuarenta minutos después del ataque, el interruptor que detiene las retiradas continuaba en falso y nadie había explicado por qué. Ese detalle convierte una pérdida acotada en una pregunta abierta sobre la operación del servicio.

## Lo qué salió exactamente del contrato

El mayor componente fue una retirada de 82,91 ankrETH, valorada en 216.370 dólares. Le siguió otra de 515.206 tokens ankrPOL por 56.372 dólares y una tercera de 7,98 millones de ANKR por 30.857. Esas tres piezas suman los 303.600 dólares que circulan como cifra oficial del incidente.

Hubo dos activos más que no entran en la cuenta porque Etherscan no mostraba precio para ellos en el momento de la evaluación: 5.372,25 aMATICb y 0,8196 aETHb. Su valor existe, pero no está cuantificado, así que el total real es un suelo y no un techo.

Las cinco retiradas dejaron el contrato de Ethereum sin las tenencias que tenía listadas. PeckShield estimó unas pérdidas iniciales de 286.000 dólares y señaló que el atacante convirtió la mayor parte del botín en 103 ether; SlowMist, con su propio análisis, elevó la cifra a unos 304.500.

## El mecanismo que falló

Un puente de este tipo funciona con una lógica simple de explicar y difícil de asegurar. El usuario deposita tokens en la red de origen, envía la transacción a verificación y el backend de Ankr emite la autorización necesaria para liberar activos en la red de destino. El depósito es la prueba; la firma es la llave. El mapa de [puentes para mover tokens entre blockchains](https://observatorioblockchain.com/blockchain/principales-puentes-para-mover-tokens-entre-blockchains-en-defi/) ayuda a situar el riesgo, y el [hackeo de Tendril CoreVault](https://observatorioblockchain.com/defi/tendril-corevault-exploit-seguro-defi/) mostró la misma dependencia de una autorización central.

El problema es la separación entre ambas cosas. Una firma válida demuestra quién autorizó una transacción, no que el depósito que la respalda siga siendo canjeable. Si el sistema que valida el recibo confía en la firma y no vuelve a comprobar el estado del depósito, un recibo modificado con firma legítima pasa sin que nadie lo note.

Ese es el punto donde las explicaciones divergen. [La hipótesis de un desarrollador](https://defi-planet.com/2026/11/ankr-ethereum-bridge-faces-ongoing-303k-exploit/) apunta a una posible compromiso de la clave de administrador: el puente habría validado las cinco retiradas con su propia llave. SlowMist sostiene que el origen de las firmas sigue bajo investigación y no confirma que las claves del firmante estén comprometidas.

Un detalle apunta en esa dirección sin probarla. La cartera administrativa asociada se habría vaciado varias horas antes del ataque, lo que encaja con un acceso previo al entorno de firma más que con una manipulación del contrato en sí.

## Lo que Ankr no ha dicho

La empresa no había publicado un comunicado con la causa, el alcance ni un plan de recuperación en el momento de escribirse estas líneas, y no respondió a las preguntas sobre servicios afectados o posibles reembolsos. Tampoco hay confirmación de que el incidente haya alcanzado su infraestructura RPC o las carteras personales de los usuarios.

La bandera de pausa merece un párrafo aparte. Cuarenta minutos después de las retiradas, el historial del puente no mostraba actividad nueva, pero el interruptor público que detiene las retiradas seguía en falso. Blockaid describió el exploit como en curso en su alerta, y ninguna de las fuentes posteriores aclara si Ankr tomó medidas adicionales.

Ese silencio convierte una pérdida de 300.000 dólares en una pregunta más grande sobre la operación del servicio. Un puente que no se pausa en la primera media hora deja abierta la posibilidad de una segunda ronda, y la única protección que tenía el contrato en ese momento era que ya estaba vacío.

## Los puentes, siempre son los puentes

El incidente no es una historia sobre un contrato mal escrito. Es una historia sobre verificación de estado: el sistema aceptó cinco veces la misma prueba porque nadie volvió a preguntar si seguía siendo válida. Cualquier diseño que autorice retiradas a partir de un recibo debería revalidarlo contra el depósito original en cada intento.

Para el usuario, la lección es la de siempre y no por repetida menos cierta. Los puentes concentran riesgo porque mantienen fondos bloqueados en un contrato que otras personas administran, y la cifra de pérdidas de los últimos años se explica por esa concentración, no por la calidad del código de cada proyecto.

Esa diferencia importa a la hora de elegir dónde dejar un activo. Un contrato auditado protege de errores de programación; un proceso de autorización mal diseñado no se ve en una auditoría de código y solo aparece cuando alguien lo prueba con una transacción ya canjeada. El segundo tipo de fallo es el que no deja rastro hasta que el saldo desaparece.

Para Ankr, el problema inmediato es de confianza. El token había perdido valor antes del incidente y el proyecto arrastra una historia de incidentes en su infraestructura; una respuesta lenta en el momento en que se descubre el fallo pesa más que cualquier nota técnica publicada una semana después.

## Tres punto grises

Con todo, aún faltan tres cosas concretas. La primera es si el contrato se pausó en algún momento y cuándo. La segunda es si las claves del firmante estuvieron comprometidas o el fallo estaba en la validación del recibo. La tercera es si habrá reembolso para los usuarios que tenían activos en el puente.

Mientras no haya respuesta, la lectura prudente es que el atacante encontró una puerta en el proceso de autorización y no en la cadena. Eso es peor noticia de lo que parece: un fallo de contrato se parchea y se audita, mientras que un proceso de firma mal diseñado sigue aceptando pruebas caducadas hasta que alguien lo reescribe.