Définition de l'oracle et stabilité du marché : Construire des marchés perpétuels fiables sur HIP-3

L’évolution de la manière dont les contrats perpétuels sont lancés a fondamentalement changé. Là où les plateformes contrôlaient autrefois quels actifs pouvaient être négociés et selon quelles conditions, HIP-3 a redistribué ce pouvoir aux constructeurs qualifiés opérant dans des paramètres définis. Depuis son déploiement sur le mainnet, plus de 13 milliards de dollars de volume de transactions ont transité par des marchés gérés par des tiers, ce qui témoigne d’une véritable démocratisation de la création de marché. Pourtant, ce passage d’un rôle de gardien à un système basé sur des règles crée un paradoxe critique : une plus grande flexibilité du marché exige une discipline opérationnelle plus rigoureuse. Au cœur de ce défi se trouve un concept apparemment simple mais aux conséquences majeures — la définition de l’oracle.

L’architecture derrière la cotation décentralisée : passer de l’approbation aux standards

Les échanges centralisés traditionnels contrôlent la cotation des contrats perpétuels via des processus internes opaques. Une équipe produit évalue un actif, prend une décision commerciale, et le déploie. Le contrôle des risques repose dans l’infrastructure de l’échange. HIP-3 inverse ce modèle. Plutôt que de maintenir un catalogue sélectionné, Hyperliquid fournit l’infrastructure — HyperCore gère la correspondance et le règlement à grande échelle, HyperEVM exécute les contrats intelligents — et invite les constructeurs à superposer des marchés dessus.

Le mécanisme est simple en apparence : miser 500k jetons HYPE, déployer un DEX (qui détient sa propre marge et son carnet d’ordres), lancer trois marchés gratuitement, puis acquérir des slots supplémentaires via des enchères hollandaises. Mais cette simplicité structurelle masque une complexité profonde dans l’exécution. Le constructeur possède désormais non seulement la création du marché mais aussi ses opérations — alimentation des prix, gestion des paramètres, surveillance continue de la stabilité. Ce qui était autrefois une responsabilité de la plateforme devient une surface de responsabilité du constructeur.

Ce changement expose une tension centrale : la décentralisation nécessite une standardisation. Le système doit établir des interfaces et contraintes claires ; sinon, le risque ne disparaît pas — il se fragmentent entre une dizaine d’opérateurs indépendants aux capacités variables.

La définition de l’oracle : la première décision cruciale

Lorsqu’un constructeur initie la création d’un marché, la première et la plus importante décision concerne la définition de l’oracle. Il ne s’agit pas simplement de choisir un flux de prix ; cela englobe tout le cadre conceptuel pour que les participants au marché déterminent si leurs positions sont rentables, si elles doivent être liquidées ou si des mécanismes d’urgence doivent être déclenchés.

Ce que la définition de l’oracle spécifie réellement :

Une définition d’oracle dans HIP-3 comprend trois composants : l’oraclePx (le prix brut provenant d’une source externe), le markPx optionnel (les prix de marque personnalisés fournis par le constructeur), et l’externalPerpPx (la médiane pondérée des prix perpétuels d’échange centralisé). Ces entrées ne sont pas interchangeables — elles ont des fonctions distinctes dans la hiérarchie de calcul du risque de HIP-3.

L’oraclePx sert de référence pour les frais de financement et comme ancrage pour les limites de prix. Le markPx est calculé par le relayer du constructeur en combinant des signaux on-chain et off-chain. L’externalPerpPx fournit une référence de secours. HIP-3 assemble ces éléments en un prix de marque réel via un calcul de médiane : d’abord la médiane du carnet d’ordres local, puis combinée avec les marques externes fournies par le constructeur, enfin comparée à l’externalPerpPx. Cette approche multi-sources empêche théoriquement qu’une seule source de prix dicte les liquidations.

Théoriquement.

Pourquoi la définition de l’oracle est plus importante que la technologie :

La composition technique de la définition de l’oracle est moins critique que la capacité opérationnelle du constructeur à la maintenir. Un constructeur qui choisit une définition d’oracle reposant sur un relayer centralisé hérite de la disponibilité, de la sécurité et de la fréquence de mise à jour de ce serveur. Si la clé privée sécurisant le relayer est compromise, ou si des attaques DDoS empêchent la mise à jour des prix, l’oraclePx stagne. Avec des prix de marque incapables d’être mis à jour, le système revient aux médianes du carnet d’ordres local — précisément au moment où la liquidité est la plus faible et où le risque de manipulation est maximal.

L’incident du 14 décembre 2025 sur trade.xyz a illustré cette dynamique. Des attaquants ont accumulé une position courte d’environ 398 contrats XYZ100 (~10 millions de dollars), créant délibérément un déséquilibre. Le prix s’est décorrélé des sources externes en raison d’une profondeur insuffisante du carnet d’ordres. Les détenteurs de positions longues ont subi des liquidations en cascade, avec environ 13 millions de dollars de positions fermées. Le mécanisme a fonctionné techniquement — les liquidations ont été exécutées — mais le système a transféré les pertes aux participants les moins préparés plutôt que de prévenir la dislocation initiale.

Ce scénario devient beaucoup plus probable lorsque la définition de l’oracle suppose des ancrages de prix externes stables en dehors des heures de marché.

La division entre actifs 24/7 et non-24/7 : quand la définition de l’oracle devient critique

La flexibilité de HIP-3 pour lister tout actif crée une différence catégorique dans les exigences de définition de l’oracle.

Actifs 24/7 (cryptomonnaies perpétuelles) :

Pour Bitcoin, Ethereum et autres actifs négociables 24h/24, la définition de l’oracle peut s’appuyer sur plusieurs flux de prix CEX/DEX combinés à des services spécialisés comme Pyth. Ces actifs se négocient en continu sur plusieurs plateformes. Un constructeur peut agréger plusieurs sources de prix, appliquer des calculs de médiane, et détecter les outliers. Lorsqu’une source dérive, d’autres fournissent un ancrage immédiat.

La définition de l’oracle pour les actifs 24/7 reste difficile — choisir des sources pondérées, gérer la fréquence de mise à jour, traiter les interruptions d’échange — mais le marché externe sous-jacent fournit des signaux cohérents même si une seule source échoue.

Actifs non-24/7 (actions et matières premières) :

La définition de l’oracle pour les contrats perpétuels sur actions nécessite des hypothèses fondamentalement différentes. Pendant les heures de marché, les flux de prix de services comme Pyth offrent des ancrages externes stables. Mais lorsque la Bourse de New York ferme, le constructeur doit faire un choix : soit suspendre les flux de prix (et limiter la négociation), soit continuer à fixer les prix en se basant uniquement sur des signaux internes avec des références externes à la « clôture précédente ».

La plupart des constructeurs utilisant des actifs non-24/7 emploient actuellement un mécanisme de tarification interne similaire à trade.xyz — combinant le dernier prix oracle externe avec la dynamique du carnet d’ordres interne, plafonné pour éviter un drift excessif (typiquement 1/max_leverage). C’est mathématiquement cohérent ; c’est opérationnellement risqué.

Lors des fermetures de marché, la profondeur du carnet d’ordres se contracte généralement. Les market makers réduisent leurs cotations, les participants retail dorment, et le marché s’amincit considérablement. Une définition de l’oracle qui limite le mouvement de prix à « 1/10e de la clôture précédente » (pour un levier 10x) paraît prudente. Mais lorsque la liquidité disparaît, même un flux d’ordres modéré peut entraîner des mouvements de prix disproportionnés dans cette plage bornée. Lors de la réouverture lundi matin, avec la ré-ancrage des données externes, des gaps apparaissent. Ces gaps déclenchent des liquidations en cascade ou, dans les cas graves, des événements ADL (réduction automatique de positions) où des trades profitables sont forcés pour couvrir des pertes sur des positions insolvables.

Construire un cadre d’oracle défendable

Les constructeurs qui cherchent à faire fonctionner des marchés stables doivent élaborer des stratégies de définition d’oracle anticipant les modes de défaillance plutôt que supposant une stabilité continue.

Ancrages de prix supplémentaires lors des fermetures de marché :

Pour les actifs non-24/7, introduire des signaux de prix externes même pendant les fermetures améliore considérablement la définition de l’oracle. Parmi les options :

• Blue Ocean ATS et autres plateformes de trading après heures : elles offrent une découverte continue des prix en dehors des heures de marché, fournissant des signaux plus actuels que la « clôture précédente ». Un constructeur peut pondérer ces données dans la définition de l’oracle lors des fermetures, créant un point de référence moins manipulable.

• Cotation CFD du week-end par des fournisseurs comme IG : elles anticipent les attentes du marché pour la réouverture de la semaine suivante. Bien qu’elles ne soient pas des substituts directs aux prix spot, elles servent d’ancres directionnelles pour les « gaps d’ouverture attendus » dans la définition de l’oracle.

Ces sources partagent une caractéristique essentielle : elles sont disponibles lors des fermetures de marché mais diffèrent structurellement des marchés spot. La définition de l’oracle doit les traiter comme des références et signaux de risque plutôt que comme des équivalents inconditionnels.

Concevoir une dérivation de prix transparente et vérifiable :

La vulnérabilité principale de la mise en œuvre actuelle de la définition de l’oracle réside dans la centralisation du relayer. Si les flux de prix proviennent exclusivement d’un serveur privé du constructeur, ce serveur devient un point unique de défaillance et d’attaque. Les constructeurs doivent mettre en place des systèmes de vérification de la définition de l’oracle permettant à des parties externes d’auditer l’authenticité des prix.

Cela implique de divulguer publiquement : les sources de données alimentant l’oracle, l’algorithme exact combinant ces sources, les horodatages d’échantillonnage pour chaque entrée, et les prix de marque résultants. Pour chaque appel setOracle, générer une preuve cryptographique incluant les données brutes, les étapes de calcul, et les résultats finaux. Sérialiser cela dans un proofHash que le relayer signe. Agréger périodiquement ces hash dans des arbres de Merkle et publier la racine en chaîne.

Cette approche transforme la définition de l’oracle de « faire confiance au serveur de prix du constructeur » à « vérifier la méthodologie du constructeur ». Tout utilisateur peut récupérer les données historiques, recomposer les résultats en utilisant les algorithmes publiés, et confirmer si les flux de prix correspondaient aux sources déclarées.

Quand la définition de l’oracle échoue : surveillance et intervention

Même une définition d’oracle bien conçue peut échouer en situation de stress extrême. Les constructeurs opérant sur HIP-3 doivent disposer de cadres de surveillance détectant la dégradation avant qu’elle ne se propage.

Surveillance du côté prix : détection du dérapage de l’oracle :

Les défaillances du flux de prix apparaissent d’abord par des discontinuités — le relayer cesse de mettre à jour. Les constructeurs doivent surveiller les observables on-chain : si deux mises à jour consécutives de l’oracle dépassent 10 secondes d’écart, cela déclenche une alerte de niveau 1. Vérifier la santé de leur infrastructure de relayer, éventuellement basculer vers des nœuds de secours.

Plus insidieux est le décalage progressif du prix de l’oracle par rapport aux références externes. La définition de l’oracle d’un constructeur pourrait s’appuyer sur Pyth pour les actions, mais si les données d’entrée (qui utilisent des prix agrégés d’échange) divergent de la réalité du marché, la définition devient obsolète sans que cela paraisse cassé. Des seuils de surveillance doivent comparer plusieurs sources externes à l’oracle du constructeur : si deux ou plusieurs divergent de plus de X %, il faut escalader.

Au niveau 1, limiter la croissance de l’intérêt ouvert via setOpenInterestCaps. Au niveau 2 (écart soutenu), ajuster progressivement la marge pour réduire le levier maximum par palier. Au niveau 3, déclencher des arrêts d’urgence via haltTrading.

Surveillance du carnet d’ordres : détection de la chute de liquidité :

La définition de l’oracle n’est utile que si la structure de liquidité du marché est saine. Si le carnet se contracte, les spreads s’élargissent, et l’impact des ordres agressifs augmente, même des prix précis deviennent dangereux. Les constructeurs doivent suivre depth_band (volume cumulé dans ±x % du prix médian), spread (écart entre meilleure ask et meilleure bid), et impact_ratio (volume agressif / depth_band). Quand la profondeur diminue alors que les spreads et impact ratios augmentent, le risque de liquidation s’accroît fortement.

Au niveau 1, limiter la croissance de l’intérêt ouvert. Au niveau 2, réduire de force le levier sur les positions à haut risque.

Surveillance de la concentration des positions : détection des cascades spéculatives :

Enfin, surveiller si le marché passe d’un vrai hedge à une spéculation pure. Suivre le ratio de l’intérêt ouvert notionnel sur le volume de trading 24h. Quand l’OI croît beaucoup plus vite que le volume, le marché devient de plus en plus exposé d’un seul côté. Combiné à des profits/pertes extrêmes majoritaires, cela précède des cascades de liquidations. Les constructeurs doivent alerter lorsque ces ratios dépassent des seuils ; si cela persiste, réduire l’OI maximum.

La gouvernance par staking : responsabilité dans les décisions de définition de l’oracle

Le mécanisme de HIP-3 pour responsabiliser les constructeurs repose sur le staking. Les constructeurs doivent maintenir 500k HYPE en stake en permanence. Les validateurs peuvent voter pour réduire cette mise si les actions du constructeur créent des états de marché invalides, des temps d’arrêt prolongés ou une dégradation des performances.

Ce mécanisme fait que les choix de définition de l’oracle ont des conséquences financières concrètes. Un constructeur qui implémente une définition négligente — acceptant une seule source centralisée, ne surveillant pas le drift, ignorant les risques hors heures — provoquera des cascades de liquidation. Les validateurs qui constatent des échecs répétés ou un effondrement du marché directement liés à une définition d’oracle inadéquate peuvent voter pour réduire toute la mise du constructeur.

Cela transforme la définition de l’oracle d’une décision technique en une décision de gouvernance. Les validateurs ratifient ou pénalisent implicitement ces choix via des votes de slashing. Avec le temps, cela crée une pression évolutive : les constructeurs qui mettent en œuvre des définitions robustes survivent ; ceux qui coupent les coins accumulent des votes de slashing.

Ce mécanisme n’est pas parfait — les validateurs peuvent manquer de compétences techniques pour évaluer équitablement, ou voter pour des raisons non liées à la qualité opérationnelle — mais il établit un seuil minimal de responsabilité.

La portée plus large : la décentralisation comme redistribution des risques

L’innovation centrale de HIP-3 n’est pas d’éliminer le risque ; c’est de le redistribuer. Là où les échanges centralisés internalisent le risque opérationnel (maintien des flux de prix, prévention de manipulation, gestion des liquidations), HIP-3 externalise ces responsabilités aux constructeurs. Le protocole fournit l’infrastructure ; les constructeurs assurent l’excellence opérationnelle.

Cela ne fonctionne que si les constructeurs comprennent ce qu’ils ont réellement assumé comme responsabilité. La définition de l’oracle représente l’une des surfaces d’attaque sous-estimées. Elle paraît simple — choisir un flux de prix — mais englobe la sélection des flux, la gestion du relayer, la tarification hors heures, les mécanismes de secours, les frameworks de vérification, la surveillance continue, et la responsabilité de gouvernance.

Les marchés bâtis sur une définition d’oracle négligente échoueront. Ceux bâtis sur une définition réfléchie, une surveillance appropriée, et des mécanismes de vérification transparents peuvent soutenir une activité de trading significative. Les 13 milliards de dollars de volume via HIP-3 indiquent que des constructeurs compétents existent. Mais chaque marché qui échoue — chaque cascade de liquidation liée à une défaillance de l’oracle — transfère du capital de traders non avertis vers les opérateurs de plateforme et les arbitrageurs sophistiqués.

Les constructeurs qui entrent dans HIP-3 doivent aborder la définition de l’oracle non pas comme un simple détail technique, mais comme la décision architecturale fondamentale déterminant si leur marché fonctionnera avec intégrité ou échouera sous stress.

La voie à suivre

Pour les constructeurs concevant l’accès au marché, les paramètres, les systèmes d’alerte et les procédures d’urgence basés sur HIP-3, la réussite dépend de la traiter comme un problème de conception basé sur les premiers principes. Cela implique de modéliser explicitement le comportement de votre définition d’oracle dans des scénarios : panne d’échange, attaque DDoS sur votre relayer, gaps entre prix interne et externe en dehors des heures, cascades de liquidation en marché peu liquide.

Cela signifie mettre en place des cadres de vérification permettant un audit externe de votre méthodologie de prix. Établir des seuils de surveillance et des procédures d’escalade avec des règles de décision claires. Plus important encore, reconnaître que la complexité de maintenir des définitions d’oracle fiables sous stress n’a pas disparu — elle a simplement été déplacée de la plateforme vers les constructeurs.

Ceux qui prennent la définition de l’oracle au sérieux exploiteront des marchés stables et fiables. Ceux qui ne le font pas deviendront des études de cas sur la manière dont les systèmes décentralisés échouent.