La mayoría de los exploits en lending tienen su origen en la manipulación del oracle. El Kaskad COB Oracle agrega profundidad de bid/ask en tiempo real de más de 15 exchanges principales en un único libro de órdenes consolidado, ejecuta un pase de agotamiento de arbitraje y publica el precio justo residual con cadencia subsegundo — desde el interior de un enclave certificado por TEE. El coste de manipulación es demostrable, no declarado. Investigación de Eliott Méa, Arquitecto Principal de Oracle de Kaskad — respaldado por una beca de la Kaspa Ecosystem Foundation.
La función de un oracle parece sencilla: decirle al protocolo cuánto vale un activo en este momento. Pero todos los exploits relevantes en lending del último ciclo se remontan a uno de tres vectores: una votación de gobernanza que empuja los parámetros a territorio inseguro, un oracle que fue front-run, o una tesorería sin límites estrictos. La mayoría de los protocolos de lending heredan un price feed genérico y confían en la suerte. Kaskad opera el suyo propio.
El COB Oracle está diseñado para un único propósito: valorar el collateral en operaciones críticas para la solvencia. No es un servicio de datos genérico adaptado para lending — es un feed construido desde cero en el que cada decisión de diseño sirve a la precisión de las liquidaciones, el escalado del coste de ataque y la frescura de los datos bajo presión.
El Kaskad COB Oracle es un sistema de agregación de precios multi-fuente respaldado por TEE. Dos componentes:
kaskad-nuntius — un binario en Rust que se ejecuta dentro de un enclave AWS Nitro. Obtiene la profundidad del libro de órdenes de más de 15 fuentes de exchanges, las agrega y firma el resultado con una clave que nunca abandona el enclave.kaskad-nuntius-contracts — un conjunto de contratos EVM que verifican las certificaciones del enclave on-chain y aceptan actualizaciones de precios firmadas.La profundidad de bid/ask en tiempo real se obtiene de los principales venues CEX, incluyendo Binance, OKX, Bybit, Coinbase, Kraken, KuCoin, Gate.io, MEXC, Bitget, Bitfinex, Bitstamp, Crypto.com, HTX y más. La autenticidad de las fuentes se verifica dentro del enclave: las sesiones TLS hacia cada exchange se abren desde el interior del enclave Nitro y están cubiertas por la misma certificación que firma el precio publicado — corromper una fuente equivale a comprometer el propio exchange.
En lugar de promediar precios de última transacción, el oracle reconstruye un Libro de Órdenes Consolidado: la profundidad de bid/ask de cada fuente se normaliza sobre una cuadrícula de precios común y se apila en un único libro combinado. A continuación ejecuta un pase de agotamiento de arbitraje — cerrando cualquier liquidez cruzada exactamente como lo haría un arbitrajista, nivel por nivel — y obteniendo un libro residual que satisface la condición de no arbitraje.
El precio justo es el punto medio de ese spread residual (su centro de Chebyshev). La demostración matemática se encuentra en A Mathematical Framework for Price Oracles — y esta elección minimiza el error en el peor caso frente a cualquier precio de liquidación "real" plausible.
La propiedad de seguridad clave demostrada en el paper: desplazar el precio justo publicado en cualquier cantidad significativa obliga a un atacante a perturbar la profundidad real en el libro combinado con un capital que escala con tanto el tamaño del desplazamiento como el grosor actual del libro. Dado que el coste lo fija la profundidad agregada entre venues, un atacante no puede manipular el feed de forma barata sesgando un único exchange.
Para activos líquidos, la manipulación del oracle es costosa por construcción — y exactamente cuánto cuesta es demostrable, no una afirmación. Esta es la diferencia entre «lo hemos probado y parece correcto» y «las matemáticas dicen que cuesta X desplazar el precio en Y».
La clave de firma del enclave se genera dentro del enclave AWS Nitro y nunca se exporta. El enclave produce un documento de certificación que contiene la medición PCR0 (un hash del binario del enclave). Cualquiera puede:
NitroAttestationVerifier.sol verifica la certificación on-chain y registra la dirección de firma del enclave. KaskadPriceOracle.sol luego acepta únicamente actualizaciones de precio firmadas por una dirección de enclave registrada.
El V1 actual es un único nodo certificado. La arquitectura objetivo es el DAN (Decentralised Arbitrage Network) — una red geodistribuida de agentes de arbitraje independientes y nodos agregadores. En cada epoch, los bots certificados por TEE no solo observan sino que ejecutan activamente arbitraje contra cualquier cruce que detectan, para luego firmar conjuntamente el snapshot post-operación resultante mediante una firma de umbral que KaskadRouter se verifica on-chain. V2 elimina cualquier punto único de confianza del price feed por completo.
Las actualizaciones de precio se publican cada 30 segundos por defecto. Una actualización también se dispara bajo demanda cuando cualquier usuario (o agente de IA) interactúa con el protocolo a través de KaskadRouter — los liquidadores y prestatarios siempre operan con un precio fresco. La disponibilidad del oracle no depende de un único proceso relayer.
Dado que Kaspa es un DAG y no una cadena lineal, el oracle puede distribuir su publicación entre múltiples bloques paralelos en el mismo round. En una cadena lineal, un único proponente de bloque adversarial puede reordenar o censurar una publicación; en un DAG, un atacante necesita controlar la mayoría de los bloques concurrentes — exponencialmente más difícil cuanto más ancho es el DAG. Esta es la razón estructural por la que Kaskad vive en Igra, que a su vez se ancla a Kaspa L1.
Cada activo tiene un límite de variación de precio por actualización (15% para activos líquidos). Tras 4 horas de silencio on-chain, la primera actualización tras una interrupción puede superar ese límite (30%), pero requiere 2× el quórum normal de fuentes para proceder. La obsolescencia es verificada por KaskadStalenessChecker, que implementa la interfaz IPriceOracleSentinel de Aave. El borrow y la liquidación quedan bloqueados cuando el feed de cualquier activo relevante lleva más tiempo del maxStaleness sin actualización (máximo 4 horas). El supply, el repay y el withdraw permanecen disponibles — los usuarios siempre pueden reducir su exposición.
KaskadPriceOracleOracle principal — verifica firmas, aplica quórum y circuit breaker, almacena el historial de precios.NitroAttestationVerifierAnaliza y verifica documentos de certificación AWS Nitro on-chain; extrae el PCR0 y la dirección de firma del enclave.KaskadAggregatorV3Wrapper compatible con la interfaz Chainlink IAggregatorV3Interface — uno desplegado por activo, sustituto directo para la configuración de price oracle de Aave.KaskadRouterRouter atómico de actualización de precio + acción de protocolo; almacena la dirección del llamador en transient storage para el staleness checker.KaskadStalenessCheckerImplementación de Aave IPriceOracleSentinel; bloquea borrow/liquidación cuando cualquier feed relevante está obsoleto.Direcciones completas de los contratos en la página de Contratos.
Nodo único certificado por TEE. Agregación de Libro de Órdenes Consolidado de más de 15 fuentes CEX. Cadencia subsegundo. Enclave AWS Nitro.
Decentralised Arbitrage Network. Agentes de arbitraje independientes geodistribuidos + nodos agregadores. Snapshots firmados por umbral verificados on-chain. Elimina cualquier punto único de confianza del price feed.