Restaking em 2026: o slashing em cascata e a corrida ao seguro

Porque é que o risco do restaking voltou à conversa em 2026

Em 17 de julho de 2026, a ether.fi anunciou, em conjunto com a Nexus Mutual, uma apólice que cobre até 15.000 ETH em perdas por slashing (aproximadamente 28,9 milhões de dólares, ou cerca de 25,3 milhões de euros, ao preço atual do ETH), a maior cobertura deste tipo alguma vez contratada no setor, segundo o noticiado pela Decrypt. O anúncio reacende uma pergunta que o setor do restaking tem evitado responder com clareza: o que acontece quando uma única falha se propaga em cascata pelos vários serviços que um mesmo ETH em restaking está a garantir ao mesmo tempo.

Desde que o EigenLayer ativou o slashing em produção na mainnet, em abril de 2025, as perdas reais atribuíveis a cortes de stake têm sido próximas de zero. Mas o facto de operadoras de grande escala como a ether.fi estarem agora a contratar seguro por conta própria sugere que o apetite por proteção contra o risco de cauda é real, mesmo sem incidentes recentes que o justifiquem publicamente. Este é, no fundo, o verdadeiro tema do restaking no seu segundo ano de vida: já não é apenas uma questão de rendimento adicional, é uma questão do que acontece quando algo corre mal, e quem paga a conta quando isso acontece, tema que já explorámos em detalhe em «A conta do post-mortem: quem paga quando a cripto é hackeada».

Este artigo foca-se especificamente no risco de slashing correlacionado, ou seja, a possibilidade de uma falha isolada gerar perdas em várias frentes ao mesmo tempo, e no que os principais protocolos do setor (EigenLayer/EigenCloud, Symbiotic, Babylon, SSV Network) estão, ou não estão, a fazer para conter esse risco.

O que é o restaking, em poucas palavras

O restaking é a prática de reutilizar ETH já apostado (staked) na camada de consenso da Ethereum, ou um token que represente essa aposta, para também garantir a segurança de serviços de terceiros, os chamados AVS (Actively Validated Services): oráculos, pontes entre blockchains, camadas de disponibilidade de dados, sequenciadores de rollups. Em troca, o utilizador recebe rendimento adicional; em contrapartida, aceita novas condições de penalização (slashing) que se somam às já existentes ao nível do protocolo Ethereum.

Uma parte significativa deste capital circula sob a forma de tokens de restaking líquido (LRT), como o eETH da ether.fi ou o ezETH da Renzo, que representam o depósito subjacente e podem ser reutilizados noutras aplicações de DeFi, uma prática conhecida como rehipotecação. É precisamente esta reutilização em camadas sucessivas, staking, restaking, e depois reutilização do LRT noutro protocolo, que torna a pergunta central deste artigo tão relevante: cada camada adicional multiplica os pontos onde algo pode correr mal, mesmo que o rendimento anunciado pareça simples de somar.

O conceito foi popularizado pelo EigenLayer e gerou, desde cedo, um aviso público de Vitalik Buterin, cofundador da Ethereum, no seu blog pessoal, em maio de 2023: «Don’t overload Ethereum’s consensus». Buterin escreveu que «qualquer expansão das funções do consenso da Ethereum aumenta os custos, a complexidade e os riscos de correr um validador», e que o consenso social das comunidades de blockchain «é algo frágil (…) cada extensão deste tipo torna o próprio núcleo mais frágil». A preocupação de fundo: se demasiadas funções 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ói a neutralidade da própria Ethereum.

Sreeram Kannan, fundador do EigenLayer (entretanto reposicionado como EigenCloud), respondeu publicamente a essa crítica numa entrevista à CoinDesk, argumentando que «tudo o que o restaking pode fazer, o liquid staking já pode fazer» e que via «o restaking como um risco menor do que o liquid staking». É uma discordância que continua por resolver em 2026, e que este artigo usa como pano de fundo para avaliar o que realmente mudou.

Slashing: o mecanismo de punição que poucos utilizadores compreendem

Ao nível 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. É um mecanismo relativamente bem compreendido, com regras fixas e um histórico de vários anos de dados desde o lançamento do Beacon Chain.

O restaking introduz uma segunda camada de slashing, definida não pelo protocolo Ethereum mas por cada AVS individualmente. Cada serviço pode definir as suas próprias condições de corte: um oráculo pode penalizar um operador que reporte um preço errado; uma ponte pode penalizar assinaturas fraudulentas; um sequenciador de rollup pode penalizar a produção de um bloco inválido. O problema não é a existência destas regras por si só, mas a possibilidade de o mesmo capital estar exposto a várias regras diferentes, escritas por equipas diferentes, com níveis de maturidade de auditoria diferentes, ao mesmo tempo.

É esta sobreposição que a indústria começou a chamar de risco de slashing correlacionado, e é o assunto central das próximas secções.

O problema do risco correlacionado: uma falha, muitas perdas

Risco correlacionado, no contexto do restaking, significa que uma única causa raiz (um bug num contrato inteligente, um operador mal configurado, uma chave comprometida) pode gerar penalizações em múltiplos AVS ao mesmo tempo, porque o mesmo stake subjacente estava a garantir todos eles em simultâneo. Ao contrário 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ços a que esse operador está exposto.

Um cenário ilustrativo, puramente hipotético: um operador que aloque o mesmo stake a um oráculo, a uma ponte e a um sequenciador de rollup pode, em teoria, ver-se exposto a três eventos de corte distintos se um único bug de software partilhado entre esses três clientes for explorado ao mesmo tempo. Nenhum destes serviços precisa de estar diretamente ligado aos outros para que isto aconteça; basta que dependam do mesmo código, da mesma infraestrutura, ou do mesmo conjunto de chaves, para que uma falha comum se traduza em múltiplas penalizações simultâneas em vez de uma só.

Matt Leisinger, cofundador e diretor de produto (Chief Product Officer) da Alluvial, empresa-mãe da Liquid Collective, resumiu o problema em declarações citadas pela BeInCrypto: «tokens em restaking estão muitas vezes expostos a várias redes de validadores. Se uma rede tiver mau desempenho ou violar as regras do protocolo, as penalizações de slashing podem propagar-se em cascata por todas as camadas de restaking». Leisinger acrescentou que «cada camada de restaking introduz novos contratos inteligentes, aumentando a superfície de ataque para exploits», e defendeu mais transparência: «isto levanta riscos que os investidores, à primeira vista, talvez não conheçam, por isso deveria existir transparência sobre quaisquer vetores de risco ou atividade deste tipo que possa afetar o stake de alguém».

Vale notar que, até à data, os incidentes mais caros do setor não 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ões de dólares (aproximadamente 256 milhões de euros) ao protocolo Kelp DAO através de uma ponte cross-chain, com efeitos de contágio na Aave, segundo o relato da CoinDesk. Esse episódio, tal como analisámos em «Auditado e hackeado: o ponto cego dos post-mortems cripto», mostra como mesmo protocolos auditados podem falhar por vetores que a auditoria não cobria. É um lembrete útil: o risco correlacionado de slashing é, até hoje, sobretudo teórico e académico, mas o histórico recente do setor mostra que os vetores de falha reais tendem a aparecer precisamente onde menos se olhou.

Como o EigenLayer tenta isolar o risco: Operator Sets e Unique Stake Allocation

A resposta mais elaborada a este problema, até à data, vem do próprio EigenLayer (agora EigenCloud), que descreveu publicamente, desde setembro de 2024, um modelo de segurança assente em dois conceitos: Operator Sets e Unique Stake Allocation. Segundo o blog oficial do EigenCloud, cada operador define, para cada AVS a que adere, que fração do seu stake fica sujeita a corte por esse serviço específico. A regra central: «uma unidade de ETH só pode ser cortada (slashed) por um Operator Set de cada vez».

Na prática, isto significa que, em vez de um AVS poder, em teoria, reclamar todo o stake delegado a um operador, cada serviço só controla a fatia que lhe foi especificamente alocada. O blog descreve o efeito como localização do risco: «como o Stake Único de um Operator Set só é cortável por esse Operator Set específico, o slashing fica localizado, eliminando a necessidade de um comité de veto comum». Isto permite ao EigenLayer continuar a aceitar novos AVS de forma permissionless (sem aprovação prévia de um comité central) sem que isso aumente automaticamente o risco agregado de cada operador individual.

É uma diferença importante face à perceção popular de que o restaking expõe cegamente todo o capital de um utilizador a todos os serviços simultaneamente. Na arquitetura atual do EigenLayer, essa exposição é, em teoria, configurável e limitada por operador e por serviço. Na prática, porém, a decisão de quanto alocar a cada AVS continua a caber ao operador, ou ao protocolo de restaking líquido que gere esse capital em nome do utilizador final, o que desloca o risco de «o protocolo falha» para «o meu operador fez uma má escolha de alocação», sem o eliminar por completo.

A matemática da cascata: o que diz a investigação académica

Para além da arquitetura dos próprios protocolos, existe também investigação académica dedicada a modelar matematicamente até que ponto uma falha se pode propagar. O artigo «Robust Restaking Networks», de Naveen Durvasula e Tim Roughgarden (Columbia University), publicado no arXiv, propõe um enquadramento para medir a robustez de uma rede de restaking através da margem entre o custo e o lucro de um ataque.

O exemplo numérico mais citado do artigo ilustra bem a lógica: «se o custo de um ataque exceder sempre o lucro do ataque em 10%, então uma perda súbita de 0,1% do stake total não pode resultar numa perda final superior a 1,1% do stake total». Ou seja, com uma margem de sobrecolateralização suficiente, o efeito de cascata fica matematicamente limitado, mesmo que não seja eliminado por completo. Os autores derivam ainda condições de robustez local, aplicáveis a serviços individuais ou a coligações de serviços, e limites para o comprimento máximo de uma cadeia de ataques em cascata, tudo calculável em tempo polinomial.

Na prática, este tipo de modelo dá aos protocolos, e aos próprios operadores, uma forma de quantificar, e não apenas descrever de forma qualitativa, até que ponto uma determinada configuração de alocação de stake é segura. Um protocolo pode, por exemplo, usar este enquadramento para decidir qual o limite máximo de stake que permite a um único operador alocar a um conjunto de AVS considerados de risco correlacionado (por partilharem código, infraestrutura ou equipa de desenvolvimento), em vez de deixar essa decisão inteiramente a critério do operador. Até à data, porém, a adoção destes modelos pelos protocolos em produção parece ainda limitada, mais um tópico de investigação ativa do que uma norma de engenharia obrigatória em toda a indústria.

Tabela: como cada protocolo lida com o risco de slashing

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ística persistente deste setor, pelo que devem ser lidos como ordens de grandeza e não como números exatos. Os preços dos tokens EIGEN e SSV citados foram consultados diretamente na CoinGecko (EIGEN) e na CoinGecko (SSV); o valor da Babylon corresponde ao indicado pelo painel oficial do protocolo.

Como a tabela sugere, não existe ainda um padrão único da indústria. O EigenLayer aposta em isolamento granular por operador e por serviço; a Symbiotic aposta em isolamento por vault com resolução de disputas delegada a terceiros; a Babylon simplifica o problema ao manter o BTC bloqueado por scripts nativos do próprio Bitcoin, ligados a um único fornecedor de finalidade escolhido pelo staker; a SSV Network protege o capital principal do validador por definição, e deixa cada bApp definir o seu próprio apetite de risco através do que a rede chama Risk Expressive Model.

O seguro chega ao restaking: o acordo entre a ether.fi e a Nexus Mutual

A resposta de mercado mais recente ao problema do risco de slashing não veio da engenharia de protocolo, mas de um produto de seguro. A 17 de julho de 2026, a ether.fi, uma das maiores operadoras de staking e restaking da Ethereum, com mais de 6 mil milhões de dólares em ativos sob gestão distribuídos pelos seus produtos Cash, Stake e Liquid, anunciou uma apólice com a Nexus Mutual que cobre até 15.000 ETH em perdas por slashing, segundo a Decrypt.

Mike Silagadze, fundador e CEO da ether.fi, justificou o investimento: «sempre acreditámos que os protocolos mais seguros acabarão por vencer. É por isso que investimos fortemente em auditorias, segurança operacional, arquitetura de staking, e agora no maior programa de seguros do setor». Hugh Karp, fundador da Nexus Mutual, descreveu o acordo como «um passo histórico, e estamos orgulhosos de que tenham escolhido a Nexus Mutual para o dar».

Na prática, esta apólice não elimina o risco de slashing correlacionado descrito nas secções anteriores, apenas transfere uma parte financeira desse risco para uma seguradora descentralizada, financiada pelos seus próprios membros e reservas de capital, à semelhança do que uma resseguradora tradicional faria no setor financeiro convencional. É, ainda assim, um sinal relevante: mesmo sem um grande incidente de slashing documentado até à data, um dos maiores operadores da Ethereum considerou que o risco de cauda justificava uma cobertura recorde.

A cobertura em camadas da Liquid Collective: um modelo para o staking institucional

Um modelo mais estruturado, pensado especificamente para clientes institucionais, é o programa de cobertura da Liquid Collective, o protocolo de liquid staking apoiado pela Alluvial, com participação de nomes como Coinbase, Kraken, Figment e Kiln na sua conceção original. Segundo o próprio site da Liquid Collective, o programa funciona em três camadas, pensadas para dar a uma tesouraria institucional uma resposta clara à pergunta «quem paga, e quanto, se algo correr mal».

A lógica em camadas é a seguinte: se um incidente afetar a rede como um todo, a tesouraria paga a franquia da apólice da Nexus Mutual; se o incidente for causado pela infraestrutura de um operador específico, esse operador paga primeiro, antes de a cobertura de terceiros ser acionada. É um desenho que distribui o risco entre três partes com incentivos distintos, o protocolo, o mercado segurador e os operadores individuais, em vez de o concentrar apenas num fundo de reserva do protocolo ou apenas numa apólice externa.

Vale notar que a Liquid Collective é, tecnicamente, um protocolo de liquid staking, não de restaking; a distinção importa porque o staking simples só está exposto ao slashing da camada de consenso da Ethereum, não ao risco correlacionado entre múltiplos AVS descrito atrás. Ainda assim, serve de referência útil sobre como o mercado de seguros de staking em sentido lato está a amadurecer, e é razoável esperar que produtos equivalentes, com camadas semelhantes, cheguem também ao restaking puro nos próximos trimestres.

Vozes divergentes: risco menor do que o liquid staking, ou uma bomba-relógio adiada?

Nem todos concordam sobre a gravidade real deste risco. Sreeram Kannan mantém, desde 2023, a posição de que o restaking, bem desenhado, é «um risco menor do que o liquid staking», precisamente porque mecanismos como o Unique Stake Allocation permitem limitar e tornar explícita a exposição de cada operador, em vez de a deixar implícita e mal compreendida, como acontecia nos primeiros protocolos de liquid staking. Do outro lado, Leisinger insiste que a arquitetura em camadas do restaking aumenta, por definição, a superfície de ataque, independentemente de quão bem isolado esteja o slashing em teoria.

A verdade está provavelmente algures no meio. O historial de incidentes reais do setor até meados de 2026 aponta para falhas de ponte e de contrato inteligente, não para slashing correlacionado em si: o caso Kelp DAO/Aave, referido atrás, resultou de uma ponte cross-chain mal configurada, não de uma cascata de penalizações entre AVS. A recuperação desse incidente envolveu uma coligação informal de protocolos, incluindo a Lido, a própria ether.fi e a Consensys, além do fundador da Aave, Stani Kulechov, que chegou a comprometer pessoalmente 5.000 ETH para o esforço de recuperação. Isso ilustra como, na prática, o setor tem vindo a resolver crises através de coordenação informal entre protagonistas, mais do que através de apólices de seguro formais. Sobre até que ponto essa coordenação ad-hoc é sustentável à escala, ou se acaba antes em disputas mais formais e morosas, escrevemos em detalhe em «Quando o post-mortem cripto acaba em tribunal».

O ponto de maior consenso entre as duas posições é este: o risco de slashing correlacionado continua, até à data, largamente teórico. Os produtos de seguro que estão a surgir em 2026 parecem, por isso, mais uma resposta preventiva ao medo desse risco, e à pressão competitiva para atrair capital institucional mais avesso a risco, do que uma resposta reativa a perdas já sofridas.

Há ainda um terceiro elemento na equação, que é precisamente o que Vitalik Buterin tinha em mente em 2023: a possibilidade de um protocolo de restaking se tornar «demasiado grande para falhar», ao ponto de a própria comunidade se sentir obrigada a organizar um resgate informal sempre que algo corre mal, como aconteceu com o Kelp DAO. Isso cria um incentivo perverso: se os utilizadores souberem, ou suspeitarem, que uma coligação de protocolos maiores vai intervir em caso de crise, a disciplina de mercado para avaliar corretamente o risco antes de investir tende a enfraquecer, o que é exatamente o argumento original de Buterin contra sobrecarregar o consenso da Ethereum com demasiadas funções financeiras interdependentes.

O que isto significa para as tesourarias corporativas e institucionais

A questão do risco de slashing correlacionado deixou de ser apenas uma discussão de nicho entre engenheiros de protocolo, porque cada vez mais capital institucional está a chegar ao setor através de vias diretas. Casos como o de uma empresa de tesouraria em ETH que destinou uma fatia significativa das suas reservas a restaking através da EigenCloud, ou o de uma criadora de mercado europeia que passou a operar como operadora numa AVS de crédito privado construída sobre o EigenLayer, mostram que este deixou de ser um mercado dominado apenas por utilizadores individuais early adopters.

Para empresas que seguem uma estratégia de tesouraria em cripto, como temos vindo a acompanhar em «Tesourarias cripto corporativas: o guia completo de 2026», o cálculo é distinto do de um utilizador individual: o rendimento adicional do restaking tem de ser justificado perante um conselho de administração e, cada vez mais, perante auditores externos e reguladores de mercados de capitais, não apenas perante o apetite de risco do próprio investidor. Isso implica, normalmente, exigir due diligence documentada sobre o modelo de isolamento de risco de cada AVS específico, sobre a existência (ou ausência) de cobertura de seguro, e sobre quem, na prática, responde financeiramente por uma eventual perda.

A existência de produtos como a apólice da ether.fi com a Nexus Mutual, ou o programa em camadas da Liquid Collective, é, também por isso, mais relevante para este público institucional do que para o utilizador de retalho médio: é o tipo de garantia contratual que um departamento de gestão de risco corporativo consegue efetivamente avaliar e documentar, ao contrário de um simples argumento de que «a arquitetura é segura».

Portugal, a CMVM e o vazio regulatório dos seguros de slashing

Em Portugal, o quadro regulatório do MiCA (Markets in Crypto-Assets) já está em vigor a título definitivo: o período transitório para prestadores de serviços de criptoativos (CASP) terminou a 1 de julho de 2026, ao abrigo da Lei n.º 69/2025, de 22 de dezembro, em vigor desde 27 de dezembro de 2025. Nesse enquadramento, o Banco de Portugal é responsável pela supervisão prudencial e pela autorização de CASP, enquanto a CMVM (Comissão do Mercado de Valores Mobiliários) supervisiona a conduta de mercado e deteta práticas de abuso de mercado, ao abrigo dos Títulos II e VI do MiCA.

O problema, do ponto de vista regulatório, é que nem o MiCA nem a legislação nacional foram desenhados a pensar em produtos como uma apólice de seguro contra slashing, emitida por uma seguradora descentralizada sem intermediário regulado. Uma apólice da Nexus Mutual não é um contrato de seguro na aceção da Diretiva Solvência II, nem está sujeita à supervisão da Autoridade de Supervisão de Seguros e Fundos de Pensões; é, tecnicamente, um contrato entre membros de uma mutualidade descentralizada, regido por regras de protocolo e votação on-chain, não pela legislação nacional de seguros. Para um investidor de retalho português, isto significa que, ao contrário de um seguro tradicional, não existe o mesmo tipo de proteção legal, fundo de garantia, ou via de reclamação junto de um regulador nacional, caso a apólice não pague como esperado.

Esta não é uma lacuna exclusivamente portuguesa: é, no essencial, uma lacuna à escala de toda a União Europeia, já que o MiCA foi desenhado sobretudo para regular emitentes de criptoativos e prestadores de serviços, não produtos de cobertura mutualizada e descentralizada como os aqui descritos. Também vale a pena notar que a interação direta com um protocolo de restaking, sem intermediário custodiante, tende a cair fora do âmbito direto do MiCA, ao passo que serviços de staking ou restaking «como serviço», oferecidos por um CASP autorizado, já caem dentro do perímetro de supervisão da CMVM e do Banco de Portugal. É uma distinção que qualquer investidor português deve procurar perceber antes de decidir onde, e como, expor capital a este setor.

Como avaliar o risco antes de expor capital ao restaking

Independentemente de se tratar de um utilizador individual ou de uma tesouraria institucional, a literatura académica e as próprias declarações da indústria sugerem um conjunto de perguntas práticas a fazer antes de expor capital a qualquer protocolo de restaking.

• A que AVS específicos o meu stake está, ou pode vir a estar, exposto, e qual a soma acumulada do meu risco de corte teórico em todos eles.
• O protocolo isola o risco por serviço, como o Unique Stake Allocation do EigenLayer, ou expõe o stake de forma mais indiferenciada.
• Existe alguma cobertura de seguro contratada e, se sim, qual o limite máximo, quem a fornece e que franquias se aplicam.
• Qual foi o histórico real de incidentes do protocolo, não apenas de slashing, mas também de pontes e contratos inteligentes associados.
• Quem, na prática, responde financeiramente por uma perda: o protocolo, uma tesouraria, uma seguradora externa, ou apenas o próprio utilizador.

Nenhuma destas perguntas tem, atualmente, uma resposta universalmente satisfatória em todos os protocolos do setor, o que é, em si mesmo, um dado relevante para qualquer decisão de alocação de capital.

O que vem a seguir

É razoável esperar que 2026 continue a trazer mais produtos de seguro e mais mecanismos de isolamento de risco, à medida que mais capital institucional pondera entrar no setor. A SSV Network, cujo modelo já protege por definição o capital principal do validador, poderia estender essa lógica ao capital delegado através de produtos de cobertura equivalentes aos da ether.fi ou da Liquid Collective. Também é plausível que protocolos de restaking de Bitcoin, como a Babylon, que já permitem a alguns custodiantes institucionais apostar BTC diretamente sem necessidade de bridging, acabem por oferecer estruturas de cobertura semelhantes às que já existem do lado da Ethereum.

Também é expectável mais pressão, regulatória e de mercado, para tornar o risco correlacionado mais visível e mais fácil de auditar externamente, em linha com o que ferramentas de monitorização on-chain já permitem detetar noutros contextos de mercado, como analisámos em «Whale alerts: o que os movimentos das baleias revelam»: capital institucional a sair rapidamente de um protocolo é, muitas vezes, o primeiro sinal visível de que algo está errado, ainda antes de qualquer comunicado oficial confirmar um incidente.

O mais provável, olhando para o que já aconteceu com o liquid staking nos últimos anos, é que o setor do restaking só resolva verdadeiramente esta questão depois de um primeiro incidente de slashing correlacionado à escala real, tal como o incidente da Kelp DAO/Aave forçou o setor a repensar a forma como avalia o risco de pontes cross-chain aceites como colateral. Até lá, seguros como o da ether.fi funcionam como uma aposta preventiva, mais do que como prova de que o problema já está resolvido.

Perguntas frequentes sobre o risco de slashing no restaking

O que é o risco de slashing correlacionado no restaking?

É a possibilidade de uma única falha, como um bug num contrato inteligente ou um operador mal configurado, provocar penalizações em vários serviços (AVS) ao mesmo tempo, porque o mesmo stake estava a garantir todos eles em simultâneo. Ao contrário do slashing simples da camada de consenso da Ethereum, que afeta um validador de cada vez segundo regras fixas, uma falha correlacionada pode multiplicar-se pela quantidade de serviços a que um operador está exposto.

O restaking já tem seguro contra perdas por slashing?

Sim, embora ainda de forma limitada. A ether.fi anunciou, em julho de 2026, uma apólice com a Nexus Mutual que cobre até 15.000 ETH em perdas por slashing, descrita como a maior cobertura deste tipo até à data. A Liquid Collective, focada em staking simples, opera um programa de cobertura em três camadas, combinando uma seguradora externa, uma tesouraria própria e compromissos dos operadores de nó.

Como é que o EigenLayer isola o risco de slashing entre diferentes AVS?

Através de um modelo chamado Operator Sets e Unique Stake Allocation, em que cada operador define, para cada serviço a que adere, que fração do seu stake fica sujeita a corte por esse serviço específico. A regra central é que uma unidade de ETH só pode ser cortada por um Operator Set de cada vez, o que localiza o risco em vez de o expor de forma indiferenciada a todos os serviços simultaneamente.

O restaking é mais arriscado do que o liquid staking normal?

É uma questão em aberto. Sreeram Kannan, fundador do EigenLayer, defende que o restaking bem desenhado é um risco menor do que o liquid staking, porque a exposição de cada operador pode ser tornada explícita e limitada. Outros, como Matt Leisinger, da Alluvial, argumentam que cada camada adicional de restaking aumenta necessariamente a superfície de ataque, independentemente do isolamento teórico do slashing.

O restaking está regulado em Portugal?

A interação direta com um protocolo de restaking descentralizado tende a cair fora do âmbito direto do MiCA, que regula sobretudo emitentes e prestadores de serviços. Já os serviços de staking ou restaking oferecidos «como serviço» por um prestador autorizado (CASP) caem dentro do perímetro de supervisão da CMVM e do Banco de Portugal. Produtos de seguro descentralizado, como as apólices da Nexus Mutual, não são regulados como contratos de seguro tradicionais em Portugal.

Redação HOGE Wire, secção DeFi e On-Chain.