AI como 'vilão': o seguro DeFi precisa de um teste de estresse

Testando a tesouraria DeFi: Firelight planeja usar IA para encontrar o 'próximo acidente'.

Escrito por: @jrdothoughts

Compilado por: AididiaoJP, Foresight News

As lacunas do seguro DeFi: não ter falhado não significa estar seguro

Comecemos com uma venda humorística: 'Nosso novo avião é absolutamente seguro, nunca caiu antes.'

'Por quanto tempo voou?'

'... Talvez duas vezes.'

Troque o avião por uma tesouraria DeFi e a história se torna familiar: seis meses de saques suaves, sem ataques, e retornos razoáveis. Isso é, sem dúvida, uma evidência. Mas, durante esses seis meses, houve algum momento em que enfrentou congestionamento na rede, com colaterais desancorados, provedores de liquidez (LPs) correndo para retirar seus fundos, ou oráculos que não atualizaram? É muito provável que não.

Um histórico limpo só pode indicar o que um sistema suportou. O que a subscrição deve perguntar é: o que ele pode enfrentar a seguir?

Essa é a oportunidade que a Firelight vê: precificar com base nas formas como as perdas se formam, e não apenas observar se as perdas ocorreram. O histórico é responsável por ancorar, a simulação é responsável por explorar cenários alternativos, a IA é responsável por encontrar fraquezas, e o capital é responsável por garantir.

O histórico é uma foto instantânea, mas o sistema pode mudar

Os dados históricos de perdas são uma foto instantânea de uma máquina operando sob certas condições. Quando a máquina muda, a foto precisa ser reavaliada.

Uma tesouraria adicionou um novo tipo de colateral, trocou de oráculo e aumentou a alavancagem. O nome não mudou, o logotipo não mudou, mas o risco é agora muito diferente. Os mutuários, liquidantes e LPs dentro não são apenas números em uma tabela. Eles reagem a incentivos e, se algo der errado, todos querem sair pela mesma porta.

É como um mapa de tráfego desenhado com base nas condições normais de uma terça-feira. Normalmente parece preciso, mas se a ponte principal fechar, ele não serve mais. O mapa em si não está errado, mas as condições da estrada mudaram.

Portanto, para a Firelight, a verdadeira questão não é apenas 'este protocolo já foi hackeado?', mas sim: que permissões existem? Quais dependências são realmente importantes? Quando todos correm para fora, quais caminhos de liquidação ainda podem ser utilizados? O quadro público da Firelight já separou vulnerabilidades técnicas e fragilidades econômicas, em vez de misturá-las em uma única pontuação de segurança.

A subscrição se concentra na construção atual do sistema e nas relações de dependência, e não na marca que tem sido usada até agora.

Os seguros contra catástrofes já escreveram o roteiro

As seguradoras tradicionais não abandonaram a modelagem da incerteza. Os seguradores de catástrofes sempre fizeram uma coisa: simular como as desastres ocorrem, quais ativos estarão expostos, quão frágeis são as estruturas e quanto será pago no final do contrato. Furacões que já ocorreram não representam todos os possíveis furacões futuros.

O DeFi também precisa de seu próprio modelo de catástrofe. A única diferença é que o desastre muda de furacão para falha de oráculo, os alvos de desastre mudam de edifícios para posições de empréstimo, e a fragilidade muda de qualidade da construção para amortecedores de colateral e design de liquidação, e finalmente, os pagamentos são calculados de acordo com os termos de cobertura.

O modelo de catástrofe pergunta: o que acontece quando um furacão passa por uma cidade? O modelo DeFi pergunta: o que acontece quando uma falha se espalha ao longo do gráfico de dependência?

A Firelight discutiu publicamente a decomposição de riscos, calibração histórica, simulação de Monte Carlo, modelos de linguagem e aprendizado por reforço, integrando-os em um laboratório de testes financeiros. É importante esclarecer que esta é uma direção proposta, não uma afirmação de que cada parte já está em operação.

Outro ponto a ser esclarecido: a Firelight define seu produto como uma cobertura baseada em protocolo, e não um contrato de seguro tradicional. As comparações feitas com seguros referem-se à disciplina de subscrição, sem envolver a qualificação legal do produto.

Como montar um laboratório de testes financeiros

O primeiro passo é fixar o estado inicial, garantindo que possa ser reproduzido. Versão do contrato, saldos, posições de colateral, configurações de oráculo, regras de liquidação e liquidez do mercado devem ser bloqueados. Caso contrário, os resultados de duas simulações podem não coincidir, possivelmente apenas porque os pontos de partida eram diferentes, e não se está testando o mesmo sistema.

O segundo passo é separar a execução das suposições. Forks de blockchain podem executar a lógica real do contrato, mas não podem criar liquidez, preços fora da cadeia e comportamentos humanos do nada. Esses devem ser modelados explicitamente. Testes baseados em forks e impulsionados por agentes já têm precedentes na pesquisa DeFi.

O terceiro passo é organizar diversos participantes no ambiente simulado. Mutuários, liquidantes, depositantes e LPs têm limitações de capital e incentivos próprios. Mas não se deve dar a ninguém um papel de protagonista: os liquidantes não devem realizar transações deficitárias apenas para criar um desfecho satisfatório. Os papéis também não precisam ser todos modelados com grandes modelos de linguagem; regras simples e transparentes às vezes são melhores, mais rápidas e mais fáceis de reproduzir. Falhas em nível técnico ainda devem ser abordadas com testes de fuzzing, revisão de código e injeção de falhas; esses métodos e simulações econômicas devem ocorrer em paralelo, não se substituindo mutuamente.

O quarto passo é causar destruição. Saltos de preço, atrasos na atualização de oráculos, liquidez se esvaindo e interrupções na execução devem ser testados. Não apenas altere a magnitude, mas também a ordem. LPs retirando liquidez antes de um choque de preço e após o choque podem ter resultados completamente diferentes.

O que a simulação deve fornecer não é uma pontuação de segurança genérica, mas sim uma cadeia de perdas: qual posição falha primeiro, quanto é recuperado e como a lacuna se expande. Com essa cadeia, é possível determinar os limites de cobertura e os requisitos de capital, ou simplesmente declarar 'não coberto'.

Deixe a IA assumir o papel de 'vilão', mas não altere as leis da física

O uso mais intuitivo da IA é ler códigos e documentos. Modelos de linguagem podem mapear dependências, explicar atualizações e sugerir cenários de falha. Mas uma história que parece crível não significa que uma vulnerabilidade foi encontrada; ainda precisa de evidências.

Mais interessante é permitir que a IA ativamente busque vários cenários possíveis. A simulação de Monte Carlo amostra de distribuições definidas, o que é útil; mas combinações realmente ruins podem ser muito raras, e a amostragem aleatória muitas vezes apenas repete a descoberta de situações comuns.

Os testes de estresse adaptativos, por outro lado: os agentes escolhem fatores de perturbação no simulador, buscando ativamente caminhos de falha críveis. Essa abordagem já foi demonstrada em testes de direção autônoma usando aprendizado por reforço. Os agentes podem mudar o clima, mas não podem reescrever as leis da física.

Na configuração proposta da Firelight, os agentes podem ajustar atrasos de oráculos, retiradas de liquidez e taxas de presença de liquidantes dentro dos limites da realidade. Encontrar caminhos destrutivos é recompensado, enquanto fraudes são punidas. Um vilão com capital infinito e poderes divinos não é um modelo de subscrição útil.

Em seguida, a IA agrupa trajetórias de falha, selecionando o próximo conjunto de experimentos que mais reduz a incerteza. Centenas de desastres que parecem diferentes podem compartilhar o mesmo gargalo de liquidação. Isso é o que tem valor em ação.

A velocidade também é importante. Métodos de aproximação de baixo custo primeiro filtram muitos cenários, enquanto testes de execução caros são repetidos em múltiplos ambientes de teste independentes para reproduzir cenários importantes. Mas os atalhos devem ser verificados. Acelerar um simulador errado apenas fará com que ele cometa erros mais rapidamente e com mais confiança.

A IA desempenha o papel de motorista em testes adversariais, não de árbitro de segurança. Ela indica o que deve ser investigado, enquanto o motor de execução, especialistas de domínio e evidências determinam se essa descoberta é válida.

Da trajetória de perdas aos termos de cobertura

Imagine um tesouro de empréstimos hipotético: os preços dos colaterais caem, LPs retiram seus fundos, e a atualização do oráculo é atrasada. Embora os liquidantes entrem, o slippage consome o valor recuperado, e, no final, a dívida do mutuário excede o preço que o colateral realmente pode ser vendido.

Agora, faça alguns contrastes: deixe o preço cair; retire liquidez enquanto o preço cai; combine vários fatores. Assim, é possível ver se a verdadeira fraqueza está no preço, na profundidade do mercado, ou na interação entre ambos.

Suponha que uma execução de exemplo produza 2 milhões de dólares em perdas qualificadas, com uma retenção de 500 mil dólares e um limite de cobertura de 1 milhão de dólares. A camada de retenção absorve 500 mil, supondo que a cobertura pague 1 milhão, restando 500 mil fora do limite.

Esses são exemplos fictícios de termos, não uma cotação da Firelight, nem resultados de simulação reais. A qualificação, recuperação, exclusões e sobreposições ainda precisam ser esclarecidas.

A chave é: ter perdas econômicas não significa que se pode receber pagamento. A simulação só é realmente útil se impactar a decisão de subscrição — por exemplo, reduzindo o limite de cobertura, exigindo controles de risco mais rigorosos, mantendo mais capital, ou simplesmente recusando a cobertura. Mesmo que a animação do desastre seja bem feita, ainda não é uma decisão financeira.

Encontrar caminhos de falha não significa calcular a probabilidade

Suponha que um agente adversário tenha quebrado o sistema em 30% dos testes. Isso significa que o sistema tem uma probabilidade de falha de 30%? Não necessariamente. Esse agente foi projetado especificamente para encontrar vulnerabilidades.

Descobrir falhas responde à pergunta 'como algo pode falhar e até que ponto'. Estimar a probabilidade responde à pergunta 'com que frequência essas condições ocorrem durante o período de cobertura'. Misturar os dois é criar uma falsa precisão.

Conceitualmente, o pagamento esperado é o montante a ser pago em cada cenário, multiplicado pela probabilidade de que esse cenário ocorra, e somado. Essas probabilidades precisam de evidências para sustentá-las, e as suposições devem ser claramente escritas. Se não houver estimativas confiáveis, use intervalos, limites conservadores e restrições de estresse, em vez de inventar números precisos até a casa decimal.

O pagamento esperado não é igual a todos os prêmios. O capital também deve cobrir riscos de cauda, custos operacionais e incertezas, e os riscos de cauda costumam ser bastante feios. Em um nível de portfólio, dependências compartilhadas também podem fazer com que várias apólices acionem pagamentos simultaneamente.

A estrutura de capital pública da Firelight já considera concentração e retirada de colaterais. As simulações devem testar simultaneamente os dois extremos: um lado é o aumento de reclamações, e o outro é a desvalorização sincronizada dos ativos, ou até mesmo torná-los mais difíceis de vender. Se um grande desastre ocorrer e o capital também encolher, o fundo de cobertura não pode ser estimado apenas com base na perda média.

Quem testa o 'testador de estresse'?

Simuladores podem ser logicamente coerentes, mas suas conclusões podem estar completamente erradas. Executar um milhão de vezes com configurações de liquidantes irreais é apenas repetir o mesmo erro um milhão de vezes. Fazer mais execuções pode reduzir o erro de amostragem, mas o erro do modelo em si não diminuirá automaticamente.

Um laboratório confiável fará quatro coisas: revisitar eventos conhecidos, testar com dados fora da amostra, comparar modelos independentes construídos por diferentes equipes e ajustar as suposições sobre o comportamento dos participantes. Capturas de tela, sementes aleatórias e registros de execução devem ser arquivados, para que descobertas importantes possam ser reproduzidas. E deve-se perguntar repetidamente: o que a IA encontrou é uma fraqueza do protocolo ou um bug do simulador?

Nenhum teste pode provar que todas as trajetórias de desastre foram encontradas. É exatamente por causa de dependências desconhecidas e comportamentos nunca vistos que precisamos de amortecedores de capital, exclusões e contenção de subscrição.

Os limites do contrato também devem ser claros. Novas evidências podem afetar a precificação e a capacidade futuras, mas não devem transformar a cobertura existente em um alvo móvel. O quadro público da Firelight separa o monitoramento contínuo de riscos e as taxas fixas durante o período de cobertura. Aprendizado contínuo e cumprimento de promessas podem coexistir; mas reescrever promessas após a emergência de um perigo não é aceitável.

Conclusão: aprender antes que as perdas ocorram

O maior valor é integrar a subscrição no processo de desenvolvimento. Quando o sistema sofre mudanças significativas, testes correspondentes são acionados; os resultados dos testes influenciam novas decisões de cobertura; eventos reais ajudam a melhorar a próxima versão do modelo. Quanto melhor o trabalho de engenharia, mais isso se refletirá nos preços e na disponibilidade da cobertura.

As reivindicações históricas são um aprendizado posterior. As simulações permitem que a Firelight entenda antecipadamente: como esse sistema pode falhar.

A IA é responsável por ampliar o escopo de busca, as evidências restringem suas conclusões, e o capital é responsável por cumprir promessas. O objetivo não é prever cada desastre, mas, após entender o que pode ser enfrentado, investir capital para suportar as perdas que precisam ser suportadas.