Na reunião de terça-feira, eu não lembro exatamente quem na discussão começou a mudar o tom primeiro. Só lembro que Trang olhou para a tela por mais tempo do que o normal e então perguntou: “E se ocorrer um exploit, mas ainda ninguém tiver concordado que é um exploit, em que estado o sistema está?”
Ninguém respondeu imediatamente. Como o Newton Protocol não define esse estado em nenhuma camada. Ele só define as permissões de ação depois que o estado tiver sido reconhecido.
Na arquitetura do Newton, a resposta a emergências se espalha por várias camadas: o sistema de detecção, a execução via multisig e a coordenação do security council. Cada camada tem um papel bem definido, mas nenhuma assume a responsabilidade de definir “o ponto de início do incidente”.
Essa lacuna não é falta técnica. É falta de um limiar de consenso na percepção. E, em DeFi, a percepção sempre fica atrás dos dados.
A tela aponta a parte de “authorized intervention” nos docs: core contributors e security council têm permissão para pausar ou fazer upgrade quando detectam anomalias. Parece completo, até seguro. Mas a palavra “detectar” não está ancorada em nenhuma condição rígida. Não há SLA, não há limiar compartilhado, não há gatilho obrigatório. Só existe permissão, sem um momento definido.
A camada de detecção pode disparar um alerta em alguns segundos quando vê uma anomalia on-chain. Mas alerta não é decisão; é apenas um sinal ainda não interpretado. Depois do alerta, vem uma sequência de pessoas que precisam olhar juntas para os dados e decidir se é volatilidade ou exploit.
Cada pessoa com um dashboard. Cada pessoa com um nível de limiar diferente. Não há uma camada de interpretação compartilhada no primeiro instante.
O multisig no Newton é visto como a última camada de segurança antes de ocorrer uma ação irreversível. Mas o multisig não só deixa a execução mais lenta. Ele fragmenta o tempo das decisões.
Um signer considera gravíssimo. Outro ainda não tem certeza. Um terceiro está offline. Ninguém está errado, mas não acontece nenhuma ação conjunta imediatamente.
Começo a ver com clareza a contradição central: a execução no Newton é determinística, mas a cognição de emergência não é. O sistema foi otimizado para reduzir a confiança na operação normal, mas acaba aumentando a dependência de confiança quando o sistema está sob pressão.
Não é uma contradição pequena. É o lugar onde o sistema é puxado para o humano exatamente no momento mais perigoso. A tela diz uma frase que desvia a discussão: “Detecção é código. Decisão é humano. Então, onde está de verdade o gargalo?”
Não há resposta “limpa”. Porque, se aumentar a automação, o sistema fica vulnerável a spam de falsos positivos para acionar a pausa. Se aumentar a verificação humana, o sistema morre por causa da latência. O Newton não escolhe um lado. Ele mantém os dois e transforma esse trade-off em estrutura de operação.
Nós tentamos construir um cenário mais concreto. Um exploit acontece no momento em que há alta liquidez. O bot começa a retirar os ativos em alguns blocos. O sistema de monitoramento detecta quase imediatamente e dispara um alerta. Mas o alerta está na zona “pode ser volatilidade”, ainda não ultrapassou o limiar para auto-pause.
Um signer vê o alerta, mas ainda não assina. O segundo está offline. O terceiro está aguardando mais dados de verificação. Ninguém se opõe à ação, mas também não acontece nenhuma ação.
Nesses 90 segundos, o TVL começa a ser retirado aos poucos. Não porque o sistema não detecta. Mas porque o sistema ainda não chegou a um estado de consenso de que está sofrendo um ataque. Depois de 90 segundos, quando o consenso se forma, o estado já mudou.
Não existe mais “incidente para impedir”. Agora só existe “dano para limitar”. A tela fica em silêncio por um instante e pergunta: “Então, o sistema está otimizando o quê — evitar erros ou reagir rápido?” Essa pergunta não tem uma resposta fixa no Newton. E justamente por isso o sistema escolhe não se tornar extremista de um lado.
Auto-pausar cedo demais cria uma superfície de ataque por meio de ruído. Confirmar manualmente demais cria uma latência inaceitável em um exploit de verdade.
Os docs mencionam coordenação do security council, mas não há SLA, não há caminho de escalonamento, não há definição de “quem precisa reagir primeiro”. Isso cria flexibilidade no design, mas ao mesmo tempo abre uma lacuna de tempo na responsabilidade. Ninguém está errado por reagir devagar. Mas o sistema não sabe quanto esperar é “demais”.
A tela chama isso de “responsabilidade assíncrona”. Eu diria que é mais do que isso: é um estado em que o poder de agir é distribuído, mas a pressão de tempo não. Em um sistema normal, distribuir poder é uma vantagem. Em um incidente, distribuir tempo é um ponto fraco.
Começo a enxergar o sistema de emergências do Newton não como um pipeline, mas como um processo de sincronização de percepções. Não é o sistema que decide quando há um incidente. É que várias pessoas precisam acreditar ao mesmo tempo que o incidente está acontecendo. E sincronizar crenças sempre é mais lento do que os dados.
A melhor analogia é um aeroporto com radar automático que detecta objetos estranhos. O radar acerta, mas a decisão de fechar a pista não vem do radar.
Isso vem de várias pessoas confirmando que o sinal não é ruído. Nos primeiros 30 segundos, ninguém está errado. Mas, se for um exploit de verdade, aqueles 30 segundos já teriam sido suficientes para mudar todo o resultado. O ponto mais importante não está na velocidade da detecção, e sim na velocidade do consenso sobre a detecção. E isso é algo que não está escrito no diagram de arquitetura do Newton Protocol.
A tela diz uma última frase antes da discussão parar: “Talvez o problema não seja quem aperta o pause, mas que o sistema não define quando todo mundo deve começar a acreditar igual”. Aquilo não conclui nada. Mas deixa claro o projeto inteiro: o Newton não carece de mecanismos de emergência. Ele só falta uma definição precisa para o instante em que várias pessoas começam a chamar a mesma ocorrência de “incidente”.
