﻿---
title: "Ataques a oráculos"
description: "Um ataque a oráculo explora dados externos manipuláveis, desatualizados, mal dimensionados ou mal configurados para que um protocolo empreste, emita, resgate, liquide ou execute uma liquidação por um valor inseguro."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ataques a oráculos

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

<a id="answer"></a>

## Resposta direta

Um ataque a oráculo explora a fronteira de confiança dos dados de um protocolo para que um preço, taxa de câmbio, índice, valor patrimonial líquido ou indicador de status provoque uma ação economicamente insegura. O invasor pode manipular um mercado com pouca liquidez, comprometer relatores ou chaves, explorar regras de agregação ou atualização, ou combinar a falta de verificações de atualidade, unidade, faixa e fallback no consumidor com capital tomado emprestado. Um feed desatualizado ou mal configurado pode causar a mesma perda sem que o operador do oráculo seja mal-intencionado; portanto, a análise do incidente deve distinguir o caminho do ataque do modo de falha.

A comparação decisiva não é se o preço exibido oscilou muito. É se o custo e o risco de influenciar o valor exato consumido pelo contrato são menores do que o valor executável disponível por empréstimo, emissão, resgate, liquidação financeira ou liquidação de garantia. A liquidez flash pode financiar um caminho atômico, mas não cria a fronteira de confiança defeituosa nem é necessária para explorá-la.

O valor de um oráculo também não é necessariamente um preço de mercado executável. Toda análise deve vinculá-lo a uma rede, bloco, endereço do feed ou pool, orientação entre ativo-base e ativo de cotação, casas decimais, timestamp, método de agregação, dimensão do mercado e função consumidora. Uma assinatura válida comprova quem reportou os dados segundo determinado esquema; por si só, ela não comprova atualidade, independência das fontes, profundidade de mercado nem correção econômica.

<a id="mechanism"></a>

## Como funciona

1. Fixe o deployment: rede, bloco, contrato e função consumidores, contratos dos ativos, proxy do feed ou pool, agregador, ativos-base e de cotação, casas decimais, administradores e estado de upgrade.
2. Mapeie todo o caminho de confiança, dos mercados, pools ou relatores, passando por agregação, assinaturas, proxy ou adaptador e fallback, até a lógica consumidora; registre mercados, operadores, chaves e estruturas de governança compartilhados, em vez de contar rótulos como fontes independentes.
3. Reproduza exatamente a leitura onchain: resposta, metadados da rodada, timestamp, confiança ou status quando aplicável, normalização decimal, inversão da cotação, estado do sequenciador e período de carência, idade máxima, limites de desvio e tratamento de valores zero ou negativos.
4. Monte o livro de exposição do consumidor: fator de garantia, limiar de liquidação, limites de empréstimo e oferta, liquidez disponível, dívida, limites de emissão ou resgate, close factor, bônus de liquidação e cada ação habilitada pelo valor.
5. Modele a manipulação em tamanho executável usando reservas, liquidez ativa, observações, janela e convenção de ponderação, taxas, arbitragem, ordenação de blocos, capital flash ou próprio, perdas na desmontagem, gas, MEV e liquidantes concorrentes.
6. Teste controles e estados de falha: fontes independentes, cardinalidade do TWAP, limites, circuit breakers, autoridade de pausa, timelocks, fallback desatualizado ou divergente, perda de relator ou chave, indisponibilidade do sequenciador L2, saltos legítimos de preço e comportamento fail-open ou fail-closed.
7. Monitore e reconcilie rodadas canônicas, mudanças de proxy e configuração, divergência entre fontes, ações do protocolo, liquidações, dívida incobrável e decisões de pausa e recuperação; repita a análise após mudanças de liquidez, listagem, upgrade ou regime de mercado.

Uma leitura spot de um AMM frequentemente pode ser alterada em uma única transação. Uma média ponderada pelo tempo pode elevar o custo ao exigir influência ao longo de várias observações, mas sua segurança depende da convenção aritmética ou baseada em ticks, da janela, da cardinalidade das observações, da distribuição de liquidez e do controle de blocos. Uma mediana pode rejeitar alguns outliers, porém mercados de origem correlacionados ou perda de quórum ainda podem comprometer a segurança ou a disponibilidade. Os parâmetros de heartbeat e desvio determinam quando alguns feeds publicam; os consumidores continuam precisando de sua própria política de atualidade e validade.

<a id="example"></a>

## Exemplos resolvidos

- **Spot de produto constante.** Ignore as taxas em um pool com `1,000,000 ABC` e `1,000,000 USDC`, de modo que `k = 10^12`. Um preço marginal-alvo de `9 USDC/ABC` exige reservas de `3,000,000 USDC` e `333,333.333333 ABC`: o operador deposita `2,000,000 USDC` e recebe `666,666.666667 ABC`. O preço marginal final é `3,000,000 / 333,333.333333 = 9`, enquanto o preço médio de execução é `2,000,000 / 666,666.666667 = 3 USDC/ABC`. Em contraste, um depósito de `5,000,000 USDC` deixa reservas de `6,000,000` e `166,666.666667`, produzindo preço marginal de `36`, não `9`. Taxas reais, arbitragem, liquidez concentrada e desmontagem alteram o livro.
- **Convenção do TWAP.** Em dez observações iguais de um minuto, nove preços são `100` e um é `160`. O TWAP aritmético didático é `(9 * 100 + 160) / 10 = 106`, apenas `6%` acima de 100, embora o último spot esteja `60%` mais alto. Para elevar essa média aritmética a `130` mantendo as outras nove observações em 100, a observação manipulada deve ser `400`. A média de ticks do Uniswap v3 é geométrica, diferentemente deste exemplo aritmético; o consumidor deve reproduzir a convenção implantada.
- **Mediana e quórum.** Sete observações normalizadas são `[99, 100, 100, 101, 101, 500, 600]`; a mediana é `101`, portanto dois relatos extremos não afastam o resultado do grupo honesto. Se a aceitação exigir cinco relatos ativos e três relatores honestos ficarem offline, restarão apenas `4 < 5`: resistência a outliers não garante disponibilidade, e o fallback passa a integrar o modelo de segurança.
- **Desatualização e liquidação indevida.** Um feed com oito casas decimais retorna o valor bruto `140,000,000,000`, ou `1,400`, mas sua idade é `17 minutes` diante de um máximo de `15 minutes` definido pelo consumidor, portanto deve ser rejeitado. Se o valor desatualizado ainda for usado para `10 ETH`, com limiar de liquidação de `75%` e dívida de `12,000`, o fator de saúde será `10 * 1,400 * 0.75 / 12,000 = 0.875`; com preço atualizado de `2,000`, será `1.25`. Uma correção posterior do preço não desfaz uma liquidação concluída.

<a id="risks"></a>

## Riscos

- Rede, ativo, feed, proxy, pool ou endereço do consumidor incorreto.
- Ativos-base e de cotação invertidos ou denominação inconsistente.
- Normalização incorreta das casas decimais do feed, token e ponto fixo interno.
- Aceitar dados desatualizados ou confundir heartbeat e desvio com garantias de atualidade.
- Aceitar rodadas incompletas, status inválido ou respostas zero, negativas, limitadas ou fora da faixa.
- Um preço spot de um único mercado raso controla grande exposição do protocolo.
- Janela TWAP curta, esparsa, ponderada incorretamente ou lida na direção errada.
- Cardinalidade, inicialização, interpolação ou fallback das observações mal compreendidos.
- Liquidez concentrada ou just-in-time faz o valor nominal do pool distorcer o custo do ataque.
- Vários feeds compartilham mercados, fornecedores, operadores, chaves ou plano de controle.
- Falha de relator, mercado, API, signatário, rede ou quórum elimina atualidade ou integridade.
- Indisponibilidade do sequenciador L2 ou período de carência ausente ou incorreto.
- Fallback desatualizado, circular, correlacionado, com escala diferente ou incompatível em termos semânticos.
- Liquidez flash e composição atômica tornam economicamente utilizável uma influência temporária.
- Ordenação de atualizações, frontrunning, sandwich, backrunning ou MEV de liquidação altera os pagamentos.
- Fatores de garantia, limiares, limites, bônus e liquidez disponível amplificam um pequeno erro.
- Comprometimento de governança, administrador, guardian, multisig ou chave de assinatura altera o caminho de confiança.
- Erros de proxy, agregador, adaptador, upgrade, armazenamento ou configuração selecionam o valor errado.
- Circuit breakers ou lógica fail-closed bloqueiam empréstimos, pagamentos ou liquidações legítimos em períodos de estresse.
- Falhas na pausa, recuperação, reconciliação de contas, alocação de dívida incobrável ou contenção entre protocolos.

<a id="misconceptions"></a>

## Equívocos comuns

- **“Todo ataque a oráculo compromete a rede do oráculo.”** Muitas falhas exploram uma fonte rasa, um valor desatualizado, unidades erradas, um adaptador inseguro ou a lógica consumidora enquanto a rede reporta conforme configurada.
- **“Vários feeds ou feeds descentralizados garantem um preço correto.”** Independência, qualidade das fontes, quórum, atualidade, unidades, agregação e verificações do consumidor continuam necessários.
- **“Um TWAP torna a manipulação impossível.”** Ele altera a duração e o custo da influência; janela fraca, poucas observações, liquidez rasa ou controle de blocos ainda podem ser exploráveis.
- **“Proibir flash loans elimina o risco do oráculo.”** Flash loans são um mecanismo de financiamento. Capital próprio, crédito, empréstimos entre protocolos, comprometimento de relatores e erros de configuração permanecem.
- **“A recuperação do preço reverte o dano.”** Empréstimos, emissões, resgates, liquidações financeiras e liquidações de garantia canônicos persistem, salvo se o protocolo tiver um processo de recuperação separado e autorizado.

<a id="related"></a>

## Tópicos relacionados

- [Oráculo](/pt-br/crypto/oracle/)
- [Protocolo de empréstimo](/pt-br/crypto/lending-protocol/)
- [Liquidação](/pt-br/crypto/liquidation/)

<a id="sources"></a>

## Fontes

- [SC03:2026 Price Oracle Manipulation](https://scs.owasp.org/sctop10/SC03-PriceOracleManipulation/) - OWASP Smart Contract Security (acesso: 2026-08-13)
- [Chainlink Data Feeds](https://docs.chain.link/data-feeds) - Chainlink Documentation (acesso: 2026-08-13)
- [Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference) - Chainlink Documentation (acesso: 2026-08-13)
- [L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds) - Chainlink Documentation (acesso: 2026-08-13)
- [Uniswap v2 Core](https://app.uniswap.org/whitepaper.pdf) - Uniswap Labs (acesso: 2026-08-13)
- [Price Oracles](https://developers.uniswap.org/docs/protocols/v3/concepts/price-oracles) - Uniswap Developers (acesso: 2026-08-13)
- [Oracles](https://aave.com/docs/aave-v3/smart-contracts/oracles) - Aave Protocol Documentation (acesso: 2026-08-13)
- [Flash Loans](https://aave.com/docs/aave-v3/guides/flash-loans) - Aave Protocol Documentation (acesso: 2026-08-13)

Source: https://wiki.fcontext.com/pt-br/crypto/oracle-attack/index.mdx
