# Ostium pausa el trading tras un exploit de ~US$18M en OLP > Ostium detuvo el trading el 15 de julio tras un ataque que abusó de un PriceUpKeep registrado e informes de oráculo con fechas futuras para sacar ~US$18M en USDC del vault OLP en Arbitrum. - **Source:** https://ptycoin.com/es/posts/2026-07-17-ostium-18m-oracle-keeper-exploit/ - **Published:** 2026-07-17 - **Category:** News - **Author:** Mateo - **Tags:** security, defi, stablecoins, self-custody, exchanges --- **Ostium**, un mercado de perpetuos en [Arbitrum](https://arbitrum.io/) orientado a activos del mundo real (oro, forex e índices), **detuvo todo el trading el 15 de julio de 2026** después de que un atacante drenara unos **US$18 millones en USDC** de su vault **Ostium Liquidity Provider (OLP)**. La firma de seguridad [Blockaid](https://x.com/blockaid_/status/2077405527428989363) afirmó que el atacante usó un **forwarder PriceUpKeep registrado** e **informes de oráculo autorizados con fechas futuras** para fabricar ganancias artificiales y forzar un pago desde el vault. ## Lo que muestra la traza on-chain [CoinDesk](https://www.coindesk.com/business/2026/07/15/ostium-suffers-usd18-million-exploit-as-oracle-attack-wave-continues-to-hit-defi) y [The Defiant](https://thedefiant.io/news/hacks/ostium-halts-trading-after-oracle-exploit-drains-up-to-usd18m-from-vault) reportan el mismo mecanismo central según Blockaid: un componente ya dentro de la automatización de precios de Ostium envió datos de oráculo con marcas de tiempo futuras manipuladas, de modo que operaciones perdedoras parecieron rentables. Esas “ganancias” se liquidaron contra el vault OLP, que actúa como contraparte del libro. Blockaid publicó la [transacción principal del exploit en Arbitrum](https://arbiscan.io/tx/0x359f8c05b86a4409d60cfba02084334313fd94b19f74a294fb7fc4ea7d4870e0) (`0x359f8c05…d4870e0`) y la dirección del atacante. Los recuentos independientes aún divergen: la cifra pública de Blockaid ronda **US$18 millones en USDC**; algunos observadores situaron la primera oleada cerca de **US$11,9 millones**; [PeckShield](https://thedefiant.io/news/hacks/ostium-vault-exploiter-routes-10-540-eth-to-tornado-cash) elevó después el drenaje del vault a unos **US$24 millones en USDC** al seguir el rastro. Ostium no ha publicado su propia contabilidad final de la pérdida. [Crypto Briefing](https://cryptobriefing.com/ostium-suspends-trading-olp-vault-exploit/) describió por separado que el vault OLP pasó de unos **US$32,7 millones** a unos **US$9 millones** restantes tras el ataque (orden de magnitud coherente con un golpe fuerte de TVL en un día). El TVL preincidente del protocolo en [DefiLlama](https://defillama.com/protocol/ostium) se reportó en decenas de millones de dólares, según la captura usada. Ostium confirmó el incidente en X: el equipo dijo estar **al tanto de un problema en el vault OLP**, haber **pausado todo el trading** y estar investigando. Según el mismo reportaje de Crypto Briefing, el protocolo indicó que **los fondos de traders y las posiciones abiertas permanecen preservados en estado congelado** mientras avanza la investigación del vault. Esa distinción importa: los proveedores de liquidez del pool OLP absorben la vía de pérdida como contraparte; las posiciones abiertas del libro son una congelación aparte, no el mismo producto que las participaciones del vault. ## Por qué los keepers y los forwarders “de confianza” son la historia Esto no fue un empujón de mercado con flash loan sobre un token ilíquido ni un bug de firma nula del tipo que PTYcoin cubrió en el [incidente Bonzo Lend / Supra](/es/posts/2026-07-14-bonzo-lend-supra-oracle-exploit/). El fallo que describe Blockaid está un nivel más afuera: la **automatización que debería empujar precios reales honestos a la cadena**. El [alcance del bug bounty de Ostium en Immunefi](https://immunefi.com/bug-bounty/ostium/scope/), citado por The Defiant, trata a los keepers registrados (incluido PriceUpKeep) y a sus forwarders como **de confianza y operando correctamente**. Hallazgos que requieran un keeper comprometido o malicioso quedan **fuera** de ese programa. En lenguaje llano: la superficie de ataque que pagó estaba en una zona que el programa público de seguridad pedía tratar como infraestructura, no como blanco. Algunos textos secundarios enmarcaron el evento como una **clave de firmante de oráculo comprometida**. La descripción pública de Blockaid enfatiza un **forwarder registrado** e **informes autorizados con fechas futuras**; Ostium no ha confirmado cómo el atacante obtuvo la capacidad de enviar esos reportes. Hasta que el equipo publique un post-mortem, la formulación honesta es: **se abusó de una ruta autorizada de reportes de precio**, y el vault pagó según su diseño sobre entradas malas. El patrón es conocido. [Summer.fi](https://blog.summer.fi/lazy-summer-usdc-vault-exploit-post-mortem-what-happened-and-what-comes-next/) perdió unos **US$6 millones** el 6 de julio en una manipulación de precio de share / vault. Ataques anteriores de suplantación de keepers (incluido KiloEx en 2025) usaron una idea similar: cuando la maquinaria que entrega precios se confía por defecto, los contratos no necesitan un bug novedoso para vaciar un vault. Solo necesitan un precio incorrecto y aún autorizado. ## Adónde fue el dinero después Para el jueves, PeckShield reportó que el explotador había canjeado el USDC robado por unos **12.080 ETH** y ya había depositado unos **10.540 ETH** en [Tornado Cash](https://thedefiant.io/news/hacks/ostium-vault-exploiter-routes-10-540-eth-to-tornado-cash), con el lavado aún en curso al momento de esa actualización. PeckShield también dijo que la primera billetera del atacante se fondeó con montos pequeños de ETH desde ChangeNow y Bybit. Esa ruta (drenaje en stablecoin → ETH → mixer) es la coreografía post-exploit estándar que las firmas de seguridad siguen tras golpes grandes a vaults. Ostium tenía tracción real de producto antes de la pausa: materiales públicos y la cobertura citan **miles de millones en volumen acumulado** en decenas de mercados RWA, y unos **US$27,8 millones** de financiamiento de inversores como General Catalyst y Jump Crypto (según CoinDesk y The Defiant). Las auditorías y el volumen no cubren la **automatización off-chain o semi-confiable** que queda fuera del perímetro del bug bounty. ## Qué debería sacar el lector Traders y proveedores de liquidez en América Latina ya usan vaults en USDC, libros de perpetuos y productos ligados a RWA en L2 grandes; Arbitrum es un riel de liquidación habitual para ese flujo. La lección es concreta y no necesita un subtrama regional forzado: - Una **participación de LP en un vault de perpetuos** es exposición a la contraparte del libro y al feed de precios que lo marca. - **“Auditado”** suele referirse a los contratos, no a cada keeper, firmante o forwarder en el que confían. - Cuando un venue **pausa el trading** y congela el libro, el acceso al capital puede detenerse aunque tu billetera personal nunca haya salido de tu control. La autocustodia protege las claves que tú guardas. No protege el capital que depositaste en un pool cuyo PnL depende de la ruta de oráculo autorizada de alguien más. Dimensiona esas posiciones como riesgo de venue, y guarda el ahorro de largo plazo donde una página de estado no sea la condición de desbloqueo. ## Conclusión El **15 de julio de 2026**, Ostium pausó el trading después de que un atacante usara automatización registrada de precios e informes de oráculo con fechas futuras para forzar unos **US$18 millones** (con algunos rastreadores después cerca de **US$24 millones**) en USDC fuera del vault OLP en Arbitrum. El equipo investiga; las posiciones de traders se reportan congeladas, no anuladas; los fondos robados se rotaron en gran parte a ETH y hacia Tornado Cash. Si haces LP o trading en vaults de perpetuos, trata las asunciones de confianza en keepers y oráculos como riesgo de primer orden, no como letra chica. Esto no es consejo financiero. --- Source: PTYcoin — https://ptycoin.com/es/posts/2026-07-17-ostium-18m-oracle-keeper-exploit/. Free to read and cite with attribution to ptycoin.com. AI-usage terms: https://ptycoin.com/es/ai-usage/