Exploit de contabilidad de subcuentas en Arcus Perps

El 10 de noviembre de 2026, Arcus, un exchange de perpetuos y tokens de acciones en Robinhood Chain, perdió aproximadamente 2,2 millones de dólares cuando un atacante explotó un error contable en las transferencias entre las subcuentas de una misma cuenta, inflando su saldo para retirar fondos que nunca depositó.

Qué ocurrió

El fallo residía en cómo Arcus registraba las transferencias entre las subcuentas de un mismo usuario. Tras una transferencia interna entre subcuentas, el exchange acreditaba a la cuenta un saldo muy superior a sus tenencias reales; una cuenta recién creada envió entonces retiros contra esa cifra inflada y extrajo 2.234.391 USDG on-chain. Arcus describió la causa raíz como un error de su propia contabilidad —no un fallo de la blockchain ni una clave robada—, aunque no publicó código ni un informe técnico post-mortem completo. El exploit comenzó alrededor de las 03:07 UTC del 10 de noviembre (a última hora del 9 de noviembre, hora del Este de EE. UU.), y otros 3 millones de dólares aproximadamente en solicitudes de retiro fueron retenidos por el límite de tasa on-chain del puente y nunca se pagaron. La firma de seguridad 0xCERT catalogó el incidente como el aviso 0xCERT-2026-0338. Rastreadores on-chain informaron de que la dirección del atacante recibió unos 1.052 ETH en Ethereum, enrutados en gran parte a través de un router de Relay, con unos 53 ETH enviados luego a THORChain.

Consecuencias

Arcus pausó los retiros en toda la plataforma a las 04:07 UTC, desplegó una corrección hacia las 04:37 UTC, bloqueó las direcciones del atacante a las 04:43 UTC y reactivó los retiros para todos los usuarios hacia las 09:26 UTC; los retiros pendientes del atacante se revirtieron a las 10:02 UTC. Para las 17:28 UTC, Arcus Labs había cubierto todo el déficit con su propia tesorería corporativa —una decisión voluntaria sin seguro de depósitos detrás—, dejando indemnes a los usuarios afectados, aunque los fondos robados en sí no se recuperaron. Arcus publicó la dirección inicial del atacante, 0xeFbf442599310E5CeE1A4EDd5c66334c5f30b3Dd, para que exchanges y proveedores de servicios pudieran marcar los activos relacionados, y afirmó que ningún otro saldo, posición u orden de usuario se vio afectado.

Por qué importa

Arcus recuerda que el libro mayor interno de una plataforma es una superficie de ataque tanto como sus contratos inteligentes. El exploit no tocó ninguna vulnerabilidad on-chain ni robó ninguna clave; simplemente alimentó la contabilidad off-chain del exchange con una transferencia mal procesada, permitiendo que una cuenta se acreditara a sí misma un valor que nunca tuvo —funcionalmente el mismo drenaje que el fallo on-chain de acuñación de participaciones que vació ACryptoS días antes, alcanzado por otra vía—. También muestra la naturaleza de doble filo de un operador bien financiado y semicentralizado: los límites de tasa on-chain acotaron el daño y una tesorería corporativa dejó indemnes a los usuarios, un resultado que la mayoría de los protocolos DeFi sin fondos no pueden ofrecer, pero la ausencia de un post-mortem publicado deja sin verificar el componente defectuoso exacto. Para un exchange de perpetuos como Drift Protocol, la confianza del usuario descansa tanto en la integridad de la contabilidad interna como en la custodia de claves.