Oracles : le prix auquel le contrat se fie

La frontière entre code et observation

Un contrat intelligent peut appliquer l'arithmétique de manière cohérente avec une mauvaise donnée d'entrée. Un oracle fournit des informations que le contrat ne peut pas déduire indépendamment de son propre état d'exécution, comme un prix de marché externe. La documentation d'Ethereum sur les oracles explique cette frontière entre l'exécution sur blockchain et les données extérieures. La question importante n'est pas seulement de savoir si un flux s'actualise, mais ce que signifie le nombre actualisé.

Un prix peut représenter un marché, un agrégat, une observation pondérée dans le temps ou une valeur de remboursement. Ces définitions répondent à des questions distinctes. Un prix exécuté décrit une transaction ; un prix de référence soutient une règle ; une valeur de remboursement décrit une créance sous conditions. Ne les substituez pas sans explication.

Examiner les spécifications du flux de données

Pour un marché de prêt fictif, indiquez la paire d’actifs, unités, décimales, conditions de mise à jour et comportement de secours. Vérifiez si la valeur est en dollars, autre jeton ou actif de base. Un nombre d’apparence correcte avec un mauvais facteur décimal peut être catastrophique lorsqu’un autre composant l’interprète.

Examinez aussi la fraîcheur des données. Un flux qui ne s'actualise qu'après un écart donné ou un intervalle écoulé peut légitimement différer d'un carnet d'ordres évoluant rapidement. L'application doit définir quand une donnée devient trop ancienne et quelle conduite adopter. Suspendre les nouveaux emprunts peut protéger contre les données périmées tout en laissant les positions existantes exposées aux actualisations ultérieures. Aucune solution de repli n'est universellement sans conséquence.

La liquidité fait partie de la qualité des données

Un marché peu profond peut afficher un dernier prix peu représentatif d’une grosse transaction exécutable. Agréger des places peut réduire la dépendance à une seule, mais propriété commune, liquidité partagée ou pannes synchronisées limitent l’indépendance gagnée. Une moyenne temporelle lisse les mouvements brefs en introduisant un retard. Chaque architecture échange un ensemble de faiblesses contre un autre.

Considérez un jeton coté 10 $, mais dont la profondeur acheteuse proche du cours n'est que de 5 000 $. Valoriser 1 million de dollars de garanties à ce prix marginal ne montre pas que les liquidateurs peuvent réaliser 1 million de dollars. L'oracle peut correctement publier sa référence définie tandis que le modèle de risque surestime le produit récupérable. La qualité des données et la capacité de liquidation sont des problèmes liés, mais distincts.

Tester les deux côtés d’un ratio de garantie

Un prêt garanti dépend du prix de la garantie et de celui de la dette. Emprunter un jeton qualifié de stable ne fixe pas mathématiquement sa valeur en dollars. Si son rachat devient plus cher pendant que la garantie baisse, la position se dégrade des deux côtés. Modélisez ces variations séparément au lieu de maintenir machinalement un côté constant.

Supposons que les garanties valent 12 000 $, que la dette soit de 6 000 unités valant initialement 1 $ chacune et que le seuil hypothétique de liquidation soit de 75 %. Le ratio de santé initial est de 1,50. Si les garanties baissent de 25 % à 9 000 $ tandis que les unités de dette montent à 1,10 $, le ratio devient 9 000 $ × 0,75 ÷ 6 600 $, soit environ 1,023. Une marge apparemment confortable est presque épuisée.

Étudier l’intégration, pas seulement le fournisseur

Un fournisseur de données réputé ne garantit pas qu'une application sélectionne le bon flux, traite les valeurs indisponibles ou vérifie correctement les horodatages. Consultez la documentation de l'application, les audits pertinents et les décisions de paramétrage. Dans un exercice de simulation, suivez dans le calcul une mise à jour de prix ordinaire, puis une mise à jour manquante. Indiquez où les preuves font défaut plutôt que de combler les lacunes par de la confiance.

Un suivi utile distingue mouvement du marché et anomalie du flux. Comparez la référence déclarée à des observations indépendantes et à sa politique de mise à jour prévue. Les écarts appellent une enquête, pas une transaction automatique. Cette leçon vise à comprendre comportement contractuel et risque opérationnel, pas à exploiter une faiblesse des entrées ni à présumer qu’un écart apparent peut être capté sans danger.

Pour vous exercer davantage, calculez la même position de garantie selon trois hypothèses de référence : le dernier prix publié par le flux, un prix acheteur actuellement exécutable et un prix de vente en situation de stress. Identifiez clairement chacune. La fourchette obtenue n'est pas un intervalle de confiance ; elle traduit la sensibilité aux choix de valorisation. Elle vise à révéler quelle définition du prix détermine la conclusion et où des éléments supplémentaires sur la liquidité sont nécessaires.

Écrire les unités avant de faire le calcul

Un jeton de garantie vaut fictivement 0,03 unité d’un actif de référence, lui-même coté 1 500 €. Son prix implicite est de 45 €. Lire directement 0,03 comme un montant en euros produirait une erreur de nature, pas une petite différence entre marchés. La devise de cotation, les décimales et l’identité exacte de l’actif font partie intégrante de la donnée.

Écrivez les unités à chaque étape : « actif de référence par jeton » multiplié par « euros par actif de référence ». L’unité intermédiaire doit s’éliminer. Faites ensuite varier un seul cours en laissant l’autre inchangé. Ce prix composé dépend alors de deux observations, éventuellement datées différemment, et non d’une mesure unique prise au même instant.

Distinguez aussi un cours négociable d’un taux de conversion comptable. Un reçu peut représenter 1,05 unité sous-jacente et se vendre moins cher sur le marché. Utiliser sa créance théorique comme prix de vente immédiatement disponible peut être inadapté à une liquidation. Le bon choix dépend de la fonction du prix dans le protocole.

Suspendre une opération ne supprime pas tout le risque

Un protocole doit décider quoi faire lorsqu’une donnée devient ancienne ou anormale. La documentation Chainlink expose les responsabilités liées au choix et à l’intégration des flux. Choisir un fournisseur ne détermine pas automatiquement les règles de repli de l’application.

Supposons qu’un système de prêt fictif suspende les nouveaux emprunts lorsque le prix est trop ancien. Il peut ainsi éviter de prêter sur une valorisation incertaine. Mais si les liquidations sont également suspendues pendant une chute de la garantie, la dette peut devenir plus difficile à recouvrer. Continuer à liquider sur l’ancien prix pose un autre problème. Il faut donc préciser ce qui s’arrête, ce qui continue et comment le fonctionnement normal reprend.

Construisez une chronologie : dernière observation acceptée, mouvement de marché, franchissement du délai maximal, nouvel apport de données. Indiquez les opérations possibles dans chaque intervalle et les personnes capables de modifier les règles. Ce travail rend visibles les arbitrages qu’un simple indicateur « prix disponible » pourrait masquer.