Ir para o conteúdo
Financial Context Wiki

Preços de oráculo desatualizados

O preço de um oráculo está desatualizado para um consumidor quando o horário de atualização documentado é anterior à idade máxima permitida para aquela ação; o tratamento seguro também exige validade do feed, verificações do sequenciador, fallbacks e recuperação controlada.

Atualizado

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

Resposta direta

Um valor de oráculo está desatualizado para uma ação específica quando age = consumerClock - sourceTimestamp supera o maxAge configurado para essa ação. Um preço inalterado ainda pode ser recente, e um valor publicado há pouco pode estar economicamente errado. O consumidor deve primeiro rejeitar timestamps ausentes ou futuros e respostas inválidas, para então aplicar uma política de aceitação específica por feed, ativo, blockchain, horário de mercado e ação.

Heartbeat e limites de desvio são gatilhos de publicação, não garantias de atualidade nem acordos de nível de serviço. Um relatório pode atrasar após o gatilho, e o mercado pode variar menos que o limite de desvio enquanto uma ação exige idade máxima mais curta. Oráculos pull criam outra fronteira: o chamador talvez precise enviar uma atualização autenticada antes da leitura, e o contrato deve rejeitar atualizações acima do limite declarado.

Em uma L2, o status do sequenciador e o período de carência após a recuperação formam uma barreira separada. Superá-la não prova que o preço está atualizado, que a L2 atingiu finalidade nem que todos tiveram acesso igual. Fontes fallback e últimos preços válidos são modos controlados de degradação, não a verdade; cada fonte e caminho de recuperação precisa de unidades, timestamps, independência, permissões, ações permitidas e regras de conciliação.

Como funciona

  1. Fixe blockchain, bloco e relógio, contrato consumidor e ação, proxy e agregador do feed, par e casas decimais, versão da interface, configuração fallback e estado de upgrade.
  2. Leia a resposta exata pela interface implantada e trate revert ou ausência de dados. Valide resposta, status ou confiança quando aplicável, sourceTimestamp != 0 e sourceTimestamp <= consumerClock antes da subtração.
  3. Registre heartbeat, desvio, horário de mercado e configuração de publicação; depois defina um maxAge independente por ação. Explicite a fronteira, como aceitar age <= maxAge e rejeitar age > maxAge.
  4. Em implantações L2 compatíveis, valide inicialização e status do feed do sequenciador, calcule pelo campo documentado o tempo desde a recuperação e imponha o período de carência antes de verificar separadamente a atualidade do preço.
  5. Rastreie cada componente necessário de preços compostos, razões e fallbacks. Normalize direção e unidades e limite a atualidade efetiva pela dependência necessária mais antiga, não pelo timestamp mais novo.
  6. Defina estados normal, degradado e pausado por ação. Novos empréstimos, emissão ou alavancagem podem falhar de modo fechado, enquanto pagamento ou adição de garantia continua disponível; teste preços antigos, fallback e retomados contra exposição, liquidez e capacidade de keepers.
  7. Monitore mudanças de fonte e proxy, latência, rejeições, sequenciador, divergência entre fontes e horários; simule indisponibilidade, falha do fallback, salto de recuperação, liquidações concentradas, MEV, contabilização de dívida incobrável e retorno ao modo normal.

Em interfaces do tipo Chainlink, latestRoundData() pode expor identificador da rodada, resposta com sinal, início, atualização e um campo legado de rodada. A API atual documenta answeredInRound como obsoleto; portanto, uma desigualdade histórica não deve ser apresentada como regra universal vigente: examine proxy, agregador e implementação exatos. O timestamp indica quando o estado documentado do feed foi atualizado, não que o valor seja executável em qualquer tamanho. Em Solidity, block.timestamp é o timestamp do bloco atual dentro dos limites do consenso, não um oráculo externo de horário civil.

Exemplos resolvidos

  • Limite de idade máxima. Considere consumerClock = 1,800,000,000 e sourceTimestamp = 1,799,999,100, logo age = 900 seconds = 15 minutes. Uma política maxAge = 600 seconds rejeita por 300 seconds; uma política maxAge = 1,200 seconds aceita com 300 seconds de folga. O mesmo valor pode ser válido para uma ação e desatualizado para outra.
  • Gatilho não é atualidade. O último preço publicado é 100.00, o limite de desvio é 1% e o heartbeat é 3,600 seconds. Após 2,700 seconds, o preço de mercado observado de 100.80 está apenas 0.8% distante; nenhum dos gatilhos didáticos disparou. Em 101.20, o desvio é 1.2% e pode iniciar a publicação, mas o consumidor ainda lê 100.00 até a inclusão de um relatório novo e válido.
  • Barreira dupla na L2. O feed do sequenciador informa operação com startedAt = 1,799,996,400, consumerClock = 1,800,000,000 e grace = 3,600 seconds; decorreram exatamente 3,600 seconds. Numa política que bloqueia enquanto elapsed <= grace, a ação segue bloqueada e torna-se elegível em 3,601 seconds. A elegibilidade ainda depende do timestamp do preço, da resposta e de todas as demais verificações.
  • Degrau de recuperação. Com 10 ETH em garantia, dívida de 12,000 USD e limite de liquidação de 75%, um valor desatualizado de 2,000 USD/ETH resulta em healthFactor = 10 * 2,000 * 0.75 / 12,000 = 1.25. Um valor retomado de 1,400 USD/ETH resulta em 0.875. Sob esses dados didáticos, a conta passa a ser liquidável, mas a execução ainda depende das regras, liquidez, keepers, gas, ordenação e disponibilidade da blockchain.

Riscos

  • Blockchain, feed, proxy, agregador, par de ativos ou versão de interface errados.
  • O consumidor lê a resposta sem timestamp ou status documentado.
  • Timestamp zero ou futuro e subtração com underflow não são rejeitados.
  • A idade máxima é frouxa demais para ativo, ação, horário ou volatilidade.
  • A idade máxima é rígida demais e causa negação de serviço ou impede redução de risco.
  • Heartbeat é tratado como prazo garantido de publicação ou acordo de serviço.
  • Desvio ou basis abaixo do limite se acumulam sem disparar atualização.
  • Relatório disparado atrasa por fonte, assinantes, rede, gas, relé ou blockchain.
  • Uma verificação de rodada obsoleta ou específica é aplicada universalmente.
  • Mudanças de feed, proxy, agregador, heartbeat, desvio ou interface passam despercebidas.
  • Semântica de mercado fechado, feriado, pausa ou dado carregado é ignorada.
  • Preço composto ou razão parece recente embora um componente esteja desatualizado.
  • Status do sequenciador L2 é ignorado, não inicializado, atrasado ou lido na rede errada.
  • Período de carência ausente, mal configurado ou com erro de fronteira.
  • O sequenciador passa, mas o preço continua desatualizado ou indisponível.
  • Tempo da L1, bloco L2, observação, publicação e relógio civil são confundidos.
  • Atualização pull está ausente, antiga, escolhida seletivamente, malformada ou sem fundos.
  • Fallback ou último valor válido está antigo, correlacionado, em outra escala ou é circular.
  • Fail-open permite ações inseguras, enquanto fail-closed indiscriminado bloqueia pagamento, reforço de garantia ou recuperação ordenada.
  • Salto de recuperação, liquidações concentradas, MEV, pouca liquidez, corrida de pausa ou conciliação de dívida ruim causam perda secundária.

Equívocos comuns

  • “Heartbeat garante atualização recente a cada intervalo.” É uma configuração de gatilho, e falhas da fonte ou blockchain ainda podem atrasar a publicação.
  • “Timestamp recente prova preço correto e executável.” Prova apenas o horário documentado; qualidade, unidades, confiança, profundidade e lógica do consumidor são separados.
  • “Uma idade máxima serve para todos os feeds e ações.” Ativos, horários, blockchains e operações de empréstimo, liquidação, negociação e settlement têm necessidades diferentes.
  • “Sequenciador ativo significa retomar tudo imediatamente.” Período de carência e atualidade do preço são barreiras independentes, e podem existir políticas adicionais.
  • “Fallback ou reverter toda função é sempre mais seguro.” Fallback fraco precifica mal; falha indiscriminada pode impedir pagamento ou melhoria da garantia.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...