---
title: "Risco de slashing correlacionado no restaking"
description: "O restaking pode expor uma carteira a vários serviços sujeitos a slashing. Entenda como operadores, software, infraestrutura e atrasos de saída compartilhados podem gerar perdas correlacionadas."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Risco de slashing correlacionado no restaking
> Somente para fins educacionais; não constitui aconselhamento de investimento. O restaking pode causar perda parcial ou total do principal.
## Resposta direta
Risco de slashing correlacionado é a possibilidade de uma falha subjacente causar perdas simultâneas em várias exposições de restaking. Operadores, sistemas de assinatura, clientes, regiões de nuvem, oráculos, governança e contratos inteligentes compartilhados podem fazer serviços aparentemente separados falharem juntos.
O restaking reutiliza stake econômico para proteger serviços adicionais, muitas vezes chamados de serviços validados ativamente (AVSs). As recompensas podem se acumular, assim como os riscos de protocolo, operador, contrato inteligente, liquidez e saída. O rendimento anunciado não mede com segurança a perda máxima.
O valor sujeito a slashing depende dos contratos vigentes, do stake alocado a cada conjunto de operadores, da política de cada serviço e de qualquer janela de saque ou desalocação ainda penalizável. Ele não deve ser inferido de uma porcentagem genérica nem do histórico de incidentes.
## Como funciona
No modelo atual de stake único da EigenLayer, um operador aloca partes do stake delegado a conjuntos de operadores. As alocações de uma estratégia não podem superar 100%, e a mesma parte não pode ser stake único de dois conjuntos. Um serviço pode penalizar a parte alocada ao seu conjunto conforme suas regras.
Essa contabilidade limita o uso duplo do mesmo stake único, mas não torna as perdas independentes. Uma implantação defeituosa pode afetar várias partes, muitos operadores podem compartilhar uma dependência e validadores nativos de ETH também podem sofrer penalidades ou slashing do consenso do Ethereum.
Retorno líquido esperado = recompensas esperadas - taxas - custo de oportunidade - perdas esperadas de slashing e liquidez
Estime perdas por cenário, não somando rendimentos anunciados. Verifique pelo menos:
- Registre estratégia, operador, conjunto, percentual alocado e valor penalizável de cada serviço.
- Leia cada condição, padrão de prova, autoridade, processo de contestação ou veto e slashing máximo.
- Mapeie clientes, chaves, signatários, regiões de nuvem, oráculos, administradores de atualização e participantes de governança compartilhados.
- Confira atrasos de saque e desalocação, pois cotas na fila podem continuar penalizáveis até o fim do prazo.
## Exemplo
Suponha 100 ETH delegados a um operador: 40% ao conjunto A, 30% ao B e 30% não alocados. Se uma falha de software fizer A penalizar 50% de sua alocação e B, 100%, a perda será 20 ETH + 30 ETH = 50 ETH. É uma ilustração, não uma fórmula universal; regras, novos slashings, penalidades do Ethereum e desconto de mercado de um LRT podem alterar a perda realizada.
## Riscos
- **Concentração oculta:** operadores diferentes podem usar o mesmo cliente, signatário, data center ou região de nuvem.
- **Risco de regras e governança:** condições amplas ou dependência de comitê, chave de atualização ou disputa podem falhar.
- **Risco residual de saída:** pedir saque ou desalocação pode não encerrar imediatamente a exposição ao slashing.
- **Perda de liquidez:** um LRT pode negociar abaixo dos ativos subjacentes durante estresse, somando perda antes do acerto contábil.
## Erros comuns
### Mito 1: Mais AVSs diversificam automaticamente o risco
Só há diversificação quando fontes de falha e alocações penalizáveis são realmente independentes.
### Mito 2: Sem slashing passado, o risco é baixo
Um histórico curto ou calmo pode não conter estresse relevante. Permissões e cenários importam mais que zero incidentes.
### Mito 3: Um fundo de seguro garante reembolso
A cobertura depende de tamanho, eventos elegíveis, exclusões, prioridade e governança. Seguro anunciado não equivale a cobertura financiada e exigível.
### Mito 4: Sair encerra a responsabilidade imediatamente
Saques ou desalocações na fila podem continuar penalizáveis durante os atrasos, e um LRT pode ter atrasos de liquidez e resgate.
## Tópicos relacionados
- [Segurança criptoeconômica](/pt-br/crypto/crypto-economic-security/)
- [Staking líquido](/pt-br/crypto/liquid-staking/)
- [Restaking](/pt-br/crypto/restaking/)
- [Slashing](/pt-br/crypto/slashing/)
- [Fila de saída e saque de validadores](/pt-br/crypto/validator-exit-withdrawal-queue/)
## Fontes
- [ELIP-002: Slashing por stake único e conjuntos de operadores](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md) - Eigen Foundation (acessado em: 2026-08-21)
- [DelegationManager: slashing e contabilidade](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/DelegationManager.md) - EigenLayer (acessado em: 2026-08-21)
- [Recompensas e penalidades de prova de participação](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (acessado em: 2026-08-21)
Source: https://wiki.fcontext.com/pt-br/crypto/restaking-correlated-slashing-risk/index.mdx