La plupart des exploits de lending ont pour origine une manipulation d'oracle. Le Kaskad COB Oracle agrège la profondeur bid/ask en temps réel depuis plus de 15 exchanges majeurs en un seul consolidated order book, exécute une passe d'épuisement d'arbitrage, et publie le prix d'équilibre résiduel à cadence infra-seconde — depuis un enclave attesté par TEE. Le coût de manipulation est prouvable, pas simplement affirmé. Recherche par Eliott Méa, architecte principal de l'oracle chez Kaskad — soutenu par une subvention de la Kaspa Ecosystem Foundation.
Le rôle d'un oracle semble simple — indiquer au protocole ce que vaut un actif en ce moment. Pourtant, chaque exploit majeur de lending du dernier cycle remonte à l'un de ces trois vecteurs : un vote de gouvernance poussant les paramètres en territoire dangereux, un oracle victime de front-running, ou une trésorerie sans limites strictes. La plupart des protocoles de lending héritent d'un flux de prix générique et espèrent que ça tient. Kaskad gère le sien.
Le COB Oracle est conçu pour une seule mission : évaluer le collateral pour les opérations critiques de solvabilité. Pas un service de données générique réutilisé pour le lending — un flux dédié où chaque choix de conception sert la justesse des liquidations, la scalabilité du coût d'attaque, et la fraîcheur des données sous pression.
Le Kaskad COB Oracle est un système d'agrégation de prix multi-sources adossé à un TEE. Deux composants :
kaskad-nuntius — un binaire Rust qui s'exécute dans un enclave AWS Nitro. Il récupère la profondeur d'order book depuis plus de 15 sources d'exchanges, les agrège, et signe le résultat avec une clé qui ne quitte jamais l'enclave.kaskad-nuntius-contracts — un ensemble de contrats EVM qui vérifient les attestations d'enclave on-chain et acceptent les mises à jour de prix signées.La profondeur bid/ask en temps réel est collectée auprès des principaux venues CEX, notamment Binance, OKX, Bybit, Coinbase, Kraken, KuCoin, Gate.io, MEXC, Bitget, Bitfinex, Bitstamp, Crypto.com, HTX, et d'autres. L'authenticité des sources est garantie à l'intérieur de l'enclave : les sessions TLS vers chaque exchange sont ouvertes depuis l'enclave Nitro et couvertes par la même attestation qui signe le prix publié — corrompre une source se ramène à compromettre l'exchange lui-même.
Plutôt que de faire la moyenne des derniers prix échangés, l'oracle reconstruit un Consolidated Order Book : la profondeur bid/ask de chaque source est normalisée sur une grille de prix commune et empilée en un seul carnet combiné. Il exécute ensuite une passe d'épuisement d'arbitrage — en faisant correspondre toute liquidité croisée exactement comme le ferait un arbitrageur, niveau par niveau — laissant un carnet résiduel qui satisfait la condition de non-arbitrage.
Le prix d'équilibre est le point médian de ce spread résiduel (son centre de Chebyshev). La démonstration mathématique figure dans A Mathematical Framework for Price Oracles — et ce choix minimise l'erreur dans le pire cas par rapport à tout prix de clearing « vrai » plausible.
La propriété de sécurité clé prouvée dans l'article : déplacer le prix d'équilibre publié d'un montant significatif oblige un attaquant à perturber la profondeur réelle du carnet combiné d'une quantité de capital qui s'échelonne avec à la fois l'ampleur du déplacement et l'épaisseur existante du carnet. Le coût étant fixé par la profondeur agrégée inter-venues, un attaquant ne peut pas manipuler le flux à moindre coût en faussant un seul exchange.
Pour les actifs liquides, la manipulation d'oracle est coûteuse par construction — et ce coût est prouvable plutôt qu'affirmé. C'est la différence entre « nous l'avons testé et ça semble tenir » et « les maths indiquent qu'il en coûte X pour déplacer le prix de Y ».
La clé de signature de l'enclave est générée à l'intérieur de l'enclave AWS Nitro et n'en est jamais exportée. L'enclave produit un document d'attestation contenant la mesure PCR0 (un hash du binaire de l'enclave). Chacun peut :
NitroAttestationVerifier.sol vérifie l'attestation on-chain et enregistre l'adresse de signature de l'enclave. KaskadPriceOracle.sol n'accepte ensuite que les mises à jour de prix signées par une adresse d'enclave enregistrée.
La V1 actuelle est un nœud unique attesté. L'architecture cible est le DAN (Decentralised Arbitrage Network) — un réseau géo-distribué d'agents d'arbitrage indépendants et de nœuds agrégateurs. À chaque epoch, les bots attestés par TEE ne se contentent pas d'observer mais exécutent activement l'arbitrage sur tout croisement détecté, puis cosignent conjointement le snapshot post-trade résultant via une signature à seuil qui KaskadRouter est vérifiée on-chain. La V2 élimine tout point de confiance unique du flux de prix.
Les mises à jour de prix sont publiées toutes les 30 secondes par défaut. Une mise à jour est également déclenchée à la demande lorsqu'un utilisateur (ou un agent IA) interagit avec le protocole via KaskadRouter — les liquidateurs et les emprunteurs opèrent toujours sur un prix frais. La vivacité de l'oracle ne dépend pas d'un seul processus relayeur.
Kaspa étant un DAG plutôt qu'une chaîne linéaire, l'oracle peut répartir sa publication sur de nombreux blocs parallèles au sein du même round. Sur une chaîne linéaire, un seul proposant de bloc adverse peut réordonner ou censurer une publication ; sur un DAG, un attaquant doit contrôler la majorité des blocs concurrents — une tâche exponentiellement plus difficile à mesure que le DAG s'élargit. C'est la raison structurelle pour laquelle Kaskad vit sur Igra, qui s'ancre lui-même au Kaspa L1.
Chaque actif dispose d'un plafond de variation de prix par mise à jour (15 % pour les actifs liquides). Après 4 heures de silence on-chain, la première mise à jour post-interruption est autorisée à présenter un écart plus large (30 %) mais nécessite 2× le quorum de sources normal pour être acceptée. La fraîcheur des données est appliquée par KaskadStalenessChecker, qui implémente l'interface IPriceOracleSentinel d'Aave. Le borrow et la liquidation sont bloqués lorsque le flux d'un actif concerné est périmé au-delà de maxStaleness (plafonné à 4 heures). Le supply, le remboursement et le retrait restent disponibles — les utilisateurs peuvent toujours réduire leur exposition.
KaskadPriceOracleOracle principal — vérifie les signatures, applique le quorum et le coupe-circuit, stocke l'historique des prix.NitroAttestationVerifierAnalyse et vérifie les documents d'attestation AWS Nitro on-chain ; extrait le PCR0 et l'adresse de signature de l'enclave.KaskadAggregatorV3Wrapper compatible avec l'interface Chainlink IAggregatorV3Interface — un déploiement par actif, plug-and-play pour la configuration de l'oracle de prix d'Aave.KaskadRouterRouteur atomique mise à jour de prix + action protocole ; renseigne le stockage transient avec l'adresse de l'appelant pour le staleness checker.KaskadStalenessCheckerImplémentation de l'IPriceOracleSentinel d'Aave ; bloque le borrow et la liquidation lorsque tout flux concerné est périmé.Adresses complètes des contrats sur la page Contrats dédiée.
Nœud unique attesté par TEE. Agrégation Consolidated Order Book depuis plus de 15 sources CEX. Cadence infra-seconde. Enclave AWS Nitro.
Decentralised Arbitrage Network. Agents d'arbitrage indépendants géo-distribués + nœuds agrégateurs. Snapshots signés par seuil, vérifiés on-chain. Élimine tout point de confiance unique du flux de prix.