La plupart des exploits de lending trouvent leur origine dans la 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 order book consolidé, effectue une passe d'épuisement d'arbitrage, puis publie le prix d'équilibre résiduel à une cadence inférieure à la seconde : depuis l'intérieur d'une enclave attestée par TEE. Le coût de manipulation est prouvable, pas simplement affirmé. Recherche menée par Eliott Méa, Lead Oracle Architect chez Kaskad, soutenue par une subvention de la Kaspa Ecosystem Foundation.
Le rôle d'un oracle paraît simple : indiquer au protocole la valeur d'un actif au moment présent. Pourtant, chaque exploit majeur de lending du dernier cycle remonte à l'un de trois vecteurs : un vote de gouvernance poussant les paramètres en zone dangereuse, un oracle victime d'un front-run, 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 tienne. Kaskad gère le sien.
Le COB Oracle est conçu pour une seule mission : valoriser le collateral pour les opérations critiques à la solvabilité. Ce n'est pas un service de données générique réutilisé pour le lending : c'est un flux dédié où chaque choix de conception sert la justesse des liquidations, la résistance aux attaques et la fraîcheur des prix sous stress.
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 une enclave AWS Nitro. Il récupère la profondeur d'order book depuis plus de 15 sources d'exchanges, les agrège, puis signe le résultat avec une clé qui ne quitte jamais l'enclave.kaskad-nuntius-contracts: un ensemble de contrats EVM, déployés sur chaque blockchain sur laquelle Kaskad opère (Igra, Robinhood Chain), 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 revient à compromettre l'exchange lui-même.
Plutôt que de calculer une moyenne des derniers prix exécuté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 dans un seul carnet d'ordres combiné. L'oracle effectue ensuite une passe d'épuisement d'arbitrage, en appariant 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 correspond au milieu 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 au pire cas face à tout prix de liquidation plausible.
La propriété de sécurité clé démontrée dans l'article : déplacer le prix d'équilibre publié de toute façon significative oblige un attaquant à perturber la profondeur réelle sur l'ensemble du carnet combiné par un montant en capital qui évolue avec à la fois l'amplitude du déplacement et l'épaisseur actuelle du carnet. Ce coût étant déterminé par la profondeur agrégée cross-venue, un attaquant ne peut pas manipuler le flux à moindre coût en biaisant un seul exchange.
Pour les actifs liquides, la manipulation d'oracle est coûteuse par construction, et ce coût est prouvable plutôt que simplement affirmé. C'est la différence entre « nous l'avons testé et ça semble correct » et « les mathématiques 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.
Le V1 actuel 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 n'observent pas seulement : ils exécutent activement l'arbitrage sur tout croisement détecté, puis co-signent collectivement le snapshot post-trade résultant via une signature à seuil qui KaskadRouter se vérifie on-chain. Le V2 supprime 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 disponibilité de l'oracle ne dépend pas d'un processus de relayage unique.
Kaspa étant un DAG plutôt qu'une chaîne linéaire, l'oracle peut répartir ses publications sur de nombreux blocs parallèles dans le même round. Sur une chaîne linéaire, un seul proposeur de bloc adversarial 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 Igra, ancrée sur Kaspa L1, est la base de Kaskad. Le même flux signé par l'enclave est publié sur chaque blockchain sur laquelle Kaskad opère, Robinhood Chain incluse.
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 habituel pour être acceptée. La détection de données périmées est assurée par KaskadStalenessChecker, qui implémente l'interface IPriceOracleSentinel d'Aave. Le borrow et la liquidation sont bloqués dès que le flux d'un actif concerné est périmé au-delà du 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, conserve 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éployé par actif, remplacement direct pour la configuration de l'oracle de prix d'Aave.KaskadRouterRouteur atomique de mise à jour de prix + action protocolaire ; peuple le transient storage avec l'adresse de l'appelant pour le staleness checker.KaskadStalenessCheckerImplémentation de l'Aave IPriceOracleSentinel ; 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 du Consolidated Order Book depuis plus de 15 sources CEX. Cadence inférieure à la seconde. Enclave AWS Nitro. Un seul flux, publié on-chain partout où Kaskad est déployé.
Decentralised Arbitrage Network. Agents d'arbitrage indépendants géo-distribués + nœuds agrégateurs. Snapshots signés par seuil et vérifiés on-chain. Supprime tout point de confiance unique du flux de prix.