Arcus, el exchange descentralizado de perpetuos y acciones tokenizadas que opera sobre Robinhood Chain, perdió 2.234.391 USDG la noche del 9 al 10 de noviembre de 2026. Nadie robó una clave privada ni forzó un contrato inteligente: una cuenta recién creada consiguió que el sistema le reconociera un saldo mayor del que había depositado y retiró contra él. La plataforma suspendió las retiradas a las 23:07, hora del Este, y las reabrió a las 04:26 del día 10 con el fallo ya corregido.
El origen del agujero importa más que su tamaño. El dinero no salió de la cartera de otro usuario, sino de un libro contable que Arcus lleva fuera de la cadena y que autoriza pagos contra lo que ese libro declara. La tesorería de Arcus Labs cubrió el 100% del faltante, así que ningún cliente perdió saldo, aunque la empresa no ha dicho que haya recuperado un solo dólar de lo retirado. Lo que falló aquí no fue una cerradura, fue una resta.
Los otros tres millones que el atacante intentó mover después nunca llegaron a salir, frenados por los topes de retirada. Son 2,23 millones frente a los 605 que DeFi perdió en veinte días de abril de 2026, según el recuento de pérdidas de este medio.
La secuencia de una noche
El informe que Arcus publicó tras el incidente sitúa la explotación en la noche del 9 y la atribuye a una cuenta recién abierta. El atacante no necesitó acceder a la cartera de nadie: le bastó mover fondos entre dos subcuentas propias y aprovechar que el sistema, en ciertas condiciones, anotaba un saldo muy superior al transferido. Contra ese saldo inventado, las retiradas pasaron sin fricción.
Las retiradas quedaron suspendidas a las 23:07, hora del Este del 9 de noviembre, y el equipo tardó unos treinta minutos en corregir la vulnerabilidad. La reapertura llegó a las 04:26 del 10 de noviembre, después de revisar el código con socios de seguridad externos. Arcus bloqueó además las direcciones del atacante para operar, transferir y retirar, y pidió a los exchanges que marcaran los fondos que salieran de ellas, un gesto que sirve para estorbar una huida más que para devolver el dinero.
El informe descarta daños colaterales: una sola cuenta afectada, sin cambios en saldos, posiciones ni órdenes del resto de clientes. El dinero, eso sí, ya había salido del sistema cuando el equipo reaccionó.
Un saldo inflado en un libro que vive fuera de la cadena
Arcus no es un DEX al uso. La documentación técnica lo describe como un exchange construido por dYdX Labs para negociar acciones tokenizadas y perpetuos, con un motor de órdenes que casa fuera de la cadena, validadores propios que reverifican cada bloque y la custodia y la liquidación final en Robinhood Chain, una capa 2 de Ethereum.
Sobre esa arquitectura, cada cuenta se identifica por una pareja: la dirección de la cartera y un índice de subcuenta del 0 al 9. Cada índice guarda su propio colateral y sus propios límites de peticiones, y los movimientos internos entre índices de una misma cartera se firman con el propio monedero. La documentación lo dice sin rodeos: esas transferencias internas nunca se liquidan on-chain, el dinero se mueve entre índices dentro del exchange.
Ahí está la grieta. Si el movimiento interno no toca la cadena, el saldo que autoriza una retirada lo calcula el código de Arcus, y un error de cálculo se convierte en permiso de pago. El dinero que sale después sí es real: la retirada cruza el puente y se liquida contra el colateral custodiado en Robinhood Chain. El fallo estaba en la aritmética, no en las firmas.
El tope que impidió duplicar la pérdida
En el segundo intento, el sistema ya no le dejó. Un límite de retirada frenó unos tres millones de dólares adicionales y los fondos se revirtieron, de modo que la pérdida confirmada se quedó en 2,23 millones y no en 5,23. Arcus documenta sus topes: dos millones de USDG por transacción y ocho millones al día a nivel de protocolo, más los límites que impone la liquidez del puente para cada cadena de destino.
Ese tope es la diferencia entre un incidente y una quiebra operativa, y funcionó donde las auditorías no llegan. Es la clase de control que nadie presume en el blog y que decide la factura final de un mal día.
| Concepto |
Importe |
Estado |
| Retirado por el atacante |
2.234.391 USDG |
Pérdida confirmada |
| Retiradas bloqueadas |
~3.000.000 USDG |
Revertidas al sistema |
| Cubierto por la tesorería |
2.234.391 USDG |
Asumido por Arcus Labs |
| Oferta de devolución del 90% |
~2.011.000 USDG |
Pendiente hasta el 13 de noviembre |
| Recompensa ofrecida (10%) |
~223.000 USDG |
Condicionada a la devolución |
La cobertura salió de la tesorería de Arcus Labs, que asumió el faltante completo con fondos propios. Cubrir no es recuperar: el balance de la empresa queda con un agujero de 2,23 millones y el atacante conserva la liquidez salvo que acepte devolverla. Para el cliente, la diferencia entre una cosa y otra es decisiva, porque su saldo nunca se movió.
El 11 de noviembre apareció un mensaje en la cadena dirigido a la dirección del atacante. Ofrecía el trato habitual: devolver el 90% del importe, unos 2.011.000 dólares en ETH, WETH o DAI a una dirección de recuperación antes del 13 de noviembre a la 01:00 UTC, y quedarse el 10% restante, unos 223.000, como recompensa. Si el dinero volvía a tiempo, Arcus trataría el episodio como un rescate white-hat del 90%.
La letra pequeña es que el informe oficial de la compañía no menciona ese ofrecimiento, y la prensa lo atribuye a cuentas de alertas de seguridad que difundieron el mensaje. Un mensaje on-chain es una propuesta unilateral: nadie puede obligar al destinatario a aceptarla y la clasificación como white-hat la decide después la empresa. Dar el rescate por cerrado antes del plazo es leer el deseo como si fuera un hecho.
El plazo vence a la 01:00 UTC del 13 de noviembre. Hasta entonces, lo único verificable es que el mensaje existe, que las cifras cuadran con la pérdida y que el reloj corre para las dos partes.
El patrón que comparten los sustos de este año
El error de Arcus se parece menos a un asalto y más a una concatenación de descuidos. Este mes, ACryptoS perdió 665.000 dólares en 77 vaults por un fallo de validación de entrada, ofreció el mismo 10% al atacante y cerró el proyecto. En mayo, Stake DAO vio acuñar 5,4 billones de vsdCRV falsos en Arbitrum antes de que nadie pudiera frenarlo. Ninguno de los dos casos necesitó una clave privada.
El patrón tiene una explicación estructural. Los exchanges híbridos, con libro fuera de la cadena y custodia dentro, mueven la superficie de ataque del contrato a la contabilidad, y la contabilidad no se audita con la misma disciplina que el Solidity. Un saldo mal calculado no rompe ninguna firma ni dispara ninguna alerta de contrato: solo produce un número que el sistema cree y con el que paga.
Cuando la cuenta de resultados la escribe un saldo
La lección práctica cabe en una frase incómoda para el sector. Los topes de retirada, tan poco vistosos, hicieron más por limitar el daño que cualquier auditoría previa: Arcus sobrevivió al fallo porque una retirada de tres millones no cabía en el límite y porque su tesorería tenía 2,23 millones disponibles para tapar el hueco sin pedir permiso a nadie.
Queda por ver si el atacante acepta el trato antes del 13 de noviembre y si Arcus publica el desenlace con el mismo detalle con que publicó el diagnóstico. Mientras el reloj corre, el caso deja una pregunta que todo DEX con subcuentas debería responder por escrito: quién comprueba, y con qué frecuencia, que la suma de los saldos internos sigue cuadrando con lo que hay en la cadena.
