Ataque de inflação do primeiro depósito ERC-4626: como o arredondamento pode apagar cotas

Entenda como uma doação direta pode manipular a taxa de conversão de um cofre ERC-4626 vazio, arredondar para zero as cotas de um depositante e como implementações e usuários podem limitar o risco.

Somente para fins educacionais; não constitui aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Um ataque de inflação do primeiro depósito tem como alvo um cofre ERC-4626 vazio ou quase vazio. O atacante deposita uma quantia mínima para receber as primeiras cotas e depois transfere os ativos subjacentes diretamente ao cofre. Essa doação aumenta totalAssets() sem aumentar totalSupply(), tornando cada cota existente mais valiosa.

Se o depósito da vítima for convertido pela taxa manipulada, a divisão inteira poderá arredondar o resultado para pouquíssimas cotas ou zero. Os ativos da vítima permanecem no cofre, enquanto o atacante, como titular das cotas em circulação, pode resgatar o direito inflado. Esse é um problema de manipulação da taxa de conversão e slippage, não um defeito da própria interface ERC-4626.

Como funciona

Em um cofre simples, sem taxas ou compensações de proteção, as cotas emitidas por um depósito são aproximadamente assets * totalSupply / totalAssets. O ERC-4626 exige que o cálculo das cotas para uma determinada quantidade de ativos favoreça o cofre por meio do arredondamento para baixo. Em taxas de conversão normais, a perda por arredondamento é pequena, mas, quando o preço da cota foi inflado, um depósito que vale menos de uma cota pode perder 100% devido ao arredondamento.

O ataque depende dos detalhes da implementação. Uma transferência direta de ERC-20 pode aumentar os ativos contabilizados pelo cofre sem emitir cotas, principalmente quando totalAssets() lê o saldo de tokens do cofre. O atacante também precisa se antecipar à vítima enquanto a oferta de cotas estiver muito baixa. Cofres que usam outra contabilidade ou defesas explícitas podem não ser vulneráveis da mesma forma.

Exemplo

Suponha que um cofre vazio vulnerável comece com uma taxa de 1:1. O atacante deposita 1 unidade de ativo e recebe 1 cota, depois doa diretamente 999 unidades. O cofre passa a ter 1,000 ativos respaldando 1 cota. A vítima deposita 999 unidades, então o cálculo simples é 999 * 1 / 1,000 = 0 cotas após o arredondamento inteiro.

O cofre passa a deter 1,999 ativos, enquanto existe apenas a 1 cota do atacante. Se o depósito permitir um resultado de zero cota e não houver taxas ou outras restrições, o atacante poderá resgatar essa cota por todos os 1,999 ativos: a 1 unidade depositada originalmente, as 999 unidades doadas e as 999 unidades depositadas pela vítima. O lucro bruto do atacante corresponde às 999 unidades da vítima, antes dos custos de transação.

Riscos e defesas

Os implementadores podem reduzir o risco fornecendo liquidez inicial significativa, queimando ou bloqueando as cotas iniciais, exigindo um resultado mínimo de pelo menos uma cota ou usando um modelo de taxa de conversão com ativos e cotas virtuais. A implementação da OpenZeppelin adiciona quantidades virtuais e permite maior precisão das cotas por meio de um deslocamento de casas decimais; no modelo documentado, as cotas virtuais capturam parte de cada doação, tornando a manipulação não lucrativa ou muito mais cara. Cada defesa tem premissas e deve ser testada contra transferências diretas, limites de arredondamento, taxas, perdas e comportamentos incomuns de tokens.

Usuários e integradores devem tratar previewDeposit() como uma cotação, não como um mínimo garantido. Envie depósitos por uma função ou roteador que imponha uma quantidade mínima aceitável de cotas e reverta a transação quando o limite não for atingido. Antes de depositar em um cofre novo ou com poucas cotas em circulação, verifique totalAssets(), totalSupply(), a fórmula de conversão da implementação e se transferências de tokens não solicitadas afetam a contabilidade. Uma cotação favorável no front-end não protege uma transação cuja ordem de execução possa ser alterada.

Erros comuns

Mito 1: O ERC-4626 garante por si só uma taxa de conversão segura. O padrão define uma interface comum e o comportamento de arredondamento, mas não torna todas as implementações imunes à manipulação da taxa.
Mito 2: Chamar previewDeposit() imediatamente antes de deposit() garante esse resultado. O estado on-chain pode mudar entre as chamadas ou antes da execução. O fluxo de depósito precisa de um limite mínimo de cotas que possa ser aplicado.
Mito 3: Rejeitar apenas depósitos que gerem zero cota elimina o ataque. Isso evita o resultado mais extremo, mas um atacante ainda pode fazer um depósito receber poucas cotas e sofrer uma grande perda por arredondamento. As defesas devem limitar o slippage aceitável, não apenas exigir um resultado diferente de zero.

Tópicos relacionados

Fontes

ERC-4626: Cofres tokenizados - Ethereum Improvement Proposals (acessado em: 2026-08-20)
Padrão ERC-4626 para cofres tokenizados - OpenZeppelin (acessado em: 2026-08-20)
Implementação ERC4626 da OpenZeppelin - OpenZeppelin (acessado em: 2026-08-20)