Cómo un fallo en Notional V1 hizo que una deuda de 2^128 pareciera cero

El incidente reportado en Notional Finance no habría sido una falta convencional de garantías. La debilidad señalada fue un desajuste contable: se creó una deuda fCash enorme en el límite de 2^128 y, al reducirse a uint128 durante el cálculo del colateral libre, pasó a contabilizarse como cero. Con el pasivo omitido justo en ese control, la cuenta podía aparentar solvencia y retirar activos a los que no debería haber tenido acceso. 416

La reconstrucción pública procede de monitoreo on-chain y de reportes de investigadores de seguridad, no de un informe técnico oficial del protocolo. Esa diferencia es importante: los movimientos de fondos son observables en Ethereum, pero la secuencia definitiva de llamadas, el impacto total y el estado de las medidas correctivas no estaban confirmados en la información disponible entonces. 34

El fallo contable: una deuda que se evaluó como cero

Notional V1 representaba obligaciones de pago futuras mediante fCash. Según la alerta pública de CertiK, el atacante usó dos llamadas a mintfCashPair() para crear un pasivo de -2^128. Durante la valoración del colateral libre, una conversión insegura a uint128 habría truncado ese valor a 0. 16

En términos prácticos, la ruta descrita por los investigadores fue la siguiente:

1. Crear una posición fCash negativa extrema. El atacante generó un pasivo exactamente en un tamaño en el que una reducción a un entero sin signo de 128 bits podía eliminar la representación de la deuda. 416
2. Activar la valoración del colateral. La contabilidad del escrow habría convertido el pasivo mediante un downcast inseguro a uint128.
3. Hacer desaparecer la deuda en la comprobación. En vez de reflejar una obligación negativa enorme, el cálculo trató el valor como cero. 46
4. Superar el control de retiro. Al quedar excluida la deuda del cálculo de colateral libre, la cuenta podía parecer apta para retirar las stablecoins líquidas del escrow. 46

Por ello, el problema se entiende mejor como un fallo de conversión reductora y de invariantes contables que como un simple “desbordamiento de enteros”. El efecto crítico reportado es que un pasivo negativo se convirtió en cero dentro de la ruta de valoración que debía impedir un retiro sin garantías suficientes. 416

Qué fondos habrían sido retirados

Los reportes on-chain situaron la pérdida en aproximadamente 69.257 DAI y 1.650.824 USDC, equivalentes a unos USD 1,728 millones. Posteriormente, los activos habrían sido intercambiados por alrededor de 689,2 ETH y depositados en Tornado Cash. 215

El contrato identificado en los reportes fue el escrow de Notional Finance: 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683. Una publicación señaló una transacción de preparación desde una dirección terminada en Ce38 a las 23:58:47 UTC del 3 de septiembre de 2026, seguida unos tres minutos después por la transacción de vaciado, ya el 4 de septiembre. 1723

Los investigadores asociaron públicamente dos direcciones de Ethereum con los movimientos:

• 0xC954…De69
• 0xDaCC…Ce38

Estas etiquetas describen una asociación investigativa basada en la cadena, no la identificación de una persona, organización o controlador final. 11

Por qué la ruta a ETH dificultó una eventual recuperación

La conversión reportada de DAI y USDC a ETH modificó el escenario de rastreo. Las transferencias iniciales de stablecoins eran claramente visibles en Ethereum; después, el intercambio distribuyó el valor en ETH. Los depósitos posteriores en Tornado Cash añadieron una capa de privacidad diseñada para ofuscar el origen, el destino y las contrapartes de las transacciones. 229

Esto no vuelve imposible el análisis de blockchain ni demuestra quién controló un eventual retiro posterior. Sí hace mucho menos directa la trazabilidad, activo por activo, entre el escrow explotado y un destinatario posterior una vez que los fondos entran en un mezclador. 29

Lo que seguía sin confirmarse

En el momento de los reportes, Notional no había publicado una respuesta oficial al incidente. Por ello, permanecían abiertas cuestiones relevantes:

• la causa técnica definitiva y el flujo completo de llamadas del exploit;
• si las transacciones reportadas representaban todos los contratos, cuentas y activos afectados;
• la pérdida final, tras intercambios, comisiones y transferencias posteriores;
• las opciones disponibles para pausar, actualizar, compensar o recuperar fondos; y
• la identidad del atacante y si las direcciones etiquetadas eran las únicas billeteras bajo control común. 3411

La causa reportada debe tratarse, por tanto, como una reconstrucción preliminar sólida, pero no como sustituto de una auditoría post mortem o de un informe oficial del protocolo.

La lección de seguridad para DeFi heredado

Un contrato heredado no deja de ser riesgoso solo por ser antiguo o por haber perdido relevancia dentro de la hoja de ruta de un producto. Si todavía custodia activos o conserva acceso a funciones de acuñación, liquidación, cálculo de garantías o retiro, sigue siendo una superficie de ataque financiera activa.

Para los equipos de protocolo, el caso reportado de Notional V1 destaca varios controles que conviene validar de forma conjunta:

• usar conversiones reductoras verificadas y rechazar explícitamente valores que no puedan representarse de forma segura;
• probar cálculos de deuda con signo, liquidación y colateral en límites numéricos como 2^128;
• expresar las reglas de solvencia y conservación como invariantes, y probarlas en secuencias de múltiples llamadas;
• revisar si rutas privilegiadas o poco habituales pueden combinar acuñación, liquidación y retiros en un orden no previsto; y
• restringir llamadores y flujos de ejecución cuando una función sea insegura fuera de su contexto previsto.

El patrón de fondo es conocido en DeFi: un defecto pequeño en la representación de datos o en la autorización puede convertirse en una pérdida total si alcanza una ruta de retiro con activos líquidos. La defensa no consiste únicamente en auditar funciones aisladas, sino en demostrar que los invariantes contables del sistema se mantienen en toda secuencia de llamadas alcanzable.