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 zona ciega del seguro DeFi: no haber fallado no significa estar a salvo

Escuchemos un poco de humor negro en la promoción: "Nuestro nuevo avión es absolutamente seguro, nunca se ha estrellado."

"¿Cuánto tiempo ha volado?"

"... Tal vez dos veces."

Si cambiamos el avión por una bóveda DeFi, la historia se vuelve familiar: seis meses de retiros sin problemas, sin ataques y con buenos rendimientos. Esto, por supuesto, es evidencia. Pero durante esos seis meses, ¿ha enfrentado congestión de red, colateral desanclado, retiros masivos 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 suscripción debe preguntar: ¿qué podría enfrentar a continuación?

Esta es la oportunidad que ve Firelight: 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 el sistema puede cambiar

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 reevaluada.

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 solo números en una tabla. Ellos reaccionarán a los incentivos y, si ocurre un problema, todos querrán salir por la misma puerta.

Es como un mapa de tráfico dibujado según las condiciones habituales 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é rutas de liquidación aún están disponibles? El marco público de Firelight ya ha separado las vulnerabilidades técnicas de las debilidades económicas, en lugar de fusionarlas en una única puntuación de seguridad.

La suscripción se centra en la construcción y las relaciones de dependencia actuales del sistema, 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 afectados pasan de edificios a posiciones de préstamo, la fragilidad cambia de calidad de construcción a amortiguación de colateral y diseño de liquidación, y finalmente se calcula el pago 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 la posibilidad de descomponer riesgos, calibrar históricamente, simular Monte Carlo, combinar modelos de lenguaje y aprendizaje por refuerzo, y conectarlos a 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 línea.

También es importante aclarar: Firelight define su producto como una cobertura basada en protocolos, no como un contrato de seguro tradicional. Las comparaciones con el seguro se refieren a la disciplina de suscripción, 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. Las versiones de contrato, saldos, posiciones de colateral, así como configuraciones de oráculos, reglas de liquidación y liquidez del mercado, deben estar bloqueadas. De lo contrario, los resultados de dos simulaciones pueden no coincidir 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 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 e incentivos. Pero no se debe dar protagonismo a nadie: los liquidadores no pueden hacer transacciones a pérdida solo para lograr un final feliz. Los roles tampoco tienen que ser todos grandes modelos de lenguaje; 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 simulaciones económicas son paralelos, no mutuamente excluyentes.

El cuarto paso es causar daños. Los saltos de precios, la actualización tardía de oráculos, la disminución de liquidez y las interrupciones en la ejecución deben ser probados. 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 calificació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 cubierto".

Dejar que la IA ocupe el 'asiento del villano', pero sin cambiar las leyes de la física

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 muestreará de distribuciones preestablecidas, lo cual es útil; pero las combinaciones realmente malas pueden ser demasiado raras, y el muestreo aleatorio la mayor parte del tiempo solo está repitiendo situaciones comunes.

Las pruebas de estrés adaptativas, por otro lado: los agentes en el simulador eligen factores de perturbación, buscando activamente rutas 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 de la física.

En el marco propuesto de Firelight, los agentes pueden ajustar la latencia 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 rutas destructivas y se castiga el engaño. Un villano con capital infinito y poderes divinos no es un modelo de suscripción útil.

Luego, la IA agrupa las trayectorias de fallo, seleccionando el siguiente conjunto de experimentos que más reduzcan la incertidumbre. Cientos de desastres que parecen diferentes pueden compartir un mismo cuello de botella de liquidación. Esto tiene valor en la acción.

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

La IA desempeña el papel de conductor en las pruebas adversariales, no de árbitro de seguridad. Indica qué buscar, 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: el precio del colateral cae, los LP retiran liquidez, la actualización de oráculos se retrasa. Aunque los liquidadores entran, el deslizamiento consume el valor recuperado, y al final, la deuda del prestatario supera el precio real al que se puede vender el colateral.

Haciendo algunos grupos de comparación: solo dejando caer el precio; retirando liquidez mientras el precio cae; 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 de 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, quedando 500,000 fuera del límite.

Estos son ejemplos de términos ficticios, no son cotizaciones de Firelight ni resultados de simulación 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 un pago. La simulación solo es realmente útil si afecta la decisión de suscripción, como reducir el límite de cobertura, exigir controles más estrictos, mantener más capital, o simplemente rechazar la cobertura. Las animaciones de desastres pueden ser atractivas, pero aún no son una decisión financiera.

Encontrar rutas de fallo no significa 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 precisamente para encontrar vulnerabilidades.

Descubrir fallos responde a "cómo podría fallar, hasta qué punto podría fallar". Estimar probabilidades responde a "qué tan frecuentemente ocurren estas condiciones durante el período de cobertura". Confundir ambos es crear una falsa precisión.

Desde un punto de vista conceptual, el pago esperado es la cantidad de pago 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 rangos, límites conservadores y restricciones de estrés, 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 incertidumbre, y los riesgos extremos suelen ser 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 público de Firelight ya ha considerado la concentración y el retiro de colateral. La simulación debe presionar ambos extremos: uno es el aumento de reclamaciones, el otro es el colapso sincronizado de activos, o incluso volverse más difícil de vender. Si en un gran desastre el capital también se reduce, el fondo de cobertura no puede estimarse solo según 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 disminuirá automáticamente.

Un laboratorio confiable hará cuatro cosas: revisar eventos conocidos, validar con datos fuera de la muestra, comparar modelos construidos independientemente por diferentes equipos y ajustar las suposiciones sobre el comportamiento de los participantes. Instantáneas, semillas aleatorias y registros de ejecución deben ser archivados para que los hallazgos clave puedan ser reproducidos. También hay que preguntarse repetidamente: ¿lo que encontró la IA son debilidades del protocolo o un error del simulador?

No hay ninguna prueba que pueda demostrar que se han encontrado todos los caminos de desastre. Justamente por la existencia de dependencias desconocidas y comportamientos nunca antes vistos, se necesitan reservas de capital, exclusiones y moderación en la suscripción.

Los límites del contrato también deben ser claros. Nuevas evidencias pueden afectar la fijación de precios y la capacidad futura, pero no deberían convertir la cobertura existente en un blanco móvil. El marco público de Firelight separa el monitoreo continuo de riesgos y las tasas 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 aparezcan las pérdidas

El valor más grande es integrar la suscripción 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; 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 posterior al hecho. La simulación permite a Firelight aclarar 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 los compromisos. El objetivo no es predecir cada desastre, sino, tras comprender lo que podría enfrentar, invertir capital para soportar las pérdidas inevitables.