Manipulação de oráculos RWA: mecânica e casos reais

Porque é que os oráculos de RWA são um problema diferente

A maioria dos exploits de DeFi sobre os quais as pessoas leem, incluindo os famosos na Uniswap ou na Aave, depende da manipulação de um preço que, pelo menos em teoria, é observável numa bolsa pública. Faz-se subir o preço spot de um token com um flash loan, um protocolo de empréstimo interpreta erradamente o novo preço como o 'real' e pede-se emprestado contra uma garantia inflacionada. A defesa é ler preços de muitas bolsas e calcular a sua média. Os ativos do mundo real quebram completamente esse modelo mental.

Um RWA, no sentido usado por protocolos como Ondo, Maple, o cofre RWA da MakerDAO ou Centrifuge, é uma reivindicação tokenizada sobre algo offchain: uma Treasury bill dos EUA, uma nota de crédito privado, uma participação num fundo. O 'preço' dessa reivindicação é um valor líquido dos ativos (NAV) comunicado por um administrador de fundo ou emitente, muitas vezes uma vez por dia útil e, por vezes, apenas quando os mercados estão abertos. Não há livro de ordens para consultar. Não há leilão duplo contínuo. Há, na melhor das hipóteses, um ficheiro assinado por um custodiante ou uma entrada manual de uma multisig de governance.

Isto cria um desfasamento estrutural com a lógica onchain de empréstimos ou cunhagem, que espera um preço novo, preciso e manipulável a cada bloco. É nesse desfasamento que vivem os ataques de manipulação de oráculos de RWA. Um atacante não precisa de mover um mercado. Precisa de explorar a lacuna entre o momento em que uma NAV é atualizada e o momento em que um protocolo age sobre ela, ou explorar um feed mal configurado que permite que um único carimbo temporal domine a visão onchain.

Os verdadeiros modos de falha: como os oráculos de RWA realmente avariam

Antes de entrar em estudos de caso, ajuda dar nome aos modos de falha que aparecem repetidamente em relatórios de incidentes e análises de auditoria. Seis padrões explicam a grande maioria das tentativas documentadas de manipulação de oráculos de RWA.

1. Manipulação de NAV em janela estreita

Alguns protocolos de RWA atualizam o seu ponteiro de preço onchain apenas quando um bot autorizado submete uma transação. Se o bot corre de poucas em poucas horas, ou apenas quando um keeper é pago, o 'preço' onchain é efetivamente uma fotografia instantânea. Um atacante que consiga mover brevemente o mercado subjacente, ou que consiga convencer o keeper a enviar um número errado, pode usar essa fotografia como valor do oráculo ao longo de todo um intervalo de blocos. Um flash loan amplifica isto: pedir emprestado, distorcer a referência, deixar o keeper enviar a NAV distorcida, cunhar contra ela, reembolsar, tudo numa única transação.

2. Iliquidez da NAV em fins de semana e feriados

As Treasuries dos EUA, o tipo dominante de garantia RWA em 2024–2026, não são negociadas aos fins de semana. Vários protocolos de RWA também pausam as atualizações de NAV aos fins de semana ou feriados. Se o protocolo onchain não pausar em paralelo com o mercado offchain, os atacantes podem cunhar ou pedir emprestado contra uma NAV que está desatualizada até 72 horas. Num fim de semana prolongado, com as taxas a moverem-se na abertura de segunda-feira, uma NAV 'desatualizada' pode estar significativamente errada em qualquer direção.

3. Repetição cross-domain de preços desatualizados

Muitas Treasuries tokenizadas e wrappers com rendimento existem agora em mais do que uma chain. Uma atualização de NAV enviada para a mainnet Ethereum não aparece automaticamente numa Layer 2, numa alt-L1 como Solana ou numa sidechain. Bridges que copiam mensagens de preço entre domínios têm frequentemente a sua própria latência, por vezes de minutos, por vezes de horas. Um atacante que repare que a NAV da Ethereum foi atualizada, mas que a chain de destino ainda está a ler o número de sexta-feira, pode arbitrar a diferença. Na prática, o 'preço desatualizado' torna-se uma opção put gratuita na chain de destino.

4. Vulnerabilidades de precificação interna

Alguns protocolos de RWA calculam a sua própria NAV a partir de sinais onchain (taxas de depósito, oferta de participações, fila de resgates). Se esses sinais forem eles próprios manipuláveis, o 'oráculo' é circular. Um depositante que infle brevemente a taxa aparente, ou que temporize resgates para distorcer uma TWAP, pode mover a NAV calculada sem nunca tocar num ativo offchain. Este é o primo exclusivamente onchain do ataque de janela estreita e é cada vez mais comum em pools RWA permissionadas.

5. Vulnerabilidades de precificação externa

A falha oposta: o protocolo confia num feed de preços de terceiros (Chainlink, RedStone, um oráculo push personalizado) sem verificar a metodologia da fonte. Se o terceiro publicar brevemente um número errado, ou se a API que o terceiro lê estiver ela própria atrás de uma paywall ou limitada por rate limits, o protocolo age com base em lixo. A Chainlink publicou várias arquiteturas de referência específicas para RWA precisamente porque 'basta usar Chainlink' não é uma resposta completa para um ativo que só é negociado OTC.

6. Compromisso de governance e de chaves

Por fim, o caso aborrecido: a multisig ou a chave privada do bot do oráculo sofre phishing, e o atacante envia a NAV que quiser. Isto não é realmente uma falha de 'oráculo' no sentido criptoeconómico, mas nos post-mortems aparece nos mesmos relatórios de incidentes, e é o modo de falha com maior probabilidade de resultar numa perda total de fundos em vez de um desconto temporário.

Risco em primeiro lugar: o que um atacante consegue realmente fazer

Vale a pena explicitar como é, ao nível do utilizador, um ataque bem-sucedido de manipulação de um oráculo RWA, porque os piores desfechos não são “o preço oscilou”.

• Colateral inflacionado, depois empréstimo: O atacante faz subir o NAV, o colateral depositado ou já depositado parece valer mais, o atacante contrai empréstimos em stablecoins ou outros ativos com um LTV artificialmente elevado e esvazia o lado do crédito.
• NAV deflacionado, depois resgate: O atacante faz descer o NAV, antecipa-se a outros resgatadores ao submeter primeiro, recebe o valor nominal total enquanto os resgatadores posteriores sofrem cortes. Muitas vezes combinado com uma posição curta num derivado relacionado.
• Mint contra colateral fantasma: Em wrappers de mint-and-burn (por exemplo, tokens do Tesouro embrulhados), o atacante cria novos tokens embrulhados contra um NAV desatualizado que já não reflete o respaldo, e depois vende num mercado que ainda confia no wrapper.
• Drenagem por arbitragem entre cadeias: O atacante identifica uma diferença de preço entre domínios, faz mint barato no domínio desatualizado, faz bridge para o domínio atualizado e vende ao preço correto. Repete até o lado barato ficar vazio.
• Cascata de liquidações: O atacante força o NAV a descer para desencadear liquidações de outros utilizadores, depois compra o colateral liquidado com desconto, porque o NAV irá recuperar quando a manipulação terminar.

Os montantes em dólares envolvidos até agora são pequenos em comparação com os hacks de DeFi de 2021–2022 que dominaram as manchetes. Mas o setor RWA está a crescer depressa, e vários dos vetores acima escalam com o TVL (total value locked). Um protocolo que parece seguro com 50 milhões de dólares de colateral em títulos do Tesouro pode tornar-se inseguro com 5 mil milhões, simplesmente porque a recompensa disponível para o atacante aumenta.

Análise de casos: os incidentes mais próximos da realidade

Os post-mortems públicos de ataques de manipulação de oráculos RWA são raros, em parte porque os protocolos envolvidos são muitas vezes pequenos, em parte porque os emitentes preferem acordos discretos e em parte porque alguns incidentes ainda estão em processos judiciais. Os quatro exemplos abaixo são reconstruídos a partir de dados onchain, relatórios de auditoria e divulgações de protocolos. Ilustram a mecânica, não necessariamente os resultados exatos em dólares, e são usados pseudónimos quando o protocolo não fez uma divulgação formal.

Caso A: A “lacuna de fim de semana” num wrapper de títulos do Tesouro tokenizados

Um pequeno protocolo de títulos do Tesouro dos EUA tokenizados numa Layer 2 precificava o seu token embrulhado contra um NAV atualizado por um bot keeper. O bot estava configurado para correr apenas em dias úteis. Durante um fim de semana prolongado de feriado nos EUA, os mercados onchain para o token embrulhado continuaram a negociar, mas o ponteiro do NAV ficou no fecho de sexta-feira. Um atacante percebeu que os rendimentos esperados dos títulos do Tesouro na segunda-feira implicavam um NAV diferente. Abriu uma posição curta no token embrulhado numa DEX e esperou que o keeper publicasse o NAV de segunda-feira. O keeper publicou um valor cerca de 40 pontos base abaixo do de sexta-feira, a posição curta deu lucro e os fornecedores de liquidez do protocolo assumiram a perda. Nenhum código foi hackeado. O “oráculo” estava tecnicamente a funcionar conforme configurado.

A mitigação, que o protocolo adotou depois, foi um limiar de desvio: recusar aceitar uma atualização de NAV a mais de X pontos base da atualização anterior sem um atraso por timelock. TWAP (time-weighted average price) por si só não ajuda aqui, porque o NAV subjacente não é precificado pelo mercado. O que ajuda é tratar, por defeito, qualquer grande movimento do NAV como suspeito.

Caso B: Manipulação de NAV com flash loan num pool de crédito privado

Um pool RWA de crédito privado permitia que depositantes fizessem mint de um token de participação contra posições de empréstimos offchain. O preço do token de participação era calculado onchain a partir de uma combinação da taxa de depósito, do comprimento da fila de resgates e de uma taxa de referência lida numa DEX de baixa liquidez. Um atacante contraiu um flash loan, distorceu temporariamente a taxa de referência para cima em 6%, o módulo de precificação onchain aceitou a taxa distorcida como o novo NAV e o atacante criou uma grande posição de participações ao NAV inflacionado. Resgatou imediatamente contra o pool offchain, drenou vários milhões de dólares de tranches sénior e reembolsou o flash loan. Toda a sequência demorou uma transação.

O post-mortem mostrou duas falhas empilhadas: a taxa de referência vinha de um único pool pouco líquido, e o módulo de precificação tratava qualquer preço de um só bloco como autoritativo. O protocolo substituiu a taxa de fonte única por uma mediana de múltiplas fontes e acrescentou uma janela TWAP de pelo menos 30 minutos. Também acrescentou uma proteção explícita: mints de participações superiores a uma fração configurável da oferta total têm de esperar um bloco e passar uma verificação de desvio.

Caso C: Repetição cross-chain numa stablecoin geradora de rendimento

Uma stablecoin geradora de rendimento respaldada por títulos do Tesouro tokenizados (da mesma família que USYC ou BUIDL, embora não esses produtos específicos) foi lançada em três cadeias. As atualizações de NAV eram enviadas por um relayer que corria na Ethereum mainnet e copiava mensagens para as outras cadeias. O relayer tinha um heartbeat de 15 minutos e saltava uma batida se o gás estivesse alto. Durante um período de gás L1 elevado, o relayer ficou várias horas atrasado. A cadeia de destino continuou a precificar a stablecoin ao NAV antigo, apesar de os rendimentos offchain dos títulos do Tesouro se terem movido.

Um bot de arbitragem identificou a diferença, fez mint barato na cadeia desatualizada, fez bridge para a cadeia atualizada e vendeu ao NAV correto. A bridge do protocolo não tinha uma verificação incorporada de que os ponteiros de NAV de origem e destino coincidiam dentro de uma tolerância. Após o incidente, o protocolo acrescentou uma verificação de consistência cross-chain: qualquer mint ou resgate numa cadeia de destino tem de referenciar uma mensagem de NAV cujo timestamp esteja dentro de N minutos da última atualização da cadeia de origem. Caso contrário, a transação reverte.

Caso D: Circularidade de precificação interna num pool permissionado

Um pool RWA permissionado emitiu um token de recibo cujo NAV era calculado inteiramente a partir dos próprios fluxos de depósitos e resgates do pool. Especificamente, o NAV era definido como a média ponderada por volume dos depósitos recentes ao longo da última hora, dividida pela oferta de participações. Um atacante que controlasse uma carteira grande podia simplesmente depositar uma pequena quantidade de stablecoins com um prémio para si próprio, o que fazia subir o VWAP, e depois fazer mint de novos tokens de recibo ao NAV inflacionado. Como o pool era permissionado, as verificações KYC (know your customer) acabaram por apanhar o atacante, mas apenas depois de vários dias e de várias iterações do ataque.

A lição: qualquer oráculo cujos inputs possam ser movidos pelo mesmo interveniente que beneficia da alteração de preço é, por definição, manipulável. A correção foi ancorar a precificação interna a uma referência externa (neste caso, um feed RWA da Chainlink baseado na curva subjacente dos títulos do Tesouro) e aplicar uma janela TWAP suficientemente longa para que um único interveniente não a possa dominar.

Mitigações que funcionam realmente, e os seus limites

As mitigações para ataques de manipulação de oráculos RWA são bem compreendidas em 2026, mas cada uma vem com uma contrapartida. Nenhuma é gratuita.

Preços médios ponderados pelo tempo (TWAP)

TWAP suaviza um preço ao longo de uma janela, normalmente de 30 minutos a 24 horas. Derrota ataques de flash loan de um só bloco, porque o atacante teria de dominar toda a janela, não apenas um bloco. O limite: TWAP não ajuda quando o NAV subjacente é ele próprio um número em lote que se move lentamente. Um TWAP sobre um NAV que atualiza uma vez por dia é apenas uma versão atrasada do mesmo NAV. Use TWAP para os sinais onchain que alimentam o cálculo do NAV, não para o próprio NAV.

Agregação de múltiplas fontes

Ler o NAV a partir de múltiplas fontes independentes (por exemplo, o administrador do fundo, um feed RWA da Chainlink, uma atestação manual por multisig) e usar a mediana. Isto derrota o comprometimento de uma única fonte e deteta uma má atualização antes de ela se propagar. O limite: se todas as fontes acabam por ler a mesma API do mesmo administrador, tem uma fonte com passos extra. Verdadeira multiplicidade de fontes significa custódia diferente, pipelines de reporte diferentes e, idealmente, entidades legais diferentes.

Limiares de desvio e timelocks

Rejeitar qualquer atualização de NAV a mais de X pontos base da atualização anterior sem um atraso (por exemplo, timelock de 24 horas) durante o qual a governance pode vetar. Esta é a mitigação mais eficaz contra manipulação em janelas estreitas, porque a maioria das tentativas de manipulação produz saltos visíveis. O limite: movimentos grandes legítimos (um choque nas taxas dos títulos do Tesouro, um evento de crédito) também ficam atrasados. Os protocolos têm de ajustar os limiares à classe de ativos.

Limites de heartbeat

Recusar agir com base num NAV com mais de N horas. Para títulos do Tesouro dos EUA, um limite sensato é 48 horas em dias úteis, 72 durante fins de semana. Para além disso, forçar uma pausa. Isto derrota ataques de lacuna de fim de semana, mas cria um problema de UX (user experience): os utilizadores não conseguem transacionar num protocolo em pausa. Alguns protocolos lidam com isto permitindo resgates, mas não mints, quando o NAV está desatualizado.

Verificações de consistência cross-chain

Em implementações multi-chain, exigir que qualquer mint, empréstimo ou resgate numa cadeia de destino referencie uma mensagem de NAV cujo timestamp esteja dentro da tolerância da cadeia de origem. Caso contrário, reverter. Isto derrota a repetição entre domínios, mas não faz nada por protocolos de cadeia única.

Circuit breakers e limites de taxa

Limitar o valor em dólares de mints, empréstimos e resgates por bloco e por dia. Isto limita os danos de um ataque bem-sucedido mesmo que todas as outras mitigações falhem. Não impede o ataque, mas limita o raio de impacto.

O que auditores e responsáveis de risco devem realmente procurar

Se está a conceber, auditar ou usar um protocolo RWA, aqui está uma lista curta de verificação derivada dos casos acima.

• De onde vem o NAV? Se a resposta for “um bot keeper chama uma API”, descubra que API, quem a opera e o que acontece quando está em baixo.
• Com que frequência o NAV atualiza, e o que acontece quando não atualiza? Lógica de pausa em NAVs desatualizados é inegociável.
• Uma única transação consegue mover o preço onchain que o oráculo lê? Se sim, conte com uma exploração.
• O protocolo é multi-chain? Se sim, existe uma verificação de consistência cross-chain em cada ação dependente do NAV?
• Qual é o limiar de desvio, e quem o pode substituir? Um limiar de 0% com substituição por multisig 7-de-12 é pouco melhor do que não ter limiar.
• Qual é a pior perda em dólares se o oráculo estiver errado durante um bloco? Limite por taxa os mints e empréstimos abaixo desse valor.
• Existe um plano explícito de resposta a incidentes, incluindo uma função de pausa testada em produção?

O risco de oráculos RWA não vai desaparecer. À medida que títulos do Tesouro tokenizados, crédito privado e outros RWA geradores de rendimento crescem para as centenas de milhares de milhões, a recompensa para o atacante cresce com eles. Os protocolos que sobreviverem serão os que tratam o reporte de NAV como uma fronteira de segurança, não como uma função de back-office.

Acompanhe o risco dos oráculos de RWA de forma inteligente

Os protocolos RWA e os seus oráculos movem-se discretamente, e as notícias que importam são muitas vezes uma publicação num fórum, uma votação de governação ou uma única transação suspeita muito antes de se tornarem manchete. O Zippfeed acompanha manchetes relacionadas com RWA em Treasuries tokenizados, protocolos de crédito e infraestrutura de oráculos, classificando cada item como bullish, neutral ou bearish para o protocolo envolvido e ordenando por importância. Assim, vê a alteração da configuração do keeper, a rotação da multisig ou a pausa do NAV antes de aparecerem numa análise pós-incidente.