O que ninguém te conta sobre validação de seeds em PDAs no Solana

Hook

⚠ Apenas **0,3 %** dos programas Solana auditados em 2025 continham um mecanismo de validação de *bump* em PDAs – e a maioria desses 0,3 % sofreu perdas superiores a US$ 1 mi.

Problema

Fundadores e CTOs de projetos Web3 que investem R$ 30 k+ por contrato enfrentam falhas recorrentes ao gerar PDAs: a ausência de verificação de *bump* permite que um atacante recrie o mesmo endereço com parâmetros diferentes, sobrescrevendo estado crítico. O sintoma costuma aparecer como "transação falha inesperadamente" ou “estado corrompido” logo após o lançamento na mainnet.

Insight

Na 38bits, nosso time de auditoria desenvolveu um padrão de **"Bump‑Safe PDA"** que inclui três camadas de defesa: 1. **Derivação explícita** – usamos `Pubkey::find_program_address` e armazenamos o *bump* retornado no próprio estado do programa, evitando chamadas implícitas que podem mudar entre builds. 2. **Validação em tempo de execução** – antes de qualquer operação que altere o PDA, comparamos o *bump* armazenado com o calculado a partir dos seeds atuais. Se houver divergência, a instrução aborta com código de erro customizado. 3. **Guardas CPI reforçadas** – ao chamar outro programa, incluímos a verificação de *bump* no `invoke_signed` e registramos o hash dos seeds no log de eventos, facilitando auditorias posteriores.

Essas práticas eliminam o vetor de ataque conhecido como *seed‑replay*, que não é detectado por scanners estáticos comuns. Além disso, adotamos o modelo de **"Zero‑Copy PDA"** com `AccountInfo::data` em Rust, reduzindo a superfície de memória e permitindo que o compilador otimize checks de overflow.

Evidência

Em um projeto anônimo de DeFi, a falta de *bump* check permitiu que um atacante criasse um PDA colidindo com a conta de liquidez, resultando em perda de **US$ 2,3 mi** antes que o bug fosse identificado.

CTA

Quer validar seu código antes que ele vá para a mainnet? Converse conosco em t.me/Fl38bits_bot.