Link original: https://rekt.news/singularitynet-rekt
Fonte: SingularityNET, SlowMist, Bitquery, PeckShield, ASI Alliance, Blockaid, Uniswap, Baltex, AMLBot, NuNet, Fetch.ai.
Declaração: Este artigo é republicado. Os leitores podem obter mais informações por meio do link original. Se o autor tiver qualquer objeção à forma de republicação, entre em contato conosco; nós faremos as alterações conforme solicitação do autor. A republicação é usada apenas para compartilhamento de informações e não constitui qualquer recomendação de investimento, nem representa as opiniões e posições do Wu Shuo.
A SingularityNET tem trabalhado há anos para promover um mercado para uso por agentes de IA autônomos.
No entanto, na noite de 19 de setembro, o “agente” mais movimentado na rede era um script que não foi escrito pela equipe da SingularityNET.
O atacante, ao invadir a infraestrutura em nuvem do projeto, obteve permissões de assinatura expostas e, com apenas uma assinatura, drenou a liquidez do FET no contrato de conversão em Ethereum. Em seguida, em nove horas, cunhou 2,3 bilhões de tokens no total: AGIX, NTX, WMTX e CGV. Alguns relatórios listaram o valor roubado como US$ 16,77 milhões. Mas a reversão por transação mostra que o montante total realizado efetivamente obtido pelo atacante foi de cerca de US$ 2,29 milhões, e que a maior parte dos tokens cunhados não foi vendida. Todas as chaves usadas para assinatura eram válidas. Cada contrato que executou instruções também estava funcionando de acordo com a lógica estabelecida.
Mas o impacto causado por este ataque vai muito além da perda de fundos. Dias se passaram e as partes envolvidas ainda não publicaram um relatório completo de investigação pós-ocorrência.
Quando todas as chaves da aliança do projeto de IA ficam armazenadas no mesmo conjunto de infraestrutura em nuvem, quem realmente controla essa máquina?
Fonte de dados: SingularityNET, SlowMist, Bitquery, PeckShield, ASI Alliance, Blockaid, Uniswap, Baltex, AMLBot, NuNet, Fetch.ai.
A primeira perda de ativos surgiu com o FET, mas o ataque não parou por aí.
Às 20:21 de 19 de setembro, o atacante concluiu a transferência do FET. Apenas 2 minutos e 24 segundos depois, cerca de 8,7 milhões de FET drenados foram convertidos em 522,78 ETH. Às 21:40, a Blockaid emitiu um alerta sobre a saída dessa quantia de FET e apontou que a mesma carteira também recebeu grandes quantidades de NTX cunhadas pelo endereço do deployer da NuNet. A Blockaid inicialmente classificou isso como um incidente de ataque à Fetch.ai, mas a SingularityNET confirmou depois que o que foi invadido foi a própria infraestrutura. Um incidente que parecia inicialmente envolver apenas a Fetch.ai acabou tendo um alcance maior do que o previsto.
Às 02:47 de 20 de setembro, o SlowMist identificou o mecanismo do ataque: basta controlar a chave do autorizador para drenar a ponte cross-chain. Uma chave vazada, mais um contrato que confia nela — esse enredo já se repetiu várias vezes.
Transferir FET não foi o fim do ataque. 29 minutos depois, às 20:50 do dia 19 de setembro, o atacante usou a permissão de cunhagem da NuNet e criou diretamente cerca de 408,5 milhões de NTX no contrato do token. Um aumento em escala maior começou no dia seguinte às 03:13: o atacante cunhou AGIX não autorizado em lotes de 10 milhões. Às 03:38, a cunhagem ilegal de WMTX começou também. A cunhagem de AGIX continuou até 04:21; depois, entre 04:34 e 04:38, a CGV passou por 50 chamadas de cunhagem.
Ao amanhecer, os alertas públicos já haviam ampliado o escopo do incidente: de “fundos da ponte cross-chain drenados” para a invasão das permissões de múltiplos tokens. As primeiras fotos das carteiras estimaram o valor nominal das holdings do atacante em cerca de US$ 16,77 milhões, mas essa avaliação assumiu que os tokens recém-cunhados, com profundidade de negociação insuficiente, poderiam ser vendidos a preços de mercado.
O ataque não terminou com a chegada da noite. Às 13:10 de 20 de setembro, um contrato de pagamento da SingularityNET transferiu todo o saldo de 289.575,10 USDC para uma carteira que já havia sido esvaziada durante a invasão anterior. 12 segundos depois, esse dinheiro entrou na segunda carteira de consolidação do atacante.
Como uma assinatura roubada consegue drenar a ponte cross-chain com uma única chamada? E por que não há nenhum mecanismo on-chain para impedir isso?
Chaves que nunca iniciaram transações
As pontes cross-chain suportadas pela SingularityNET abrangem tokens em duas cadeias. Para o caminho de transferência Cardano→Ethereum que ela suporta, os tokens são primeiro destruídos na Cardano e, em seguida, a ponte cross-chain do lado Ethereum cunha ou libera os tokens correspondentes. No entanto, os contratos no lado Ethereum não verificam independentemente se a destruição na Cardano realmente ocorreu; eles tratam as assinaturas fornecidas pelos autorizadores predefinidos como prova de que a destruição foi concluída.
A Bitquery contabilizou, nas pontes cross-chain afetadas, cinco endereços autorizadores. Esses endereços antes nunca enviaram transações on-chain. Esse padrão é consistente com chaves de assinatura off-chain usadas para aprovar a liberação de ativos da ponte cross-chain, e não para iniciar transações diretamente. Mais tarde, a SingularityNET disse que um terceiro não autorizado “acessou parte da nossa infraestrutura em nuvem”, mas não explicou como essa pessoa obteve acesso.
Esse design faz com que a confiança de cada ponte cross-chain fique concentrada na parte que controla a permissão de assinatura.
Contrato cross-chain de conversão do qual foi drenado todo o saldo de FET: 0xab424a430cc09864fa1277a38193111705adf3a3
Autorizador da conversão que aprovou a saída de fundos: 0x69e5446b07b23de0a76730062c3252152216c85c
Transação de ataque que liberou 8.721.530,40 FET: 0xfe12c63b322d52727c615f3342222138d1563400a9880cebb516a9a162ac69e2
Um relatório forense compilado pela Athena para a ASI Alliance recuperou o endereço do signatário a partir das assinaturas da operação de saída desta vez e confirmou que ele corresponde aos autorizadores configurados atualmente no contrato. O relatório afirma que, desde que esse contrato de conversão foi implantado em setembro de 2024, esse autorizador nunca foi alterado.
Duas escolhas de design amplificaram o impacto de uma tomada indevida de permissões. Primeiro, conversionIn() usa a assinatura de uma única conta externa (EOA) como verificação única de autorização. Segundo, essa função não aplica a verificação de limite checkLimits(amount) usada no conversionOut(). Portanto, os limites de 100 a 1 milhão de FET configurados no contrato não restringem o conversionIn(); o contrato acabou aceitando solicitações de liberação de cerca de 8,72 milhões de FET — aproximadamente 8,7 vezes o limite máximo indicado.
O relatório forense da Athena também descobriu que todos os 100 eventos normais de ConversionIn usaram identificadores no formato UUID gerados pelo backend da SingularityNET. O identificador usado neste ataque, porém, era uma sequência de bytes crus, não-ASCII — a única exceção. Essa transação não tem as características de uma operação normal de ponte cross-chain.
A cunhagem em lote de AGIX foi executada pelo endereço deployer da SingularityNET: 0xA7A31d206042B8A3E81aa4cf8c68c1B76856eE48
Transação de cunhagem de 408.532.878,13 NTX: 0xe14442f6171d8a652e79d44336e58c00cdab271bdb69c668493d420e03ee13ab
A cunhagem em lote de AGIX foi executada pelo endereço deployer da SingularityNET: 0xA7A31d206042B8A3E81aa4cf8c68c1B76856eE48
As chamadas para os contratos de conversão de AGIX, WMTX e CGV terminaram todas com uma operação de cunhagem distinta do padrão de quantidade em lote. Esse padrão corresponde ao cenário de cunhagem automatizada e contínua até atingir alguma restrição de operação.
O contrato de troca de WMTX da World Mobile realmente configurou um limite por chamada única, mas isso não impediu o ataque: apenas forçou o atacante a dividir a cunhagem em 503 chamadas. A maioria das chamadas cunhou exatamente 1 milhão de WMTX, e no máximo apareceram dez chamadas em um único bloco.
A Bitquery afirmou que, antes de qualquer token ser cunhado, 16 carteiras foram esvaziadas em 21 minutos, e também apareceu atividade relacionada na BNB Chain no mesmo período. Com base em seu diretório de endereços, quatro carteiras tinham etiquetas de funcionário da SingularityNET ou da NuNet, incluindo uma conta que implantou um contrato de conversão relacionado em 2022. Isso indica que o incidente envolve múltiplas rotas de autorização para os projetos afetados.
Um endereço de recuperação alterou a configuração de autorizadores dos contratos de conversão da NuNet, Cogito e Rejuve e, em seguida, congelou o NTX. A Bitquery afirma que os contratos de conversão de AGIX e WMTX não conseguiram ser tratados a tempo pelo mesmo método, porque seus proprietários eram, respectivamente, um Gnosis Safe multisig e um Safe multisig que exigia a aprovação de três dos quatro signatários. Durante a transição de permissões, a cunhagem de AGIX e WMTX continuou por cerca de mais uma hora.
A SingularityNET escreveu: “Nosso sistema aceita auditorias regularmente e segue padrões de segurança da indústria.” As auditorias podem avaliar o código dos contratos inteligentes, mas apenas com auditorias não é possível provar que os sistemas off-chain e as chaves privadas usados para gerar assinaturas ou exercer permissões de assinatura são seguros. As chaves de autorizadores associadas aos projetos afetados forneciam assinaturas válidas, permitindo que um grande volume de tokens adicionais fosse gerado.
Então, qual é o montante da grande perda reportada que virou ativos líquidos, e quanto foi apenas por novos tokens cunhados que, talvez, o mercado nem consiga absorver?
Milhões de dólares no papel
Os diferentes números neste artigo medem coisas diferentes. A transferência não autorizada de tokens do contrato representa uma perda direta de ativos; a cunhagem não autorizada de tokens destrói a oferta de tokens. O ETH e as stablecoins obtidos pelo endereço atribuído ao atacante — via venda de tokens ou via retirada direta de ativos — são os lucros efetivamente realizados. O saldo calculado pelas cotações de mercado dos tokens não equivale automaticamente a dinheiro em caixa, nem automaticamente ao valor que pode ser recuperado. Reportagens iniciais confundiram repetidamente esses conceitos.
É fácil cunhar 2,3 bilhões de tokens, mas é difícil encontrar compradores. O FET drenado nas pontes cross-chain constitui a maior operação de realização identificada em uma única transação. Uma conversão feita via roteamento da MetaMask, após descontar as taxas visíveis desse caminho, trocou esses FET por 522,78 ETH.
Transação em que cerca de 8720000 FET foram convertidos em 522,78 ETH: 0x98f6e59b54fd4d2c086cc7cab4e7070edff6410210a1bf1fbaffd62da3b76d1c
Dois endereços receberam a maior parte dos ganhos identificados e dos tokens cunhados. O principal endereço de consolidação do atacante recebeu o FET drenado e o NTX recém-cunhado. De acordo com a reversão das transações, também era o destinatário das primeiras 26 de 90 chamadas de cunhagem de AGIX e das primeiras 54 de 503 chamadas de cunhagem de WMTX.
Principais endereços de consolidação do atacante: 0x2dcc1085fdcf418b421e45e86e4e54637cc21dfe
A segunda carteira recebeu os tokens gerados por chamadas restantes de 64 cunhagens de AGIX, 449 cunhagens de WMTX e todas as 50 cunhagens de CGV, além de USDC provenientes do contrato de pagamento.
Endereço da segunda carteira: 0x83f4424a401a9bb75f90314f21adaea6a9ce09c5
A Bitquery rastreou a origem inicial do dinheiro do principal endereço de consolidação até a ChangeNOW.
Transação em que o ChangeNOW forneceu fundos: 0xa99a8b71bd90d295db305639fc976339a057812c2693f3e44ae9288e5c13ebe1
O histórico de Ethereum desse endereço de consolidação também mostra que, em 1º de setembro, houve uma entrega concluída por meio da ponte cross-chain Across.
Transação de entrega Across cross-chain em 1º de setembro: 0xb56d3b900b5ac694d56d6efb9552a89fc0a14641eceefa7e16107cb8ccb0ea6d
Às 04:04 de 20 de setembro, a segunda carteira recebeu ETH para pagar o Gas e, cerca de um minuto depois, começou a vender os tokens.
Transação em que a segunda carteira recebeu fundos de Gas: 0x4e8894823caaf8fefaf0849cf69b30148ae5ddcee9e7f9bd0c1be0dae0c720c2
Transação em que a segunda carteira autorizou o MetaMask Swap Router a usar 100.000 WMTX: 0x8fcaa005da0c1a5ab138898571e2974ba8aa8f0b9864381e5b2b98b81e702da9
A primeira venda da segunda carteira de WMTX: após a conversão de 100.000 WMTX (descontada a taxa exibida da MetaMask), o valor foi trocado por 0,832455441 ETH: 0xcf4b119f38d0da10dccac787234e05c6cabe3440dfe303f4f407daa92ab8829e
Os ativos estavam distribuídos em duas carteiras, o que torna as estatísticas do relatório mais complexas. O alerta inicial do PeckShield classificou a avaliação de ativos do atacante em US$ 16,77 milhões, incluindo 198,3 milhões de AGIX, 649 ETH e 33,538 milhões de WMTX.
O resultado de venda real revela a diferença entre a avaliação em livro e a capacidade de realização. Uma troca roteada pela MetaMask e executada via Mayan converteu 10 milhões de NTX em 940,39 USDT. Enquanto isso, a segunda carteira usou ordens do UniswapX, com a contraprestação em ETH fornecida por um executor de ordens terceirizado. O registro de liquidação não explica como esses executores levantaram os fundos, como fizeram hedge ou como trataram, por fim, os WMTX recebidos.
Transação convertida via MetaMask/Mayan do NTX: foram enviados 10.000.000 de NTX, e 940,5087 USDT chegaram ao contrato de origem na cadeia Ethereum do Mayan, para liquidação na BNB Chain: 0xb6ecca4deeb2a616507a3f5779cb12db4fd986e5ee37c1832237fae2a1f1258f
CGV é o exemplo mais extremo: ao vender 246,2 milhões de CGV na pool Uniswap do Cogito, foram devolvidos apenas 0,0123 ETH.
Transação em que 246.200.000 CGV foram convertidos em 0,0123 ETH: 0x69a28fb152b2b1b4158ec3db17f7baf565b644859a5150c38729bbb2d198bfad
Além disso, os 289.575,10 USDC enviados pelo contrato de pagamento acabaram indo para a segunda carteira, virando outra grande receita em stablecoin. Esses fundos não precisaram ser obtidos com a venda de tokens emitidos adicionalmente.
Transação em que o contrato de pagamento enviou 289.575,1047 USDC para o endereço intermediário: 0x869343d87a137a52aebce119c8c35e2fc3500205bf7a8c574ec2e8f4ab677c18
Transação em que o endereço intermediário transferiu 289.575,1047 USDC para a segunda carteira: 0xca9facda3f3629fa72ff98b4c8e663d3b415011979d749fab96ed9eda287e66f
Em 22 de setembro, a reversão ponto a ponto dessas transações descobriu que os dois endereços principais receberam ativos equivalentes a cerca de 742,7 ETH, bem como stablecoins no valor de US$ 362.075. Essa estatística não inclui AGIX, WMTX, CGV e NTX que ainda não foram vendidos. Ela calcula WETH e ETH na proporção 1∶1; representa receita total, não lucro líquido.
Uma parte considerável dos ativos líquidos não ficou nessas duas principais carteiras. No mais tardar até 21 de setembro às 00:00, três carteiras diferentes depositaram 75.000 USDC na Chainflip, 75.000 USDC na Baltex e 118.015,16 USDC na Chainflip.
A Baltex descreveu seus serviços como “sem KYC” e promoveu um caminho “privado” de troca envolvendo Monero. Além disso, segundo revelações da AMLBot, um corretor da Chainflip rejeitou um depósito em ETH, e a AMLBot atribuiu esse depósito ao mesmo atacante.
Transação de depósito de 75.000 USDC na Chainflip: 0x3c8b12fedf147d82c8a5506edf3fcad4b7e25c8b96e4fb13b10cf2915aba0076
Transação de depósito de 75.000 USDC na Baltex: 0x05d6d42c75356900e523116d34892b480e9f9134ba195db698d7b1448e0b0696
Última transação de depósito na Chainflip: 118.015,16 USDC: 0xea254b148da1a6d028050f3a59f87845e3dc177ca37ef6441c7eb6cff47eb8ed
Perto da meia-noite UTC, a segunda carteira enviou 93,70 ETH para um endereço de recebimento. As fontes públicas citadas neste artigo não confirmaram o proprietário desse endereço. Cerca de 40 minutos depois, a principal carteira de consolidação do atacante iniciou mais duas transferências, cada uma exatamente de 100 ETH.
Transação em que a segunda carteira enviou 93,70 ETH: 0x605d803890ae4eddc684f82f6de1a82c49a6a3f5646295c1a01fd897fa2a7577
Carteira de recebimento: 0x2fD3285C93437077EF5FA6cecc367FD24d0fF726
As principais transações do atacante para consolidar e enviar a primeira vez de 100 ETH: 0xa8511628388c330db78fcdcfe7af5577e1f300adee795b578508fb21203b4756
Principais transações do atacante para consolidar a segunda remessa de 100 ETH: 0x14399c61687de491461f76e961a91d2c0dcda4c6bb00ba332ec18b19d394822f
Em seguida, a AMLBot descreveu duas transferências independentes de fundos de 100 ETH cada. Ela afirma que uma dessas transferências foi convertida em cerca de 266.000 USDC e depois enviada para “FXMR” via CCTP, Arbitrum e Hyperliquid. A outra foi, supostamente, convertida em cerca de 3,28 BTC via THORChain após ter sido recusada pelo corretor da Chainflip. A AMLBot não divulgou os endereços de origem desses fundos.
As duas carteiras também exibiram registros de transferências pequenas de “poeira” e transferências de tokens falsificados; o endereço de envio imitou deliberadamente o endereço do contraparte de transações anteriores. Isso corresponde às características de um ataque de envenenamento de endereço. Se esse de fato fosse o objetivo, alguém estava tentando roubar novamente o dinheiro do atacante.
Em 25 de setembro, as principais carteiras de consolidação do atacante mantinham cerca de 433 ETH, 15,94 WETH e 52.395 mUSD, de acordo com o saldo de aproximadamente 433 ETH reportado pelo AMLBot no dia anterior. Além disso, essa carteira também detinha cerca de 198,3 milhões de AGIX e 33,54 milhões de WMTX. A segunda carteira, por sua vez, tinha cerca de 18.109 USDC, 625,86 milhões de AGIX, 166,49 milhões de WMTX e 246 milhões de CGV.
O valor exibido por esses tokens não equivale ao valor que realmente pode ser vendido. Quando holdings tão grandes são vendidas, pode haver falta de liquidez e forte impacto no preço. A questão real não é quanto o painel de saldo mostra, e sim: sem romper o mercado, quanto é possível vender de fato.
Com base na reversão dessa transação, o total de ativos líquidos realizados trazidos pela ação do ataque era de aproximadamente US$ 2,29 milhões. Os fundos realizados podem ser transferidos, mas cerca de 1,27 bilhão de tokens remanescentes têm dificuldade em ser realizados da mesma forma. Se essas posições forem vendidas no final, o custo ficará com quem?
Sete décimos dos tokens vieram de emissão ilegal
O preço pode se recuperar, mas a estrutura de oferta não consegue se restaurar sozinha.
A Bitquery contabilizou cerca de 1,28 bilhão de AGIX na verificação cross-chain: cerca de 895,96 milhões foram cunhados durante o ataque, representando 70,1% do total contabilizado. Os restantes cerca de 382,65 milhões podem ser rastreados até a oferta antes do ataque. A mesma análise indica que os tokens cunhados sem autorização representavam 81,1% da oferta de CGV contabilizada, 32,4% da oferta de WMTX e 29,0% da oferta de NTX.
Esta emissão adicional de NTX fez com que o total cross-chain contabilizado subisse para cerca de 1,41 bilhão de NTX, acima da oferta de 1 bilhão definida nos documentos da NuNet. Cerca de 40,10 milhões de NTX emitidos ilegalmente cross-chain entraram na Cardano, e aproximadamente 40 milhões foram para pools de liquidez comuns. Registros de transação podem rastrear o caminho desses tokens, mas, uma vez que eles entram na pool, a pool não consegue diferenciá-los do NTX emitido legitimamente.
O problema do FET não é a emissão ilegal em si, e sim se a ponte cross-chain consegue pagá-lo (redeem). O contrato de conversão em Ethereum responsável por liberar o FET vindo da Cardano foi drenado, enquanto ainda há cerca de 870 milhões de FET na Cardano. De acordo com essa análise, desde que os fundos foram transferidos, ninguém tentou mover o FET da Cardano para o Ethereum; portanto, ainda não surgiram casos de usuários que tiveram de esperar o reembolso porque o saldo do contrato de conversão acabou.
O NTX enfrenta um outro problema: cerca de 40 milhões de tokens emitidos ilegalmente já entraram na pool comum de liquidez da Cardano e, embora a origem não seja autorizada, a pool ainda os trata como trataria qualquer outro NTX.
A SingularityNET disse que revogou o acesso que foi invadido, desativou as pontes cross-chain e os contratos de conversão afetados e pausou as transferências de AGIX e NTX na rede Ethereum. A empresa afirmou que essas pontes cross-chain continuarão offline até que uma auditoria independente e segura confirme que é possível retomá-las com segurança. A Bitquery, por outro lado, descobriu que, até 20 de setembro, três dos cinco chaves dos autorizadores ainda não haviam sido substituídas. Com as pontes cross-chain desligadas, se essas chaves ainda podem ser exploradas, só será verificado de forma real após a retomada.
Para detentores de AGIX, a SingularityNET inicialmente afirmou que estava preparando um “caminho legal e verificado de processamento posterior” para os titulares qualificados. Depois disso, o projeto anunciou que desativaria o token AGIX original e emitiria um token substituto para os detentores afetados, mas ainda não explicou quem tinha elegibilidade nem como o token substituto seria distribuído. As transferências de AGIX na Ethereum continuam pausadas.
Entre os AGIX contabilizados, cerca de 7 em cada 10 foram cunhados durante o ataque; portanto, a determinação de elegibilidade ainda é a questão mais difícil. Qualquer alternativa precisa decidir como tratar holdings que foram cunhadas ilegalmente e depois circularam por meio de transações normais de mercado.
A Fetch.ai disse que seus contratos não foram afetados. A ASI Alliance confirmou que um valor de 1,56 milhão de dólares em FET foi transferido do contrato de conversão e prometeu publicar um relatório completo. Mas, até o momento da publicação do texto original, esse relatório ainda não apareceu, e não foi publicado nenhum plano de compensação para os detentores, nem para os executores de ordens e provedores de liquidez que pagaram dinheiro real para comprar tokens de emissão ilegal.
As assinaturas aceitas pelo contrato da ponte cross-chain eram de fato válidas. O contrato verificou as assinaturas e executou as instruções, mas não verificou se o evento cross-chain alegado pelas assinaturas realmente ocorreu. A cunhagem de NTX da NuNet seguiu outro caminho: o atacante usou diretamente a permissão de mintagem do próprio token.
Uma aliança que sonha com uma IA descentralizada, mas que deixou as permissões de cunhagem de quatro tipos de tokens — e as permissões de liberação de FET a partir de contratos de conversão — ao alcance de uma intrusão em uma única infraestrutura.
Se o futuro retratado por esses projetos é um software executado de forma autônoma, então quem supervisiona o software que possui as chaves?
A ponte cross-chain e os contratos de conversão aceitaram assinaturas do autorizador especificado. Durante a cunhagem cross-chain, o contrato tratou essas assinaturas como uma prova de que o evento correspondente na outra cadeia já havia ocorrido, sem verificar o evento por conta própria. A cunhagem de NTX é diferente: o atacante usou sua permissão de cunhagem e chamou diretamente a função mint() no contrato do token.
A SingularityNET afirmou que um terceiro não autorizado acessou parte de sua infraestrutura em nuvem e, com isso, cunhou tokens e extraiu ativos por meio da infraestrutura da ponte cross-chain. A Fetch.ai, por sua vez, disse que seus contratos não foram afetados. Mas os comunicados públicos não explicaram como o atacante obteve o acesso, nem descreveram com precisão como as diversas permissões foram expostas.
Os registros on-chain permitem rastrear as transações liberadas por essas permissões, mas não conseguem provar como o atacante obteve acesso nem identificar quem tomou as decisões de segurança por trás. A Bitquery descobriu que os endereços dos cinco autorizadores de ponte cross-chain nunca haviam iniciado transações antes, o que é consistente com o fato de que eles eram usados para assinaturas de mensagens off-chain. O contrato verificou as assinaturas.
Quando uma assinatura é tratada como prova, quem verifica se o que ela comprova é realmente verdadeiro?