Quando vale (e quando NÃO vale) o restaking em Solana

#solana #rust #security #audit

Hook

⚠ Restaking promete rentabilidade extra, mas 42 % dos projetos que adotaram a prática sofreram falhas críticas nos primeiros três meses.

Problema

Fundadores de protocolos Solana que buscam otimizar a taxa de retorno frequentemente incorporam restaking sem mapear as implicações de segurança. O resultado: ataques de reentrada em contratos de staking, perda de fundos e atrasos no roadmap. CTOs que gerenciam projetos acima de R$30 k precisam garantir que a camada adicional de delegação não introduza vetores de ataque inesperados.

Insight

Nossa equipe tem aprofundado a análise de cross‑program invocations (CPI) quando o mesmo token é usado simultaneamente como garantia e como fonte de renda. Identificamos três pontos críticos que a maioria das auditorias ignora:

Gerenciamento de nonce – Restaking reutiliza o mesmo seed de PDA sem bump check, permitindo que um atacante force a criação de contas colididas.
Guardas de CPI mal configuradas – Quando o contrato de staking delega chamadas para um contrato de recompensa, a falta de restrição de contas externas gera um caminho de execução livre para reentrância.
Dependência de oráculos externos – Muitos protocolos confiam em preços de oráculos para ajustar recompensas; se o oráculo for comprometido, o algoritmo de restaking pode ser manipulado para drenagem de tokens. Para mitigar esses riscos, recomendamos:
Sempre incluir o bump na derivação de PDAs e validar sua consistência antes de cada operação de staking.
Aplicar a macro require!(!cpi_program_id.is_signer(), ErrorCode::InvalidCPI) para bloquear chamadas de programas não autorizados.
Utilizar oráculos com assinatura múltipla e fallback de preço para evitar manipulação de dados.

Evidência

Em um caso anônimo, um protocolo de DeFi que implementou restaking sem bump check teve 18 % de seu pool drenado em menos de 48 h após um ataque de reentrada.