Como auditamos um protocolo DeFi e encontramos R$ 2M em risco

Em março de 2026, auditamos um protocolo de staking com R$ 2 milhões em TVL. Encontramos 3 vulnerabilidades críticas antes do lançamento público. Este é o relato técnico completo — os vetores de ataque, as explorações e as correções.

O protocolo e o escopo

O cliente construiu um protocolo de staking com recompensas variáveis em Token-2022. O escopo incluía o programa principal em Anchor, dois programas auxiliares e a lógica de distribuição de recompensas. Três semanas de trabalho, dois auditores.

Vulnerabilidade #1: Missing signer check em `unstake`

A instrução `unstake` não validava que o chamador era o dono da conta de staking. Qualquer carteira poderia remover tokens de qualquer usuário.

// VULNERÁVEL — sem validação de ownership
#[derive(Accounts)]
pub struct Unstake<'info> {
    #[account(mut)]
    pub stake_account: Account<'info, StakeAccount>,
    pub user: Signer<'info>,
    // Faltava: constraint = stake_account.owner == user.key()
}

A correção exige um constraint explícito no macro `#[account]` ou validação manual dentro da instrução:

// CORRIGIDO
#[derive(Accounts)]
pub struct Unstake<'info> {
    #[account(
        mut,
        constraint = stake_account.owner == user.key() @ StakeError::Unauthorized
    )]
    pub stake_account: Account<'info, StakeAccount>,
    pub user: Signer<'info>,
}

Vulnerabilidade #2: Reentrância via CPI não verificada

A instrução `claim_rewards` chamava um programa externo via CPI antes de zerar o saldo de recompensas. Um atacante poderia criar um programa malicioso que re-entrasse no protocolo durante a CPI, dobrando o saque.

// PADRÃO CORRETO: checks-effects-interactions
pub fn claim_rewards(ctx: Context<ClaimRewards>) -> Result<()> {
    let rewards = ctx.accounts.stake_account.pending_rewards;

    // 1. Zera ANTES da CPI (effect)
    ctx.accounts.stake_account.pending_rewards = 0;

    // 2. Transfere depois (interaction)
    transfer_tokens(&ctx, rewards)?;

    Ok(())
}

Vulnerabilidade #3: Overflow silencioso no cálculo de recompensas

O cálculo de recompensas usava multiplicação em `u64` sem checar overflow. Com valores grandes de stake e tempo, o resultado silenciosamente wrapeava para um número pequeno — o usuário recebia quase zero em vez de uma quantia alta.

// VULNERÁVEL — overflow silencioso em release builds
let rewards = stake_amount * reward_rate * time_elapsed; // pode overflow

// CORRIGIDO — usar checked arithmetic
let rewards = stake_amount
    .checked_mul(reward_rate)
    .and_then(|r| r.checked_mul(time_elapsed))
    .ok_or(StakeError::MathOverflow)?;

O que isso ensina sobre auditorias

• Signer checks são a vulnerabilidade #1 em programas Anchor — sempre verifique ownership explicitamente
• Siga checks-effects-interactions mesmo em Solana — CPIs maliciosas existem
• Use `checked_mul` e `checked_add` em vez de aritmética direta em `u64`
• Fuzzing com Trident ou Honggfuzz detecta overflows antes de você
• Revise todas as instruções que transferem tokens — não só as 'óbvias'

Conclusão

Essas três vulnerabilidades teriam custado R$ 2M ao protocolo. Foram encontradas antes do deploy. O tempo de auditoria foi 3 semanas; o custo de não auditar teria sido catastrófico. Se você está construindo um protocolo com TVL real, contate-nos antes do lançamento — não depois.