La IA como 'villano': Las aseguradoras DeFi necesitan una prueba de estrés

Realizando pruebas de choque en las bóvedas DeFi: Firelight planea usar IA para encontrar "el próximo accidente".

Escrito por: @jrdothoughts

Compilado por: AididiaoJP, Foresight News

La ceguera de las aseguradoras DeFi: No haber fallado no significa estar a salvo

Escuchemos una venta de humor negro: "Nuestro nuevo avión es absolutamente seguro, nunca se ha estrellado."

"¿Cuánto ha volado?"

"... Tal vez dos veces."

Cambiando el avión por una bóveda DeFi, la historia se vuelve familiar: seis meses de retiros sin problemas, sin ataques, y buenos rendimientos. Esto, por supuesto, es evidencia. Pero durante esos seis meses, ¿se ha enfrentado a congestión de la red, colaterales desanclados, retiradas masivas de proveedores de liquidez (LP), o oráculos que no actualizan? Es muy probable que no.

Un historial limpio solo indica lo que un sistema ha soportado. La aseguradora debe preguntar: ¿qué podría enfrentar a continuación?

Esta es la oportunidad que Firelight ha visto: establecer precios en función de cómo se forman las pérdidas, no solo si han ocurrido. La historia se encarga de anclar, la simulación explora escenarios alternativos, la IA busca debilidades, y el capital respalda.

La historia es una instantánea, pero los sistemas cambian

Los datos históricos de pérdidas son una instantánea de una máquina funcionando bajo ciertas condiciones. Cuando la máquina cambia, la instantánea necesita ser revisada.

Una bóveda que añade un nuevo tipo de colateral, cambia de oráculo y aumenta el apalancamiento. El nombre no ha cambiado, el logo no ha cambiado, pero el riesgo es muy diferente. Los prestatarios, liquidadores y LP dentro no son números estáticos en una tabla. Ellos reaccionarán a los incentivos y, si algo sale mal, todos querrán salir por la misma puerta.

Es como un mapa del tráfico dibujado según la situación habitual de un martes. Normalmente parece bastante preciso, pero si se cierra el puente principal, deja de ser útil. El mapa en sí no está mal, es la situación en la carretera la que ha cambiado.

Por lo tanto, para Firelight, la verdadera pregunta no es solo "¿ha sido hackeado este protocolo?", sino: ¿qué permisos existen? ¿Cuáles dependencias son realmente importantes? Cuando todos intentan salir al mismo tiempo, ¿qué caminos de liquidación aún están disponibles? El marco que Firelight ha hecho público ya separa las vulnerabilidades técnicas de las debilidades económicas, en lugar de fusionarlas en una única puntuación de seguridad.

La aseguradora se centra en la construcción actual del sistema y sus relaciones de dependencia, no en la marca que ha perdurado hasta hoy.

Los seguros de catástrofe ya han escrito el guion

Las compañías de seguros tradicionales no han abandonado la modelización de la incertidumbre. Los aseguradores de catástrofes han estado haciendo una cosa: simular cómo ocurren los desastres, qué activos estarán expuestos, cuán frágil es la estructura, y cuánto se pagará al final del contrato. Los huracanes que han pasado no representan todos los huracanes que podrían aparecer en el futuro.

DeFi también necesita su propio modelo de catástrofe. Solo que el desastre cambia de huracanes a fallos de oráculos, los objetos de desastre pasan de edificios a posiciones de préstamos, y la vulnerabilidad cambia de calidad de construcción a amortiguación de colaterales y diseño de liquidación, para finalmente calcular las indemnizaciones según los términos de cobertura.

El modelo de catástrofe pregunta: ¿qué pasaría si un huracán barre una ciudad? El modelo DeFi pregunta: ¿qué pasaría si un fallo se propaga a lo largo del gráfico de dependencias?

Firelight ha discutido públicamente cómo descomponer riesgos, calibrar históricamente, combinar simulaciones de Monte Carlo, modelos de lenguaje y aprendizaje por refuerzo, integrándolos en un laboratorio de pruebas de choque financiero. Es importante señalar que esta es una dirección propuesta, no una afirmación de que cada componente ya esté en funcionamiento.

También es necesario aclarar que Firelight define su producto como una cobertura basada en protocolos, no como un contrato de seguro tradicional. Las comparaciones con seguros se refieren a la disciplina de aseguramiento, no a la calificación legal del producto.

Cómo construir un laboratorio de pruebas de choque financiero

El primer paso es fijar el estado inicial, asegurando que se pueda reproducir. La versión del contrato, los saldos, las posiciones colaterales, así como la configuración del oráculo, las reglas de liquidación y la liquidez del mercado, deben estar bloqueadas. De lo contrario, si los resultados de dos simulaciones no coinciden, puede ser simplemente porque el punto de partida es diferente, y no se está midiendo el mismo sistema.

El segundo paso es separar la ejecución de las suposiciones. Las bifurcaciones de blockchain pueden ejecutar la lógica de contratos reales, pero no pueden generar de la nada la liquidez de mañana, los precios fuera de la cadena y el comportamiento humano. Estos deben ser modelados explícitamente. Las pruebas basadas en bifurcaciones y impulsadas por agentes ya tienen precedentes en la investigación DeFi.

El tercer paso es organizar diversos participantes en el entorno de simulación. Los prestatarios, liquidadores, depositantes y LP tienen limitaciones de capital y motivaciones. Pero no se debe dar protagonismo a nadie: los liquidadores no deben hacer transacciones en pérdidas solo para lograr un final feliz. Los roles tampoco necesitan ser todos modelos de lenguaje grandes; reglas simples y transparentes a veces son mejores, más rápidas y más fáciles de reproducir. Los fracasos a nivel técnico aún deben depender de pruebas de fuzzing, auditorías de código e inyecciones de fallos; estos métodos y la simulación económica son paralelos, no mutuamente excluyentes.

El cuarto paso es causar destrucción. Deben probarse saltos de precios, retrasos en las actualizaciones de oráculos, reducción de liquidez y interrupciones en la ejecución. No solo se debe cambiar la magnitud, sino también el orden. Retirar liquidez antes de un choque de precios y hacerlo después puede dar resultados completamente diferentes.

Lo que la simulación finalmente debe proporcionar no es una puntuación de seguridad general, sino una cadena de pérdidas: qué posición falla primero, cuánto se recupera y cómo se expande el déficit. Con esta cadena, se pueden determinar los límites de cobertura y los requisitos de capital, o simplemente dar una respuesta de "no cobertura".

Dejar que la IA ocupe el 'asiento del villano', pero sin alterar las leyes físicas

El uso más intuitivo de la IA es leer código y documentos. Los modelos de lenguaje pueden desglosar dependencias, explicar actualizaciones y proponer escenarios de fallos. Pero una historia que suena creíble no significa que se haya encontrado una vulnerabilidad; aún necesita evidencia.

Lo más interesante es permitir que la IA busque activamente varios escenarios posibles. La simulación de Monte Carlo muestrea de distribuciones establecidas, lo cual es útil; pero las combinaciones realmente malas pueden ser demasiado raras, y el muestreo aleatorio la mayor parte del tiempo solo repite situaciones comunes.

Las pruebas de estrés adaptativas, por otro lado: los agentes en el simulador eligen factores de perturbación, buscando activamente caminos de fallo creíbles. Ya se ha demostrado este enfoque en pruebas de conducción autónoma utilizando aprendizaje por refuerzo. Los agentes pueden cambiar el clima, pero no pueden reescribir las leyes físicas.

En la configuración propuesta de Firelight, los agentes pueden ajustar el retraso de los oráculos, la retirada de liquidez y la tasa de llegada de liquidadores dentro de los límites de la realidad. Se recompensa encontrar caminos destructivos y se castiga el engaño. Un villano con capital infinito y permisos divinos no es un modelo de aseguramiento útil.

Luego, la IA agrupa las trayectorias de fallo, eligiendo el siguiente conjunto de experimentos que más pueden reducir la incertidumbre. Cientos de desastres que parecen diferentes pueden compartir el mismo cuello de botella de liquidación. Esto tiene valor práctico.

La velocidad también es importante. Los métodos de aproximación de bajo costo filtran primero una gran cantidad de escenarios, y las pruebas de ejecución costosas se repiten en múltiples entornos de prueba independientes para reproducir escenarios importantes. Pero los atajos deben ser verificados. Acelerar un simulador erróneo solo hará que cometa errores con más confianza.

La IA desempeña el papel de conductor en las pruebas adversariales, no de árbitro de seguridad. Indica qué se debe investigar, y el motor de ejecución, los expertos en el campo y la evidencia determinan si este hallazgo es válido.

De las trayectorias de pérdidas a los términos de cobertura

Imaginemos una bóveda de préstamos hipotética: los precios de los colaterales caen, los LP retiran liquidez, y la actualización de los oráculos se retrasa. Aunque los liquidadores entran, el deslizamiento devora el valor recuperado, y al final, la deuda del prestatario supera el precio real al que se pueden vender los colaterales.

Luego, hagamos algunos contrastes: solo dejando caer los precios; retirando liquidez mientras los precios caen; varios factores juntos. Solo así se puede ver si la verdadera debilidad está en el precio, en la profundidad del mercado, o en la interacción entre ambos.

Supongamos que una ejecución de ejemplo genera 2 millones de dólares en pérdidas calificadas, con una retención de 500,000 dólares y un límite de cobertura de 1 millón de dólares. La capa de retención absorbe 500,000, supongamos que la cobertura paga 1 millón, y los 500,000 restantes quedan fuera del límite.

Estos son ejemplos de términos ficticios, no son cotizaciones de Firelight, ni resultados de simulaciones reales. La calificación, recuperación, exclusiones y coberturas superpuestas aún necesitan ser aclaradas.

La clave es: tener pérdidas económicas no significa que se pueda recibir una indemnización. La simulación solo es realmente útil si afecta la decisión de aseguramiento, como reducir el límite de cobertura, exigir controles de riesgo más estrictos, mantener más capital, o simplemente rechazar la cobertura. Una animación de desastre bien hecha no es una decisión financiera.

Encontrar caminos de fallo no equivale a calcular probabilidades

Supongamos que un agente adversarial ha comprometido el sistema en el 30% de las pruebas. ¿Significa esto que el sistema tiene un 30% de probabilidad de fallo? No necesariamente. Este agente fue diseñado específicamente para encontrar vulnerabilidades.

Descubrir fallos responde a la pregunta de "¿cómo podría fallar, y hasta qué punto?" Estimar probabilidades responde a la pregunta de "¿con qué frecuencia ocurren estas condiciones durante el período de cobertura?" Confundir ambas es crear una falsa precisión.

Desde un punto de vista conceptual, el pago esperado es la cantidad de indemnización en cada escenario, multiplicada por la probabilidad de que ese escenario ocurra, y luego sumada. Estas probabilidades necesitan estar respaldadas por evidencia, y las suposiciones deben estar claramente escritas. Si no hay estimaciones creíbles, se deben usar intervalos, límites conservadores y restricciones de presión, en lugar de inventar números precisos hasta el decimal.

El pago esperado no es igual a todas las primas. El capital también debe cubrir riesgos extremos, costos operativos e incertidumbres, y los riesgos extremos a menudo son bastante feos. En un nivel de cartera, las dependencias compartidas también pueden hacer que múltiples contratos se activen simultáneamente.

El marco de capital que Firelight ha hecho público ya considera la concentración y la retirada de colaterales. La simulación debe presionar ambos extremos: uno es el aumento de reclamaciones, y el otro es el colapso sincronizado de activos, incluso volviéndose más difíciles de vender. Si un gran desastre ocurre y el capital también se reduce, el fondo de cobertura no puede ser estimado solo por la pérdida promedio.

¿Quién prueba la 'prueba de estrés'?

Un simulador puede ser lógicamente coherente, pero sus conclusiones pueden ser completamente erróneas. Ejecutar un millón de veces con configuraciones de liquidadores poco realistas no es más que repetir el mismo error un millón de veces. Hacer más ejecuciones puede reducir el error de muestreo, pero el error del modelo en sí no se reducirá automáticamente.

Un laboratorio confiable hará cuatro cosas: revisará eventos conocidos, validará con datos fuera de muestra, comparará modelos construidos independientemente por diferentes equipos, y ajustará las suposiciones sobre el comportamiento de los participantes. Las instantáneas, semillas aleatorias y registros de ejecución deben archivarse para que los hallazgos clave puedan reproducirse. También se debe preguntar repetidamente: ¿lo que encontró la IA son debilidades del protocolo, o errores del simulador?

No hay ninguna prueba que pueda demostrar que se han encontrado todos los caminos de desastre. Justamente porque existen dependencias desconocidas y comportamientos nunca antes vistos, se necesita un colchón de capital, exclusiones y moderación en la cobertura.

Los límites del contrato también deben ser claros. Nuevas evidencias pueden afectar los precios y capacidades futuras, pero no deberían convertir la cobertura existente en un blanco móvil. El marco que Firelight ha hecho público separa el monitoreo continuo de riesgos y las tarifas fijas durante el período de cobertura. El aprendizaje continuo y el cumplimiento de compromisos pueden coexistir; pero reescribir compromisos después de que surja un peligro no es aceptable.

Conclusión: Aprender antes de que ocurran las pérdidas

El mayor valor es integrar la aseguradora en el proceso de desarrollo. Cuando el sistema experimenta cambios significativos, se activarán pruebas correspondientes; los resultados de las pruebas influirán en nuevas decisiones de cobertura; los eventos reales ayudarán a mejorar la próxima versión del modelo. Cuanto mejor se realice la ingeniería, más se reflejará en los precios de cobertura y la disponibilidad.

Las reclamaciones históricas son una lección aprendida después del hecho. La simulación permite a Firelight entender de antemano: cómo podría fallar este sistema.

La IA se encarga de ampliar el rango de búsqueda, la evidencia restringe sus conclusiones, y el capital se encarga de cumplir las promesas. El objetivo no es predecir cada desastre, sino, después de ver lo que podría enfrentar, invertir capital para soportar esas pérdidas inevitables.