Attaque d’oracle RWA : quand le flux de prix ment

À quoi ressemble réellement une attaque d’oracle RWA

Un RWA, ou token d’actif du monde réel, représente quelque chose hors chaîne : un bon du Trésor américain, une part de capital dans l’immobilier commercial, une position de crédit privé, une part de fonds monétaire. Pour utiliser ce token comme garantie, frapper un stablecoin adossé à celui-ci ou liquider un emprunteur, un protocole DeFi a besoin d’un prix. Ce prix doit venir de quelque part, et ce quelque part est ce que nous appelons un oracle.

Une attaque d’oracle, au sens strict, désigne tout incident où le prix vu par le protocole diverge de manière significative du prix auquel l’actif sous-jacent se négocierait réellement. La divergence peut résulter d’un adversaire qui pousse un flux fondé sur le marché, d’un émetteur qui suspend un flux NAV, d’un opérateur de nœud qui passe hors ligne, d’une banque dépositaire qui gèle les remboursements ou simplement d’une mise à jour lente pendant un week-end. Le point commun est que le chiffre on-chain cesse de correspondre à la réalité assez longtemps pour que quelqu’un tire de la valeur de cet écart.

Cela compte pour les protocoles RWA d’une manière qui ne s’applique pas, par exemple, à un simple pool ETH/USDC. Le pool peut se corriger de lui-même, car les arbitragistes comblent l’écart en quelques blocs. Un fonds immobilier tokenisé ne le peut pas. Il n’existe pas de marché mondial 24/7 pour un immeuble de bureaux à Brooklyn, donc lorsque la NAV on-chain indique une chose et que les expertises sous-jacentes en indiquent une autre, le protocole reste bloqué avec ce que l’oracle a publié en dernier.

Comment la perte se propage : déroulé d’un scénario de REIT tokenisé

Imaginez un protocole appelé BlockREIT qui accepte comme garantie un fonds immobilier tokenisé, appelé tREIT. Le protocole permet aux utilisateurs de frapper un stablecoin, disons rUSD, contre du tREIT avec un ratio prêt-valeur de 70 %. L’oracle est un flux fondé sur la NAV exploité par l’émetteur de tREIT, actualisé on-chain toutes les 24 heures et signé par un multisig de trois dépositaires. Les smart contracts sont audités. Le marketing parle de qualité institutionnelle.

Vendredi soir, le REIT sous-jacent annonce que l’un de ses plus grands locataires a fait défaut sur un bail de 40 millions de dollars et que l’auditeur du fonds a besoin de quatre à six semaines pour réévaluer les actifs. Le monde hors chaîne estime désormais que tREIT vaut environ 0,78 dollar par token. L’oracle on-chain indique encore 1,00 dollar, car la prochaine actualisation n’aura lieu que samedi à midi, et la politique de gouvernance de l’émetteur interdit les mises à jour en cours de cycle.

Toute personne qui suit les nouvelles hors chaîne peut désormais voir l’écart. Un emprunteur avec une position à 0,95 dollar de prêt-valeur est en réalité surgaranti en apparence et sous-garanti dans les faits. Le protocole ne peut pas liquider, car l’oracle indique encore que l’emprunteur est en sécurité. L’emprunteur, qui a suivi la situation de près, retire la garantie tREIT vers un nouveau wallet, l’échange contre un token plus liquide sur un DEX où la liquidité de tREIT est faible, puis s’en va. Le protocole se retrouve avec un passif en stablecoin adossé à une garantie qui vaut désormais moins que le prêt.

La partie intéressante est ce qui se passe ensuite. L’oracle s’actualise enfin samedi à midi et inscrit 0,78 dollar. Les liquidations se déclenchent automatiquement sur toutes les positions au-dessus de la ligne de 70 % de LTV. Mais la liquidité du DEX pour tREIT est désormais épuisée, et les bots liquidateurs ne peuvent exécuter qu’à 0,55 dollar, car ils vendent sur un marché à sens unique. La dette irrécouvrable s’accumule dans le protocole. rUSD perd son ancrage. Les détenteurs remboursent rUSD via le protocole sur l’hypothèse de la valeur nominale, en vidant ce qui reste de la trésorerie. La perte se propage d’une seule NAV obsolète à une défaillance de stablecoin en environ douze heures.

Chaque étape de ce scénario est en principe évitable, et presque chaque mesure de prévention ajoute de la friction, de la latence ou de la complexité de gouvernance qu’un émetteur RWA préférerait éviter.

Les deux types d’oracles RWA : basés sur le marché ou basés sur la NAV

Les protocoles RWA ont en pratique deux options pour obtenir les prix, et ce choix est plus déterminant que le nom de marque du fournisseur d’oracle.

Oracles basés sur le marché

Un oracle basé sur le marché agrège les prix provenant de plateformes où l’actif se négocie réellement. Chainlink est le réseau le plus établi dans ce domaine, avec un réseau d’opérateurs de nœuds indépendants qui récupèrent les prix auprès de plusieurs exchanges centralisés et décentralisés, les agrègent hors chaîne, puis publient on-chain une valeur médiane ou pondérée par le volume. Pyth suit une autre approche, en obtenant les prix directement auprès de teneurs de marché et d’exchanges sur une base volontaire, puis en les publiant avec une latence inférieure à la seconde sur Solana et d’autres chaînes.

Pour un bon du Trésor tokenisé comme BUIDL, qui se négocie sur quelques plateformes en liste blanche, un oracle basé sur le marché peut fonctionner, mais le volume sur ces plateformes constitue le goulot d’étranglement. Si un manipulateur vend 5 millions de dollars de BUIDL sur une seule plateforme pendant une session nocturne en Asie, la médiane de l’oracle peut bouger avant que l’arbitrage ne comble l’écart. La conception de Pyth s’en protège partiellement en pondérant les éditeurs et en exigeant un nombre minimal d’éditeurs, mais cette protection est statistique, pas absolue.

L’étude de cas classique ici est Mango Markets en 2022, où un attaquant a gonflé le prix de MNGO-PERP sur un seul exchange, utilisé ce prix gonflé comme collatéral pour emprunter l’intégralité de la trésorerie, et drainé environ 114 millions de dollars. Le flux de prix fonctionnait techniquement. Il lisait simplement une seule plateforme dont l’attaquant contrôlait le volume.

Oracles basés sur la NAV

Un oracle basé sur la NAV, à l’inverse, ne regarde pas les transactions. Il publie la valeur liquidative propre de l’émetteur, généralement calculée à partir d’expertises, de rapports d’administration de fonds ou d’une comptabilité mark-to-model. Pour un actif illiquide comme un fonds immobilier tokenisé ou une note de crédit privée, la NAV est souvent la seule réponse honnête, car il n’existe pas de marché continu à observer.

Le coût est que les mises à jour de la NAV sont lentes. Une actualisation hebdomadaire ou quotidienne signifie que le prix on-chain a, au mieux, 24 heures de retard. Pendant cette fenêtre, tout avantage informationnel hors chaîne peut être exploité. L’incident Synthetix sUSD de 2019, bien qu’antérieur à la plupart des infrastructures RWA, est parlant : un flux d’oracle sur le won coréen a fourni un taux hors marché, et des traders ont drainé le système avant que le flux ne soit corrigé. L’architecture s’est améliorée, mais le problème fondamental persiste : un seul éditeur de confiance devient un point de défaillance unique.

Les flux basés sur la NAV échouent aussi d’une manière différente des flux de marché. L’éditeur peut interrompre la publication. L’éditeur peut être l’émetteur lui-même, ce qui soulève des questions évidentes de conflit d’intérêts. La clé de signature de l’éditeur peut être compromise. L’administrateur du fonds peut manquer une fenêtre de rachat. Aucun de ces cas ne constitue une manipulation de prix au sens technique, mais pour le protocole, ils se ressemblent tous : l’oracle cesse de se mettre à jour, ou se met à jour vers un chiffre auquel personne ne croit.

Cas historiques de manipulation d’oracles, avec le contexte RWA

L’historique des manipulations d’oracles dans l’industrie crypto ressemble à un catalogue de leçons répétées. bZx a été exploité deux fois en 2020 au moyen d’une manipulation d’oracle sur une liquidité faible, entraînant environ un million de dollars de pertes au total sur les deux incidents. Harvest Finance a perdu 24 millions de dollars en octobre 2020 à cause d’un arbitrage sur une courbe de stablecoin lié au timing de l’oracle. Cream Finance a perdu 130 millions de dollars en octobre 2021 à la suite d’une manipulation d’oracle de prix qui valorisait un token de collatéral à une référence gonflée.

L’exploit Mango Markets de 2022 a été la démonstration la plus nette du schéma : un flux de prix provenant d’une seule plateforme, un manipulateur disposant de capitaux, et un protocole de prêt qui faisait confiance au flux sans vérifier le volume. La défense d’Avraham Eisenberg lors du procès était qu’il faisait du trading, pas du piratage. Le jury n’a pas été d’accord. Les 114 millions de dollars étaient bien réels.

Dans l’espace propre aux RWA, 2024 a ajouté des cas plus discrets mais instructifs. Un protocole de crédit privé tokenisé a subi un événement partiel de créance douteuse lorsque son oracle NAV a continué à valoriser les positions au pair même après que l’émetteur sous-jacent a déposé une demande de restructuration. Un fonds monétaire tokenisé a connu un décrochage temporaire lorsque sa banque dépositaire a suspendu les rachats pour examen AML, laissant le prix on-chain inchangé pendant que les détenteurs hors chaîne faisaient la queue pour sortir. Aucun de ces événements n’était un hack au sens juridique. Tous deux ont généré de vraies pertes pour les utilisateurs des protocoles.

La leçon n’est pas que les oracles sont particulièrement mauvais. La leçon est que la manipulation d’oracle est une catégorie d’attaque, pas un bug unique, et que les protocoles RWA héritent de toutes les variantes de cette catégorie, plus quelques nouvelles liées à la garde et à la gouvernance des émetteurs.

Pourquoi un oracle précis à 1 point de base perd quand même de l’argent

Les textes marketing des produits RWA institutionnels se vantent souvent de la précision des oracles. Le prix on-chain est mis à jour au point de base près, soit 0,01 %, ce qui est parfois plus précis que le marché obligataire lui-même. C’est réel, mais cela répond à la mauvaise question.

Un bon du Trésor tokenisé avec un oracle parfaitement exact perd quand même de l’argent si le dépositaire qui détient les Treasuries sous-jacents fait défaut. L’exemple classique est l’incident d’octobre 2023, lorsqu’un petit dépositaire crypto institutionnel a suspendu les retraits ; les produits de bons du Trésor tokenisés ayant ce dépositaire comme unique sous-dépositaire ont vu leur NAV se figer parce que les actifs sous-jacents ne pouvaient pas être rachetés. La précision de l’oracle n’avait aucune importance, car cette précision était appliquée à un chiffre que personne ne pouvait vérifier de manière indépendante.

La même logique s’applique à l’immobilier tokenisé, au crédit privé tokenisé et aux matières premières tokenisées. L’oracle vous dit ce que vaut l’actif. Il ne vous dit pas si l’actif existe encore, s’il appartient toujours au détenteur du token, s’il peut être racheté à la demande ou s’il fait l’objet d’une revendication juridique. Ce sont des questions de garde et de droit, et elles se situent entièrement en dehors du smart contract.

Pour les responsables des risques, cela signifie qu’un examen de l’oracle est nécessaire mais insuffisant. L’examen complet porte d’abord sur la garde, puis sur l’oracle, puis sur la gouvernance, puis sur l’opposabilité juridique du token sur l’actif sous-jacent, à peu près dans cet ordre.

Comment le consensus Hashgraph et Canton Network abordent le problème

La plupart des conceptions d’oracles RWA traitent le flux de prix comme un problème de données : qui publie le chiffre, à quelle fréquence, et comment leur faire confiance. Le consensus Hashgraph et Canton Network le traitent plutôt comme un problème de coordination. La différence est architecturale, pas seulement une question de marque.

Le consensus Hashgraph, protocole sous-jacent du réseau Hedera et fondation de l’écosystème HASH, est un protocole de gossip tolérant aux fautes byzantines, avec tolérance aux fautes byzantines asynchrone et finalité en quelques secondes. Pour les cas d’usage RWA, la propriété pertinente n’est pas la vitesse brute, mais la finalité déterministe avec des horodatages vérifiables. Un flux d’oracle publié sur un réseau basé sur Hashgraph porte un horodatage de consensus accepté par tous les participants, ce qui rend plus difficile d’affirmer après coup qu’un prix n’était pas le prix de consensus à un moment donné.

Canton Network adopte une approche plus radicale. Plutôt qu’une seule chaîne globale avec un seul flux de prix, Canton est un réseau de sous-réseaux interopérables, chacun pouvant être un registre permissionné exploité par des institutions réglementées. Le composant synchronizer coordonne des transactions atomiques entre sous-réseaux sans les obliger à partager un environnement d’exécution unique. Pour un oracle RWA, cela signifie que le flux de prix n’a pas du tout besoin d’être publié sur une chaîne publique. La banque qui détient les Treasuries sous-jacents, l’administrateur du fonds qui calcule la NAV, le dépositaire et le protocole DeFi qui consomme le prix peuvent tous exploiter leurs propres sous-réseaux et utiliser le synchronizer pour s’accorder sur un prix de manière atomique avec une transaction liée, comme la création d’un token ou une vérification de collatéral.

L’effet pratique est de déplacer entièrement le problème de l’oracle hors de la chaîne publique, vers une couche de coordination privée où chaque participant est identifié et où les recours juridiques restent intacts. Ce n’est pas une solution universelle. Elle exige une coopération institutionnelle et une volonté d’opérer dans un cadre permissionné. Mais pour les grands déploiements RWA où l’actif est un titre réglementé et où les participants sont des entités connues, elle supprime plusieurs catégories d’attaques contre les oracles en éliminant la surface de prix de la chaîne publique.

Ce que les responsables des risques doivent réellement faire

Pour quelqu’un qui évalue une intégration RWA, les questions ne sont pas abstraites. Elles sont concrètes, et la plupart d’entre elles ont des réponses inconfortables.

Premièrement, demandez quel type d’oracle le protocole utilise et si l’actif se négocie réellement en continu sur les plateformes que l’oracle consulte. Si la réponse repose sur la NAV, demandez qui la publie, à quelle fréquence, et quelle est la politique pour les mises à jour non programmées. S’il n’y a pas de réponse, partez du pire scénario.

Deuxièmement, demandez ce qui se passe pendant une panne de l’oracle. Le protocole se met-il en pause ? Se rabat-il sur un prix conservateur, par exemple la dernière mise à jour moins une décote ? Autorise-t-il de nouveaux emprunts contre le prix obsolète ? Les exploits Mango et bZx ont tous deux fonctionné parce que le protocole a continué à opérer pendant la manipulation. Un protocole bien conçu devrait traiter un oracle obsolète comme une urgence.

Troisièmement, posez des questions sur la conservation. Qui détient l’actif sous-jacent ? Le dépositaire est-il ségrégué ? Existe-t-il une structure à l’abri de la faillite ? Le dépositaire a-t-il déjà suspendu les retraits ? Un oracle à 1 point de base au-dessus d’une structure de conservation capable de geler les rachats n’est pas un système à 1 point de base.

Quatrièmement, posez des questions sur la gouvernance. Qui peut changer la source de l’oracle ? Qui peut mettre le flux en pause ? Qui peut mettre le prix à jour manuellement ? Dans un déploiement RWA permissionné, la gouvernance est l’oracle, et les réponses déterminent le type d’attaque auquel le protocole est exposé.

Enfin, calibrez l’exposition en conséquence. Même un protocole RWA bien conçu peut échouer d’une manière qu’aucun examen d’oracle ne permettrait de prévoir. Les cas limites de 2024 impliquaient tous des émetteurs, des dépositaires ou des contreparties agissant de manière inattendue. La diversification entre émetteurs RWA et entre types d’oracles réduit le risque qu’une défaillance unique se propage à tout un portefeuille.

Gardez une longueur d’avance sur le risque des oracles RWA grâce à des signaux structurés

La manipulation des oracles RWA évolue plus vite qu’un analyste seul ne peut la suivre. De nouveaux exploits, de nouvelles suspensions de la part de dépositaires, de nouveaux litiges sur la NAV et de nouvelles propositions de gouvernance apparaissent chaque semaine, et la plupart sont enfouis dans des forums de gouvernance, des dossiers judiciaires ou des post-mortems qui ne deviennent pas tendance sur les réseaux sociaux. Zippfeed fait remonter les actualités RWA avec un score de sentiment, en classant chaque information comme bullish, neutral ou bearish selon que la nouvelle indique un protocole sous-jacent plus sain ou plus fragile, ainsi qu’une note d’importance qui met en avant les informations les plus susceptibles de faire bouger les prix ou de déclencher des liquidations. Cette combinaison permet aux responsables des risques et aux traders avancés de repérer les signaux précoces d’un problème d’oracle ou de conservation avant que le prix on-chain ne le reflète.