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.