Em 17 de julho de 2026, a ether.fi anunciou, em conjunto com a Nexus Mutual, uma ap\u00f3lice que cobre at\u00e9 15.000 ETH em perdas por slashing (aproximadamente 28,9 milh\u00f5es de d\u00f3lares, ou cerca de 25,3 milh\u00f5es de euros, ao pre\u00e7o atual do ETH), a maior cobertura deste tipo alguma vez contratada no setor, segundo o noticiado pela Decrypt<\/a>. O an\u00fancio reacende uma pergunta que o setor do restaking tem evitado responder com clareza: o que acontece quando uma \u00fanica falha se propaga em cascata pelos v\u00e1rios servi\u00e7os que um mesmo ETH em restaking est\u00e1 a garantir ao mesmo tempo.<\/p> Desde que o EigenLayer ativou o slashing em produ\u00e7\u00e3o na mainnet, em abril de 2025, as perdas reais atribu\u00edveis a cortes de stake t\u00eam sido pr\u00f3ximas de zero. Mas o facto de operadoras de grande escala como a ether.fi estarem agora a contratar seguro por conta pr\u00f3pria sugere que o apetite por prote\u00e7\u00e3o contra o risco de cauda \u00e9 real, mesmo sem incidentes recentes que o justifiquem publicamente. Este \u00e9, no fundo, o verdadeiro tema do restaking no seu segundo ano de vida: j\u00e1 n\u00e3o \u00e9 apenas uma quest\u00e3o de rendimento adicional, \u00e9 uma quest\u00e3o do que acontece quando algo corre mal, e quem paga a conta quando isso acontece, tema que j\u00e1 explor\u00e1mos em detalhe em \u00abA conta do post-mortem: quem paga quando a cripto \u00e9 hackeada\u00bb<\/a>.<\/p> Este artigo foca-se especificamente no risco de slashing correlacionado, ou seja, a possibilidade de uma falha isolada gerar perdas em v\u00e1rias frentes ao mesmo tempo, e no que os principais protocolos do setor (EigenLayer\/EigenCloud, Symbiotic, Babylon, SSV Network) est\u00e3o, ou n\u00e3o est\u00e3o, a fazer para conter esse risco.<\/p> O restaking \u00e9 a pr\u00e1tica de reutilizar ETH j\u00e1 apostado (staked) na camada de consenso da Ethereum, ou um token que represente essa aposta, para tamb\u00e9m garantir a seguran\u00e7a de servi\u00e7os de terceiros, os chamados AVS (Actively Validated Services): or\u00e1culos, pontes entre blockchains, camadas de disponibilidade de dados, sequenciadores de rollups. Em troca, o utilizador recebe rendimento adicional; em contrapartida, aceita novas condi\u00e7\u00f5es de penaliza\u00e7\u00e3o (slashing) que se somam \u00e0s j\u00e1 existentes ao n\u00edvel do protocolo Ethereum.<\/p> Uma parte significativa deste capital circula sob a forma de tokens de restaking l\u00edquido (LRT), como o eETH da ether.fi ou o ezETH da Renzo, que representam o dep\u00f3sito subjacente e podem ser reutilizados noutras aplica\u00e7\u00f5es de DeFi, uma pr\u00e1tica conhecida como rehipoteca\u00e7\u00e3o. \u00c9 precisamente esta reutiliza\u00e7\u00e3o em camadas sucessivas, staking, restaking, e depois reutiliza\u00e7\u00e3o do LRT noutro protocolo, que torna a pergunta central deste artigo t\u00e3o relevante: cada camada adicional multiplica os pontos onde algo pode correr mal, mesmo que o rendimento anunciado pare\u00e7a simples de somar.<\/p> O conceito foi popularizado pelo EigenLayer e gerou, desde cedo, um aviso p\u00fablico de Vitalik Buterin, cofundador da Ethereum, no seu blog pessoal, em maio de 2023: \u00abDon’t overload Ethereum’s consensus\u00bb<\/a>. Buterin escreveu que \u00abqualquer expans\u00e3o das fun\u00e7\u00f5es do consenso da Ethereum aumenta os custos, a complexidade e os riscos de correr um validador\u00bb, e que o consenso social das comunidades de blockchain \u00ab\u00e9 algo fr\u00e1gil (…) cada extens\u00e3o deste tipo torna o pr\u00f3prio n\u00facleo mais fr\u00e1gil\u00bb. A preocupa\u00e7\u00e3o de fundo: se demasiadas fun\u00e7\u00f5es financeiras complexas passarem a depender do mesmo conjunto de validadores, cria-se um incentivo para resgatar (bail out) protocolos falhados, considerados demasiado grandes para falhar, o que corr\u00f3i a neutralidade da pr\u00f3pria Ethereum.<\/p> Sreeram Kannan, fundador do EigenLayer (entretanto reposicionado como EigenCloud), respondeu publicamente a essa cr\u00edtica numa entrevista \u00e0 CoinDesk<\/a>, argumentando que \u00abtudo o que o restaking pode fazer, o liquid staking j\u00e1 pode fazer\u00bb e que via \u00abo restaking como um risco menor do que o liquid staking\u00bb. \u00c9 uma discord\u00e2ncia que continua por resolver em 2026, e que este artigo usa como pano de fundo para avaliar o que realmente mudou.<\/p> Ao n\u00edvel do protocolo Ethereum, o slashing existe para punir comportamento comprovadamente malicioso ou negligente de um validador, por exemplo assinar dois blocos em conflito na mesma altura (double signing) ou estar offline de forma prolongada. \u00c9 um mecanismo relativamente bem compreendido, com regras fixas e um hist\u00f3rico de v\u00e1rios anos de dados desde o lan\u00e7amento do Beacon Chain.<\/p> O restaking introduz uma segunda camada de slashing, definida n\u00e3o pelo protocolo Ethereum mas por cada AVS individualmente. Cada servi\u00e7o pode definir as suas pr\u00f3prias condi\u00e7\u00f5es de corte: um or\u00e1culo pode penalizar um operador que reporte um pre\u00e7o errado; uma ponte pode penalizar assinaturas fraudulentas; um sequenciador de rollup pode penalizar a produ\u00e7\u00e3o de um bloco inv\u00e1lido. O problema n\u00e3o \u00e9 a exist\u00eancia destas regras por si s\u00f3, mas a possibilidade de o mesmo capital estar exposto a v\u00e1rias regras diferentes, escritas por equipas diferentes, com n\u00edveis de maturidade de auditoria diferentes, ao mesmo tempo.<\/p> \u00c9 esta sobreposi\u00e7\u00e3o que a ind\u00fastria come\u00e7ou a chamar de risco de slashing correlacionado, e \u00e9 o assunto central das pr\u00f3ximas sec\u00e7\u00f5es.<\/p> Risco correlacionado, no contexto do restaking, significa que uma \u00fanica causa raiz (um bug num contrato inteligente, um operador mal configurado, uma chave comprometida) pode gerar penaliza\u00e7\u00f5es em m\u00faltiplos AVS ao mesmo tempo, porque o mesmo stake subjacente estava a garantir todos eles em simult\u00e2neo. Ao contr\u00e1rio de um evento de slashing isolado na camada de consenso da Ethereum, que afeta um validador de cada vez segundo regras conhecidas, uma falha correlacionada pode multiplicar-se pela quantidade de servi\u00e7os a que esse operador est\u00e1 exposto.<\/p> Um cen\u00e1rio ilustrativo, puramente hipot\u00e9tico: um operador que aloque o mesmo stake a um or\u00e1culo, a uma ponte e a um sequenciador de rollup pode, em teoria, ver-se exposto a tr\u00eas eventos de corte distintos se um \u00fanico bug de software partilhado entre esses tr\u00eas clientes for explorado ao mesmo tempo. Nenhum destes servi\u00e7os precisa de estar diretamente ligado aos outros para que isto aconte\u00e7a; basta que dependam do mesmo c\u00f3digo, da mesma infraestrutura, ou do mesmo conjunto de chaves, para que uma falha comum se traduza em m\u00faltiplas penaliza\u00e7\u00f5es simult\u00e2neas em vez de uma s\u00f3.<\/p> Matt Leisinger, cofundador e diretor de produto (Chief Product Officer) da Alluvial, empresa-m\u00e3e da Liquid Collective, resumiu o problema em declara\u00e7\u00f5es citadas pela BeInCrypto<\/a>: \u00abtokens em restaking est\u00e3o muitas vezes expostos a v\u00e1rias redes de validadores. Se uma rede tiver mau desempenho ou violar as regras do protocolo, as penaliza\u00e7\u00f5es de slashing podem propagar-se em cascata por todas as camadas de restaking\u00bb. Leisinger acrescentou que \u00abcada camada de restaking introduz novos contratos inteligentes, aumentando a superf\u00edcie de ataque para exploits\u00bb, e defendeu mais transpar\u00eancia: \u00abisto levanta riscos que os investidores, \u00e0 primeira vista, talvez n\u00e3o conhe\u00e7am, por isso deveria existir transpar\u00eancia sobre quaisquer vetores de risco ou atividade deste tipo que possa afetar o stake de algu\u00e9m\u00bb.<\/p> Vale notar que, at\u00e9 \u00e0 data, os incidentes mais caros do setor n\u00e3o vieram do slashing propriamente dito, mas de falhas de pontes e contratos inteligentes, como o exploit de abril de 2026 que retirou cerca de 292 milh\u00f5es de d\u00f3lares (aproximadamente 256 milh\u00f5es de euros) ao protocolo Kelp DAO atrav\u00e9s de uma ponte cross-chain, com efeitos de cont\u00e1gio na Aave, segundo o relato da CoinDesk<\/a>. Esse epis\u00f3dio, tal como analis\u00e1mos em \u00abAuditado e hackeado: o ponto cego dos post-mortems cripto\u00bb<\/a>, mostra como mesmo protocolos auditados podem falhar por vetores que a auditoria n\u00e3o cobria. \u00c9 um lembrete \u00fatil: o risco correlacionado de slashing \u00e9, at\u00e9 hoje, sobretudo te\u00f3rico e acad\u00e9mico, mas o hist\u00f3rico recente do setor mostra que os vetores de falha reais tendem a aparecer precisamente onde menos se olhou.<\/p> A resposta mais elaborada a este problema, at\u00e9 \u00e0 data, vem do pr\u00f3prio EigenLayer (agora EigenCloud), que descreveu publicamente, desde setembro de 2024, um modelo de seguran\u00e7a assente em dois conceitos: Operator Sets e Unique Stake Allocation. Segundo o blog oficial do EigenCloud<\/a>, cada operador define, para cada AVS a que adere, que fra\u00e7\u00e3o do seu stake fica sujeita a corte por esse servi\u00e7o espec\u00edfico. A regra central: \u00abuma unidade de ETH s\u00f3 pode ser cortada (slashed) por um Operator Set de cada vez\u00bb.<\/p> Na pr\u00e1tica, isto significa que, em vez de um AVS poder, em teoria, reclamar todo o stake delegado a um operador, cada servi\u00e7o s\u00f3 controla a fatia que lhe foi especificamente alocada. O blog descreve o efeito como localiza\u00e7\u00e3o do risco: \u00abcomo o Stake \u00danico de um Operator Set s\u00f3 \u00e9 cort\u00e1vel por esse Operator Set espec\u00edfico, o slashing fica localizado, eliminando a necessidade de um comit\u00e9 de veto comum\u00bb. Isto permite ao EigenLayer continuar a aceitar novos AVS de forma permissionless (sem aprova\u00e7\u00e3o pr\u00e9via de um comit\u00e9 central) sem que isso aumente automaticamente o risco agregado de cada operador individual.<\/p> \u00c9 uma diferen\u00e7a importante face \u00e0 perce\u00e7\u00e3o popular de que o restaking exp\u00f5e cegamente todo o capital de um utilizador a todos os servi\u00e7os simultaneamente. Na arquitetura atual do EigenLayer, essa exposi\u00e7\u00e3o \u00e9, em teoria, configur\u00e1vel e limitada por operador e por servi\u00e7o. Na pr\u00e1tica, por\u00e9m, a decis\u00e3o de quanto alocar a cada AVS continua a caber ao operador, ou ao protocolo de restaking l\u00edquido que gere esse capital em nome do utilizador final, o que desloca o risco de \u00abo protocolo falha\u00bb para \u00abo meu operador fez uma m\u00e1 escolha de aloca\u00e7\u00e3o\u00bb, sem o eliminar por completo.<\/p> Para al\u00e9m da arquitetura dos pr\u00f3prios protocolos, existe tamb\u00e9m investiga\u00e7\u00e3o acad\u00e9mica dedicada a modelar matematicamente at\u00e9 que ponto uma falha se pode propagar. O artigo \u00abRobust Restaking Networks\u00bb<\/a>, de Naveen Durvasula e Tim Roughgarden (Columbia University), publicado no arXiv, prop\u00f5e um enquadramento para medir a robustez de uma rede de restaking atrav\u00e9s da margem entre o custo e o lucro de um ataque.<\/p> O exemplo num\u00e9rico mais citado do artigo ilustra bem a l\u00f3gica: \u00abse o custo de um ataque exceder sempre o lucro do ataque em 10%, ent\u00e3o uma perda s\u00fabita de 0,1% do stake total n\u00e3o pode resultar numa perda final superior a 1,1% do stake total\u00bb. Ou seja, com uma margem de sobrecolateraliza\u00e7\u00e3o suficiente, o efeito de cascata fica matematicamente limitado, mesmo que n\u00e3o seja eliminado por completo. Os autores derivam ainda condi\u00e7\u00f5es de robustez local, aplic\u00e1veis a servi\u00e7os individuais ou a coliga\u00e7\u00f5es de servi\u00e7os, e limites para o comprimento m\u00e1ximo de uma cadeia de ataques em cascata, tudo calcul\u00e1vel em tempo polinomial.<\/p> Na pr\u00e1tica, este tipo de modelo d\u00e1 aos protocolos, e aos pr\u00f3prios operadores, uma forma de quantificar, e n\u00e3o apenas descrever de forma qualitativa, at\u00e9 que ponto uma determinada configura\u00e7\u00e3o de aloca\u00e7\u00e3o de stake \u00e9 segura. Um protocolo pode, por exemplo, usar este enquadramento para decidir qual o limite m\u00e1ximo de stake que permite a um \u00fanico operador alocar a um conjunto de AVS considerados de risco correlacionado (por partilharem c\u00f3digo, infraestrutura ou equipa de desenvolvimento), em vez de deixar essa decis\u00e3o inteiramente a crit\u00e9rio do operador. At\u00e9 \u00e0 data, por\u00e9m, a ado\u00e7\u00e3o destes modelos pelos protocolos em produ\u00e7\u00e3o parece ainda limitada, mais um t\u00f3pico de investiga\u00e7\u00e3o ativa do que uma norma de engenharia obrigat\u00f3ria em toda a ind\u00fastria.<\/p> A tabela seguinte resume, de forma necessariamente simplificada, a abordagem de quatro dos principais protocolos do setor ao problema do isolamento de risco. Os valores de TVL (valor total bloqueado) variam significativamente consoante a fonte e a data de consulta, uma caracter\u00edstica persistente deste setor, pelo que devem ser lidos como ordens de grandeza e n\u00e3o como n\u00fameros exatos. Os pre\u00e7os dos tokens EIGEN e SSV citados foram consultados diretamente na CoinGecko (EIGEN)<\/a> e na CoinGecko (SSV)<\/a>; o valor da Babylon corresponde ao indicado pelo painel oficial do protocolo<\/a>.<\/p>O que \u00e9 o restaking, em poucas palavras<\/h2>
Slashing: o mecanismo de puni\u00e7\u00e3o que poucos utilizadores compreendem<\/h2>
O problema do risco correlacionado: uma falha, muitas perdas<\/h2>
Como o EigenLayer tenta isolar o risco: Operator Sets e Unique Stake Allocation<\/h2>
A matem\u00e1tica da cascata: o que diz a investiga\u00e7\u00e3o acad\u00e9mica<\/h2>
Tabela: como cada protocolo lida com o risco de slashing<\/h2>