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 paso de agotamiento de arbitraje y publica el precio justo residual con cadencia subsegundo, desde dentro de un enclave certificado por TEE. El coste de manipulación es demostrable, no declarado. Investigación de Eliott Méa, Lead Oracle Architect de Kaskad, respaldada 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. Sin embargo, todos los exploits relevantes en lending del último ciclo se remontan a uno de tres vectores: una votación de gobernanza que empujó los parámetros a territorio inseguro, un oracle que fue objeto de front-running, o un treasury sin límites estrictos. La mayoría de los protocolos de lending heredan un feed de precios genérico y confían en la suerte. Kaskad ejecuta el suyo propio.
El COB Oracle está diseñado para una sola tarea: valorar el collateral en operaciones críticas para la solvencia. No es un servicio de datos genérico adaptado para lending; es un feed específicamente construido donde cada decisión de diseño sirve a la corrección de las liquidaciones, al escalado del coste de ataque y a 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, desplegados en cada cadena en la que opera Kaskad (Igra, Robinhood Chain), que verifican on-chain las certificaciones del enclave 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 con cada exchange se abren desde el interior del enclave Nitro y quedan 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 del último trade, el oracle reconstruye un Consolidated Order Book: la profundidad de bid/ask de cada fuente se normaliza sobre una cuadrícula de precios compartida y se apila en un único libro combinado. A continuación ejecuta un paso de agotamiento de arbitraje, emparejando toda la liquidez cruzada exactamente como lo haría un arbitrajista, nivel por nivel, dejando 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 matemática está demostrada en A Mathematical Framework for Price Oracles, y la 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: mover el precio justo publicado en cualquier cantidad significativa obliga al atacante a perturbar la profundidad real en todo el libro combinado con un capital que escala con tanto el tamaño del movimiento como el grosor actual del libro. Dado que el coste lo determina 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 que funciona" y "la matemática dice que cuesta X desplazar el precio en Y".
La clave de firma del enclave se genera dentro de el 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 la 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 detecten, y luego firman conjuntamente el snapshot post-trade resultante mediante una firma de umbral que KaskadRouter se verifica on-chain. V2 elimina por completo cualquier punto único de confianza del feed de precios.
Las actualizaciones de precio se publican cada 30 segundos por defecto. Una actualización de precio 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 los borrowers 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 muchos bloques paralelos en la misma ronda. 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 amplio es el DAG. Esta es la razón estructural por la que Igra, anclada a Kaspa L1, es la base de operaciones de Kaskad. El mismo feed firmado por el enclave se publica on-chain en cada cadena donde opera Kaskad, incluida Robinhood Chain.
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 post-interrupción puede tener una desviación más amplia (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 se bloquean cuando el feed de cualquier activo relevante está obsoleto más allá de maxStaleness (con un tope de 4 horas). Supply, repay y 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.NitroAttestationVerifierParsea y verifica on-chain los documentos de certificación AWS Nitro; extrae el PCR0 y la dirección de firma del enclave.KaskadAggregatorV3Wrapper compatible con la interfaz IAggregatorV3Interface de Chainlink, uno desplegado por activo, sustituto directo para la configuración del price oracle de Aave.KaskadRouterRouter de actualización de precio + acción de protocolo atómica; almacena la dirección del caller en transient storage para el staleness checker.KaskadStalenessCheckerImplementación de Aave IPriceOracleSentinel; bloquea borrow/liquidation cuando cualquier feed relevante está obsoleto.Direcciones completas de contratos en la página de Contratos dedicada.
Nodo único certificado por TEE. Agregación del Consolidated Order Book desde más de 15 fuentes CEX. Cadencia subsegundo. Enclave AWS Nitro. Un único feed, publicado on-chain donde sea que Kaskad esté desplegado.
Decentralised Arbitrage Network. Agentes de arbitraje independientes geodistribuidos + nodos agregadores. Snapshots firmados por umbral verificados on-chain. Elimina cualquier punto único de confianza del feed de precios.