El caso Allbridge Core: cómo se produjo el robo y por qué apareció una ventana de arbitraje

En este artículo vamos a analizar en detalle lo ocurrido en Allbridge Core, uno de los protocolos en los que llevo invirtiendo desde hace tiempo y que, personalmente, siempre me había funcionado muy bien.

Por desgracia, este tipo de incidentes son difíciles de anticipar para un inversor. Podemos estudiar el protocolo, revisar su funcionamiento, analizar su liquidez y entender sus riesgos, pero siempre existe una parte que queda fuera de nuestro control: la seguridad del código.

Ese es, precisamente, uno de los puntos débiles de DeFi. Aunque los protocolos son cada vez más sólidos, están mejor auditados y cuentan con mayores medidas de protección, un pequeño error en el diseño o en la lógica de un contrato inteligente puede tener consecuencias muy graves.

En este caso, el atacante consiguió aprovechar un fallo en la lógica interna de los pools de Allbridge para extraer aproximadamente 1,66 millones de dólares.

Por suerte, los pools afectados ofrecían una rentabilidad bastante baja y, probablemente —o al menos eso espero—, no eran los más utilizados por los inversores de nuestra comunidad. Aun así, cualquier usuario que tuviera liquidez depositada en ellos podía verse afectado.

Este tipo de situaciones deben servirnos como recordatorio de algo fundamental: antes de invertir nuestro capital, debemos estudiar a fondo los protocolos en los que depositamos nuestra confianza, entender de dónde sale la rentabilidad, conocer sus riesgos y evitar concentrar todo nuestro capital en una única plataforma.

También es importante entender que ningún protocolo es completamente seguro. Las auditorías, el historial y la reputación reducen el riesgo, pero nunca lo eliminan por completo.

A continuación explicamos cómo funciona realmente Allbridge Core, qué papel tienen los proveedores de liquidez y los usuarios del bridge, qué significa el imbalance y cómo el atacante consiguió manipular el sistema para hacerse con el botín.

Los dos grandes actores de Allbridge

Para entender el ataque, primero hay que diferenciar los dos tipos de usuarios de Allbridge.

Usuarios del bridge

‍Son quienes utilizan Allbridge para mover stablecoins entre blockchains. Por ejemplo: envían USDC desde Polygon y reciben USDT en Celo. Estos usuarios no están invirtiendo en un pool. Simplemente utilizan la liquidez disponible para trasladar valor de una red a otra.

Proveedores de liquidez (LP)

‍Son quienes depositan stablecoins en los diferentes pools de Allbridge (USDC en Polygon, USDT en Celo, USDC en Optimism, USDC o USDT en Solana). A cambio reciben LP Points, que representan su participación en el pool. Su rendimiento procede principalmente de las comisiones que generan los usuarios del bridge. Cuanto mayor sea el volumen de operaciones, mayores pueden ser las comisiones distribuidas entre los proveedores de liquidez. En este incidente, fueron precisamente los LP de los pools de Solana quienes sufrieron la pérdida.

Cómo funciona Allbridge internamente

Cada stablecoin tiene su propio pool: un pool de USDC, un pool de USDT, etc. Cada uno contiene dos elementos: la stablecoin real depositada y un saldo virtual denominado vUSD. El vUSD funciona como una unidad interna de contabilidad que permite conectar el valor entre los distintos pools.

En una operación normal de USDC a USDT ocurre lo siguiente:

1. El usuario entrega USDC al pool de USDC.
2. Ese pool libera una cantidad equivalente de vUSD.
3. El vUSD se utiliza contra el pool de USDT.
4. El pool de USDT entrega USDT al usuario.

Cuando el pool de entrada y el de salida son diferentes, la operación conserva correctamente el valor.

Qué significa el imbalance

El imbalance mide la relación entre la stablecoin real de un pool y su saldo virtual en vUSD. No indica únicamente cuánto dinero hay depositado, sino si el saldo real y el saldo virtual están equilibrados.

Imbalance positivo

‍Significa que el pool tiene más stablecoin real de la que le correspondería frente a su vUSD. Dicho de forma sencilla: el pool está sobrado de liquidez real.

Imbalance negativo

‍Significa que el pool tiene menos stablecoin real de la que debería frente a su vUSD. Dicho de forma sencilla: el pool tiene un déficit de liquidez real.

El protocolo modifica los tipos de cambio para incentivar operaciones que ayuden a corregir estos desequilibrios.

La vulnerabilidad que permitió el ataque

El atacante no se limitó a encontrar una ruta de arbitraje ya existente. Lo que hizo fue manipular artificialmente la contabilidad interna del pool de USDT en Solana, creando un imbalance extremo y un precio completamente alejado de la realidad. La vulnerabilidad surgió por la combinación de dos fallos.

Allbridge permitía swaps del mismo activo. El protocolo permitía hacer una operación como USDT → USDT. Aunque económicamente no tiene demasiado sentido, técnicamente el contrato la procesaba como cualquier otro intercambio. El problema era que tanto la entrada como la salida apuntaban al mismo pool de USDT. Las dos mitades de la operación actualizaban el estado interno del mismo pool, pero no lo hacían de forma perfectamente consistente. Al repetir la operación varias veces, el atacante consiguió que se separaran progresivamente el saldo real de USDT, el saldo virtual en vUSD y el precio interno calculado por el protocolo.

La protección contra imbalances era demasiado permisiva

‍Allbridge disponía de mecanismos para limitar estados extremos de desequilibrio, pero estaban configurados de forma demasiado flexible. Eso permitió que el pool continuara operando incluso cuando su precio interno ya se había desviado enormemente de sus reservas reales.

Los dos problemas eran necesarios: los swaps del mismo activo permitían distorsionar la contabilidad, y la protección insuficiente permitía llevar esa distorsión hasta un nivel explotable.

Cómo se produjo el robo, paso a paso

Todo el ataque ocurrió dentro de una sola transacción atómica.

Paso 1 · Préstamo flash

‍El atacante pidió prestados aproximadamente 1,12 millones de USDC mediante un flash loan. Un flash loan permite pedir prestado dinero sin aportar garantías, siempre que el préstamo se devuelva antes de que termine la misma transacción. Esto significa que el atacante prácticamente no necesitó capital propio.

Paso 2 · Intercambio inicial de USDC por USDT

‍Utilizó los 1,12 millones de USDC para comprar aproximadamente 949.000 USDT dentro de Allbridge. Esta operación le proporcionó una gran cantidad de USDT con la que manipular el pool.

Paso 3 · Swaps repetidos de USDT por USDT

‍Después realizó cinco intercambios consecutivos del mismo activo (USDT → USDT), de aproximadamente 100.000 USDT cada uno. En cada vuelta recibía progresivamente menos USDT, pero ese no era el objetivo principal. Lo importante era que cada swap alteraba de forma inconsistente la relación entre los USDT reales, el saldo virtual en vUSD y el precio interno del pool. Con cada repetición, el imbalance se hacía más extremo y el valor registrado por el protocolo se alejaba más de la realidad.

Paso 4 · Extracción de USDC

‍Cuando el pool de USDT ya estaba completamente distorsionado, el atacante realizó un último intercambio. Entregó menos de 4.000 USDT y el protocolo calculó que debía entregarle aproximadamente 2,24 millones de USDC. El pool de USDC no había sido manipulado directamente. Simplemente pagó contra una cantidad de vUSD que el pool de USDT manipulado había emitido en exceso. En otras palabras: el atacante convirtió menos de 4.000 USDT en un derecho virtual a retirar 2,24 millones de USDC.

Paso 5 · Devolución del flash loan

‍Después devolvió los 1,12 millones de USDC prestados más la pequeña comisión del flash loan, que fue de alrededor de 11 dólares. Tras devolver el préstamo, el atacante conservó aproximadamente 1.118.239 USDC y 538.692 USDT. En total, cerca de 1,66 millones de dólares.

¿Manipuló el imbalance para obtener un cambio absurdo?

Sí. Pero la formulación más precisa es que manipuló la relación entre los USDT reales y el vUSD del pool. El imbalance extremo fue el resultado visible de esa manipulación.

El atacante consiguió que el protocolo creyera que el pool de USDT había generado mucho más valor virtual del que realmente existía. Después utilizó ese vUSD inflado para retirar USDC reales del otro pool. Por tanto, no fue simplemente "vio un imbalance y aprovechó una oportunidad", sino "creó artificialmente un imbalance extremo, manipuló el precio interno y utilizó esa valoración falsa para extraer fondos".

Por qué aparecieron oportunidades de arbitraje después

Tras el ataque, varios pools quedaron profundamente desequilibrados. En condiciones normales, Allbridge ajusta los tipos de cambio para ayudar a reequilibrar la liquidez: incentiva que entren fondos en pools deficitarios, incentiva que salgan fondos de pools con exceso y ofrece mejores o peores cotizaciones según la ruta utilizada.

Por ejemplo, si un usuario hace Polygon → Celo, deposita USDC en el pool de Polygon y recibe USDT procedentes del pool de Celo. Aunque desde la perspectiva del usuario está "llevando fondos a Celo", desde la perspectiva de los pools está añadiendo liquidez a Polygon y sacando liquidez de Celo. Si Celo tiene un imbalance muy positivo y Polygon uno negativo, esta operación ayuda a equilibrar ambos lados. Por eso pueden aparecer tipos de cambio favorables.

El ejemplo de Polygon a Celo

Después del incidente se llegó a ver una cotización como esta: enviar 50 USDC desde Polygon y recibir aproximadamente 93,49 USDT en Celo. Esto supone recibir casi el doble de stablecoins.

No era una rentabilidad normal ni una promoción del protocolo. Era el resultado de un sistema extremadamente desequilibrado que estaba intentando corregir sus pools mediante precios muy agresivos. Esa es la ventana temporal de arbitraje positivo mencionada por Allbridge.

Diferencia entre el atacante y los arbitrajistas posteriores

Es importante no confundir ambos grupos.

El atacante:

• Tomó un flash loan.
• Manipuló el pool de USDT en Solana.
• Creó un imbalance artificial.
• Generó vUSD sobrevalorado.
• Extrajo USDC y USDT reales.

Los arbitrajistas posteriores:

• No necesariamente explotaron la vulnerabilidad original.
• Encontraron pools ya desequilibrados.
• Utilizaron rutas que ofrecían cambios extraordinariamente favorables.
• Extrajeron valor adicional del sistema.

Por eso Allbridge pidió a quienes aprovecharon esas rutas que consideraran devolver los beneficios obtenidos. Ese dinero salía, en última instancia, de la liquidez aportada por los LP.

Quién sufrió la pérdida

Los fondos robados pertenecían a los proveedores de liquidez de los pools de USDC en Solana y USDT en Solana. No se comprometieron las wallets personales, las frases semilla, las claves privadas, los fondos que los usuarios mantenían fuera del protocolo ni las rutas del bridge que no dependían de pools de liquidez. El fallo estaba limitado a la funcionalidad de intercambio de los pools de Solana.

Qué hizo Allbridge después

El equipo fue alertado unos 25 minutos después de la transacción. Posteriormente:

• Suspendió las operaciones entre cadenas.
• Deshabilitó los swaps basados en pools.
• Restauró las rutas que no acceden a pools de liquidez.
• Mantuvo disponible la interfaz para que los LP pudieran retirar.
• Recomendó retirar la liquidez porque esos pools ya no generaban rendimiento.
• Anunció que eliminaría gradualmente los swaps basados en pools.

Allbridge ha decidido centrarse en rutas que no dependan de este tipo de liquidez compartida.

Dónde están los fondos robados

Allbridge y sus colaboradores forenses han rastreado aproximadamente 1,63 millones de dólares. Una parte de los fondos fue movida hacia Ethereum y posteriormente distribuida por distintas rutas:

• Aproximadamente 1 millón de dólares fue convertido a ZEC y enviado al pool privado Orchard de Zcash.
• Cerca de 313.000 dólares permanecían en ETH en una dirección de Ethereum vigilada.
• Aproximadamente 307.000 dólares permanecían en DAI en esa misma dirección.

Railgun bloqueó un intento de mover unos 307.000 DAI y devolvió los fondos a la dirección de consolidación.

Conclusión

El ataque a Allbridge Core no fue un simple arbitraje ni el robo de claves privadas. Fue una manipulación de la contabilidad interna de los pools. El atacante aprovechó que el protocolo permitía swaps del mismo activo y que las protecciones contra imbalances extremos eran demasiado permisivas.

Mediante varios swaps USDT → USDT consiguió inflar artificialmente el vUSD del pool de USDT. Después utilizó ese valor virtual falso para retirar 2,24 millones de USDC reales entregando menos de 4.000 USDT.

Después del robo, los pools quedaron muy descompensados y el sistema ofreció cotizaciones extraordinariamente favorables en determinadas rutas. Eso creó una segunda ventana de arbitraje que permitió a otros usuarios extraer todavía más valor del protocolo.

Los grandes perjudicados fueron los proveedores de liquidez, porque el dinero robado y los beneficios de arbitraje posteriores procedían, en última instancia, del capital que tenían depositado en los pools.

Llevamos desde 2017 en la trinchera, y casos como este confirman lo de siempre: en DeFi no basta con mirar la rentabilidad. Hay que entender de dónde sale, quién asume el riesgo y qué pasa cuando el código falla.

‍