Manipulación de oráculos RWA: mecánica de los ataques y casos reales

Por qué los oráculos de RWA plantean un problema diferente

La mayoría de los ataques contra DeFi sobre los que se suele leer, incluidos los más famosos en Uniswap o Aave, se basan en manipular un precio que, al menos en teoría, puede observarse en un mercado público. Se eleva el precio al contado de un token mediante un préstamo flash, un protocolo de préstamos interpreta erróneamente el nuevo precio como el «real» y el atacante pide prestado utilizando una garantía cuyo valor está inflado. La defensa consiste en consultar los precios de varios mercados y calcular su promedio. Los activos del mundo real rompen por completo ese modelo mental.

Un RWA, en el sentido empleado por protocolos como Ondo, Maple, la bóveda de RWA de MakerDAO o Centrifuge, es un derecho tokenizado sobre algo offchain: una letra del Tesoro de EE. UU., un pagaré de crédito privado o una participación en un fondo. El «precio» de ese derecho es un valor neto de los activos (NAV) comunicado por el administrador o el emisor de un fondo, a menudo una vez por día hábil y, en ocasiones, solo cuando los mercados están abiertos. No existe ningún libro de órdenes que consultar. No hay una subasta doble continua. En el mejor de los casos, existe un archivo firmado por un custodio o una entrada manual realizada desde una multisig de gobernanza.

Esto crea un desajuste estructural con la lógica onchain de préstamos o acuñación, que espera disponer en cada bloque de un precio reciente, preciso y susceptible de manipulación. Los ataques de manipulación de oráculos de RWA surgen de este desajuste. Un atacante no necesita mover un mercado. Necesita aprovechar la diferencia entre el momento en el que se actualiza un NAV y aquel en el que un protocolo actúa en función de él, o explotar una fuente mal configurada que permita que una única marca temporal domine la perspectiva onchain.

Los verdaderos modos de fallo: cómo se rompen realmente los oráculos de RWA

Antes de analizar casos concretos, conviene identificar los modos de fallo que aparecen una y otra vez en los informes de incidentes y auditorías. Seis patrones representan la inmensa mayoría de los intentos documentados de manipulación de oráculos de RWA.

1. Manipulación del NAV durante intervalos breves

Algunos protocolos de RWA solo actualizan su indicador de precios onchain cuando un bot autorizado envía una transacción. Si el bot se ejecuta cada pocas horas, o únicamente cuando se paga a un keeper, el «precio» onchain es, en la práctica, una instantánea. Un atacante que pueda mover brevemente el mercado subyacente, o que pueda convencer al keeper de que publique una cifra incorrecta, puede utilizar esa instantánea como valor del oráculo durante todo un intervalo de bloques. Un préstamo flash amplifica este ataque: pedir prestado, distorsionar la referencia, dejar que el keeper publique el NAV distorsionado, acuñar activos usándolo como garantía y devolver el préstamo, todo ello dentro de una única transacción.

2. Iliquidez del NAV durante fines de semana y festivos

Los bonos del Tesoro de EE. UU., el tipo dominante de garantía RWA entre 2024–2026, no se negocian durante los fines de semana. Varios protocolos de RWA también suspenden las actualizaciones del NAV los fines de semana y festivos. Si el protocolo onchain no se detiene al mismo tiempo que el mercado offchain, los atacantes pueden acuñar activos o pedir prestado utilizando un NAV que lleva hasta 72 horas sin actualizarse. Durante un fin de semana largo, si los tipos se mueven en la apertura del lunes, un NAV «obsoleto» puede ser considerablemente erróneo en cualquiera de las dos direcciones.

3. Reutilización entre dominios de precios obsoletos

Muchos bonos del Tesoro tokenizados y envoltorios que generan rendimiento ya existen en más de una cadena. Una actualización del NAV publicada en la red principal de Ethereum no aparece automáticamente en una capa 2, una L1 alternativa como Solana o una cadena lateral. Los puentes que copian mensajes de precios entre dominios suelen tener su propia latencia, a veces de minutos y otras veces de horas. Un atacante que observe que el NAV de Ethereum se ha actualizado, pero que la cadena de destino sigue leyendo la cifra del viernes, puede aprovechar la diferencia mediante arbitraje. En la práctica, el «precio obsoleto» se convierte en una opción de venta gratuita en la cadena de destino.

4. Vulnerabilidades de valoración interna

Algunos protocolos de RWA calculan su propio NAV a partir de señales onchain, como los tipos de depósito, la oferta de participaciones y la cola de reembolsos. Si esas señales también pueden manipularse, el «oráculo» es circular. Un depositante que infle brevemente el tipo aparente, o que programe los reembolsos para sesgar un TWAP, puede modificar el NAV calculado sin interactuar en ningún momento con un activo offchain. Esta es la variante exclusivamente onchain del ataque mediante intervalos breves y cada vez resulta más común en los fondos de RWA con permisos.

5. Vulnerabilidades de valoración externa

El fallo opuesto se produce cuando el protocolo confía en una fuente de precios de terceros, como Chainlink, RedStone o un oráculo push personalizado, sin verificar la metodología de la fuente. Si el tercero publica brevemente una cifra incorrecta, o si la API que consulta está tras un muro de pago o sujeta a límites de solicitudes, el protocolo actúa basándose en datos inservibles. Chainlink ha publicado varias arquitecturas de referencia específicas para RWA precisamente porque «limitarse a usar Chainlink» no es una respuesta completa para un activo que solo se negocia OTC.

6. Vulneración de la gobernanza y de las claves

Por último, está el caso más aburrido: la multisig o la clave privada del bot del oráculo cae en una campaña de phishing y el atacante publica el NAV que desee. En realidad, no se trata de un fallo del «oráculo» en el sentido criptoeconómico, pero en los análisis posteriores aparece en los mismos informes de incidentes y es el modo de fallo con más probabilidades de provocar la pérdida total de los fondos, en vez de un descuento temporal.

Primero el riesgo: lo que un atacante realmente puede hacer

Merece la pena ser explícito sobre cómo se ve un ataque exitoso de manipulación de oráculos de RWA a nivel de usuario, porque los peores resultados no son 'el precio osciló un poco'.

• Colateral inflado y luego préstamos: el atacante empuja el NAV al alza, el colateral depositado o ya depositado parece valer más, el atacante pide prestado stablecoins u otros activos con un LTV artificialmente alto y drena la parte de préstamos.
• NAV deflactado y luego reembolso: el atacante empuja el NAV a la baja, se adelanta al resto de reembolsos enviando su solicitud primero, recibe el valor nominal completo mientras que los reembolsos posteriores sufren recortes. A menudo se combina con una posición corta en un derivado relacionado.
• Acuñación contra colateral fantasma: en envoltorios de acuñación y quema (por ejemplo, tokenswrapped de bonos del Tesoro), el atacante acuña nuevos tokenswrapped contra un NAV obsoleto que ya no refleja el respaldo y luego los vende en un mercado que todavía confía en el envoltorio.
• Drenaje por arbitraje entre cadenas: el atacante detecta un desajuste de precio entre dominios, acuña barato en el dominio obsoleto, traslada al dominio actualizado y vende al precio correcto. Lo repite hasta vaciar el lado barato.
• Cascada de liquidaciones: el atacante fuerza el NAV a la baja para provocar liquidaciones de otros usuarios y luego compra el colateral liquidado con descuento, porque el NAV se recuperará cuando termine la manipulación.

Los importes en dólares involucrados hasta ahora son pequeños en comparación con los hackeos de DeFi que acapararon titulares en 2021–2022. Pero el sector de RWA está creciendo rápido, y varios de los vectores anteriores escalan con el TVL (valor total bloqueado). Un protocolo que parece seguro con 50 millones de dólares en colateral de bonos del Tesoro puede volverse inseguro con 5 mil millones, simplemente porque la recompensa accesible para el atacante crece.

Análisis de casos: los incidentes más cercanos a la realidad

Las autopsias públicas de ataques de manipulación de oráculos de RWA son escasas, en parte porque los protocolos involucrados suelen ser pequeños, en parte porque los emisores prefieren acuerdos discretos y en parte porque algunos incidentes siguen en procesos legales. Los cuatro ejemplos siguientes se han reconstruido a partir de datos onchain, informes de auditoría y divulgaciones de los protocolos. Ilustran la mecánica, no necesariamente los importes exactos en dólares, y se utilizan seudónimos allí donde el protocolo no ha divulgado formalmente.

Caso A: el 'hueco del fin de semana' en un envoltorio tokenizado de bonos del Tesoro

Un pequeño protocolo tokenizado de bonos del Tesoro de EE. UU. en una Layer 2 valoraba su token wrapped frente a un NAV actualizado por un bot keeper. El bot estaba configurado para ejecutarse solo en días laborables. Durante un largo fin de semana festivo en EE. UU., los mercados onchain del token wrapped siguieron operando, pero el puntero del NAV se quedó en el cierre del viernes. Un atacante observó que los rendimientos esperados del Tesoro el lunes implicaban un NAV diferente. Tomó una posición corta sobre el token wrapped en un DEX y luego esperó a que el keeper publicara el NAV del lunes. El keeper publicó una cifra aproximadamente 40 puntos básicos por debajo de la del viernes, la posición corta dio resultado y los proveedores de liquidez del protocolo asumieron la pérdida. No se hackeó ningún código. El 'oráculo' técnicamente funcionaba como estaba configurado.

La mitigación, que el protocolo adoptó después, fue un umbral de desviación: rechazar cualquier actualización de NAV que se alejara más de X puntos básicos de la actualización anterior sin un retraso de timelock. El TWAP (precio medio ponderado por tiempo) por sí solo no ayuda aquí, porque el NAV subyacente no se valora en absoluto en el mercado. Lo que ayuda es tratar por defecto cualquier movimiento grande del NAV como sospechoso.

Caso B: manipulación de NAV con flash loan en un pool de crédito privado

Un pool de RWA de crédito privado permitía a los depositantes acuñar un token de participación contra posiciones crediticias fuera de la cadena. El precio del token de participación se calculaba onchain a partir de una combinación de la tasa de depósito, la longitud de la cola de reembolsos y una tasa de referencia leída de un DEX de baja liquidez. Un atacante tomó un flash loan, sesgó brevemente la tasa de referencia al alza en un 6%, el módulo de precios onchain aceptó la tasa sesgada como nuevo NAV y el atacante acuñó una gran posición de participación al NAV inflado. Reembolsó de inmediato contra el pool fuera de la cadena, drenó varios millones de dólares de tramos senior y devolvió el flash loan. Toda la secuencia ocurrió en una sola transacción.

La autopsia mostró dos fallos acumulados: la tasa de referencia provenía de un único pool con poco volumen, y el módulo de precios trataba cualquier precio de un solo bloque como autoritativo. El protocolo sustituyó la tasa de fuente única por una mediana de múltiples fuentes y añadió una ventana TWAP de al menos 30 minutos. También incorporó una salvaguarda explícita: las acuñaciones de participaciones superiores a una fracción configurable del suministro total deben esperar un bloque y superar una comprobación de desviación.

Caso C: reproducción entre cadenas en un stablecoin con rendimiento

Un stablecoin con rendimiento respaldado por bonos del Tesoro tokenizados (de la misma familia que USYC o BUIDL, aunque no esos productos concretos) se lanzó en tres cadenas. Las actualizaciones de NAV las empujaba un relayer que se ejecutaba en la mainnet de Ethereum y copiaba mensajes a las otras cadenas. El relayer tenía un latido de 15 minutos y se saltaba uno si el gas estaba alto. Durante un periodo de gas elevado en la L1, el relayer se retrasó varias horas. La cadena de destino siguió valorando el stablecoin al NAV antiguo, aunque los rendimientos de los bonos del Tesoro fuera de la cadena se habían movido.

Un bot de arbitraje detectó el desfase, acuñó barato en la cadena obsoleta, trasladó a la cadena actualizada y vendió al NAV correcto. El puente del protocolo no incluía una comprobación de que los punteros de NAV de origen y destino coincidieran dentro de una tolerancia. Tras el incidente, el protocolo añadió una comprobación de coherencia entre cadenas: cualquier acuñación o reembolso en una cadena de destino debe hacer referencia a un mensaje de NAV cuya marca de tiempo esté dentro de los N minutos de la última actualización de la cadena de origen. Si no, la transacción se revierte.

Caso D: circularidad de precios interna en un pool permissionado

Un pool de RWA permissionado emitía un token de recibo cuyo NAV se calculaba por completo a partir de los flujos de depósito y reembolso del propio pool. Concretamente, el NAV se fijaba como la media ponderada por volumen de los depósitos recientes durante la última hora, dividida por el suministro de participaciones. Un atacante que controlaba una billetera grande podía simplemente depositar una pequeña cantidad de stablecoins con prima hacia sí mismo, lo que subía el VWAP, y luego acuñar nuevos tokens de recibo al NAV inflado. Como el pool era permissionado, las comprobaciones de KYC (conoce a tu cliente) terminaron por atrapar al atacante, pero solo después de varios días y de varias iteraciones del ataque.

La lección: cualquier oráculo cuyas entradas pueda mover el mismo actor que se beneficia del cambio de precio es, por definición, manipulable. La solución fue anclar el precio interno a una referencia externa (en este caso, un feed RWA de Chainlink basado en la curva del Tesoro subyacente) y aplicar una ventana TWAP lo suficientemente larga para que un solo actor no pudiera dominarla.

Mitigaciones que realmente funcionan, y sus límites

Las mitigaciones para ataques de manipulación de oráculos de RWA se conocen bien en 2026, pero cada una implica un compromiso. Ninguna es gratis.

Precios medios ponderados por tiempo (TWAP)

El TWAP suaviza un precio a lo largo de una ventana, normalmente de 30 minutos a 24 horas. Derrota los ataques con flash loan en un solo bloque, porque el atacante necesitaría dominar toda la ventana, no solo un bloque. El límite: el TWAP no sirve cuando el NAV subyacente es en sí mismo un número por lotes que se mueve lentamente. Un TWAP sobre un NAV que se actualiza una vez al día es solo una versión retardada del mismo NAV. Usa TWAP para las señales onchain que alimentan el cálculo del NAV, no para el NAV en sí.

Agregación de múltiples fuentes

Lee el NAV desde múltiples fuentes independientes (por ejemplo, el administrador del fondo, un feed RWA de Chainlink, una atestación manual con multisig) y toma la mediana. Esto derrota el compromiso de una sola fuente y detecta una actualización incorrecta antes de que se propague. El límite: si todas las fuentes leen en última instancia la misma API del administrador, tienes una sola fuente con pasos adicionales. Una verdadera multi-fuente implica custodia distinta, canalizaciones de informes distintas e idealmente entidades legales distintas.

Umbrales de desviación y timelocks

Rechaza cualquier actualización de NAV que se aleje más de X puntos básicos de la actualización anterior sin un retraso (por ejemplo, timelock de 24 horas) durante el cual la gobernanza puede vetar. Es la mitigación más eficaz contra la manipulación en ventanas finas, porque la mayoría de los intentos de manipulación producen saltos visibles. El límite: los movimientos legítimos grandes (un shock de tipos en bonos del Tesoro, un evento de crédito) también se retrasan. Los protocolos deben ajustar los umbrales a la clase de activo.

Límites de latido (heartbeat)

Rechaza operar con un NAV que tenga más de N horas de antigüedad. Para bonos del Tesoro de EE. UU., un límite razonable es de 48 horas en días laborables y 72 en fines de semana. Más allá de eso, fuerza una pausa. Esto derrota los ataques por hueco de fin de semana, pero crea un problema de UX (experiencia de usuario): los usuarios no pueden operar en un protocolo en pausa. Algunos protocolos lo gestionan permitiendo reembolsos pero no acuñaciones cuando el NAV está obsoleto.

Comprobaciones de coherencia entre cadenas

Para despliegues multicadena, exige que cualquier acuñación, préstamo o reembolso en una cadena de destino haga referencia a un mensaje de NAV cuya marca de tiempo esté dentro de la tolerancia respecto a la cadena de origen. Si no, se revierte. Esto derrota la reproducción entre dominios, pero no sirve de nada para protocolos monocadena.

Circuit breakers y límites de tasa

Limita el valor en dólares de las acuñaciones, préstamos y reembolsos por bloque y por día. Esto acota el daño de un ataque exitoso aunque fallen todas las demás mitigaciones. No evita el ataque, pero limita el radio de la explosión.

Qué deberían comprobar de verdad los auditores y responsables de riesgo

Si estás diseñando, auditando o usando un protocolo de RWA, esta es una lista de comprobación breve derivada de los casos anteriores.

• ¿De dónde procede el NAV? Si la respuesta es 'un bot keeper llama a una API', averigua qué API, quién la opera y qué ocurre cuando se cae.
• ¿Con qué frecuencia se actualiza el NAV y qué pasa cuando no se actualiza? Una lógica de pausa sobre NAV obsoletos es innegociable.
• ¿Puede una sola transacción mover el precio onchain que lee el oráculo? Si es así, espera un exploit.
• ¿El protocolo es multicadena? Si lo es, ¿existe una comprobación de coherencia entre cadenas en cada acción que dependa del NAV?
• ¿Cuál es el umbral de desviación y quién puede anularlo? Un umbral del 0% con una anulación de multisig 7 de 12 apenas mejora la situación respecto a no tener umbral.
• ¿Cuál es la peor pérdida posible en dólares si el oráculo se equivoca durante un bloque? Limita la tasa de acuñaciones y préstamos por debajo de esa cifra.
• ¿Existe un plan explícito de respuesta a incidentes, incluida una función de pausa probada en producción?

El riesgo de oráculo en RWA no va a desaparecer. A medida que los bonos del Tesoro tokenizados, el crédito privado y otras RWA con rendimiento crezcan hasta los cientos de miles de millones, la recompensa para los atacantes crecerá con ellas. Los protocolos que sobrevivan serán los que traten el reporte del NAV como una frontera de seguridad, no como una función de back-office.

Sigue el riesgo de los oráculos RWA de forma inteligente

Los protocolos RWA y sus oráculos se mueven discretamente, y las noticias importantes suelen ser una publicación en un foro, una votación de gobernanza o una única transacción sospechosa mucho antes de convertirse en un titular. Zippfeed rastrea titulares relacionados con RWA en bonos del Tesoro tokenizados, protocolos de crédito e infraestructura de oráculos, y clasifica cada elemento como bullish, neutral o bearish para el protocolo implicado, además de ordenarlos por importancia. Así podrás ver el cambio en la configuración del keeper, la rotación del multisig o la pausa del NAV antes de que aparezca en un análisis posterior al incidente.