Cómo seis fallos convirtieron un bug de outbounds de MAYAChain en un drenaje de pool

⏱️ 6 minutos de lectura

Un protocolo no necesita un único bug catastrófico para perder fondos. El incidente reportado de MAYAChain muestra cómo seis supuestos inseguros se pueden encadenar: el estado de una transacción puede sobrescribirse, un outbound puede asociarse a una altura equivocada, un subsidio puede valorarse sin límite, y una operación fallida puede dejar su contabilidad detrás.

Un voter sobrescrito cambia el significado de una transacción

Según el postmortem, el atacante envió un único MsgDeposit con 23 mensajes y terminó con DONATE:ARB.LINK. Cada mensaje almacenó un ObservedTxVoter bajo el mismo identificador de transacción. El último mensaje sobrescribió los voters asociados con retiros anteriores, dejó OutboundHeight en cero y marcó la transacción como terminada.

Un voter es estado para seguir una transacción observada y su ciclo de procesamiento. Si una operación posterior puede reemplazar ese estado sin preservar la información previa, se pierde la identidad económica de los mensajes anteriores. Esa fue la primera condición de la cadena.

El matching buscó en alturas equivocadas

Con la altura outbound perdida, la lógica de matching recurrió a FinalisedHeight y avanzó según el período de firma. El recorrido no comprobó la altura real en la que se registraron los outbounds de LINK. El protocolo los clasificó falsamente como ausentes y activó el manejo de robo.

En sistemas cross-chain, la altura de bloque no es un detalle decorativo. Puede formar parte de la identidad usada para conciliar una instrucción, un conjunto de firmas y una transferencia completada. Un fallback debe demostrar que alcanza el evento esperado, no solo recorrer alturas en una cadencia.

Un subsidio sin límite infló un pool

El manejo de robo calculó un subsidio usando el monto bruto reclamado sin limitarlo por el saldo del activo del pool ARB.LINK, que tenía liquidez de activo muy baja. El postmortem reportó que el cálculo registró aproximadamente 49,45 millones de CACAO en el pool.

El siguiente problema fue el orden de las escrituras. El estado inflado del pool se guardó antes de que el protocolo intentara financiarlo desde Reserve hacia Asgard. Reserve no podía cubrir ese monto. La transferencia falló, pero el estado ya había quedado guardado.

Un error registrado no es un rollback

El handler de outbounds registró el error, marcó el voter como terminado y continuó sin revertir el contexto. El resultado fue un pool con un saldo de CACAO inflado que no tenía respaldo equivalente.

La persistencia parcial es especialmente peligrosa en protocolos financieros. Cada operación que ajusta saldo debe conservar una invariante clara: o todas sus actualizaciones ocurren y se financian, o ninguna se confirma. Registrar una falla no restaura automáticamente un estado anterior.

Liquidez mínima capturó casi toda la propiedad

Con el pool inflado y casi sin activo, el atacante añadió liquidez mínima. La matemática de unidades lo trató de forma parecida a un pool nuevo, otorgándole cerca de 99,93% de sus unidades. Después retiró 9900 puntos base y liberó 48,87 millones de CACAO, según el postmortem.

El CACAO fue intercambiado por activos externos. El reporte distingue aproximadamente $1,36 millones de extracción directa hacia L1 de una caída más amplia del valor de los pools. Esa diferencia importa: el arbitraje de terceros y la devaluación de CACAO también afectaron los saldos, pero no son equivalentes a retiros directos del atacante.

Qué debe probar una auditoría

1. Probar transacciones por lotes que reutilicen identificadores y validar que el estado no se sobrescriba de forma incompatible.
2. Diseñar matching de outbounds con comprobaciones explícitas de altura, identidad y límites de búsqueda.
3. Limitar toda valoración, subsidio, slash o compensación por el activo realmente disponible.
4. Ejecutar actualizaciones de pool y transferencias de fondos de forma atómica, con rollback ante fallos.
5. Tratar los errores en handlers financieros como condiciones que detienen la transición, no como eventos para registrar y continuar.
6. Simular pools con liquidez extrema o casi vacía para verificar que las unidades no permitan captura desproporcionada.

La lección no es que una auditoría sea inútil. Es que las revisiones necesitan buscar cómo los componentes correctos en aislamiento pueden fallar juntos. Los equipos cross-chain deben probar rutas de error, estado parcial, economía de pool y secuencias de mensajes adversariales como parte del mismo sistema.

Fuentes

1. MAYAChain Inspector, postmortem técnico.
2. Decrypt, “Six-Bug Exploit Halts Maya Protocol After $1.4 Million in Bitcoin Stolen”.
3. Cointelegraph, “MAYAChain halts network after estimated $1.7M exploit”.