Comment les oracles DeFi agrègent et publient les prix

L’oracle relie une information extérieure à une blockchain au code exécuté onchain. Un protocole de prêt peut lire un flux pour valoriser un collatéral ; un contrat dérivé peut utiliser une référence pour le règlement ou une limite de risque. Le contrat lit l’état publié sur la chaîne, mais ne consulte pas lui-même tous les carnets d’ordres externes pour décider du prix équitable.

« Prix » peut désigner une paire actif/devise de cotation, un taux de rachat défini par le protocole ou une autre mesure. Il ne correspond pas automatiquement au prix de vente d’une position importante. Le guide sur l’impact et le slippage des swaps DEX et la comparaison mark price et dernier échange expliquent d’autres écarts. Cet article porte sur les flux push EVM courants, pas sur une règle universelle de la DeFi.

Dans le modèle Offchain Reporting de Chainlink, des nœuds oracle échangent leurs observations hors chaîne et s’accordent sur un rapport. Un quorum le signe, un transmetteur l’envoie dans une transaction, puis l’agrégateur vérifie les signatures et expose la réponse, l’identifiant de ronde et l’horodatage. La documentation Offchain Reporting décrit la médiane des observations publiée par cette architecture.

Le contrat consommateur ne refait généralement pas l’agrégation : il appelle latestRoundData() sur l’adresse proxy du flux. L’agrégateur derrière le proxy peut changer. Consultez le guide EVM, la référence API et l’adresse de la chaîne précise. Plusieurs nœuds ne signifient pas que leurs sources sont indépendantes : ils peuvent dépendre des mêmes marchés ou fournisseurs.

Beaucoup de flux push combinent un seuil d’écart et un heartbeat. Un mouvement en pourcentage défini par rapport à la dernière valeur publiée peut déclencher un nouveau rapport ; le heartbeat peut en demander un après une durée même sans forte variation. Le répertoire Data Feeds actuel et la liste des adresses affichent les paramètres propres à chaque actif, réseau et flux.

Ce sont des déclencheurs propres au flux, pas une promesse de mise à jour toutes les N secondes. Un petit mouvement peut ne pas franchir le seuil ; un rapport demandé doit encore être observé, transmis et inclus dans un bloc. Le heartbeat ne garantit donc ni l’heure exacte d’arrivée ni l’absence de prix obsolète. Le protocole doit fixer son propre âge maximal selon la rapidité de l’actif et l’usage.

latestRoundData() renvoie l’identifiant de ronde, answer, startedAt, updatedAt et answeredInRound; la référence API indique que le dernier champ est obsolète. answer est un entier à virgule fixe, pas nécessairement un montant en dollars lisible. Lisez decimals() et la description du flux exact. Un flux BTC/USD hypothétique qui renvoie 6,725,000,000,000 avec 8 décimales signifie 67 250 dollars par BTC.

Les décimales du flux et du jeton sont différentes. Un montant ERC-20 peut utiliser 18 décimales alors que la réponse de prix en utilise 8 ; chaque donnée doit être mise à l’échelle selon son unité avant la multiplication. BTC/USD signifie des dollars par bitcoin ; USD/BTC inverse l’unité. Pour dériver une paire, mettez les deux flux à l’échelle et divisez dans le bon ordre. L’exemple de dénomination dérive BTC/EUR depuis BTC/USD et EUR/USD.

updatedAt indique la mise à jour de la dernière ronde. Le consommateur peut comparer ce moment à l’horodatage du bloc actuel et rejeter les valeurs plus anciennes que son âge maximal. Selon le flux, il peut aussi vérifier un horaire non nul, une réponse positive pour un actif à prix positif et des bornes plausibles. Des bornes trop serrées peuvent rejeter un mouvement de marché légitime.

Supposons un marché de prêt hypothétique qui accepte quatre unités de collatéral avec un facteur de 75 %. La dernière réponse vaut 200,000,000,000 avec 8 décimales, soit 2 000 $ par unité ; le plafond d’emprunt est 4 × 2 000 $ × 75 % = 6 000 $. Si le marché tombe à 1 820 $, la baisse est de 9 %. Avec des hypothèses de seuil à 10 % et de heartbeat à 60 minutes, aucun nouveau rapport n’a forcément été demandé ; le plafond au prix bas serait de 5 460 $.

Si l’application rejette les prix de plus de cinq minutes et que la ronde a vingt minutes, elle peut bloquer les nouveaux emprunts plutôt que d’utiliser 2 000 $. Le contrôle ne met pas à jour le flux : il modifie les actions permises quand la donnée dépasse l’âge admis. Emprunt, retrait, liquidation et remboursement peuvent avoir des règles différentes, car tout arrêter peut aussi nuire. Les chiffres et paramètres sont illustratifs, pas des réglages actuels ni des recommandations.

Sur beaucoup de L2, les utilisateurs soumettent leurs transactions via un séquenceur. Pendant une panne ou un redémarrage, elles peuvent être retardées, les opérations habituelles interrompues et des ordres exécutés après un changement de marché. Une réponse de prix apparemment récente ne prouve pas que le parcours d’exécution fonctionnait ou que tous pouvaient agir au même moment.

Chainlink documente un flux distinct d’état du séquenceur L2 : answer == 0 signifie actif et answer == 1, arrêté. startedAt enregistre le changement d’état. L’exemple vérifie l’état puis attend un délai de grâce défini par l’application après la reprise avant de lire le prix. Vérifiez l’adresse et le comportement du réseau dans le guide L2 Sequencer Uptime Feeds. Ce délai ne garantit ni des données fraîches ni la fin des transactions en attente.

Quorum, médiane, écart, heartbeat, limite d’âge et état du séquenceur répondent à des questions limitées. Ils ne garantissent ni liquidité, ni identité correcte de l’actif, ni indépendance des fournisseurs, ni prix exécutable pour une taille donnée. Un horodatage récent peut accompagner une valeur fausse ou manipulée ; une valeur ancienne peut rester proche du marché calme.

Aucun déclencheur n’élimine les écarts soudains, la congestion ou les erreurs de mise à l’échelle, de paire, de fraîcheur ou de liquidation. Les conseils de sélection des flux recommandent d’évaluer la liquidité et les dépendances et de prévoir les données obsolètes, retardées, absentes ou inattendues. Les risques de contrat, gouvernance, pont, collatéral et liquidation subsistent. Le prix oracle d’un stablecoin ne garantit pas son rachat au pair ; voir le guide du depeg.

Identifiez la chaîne, le proxy, la paire, la devise de cotation, les décimales de answer et l’adresse du contrat. Vérifiez que la description correspond à l’actif visé et ne copiez pas l’adresse d’un autre réseau. Examinez le modèle de sources et l’historique si l’usage exige une surveillance plus poussée. Chainlink indique que les agrégateurs peuvent différer selon le réseau : code et configuration comptent.

Puis suivez l’usage de la réponse : conversion des unités, contrôle de updatedAt, âge maximal et réaction à une valeur invalide. Sur L2, vérifiez le flux d’état, l’heure de reprise, le délai de grâce et les transactions retardées. Examinez sur le contrat réel un cas de prix obsolète et un cas de panne/reprise. Pour distinguer les références, consultez mark price et dernier échange.