A verdade explosiva por trás dos bots de criptomoedas que antecipam ladrões para "salvar" fundos — mas eles decidem quem é reembolsado

Fonte: CryptoNewsNet Título Original: Explosive truth behind crypto bots that front-run thieves to “save” funds — but they decide who gets paid back Link Original:

O Incidente Makina Finance

Makina Finance perdeu 1.299 ETH, aproximadamente 4,13 milhões de dólares, numa exploração de empréstimo instantâneo e manipulação de oráculos.

O atacante esvaziou os fundos do protocolo e transmitiu a transação para o mempool público do Ethereum, onde deveria ter sido detectada pelos validadores e incluída no próximo bloco.

Em vez disso, um construtor MEV identificado pelo endereço 0xa6c2 front-runou a transação de esvaziamento, redirecionando a maior parte dos fundos para uma custódia controlada pelo construtor antes que o hacker pudesse movê-los para fora da cadeia.

A transação do hacker falhou. Os fundos foram parar em dois endereços associados ao construtor MEV.

A conclusão imediata é que os utilizadores do Makina evitaram uma perda total. O sinal mais profundo é quem acabou por segurar o dinheiro e o que isso significa para a arquitetura emergente de resposta a emergências no mundo cripto.

O ator mais importante nesta história não é o atacante ou o protocolo, mas a cadeia de fornecimento de construção de blocos que interceptou a exploração e agora controla se os utilizadores recuperam os seus fundos, sob que condições, e com que rapidez.

Bots e construtores MEV estão a tornar-se na última linha de defesa do cripto, não por design, mas por posição estrutural. Isso é um problema, porque a capacidade de resgate está concentrada nas mãos de intermediários que maximizam lucros, operando com responsabilidade pouco clara.

MEV como uma rede de segurança já é um padrão

O incidente Makina não é um caso isolado. A Chainalysis documentou uma dinâmica semelhante durante a exploração do Curve e Vyper em 2023, observando que hackers de chapéu branco e operadores de bots MEV ajudaram a recuperar fundos, reduzindo as perdas realizadas abaixo das estimativas iniciais.

O padrão é mecânico: enquanto as explorações ou tentativas de resgate forem visíveis nos canais públicos de transações, buscadores e construtores sofisticados podem competir para reordenar transações.

Às vezes salvam fundos. Às vezes capturam-nos. De qualquer forma, atuam como uma camada de resposta a emergências de facto.

Quando uma transação de exploração entra no mempool público, os buscadores MEV monitorizam oportunidades lucrativas. Se um hacker esvazia um protocolo e transmite a transação publicamente, um buscador pode construir uma transação concorrente que seja executada primeiro, redirecionando os fundos para um endereço diferente.

O buscador agrupa a transação e submetê-la a um construtor de blocos, que a inclui se o lucro superar as ofertas concorrentes. Se o bloco do construtor for escolhido por um validador, a transação do buscador é executada, e a transação do hacker falha.

Isto é extração de lucro com um efeito secundário benéfico, e não puro altruísmo. Mas também é o mecanismo mais fiável que o cripto desenvolveu para interceptar explorações em tempo real, porque opera na camada de ordenação de transações, em vez de depender de circuit breakers ou intervenções de governança ao nível do protocolo.

Porque a dependência de construtores MEV é desconfortável

O problema com os resgates baseados em MEV é que concentram a capacidade de resposta a emergências numa cadeia altamente intermediada.

No Ethereum, o MEV-Boost domina a produção de blocos. O panorama de retransmissão do Rated mostra que cerca de 93,5% dos blocos recentes são roteados via MEV-Boost, em comparação com cerca de 6% usando produção de blocos padrão.

Dentro do MEV-Boost, a quota de mercado dos Relays está ainda mais concentrada: a Ultra Sound Money representa cerca de 29,84% do tráfego de relays, e a Titan cerca de 24,24%, o que significa que os dois maiores relays juntos gerem mais de 54% da produção de blocos.

Se a maioria dos blocos passa pelo MEV-Boost e a maior parte do tráfego do MEV-Boost passa por dois relays, a camada de resgate depende estruturalmente de um pequeno conjunto de intermediários. Isso cria rapidamente problemas de governança.

Se um construtor acabar por segurar fundos resgatados, quem autoriza a custódia? Quem define a recompensa? O que impede extorsão ou exigências de resgate? E se o construtor estiver offshore, anónimo, ou a operar numa jurisdição com aplicação fraca da lei?

O caso Makina ilustra o problema. Os fundos estão na custódia do construtor, mas não há SLA público, recompensa pré-definida, ou mecanismo claro para devolver os fundos ao Makina ou aos seus utilizadores.

O construtor poderia devolver voluntariamente os fundos, negociar uma recompensa, exigir uma taxa mais elevada do que as normas do setor, ou recusar-se a devolver os fundos.

O roteamento privado agrava o problema

Um artigo académico de 2025 intitulado “Sandwiched and Silent” documentou um amplo roteamento privado de transações e constatou que muitas vítimas migram para canais privados após serem “sandwiched” por bots MEV.

No entanto, o roteamento privado não elimina o MEV, apenas o desloca dos mempools públicos para canais de encomenda privados controlados por construtores e relays.

Para os protocolos, isso significa que os resgates no mempool público se tornam menos fiáveis, pois as transações de exploração cada vez mais passam por canais privados acessíveis apenas a um subconjunto de construtores.

Uma tentativa de civilizar o caos

Safe Harbor é uma estrutura desenvolvida pela SEAL que procura substituir o modelo de “construtor MEV como custodiante acidental” por respondedores autorizados, SLAs explícitos, e incentivos limitados.

A SEAL descreve o Safe Harbor como uma estrutura legal e técnica que permite aos protocolos pré-autorizar chapéus brancos a intervir durante explorações ativas.

A regra operacional principal é que os fundos resgatados devem ser enviados para endereços de recuperação oficiais dentro de 72 horas, com recompensas pré-definidas e executáveis.

A SEAL afirma que o Safe Harbor foi motivado pelo hack Nomad, onde os chapéus brancos estavam dispostos a ajudar, mas estavam limitados por ambiguidades legais sobre se devolver fundos poderia ser processado como acesso não autorizado a computadores.

O Safe Harbor elimina essa ambiguidade ao dar aos protocolos uma forma de pré-autorizar intervenções e definir termos claros. A SEAL afirma que o Safe Harbor já está a proteger mais de $16 biliões de dólares em vários protocolos principais, incluindo certos DEXs, Pendle, algumas soluções layer-2, e zkSync.

A Immunefi, a plataforma de recompensas por bugs, operacionalizou o Safe Harbor com termos mais rigorosos.

A Immunefi descreve o Safe Harbor como uma estrutura desenvolvida pela SEAL que redireciona fundos para um cofre controlado pelo protocolo na plataforma da Immunefi. Na página do programa Safe Harbor da Immunefi, os termos dizem: “Tem 6 horas para transferir os fundos de volta.”

O não cumprimento do prazo de seis horas constitui uma violação material. Isso é quatro vezes mais rápido do que o requisito padrão de 72 horas da SEAL.

O Safe Harbor não elimina a dependência da infraestrutura de MEV. Em vez disso, tenta apenas formalizá-la.

Se um construtor front-runear uma exploração e o protocolo tiver adotado o Safe Harbor, espera-se que o construtor reconheça a intervenção como autorizada e redirecione os fundos para o endereço de recuperação designado pelo protocolo dentro do SLA.

Mas isso pressupõe que os construtores monitorizem os registos do Safe Harbor, respeitem os termos, e priorizem a conformidade sobre o lucro.

Faixa de cenários

A taxa de recuperação esperada do utilizador numa exploração pode ser modelada como: recuperação esperada = probabilidade de intervenção x (1 - percentagem de recompensa) x (1 - percentagem de falha ou fuga).

O Safe Harbor pretende aumentar a probabilidade de intervenção ao reduzir a ambiguidade legal e limitar a percentagem de recompensa antecipadamente.

No caso base, a adoção do Safe Harbor aumenta nos próximos 12 meses. Mais protocolos estão a acrescentar termos do Safe Harbor às suas estruturas de governança, e mais chapéus brancos estão a registar-se como respondedores autorizados.

A probabilidade de intervenção aumenta porque os respondedores têm clareza legal e termos de recompensa fixos. As taxas de recuperação melhoram, especialmente para protocolos que adotam SLAs mais rigorosos, como a janela de seis horas da Immunefi.

No cenário otimista, a camada de resgate torna-se profissional. Os protocolos constroem endereços de cofres seguros, comprimem os SLAs para horas, e pré-negociam cronogramas de recompensas com equipas de chapéus brancos conhecidas.

Os construtores integram os registos do Safe Harbor nos seus algoritmos de ordenação de transações, redirecionando automaticamente os fundos resgatados para os endereços designados sem intervenção manual.

No cenário pessimista, a dependência dos construtores endurece. O fluxo privado de encomendas e a concentração de relays tornam os resgates menos transparentes e mais oligopolísticos. Protocolos que não adotaram o Safe Harbor acabam por negociar com construtores após o facto, sem alavancagem ou SLA claros.

A governança torna-se dependente de intermediários que seguram fundos e definem termos unilateralmente.