Guide du constructeur HIP-3 : Pourquoi la définition d'Oracle façonne le destin de votre marché perpétuel

Lorsque Hyperliquid a lancé HIP-3, il a fondamentalement changé la façon dont les marchés de contrats perpétuels prennent vie. Au lieu de limiter l’accès aux listings de marché derrière un processus d’approbation centralisé, le protocole a ouvert l’accès aux constructeurs qualifiés — mais cette liberté s’accompagne d’un piège : les constructeurs assument désormais le risque opérationnel. La pierre angulaire de cette responsabilité commence par une décision souvent sous-estimée : votre définition de l’oracle.

Après plus de trois mois depuis le lancement du mainnet, les marchés déployés par les constructeurs sur HIP-3 ont déjà accumulé plus de $13 milliards en volume de transactions. Cette échelle ne s’est pas produite par hasard. Elle reflète à la fois l’innovation du protocole et les constructeurs qui ont réussi à naviguer dans sa complexité. Pourtant, pour chaque marché réussi, il existe une histoire d’avertissement — comme l’incident de décembre 2025 sur trade.xyz où un attaquant a exploité une définition d’oracle faible sur un actif non 24/7, drainant $13 millions en positions longues via manipulation de prix.

Ce guide vous accompagne à travers l’architecture, les risques et les stratégies de contrôle éprouvées qui distinguent les marchés florissants de ceux qui sombrent dans des cascades de liquidations et des déclencheurs ADL.

Comprendre l’Infrastructure de Hyperliquid : La Fondation pour la Définition de l’Oracle

Hyperliquid ne demande pas aux constructeurs de réinventer la roue. Il fournit une infrastructure à deux niveaux :

HyperCore : une blockchain Layer 1 personnalisée optimisée pour le trading perpétuel, traitant 200 000 ordres par seconde avec une finalité déterministe. La correspondance, la compensation et le règlement se font tous au niveau du protocole — ce qui signifie que les constructeurs ne construisent pas des moteurs de trading à partir de zéro.

HyperEVM : la couche applicative exécutant des contrats intelligents, compatible avec les outils Ethereum existants.

En réutilisant ces couches d’infrastructure, les constructeurs se concentrent sur ce qui compte : la définition du marché et la discipline opérationnelle. La place de marché perpétuelle native Hyperliquid suit toujours les processus traditionnels de listing CEX — les validateurs votent pour inclure ou non certains contrats. Mais HIP-3 inverse ce modèle : tout constructeur remplissant le seuil peut lancer.

Pour lancer sous HIP-3, vous devez miser 500 000 jetons HYPE. Vos trois premiers marchés sont déployés gratuitement ; les marchés supplémentaires nécessitent une enchère hollandaise (cycles de 31 heures, débutant à 2x le prix final de la ronde précédente). La exigence de mise reste en place pendant 30 jours même si vous suspendez tous les marchés — ce n’est pas une assurance optionnelle ; c’est votre mécanisme de responsabilité.

Votre Rôle en tant que Constructeur : Deux Responsabilités Distinctes

HIP-3 divise le travail du constructeur en deux phases : définition du marché et opération du marché.

Définition du marché consiste à bien faire dès le départ. Vous devez spécifier :

1. Définition de l’oracle : Quelle source de données ancrera les prix ? Quel sera votre prix oracle initial (oraclePx) ? Pour un perpétuel d’actions, est-ce Pyth ? Pour une altcoin moins liquide, s’agit-il d’un flux de prix CEX ? Cette décision est irréversible une fois que les traders entrent en position.

2. Spécifications du contrat : Symbole, taille minimale d’ordre, levier maximum, actif de garantie (USDC, par exemple), et tableaux de marge qui lient les limites de levier à la taille de la position.

Opération du marché signifie vigilance continue :

• Alimentation des prix : Vous appelez setOracle à plusieurs reprises pour soumettre les prix de l’oracle. Il doit y avoir au moins 2,5 secondes entre les appels ; si votre prix de référence (optional) n’est pas mis à jour en 10 secondes, le système revient au prix du carnet d’ordres local.
• Ajustement du levier : Vous liez les tableaux de marge à votre marché, en fixant des limites de levier par paliers en fonction de la taille notionnelle.
• Contrôles d’urgence : Vous pouvez invoquer haltTrading pour geler le marché, annuler toutes les ordres, et régler les positions au prix de référence actuel.

Le protocole impose des garde-fous — le prix de référence ne peut pas bouger de plus de ±1% par mise à jour, et tous les prix sont plafonnés à 10x la valeur de début de journée. Mais ces garde-fous ne sont pas des menottes. Dans ces contraintes, vos choix déterminent si votre marché prospère ou s’effondre.

Définition de l’Oracle : Le Point Critique pour la Stabilité du Marché

La définition de l’oracle est le point où le destin de votre marché diverge. C’est la première chose que vous définissez et la plus difficile à corriger. Voici pourquoi cela importe tant.

Ce que Signifie Vraiment la Définition de l’Oracle

La définition de l’oracle dans HIP-3 comprend trois couches :

1. OraclePx (obligatoire) : l’ancrage principal du prix. Il provient généralement de votre relais, qui agrège des flux externes (Pyth, DEX AMMs, prix CEX). C’est votre point de défaillance unique si le relais tombe en panne ou subit une attaque DDoS.

2. MarkPx (optionnel) : des prix de référence que vous soumettez — jusqu’à 2 ensembles — pour calculer la référence de liquidation réelle. C’est là que brillent les constructeurs avec des modèles de tarification propriétaires, mais aussi là où une mauvaise décision peut tuer un marché.

3. ExternalPerpPx (obligatoire) : la médiane pondérée des prix médian des perpétuels provenant de plusieurs CEX. Cela sert de contrôle de cohérence, empêchant votre marché isolé de s’éloigner trop du consensus général.

Le système combine ensuite ces couches en un prix de référence final : la médiane entre (le prix médian du carnet local, vos sets de prix markPx soumis, et externalPerpPx). Si une couche échoue, le système cascade vers la suivante. Si tout échoue, vous tradez à l’aveugle.

24/7 vs. Actifs Non 24/7 : Deux Définitions d’Oracle Différentes

Pour les actifs 24/7 (BTC, ETH, la plupart des altcoins) : la définition de l’oracle est simple. Pyth, Chainlink ou flux CEX offrent des signaux de prix continus et liquides. Votre relais les agrège. La manipulation est coûteuse car repérer des décalages de prix contre des dizaines de marchés externes est immédiat.

Pour les actifs non 24/7 (actions, indices, matières premières) : la définition de l’oracle devient existentielle. Prenez les actions NASDAQ. Pendant les heures de marché, Pyth fournit des prix nets. À la clôture, il n’y a pas de prix externe. Votre définition d’oracle doit alors survivre dans un vide.

Voici le piège : pendant les heures creuses, votre mécanisme setOracle ne peut pas récupérer un vrai prix de marché. Vous vous rabattez alors sur « dernier clôture + pression interne du carnet d’ordres ». Mais sans ancrage externe, la pression interne devient un miroir — le prix ne reflète que ce qui est à l’intérieur de votre marché, pas la valeur réelle de l’actif sous-jacent.

Le protocole impose une limite de ±1/maxLeverage sur le mouvement de prix (par exemple, 10x levier → variation maximale de 10%). Sur des actifs à forte volatilité en heures normales, c’est raisonnable. Sur une action peu liquide le week-end, avec zéro prix externe, une variation de 10% suffit à liquider des portefeuilles entiers et à déclencher des cascades ADL.

Liquidation & ADL : Comment la Définition de l’Oracle Impacte les Risques de Cascade

Une fois les positions ouvertes, la définition de l’oracle détermine quand les traders sont margin-callés.

Le Déclencheur de Liquidation

La liquidation se produit lorsque la valeur de votre position isolée tombe en dessous du marge de maintenance. La vérification utilise le prix de référence (calculé à partir de votre définition d’oracle), et non un prix de transaction spécifique. Mathématiquement :

Prix de liquidation = (valeur notionnelle × exigence de marge) / taille de la position

L’exigence de marge de maintenance est elle aussi par paliers — un levier plus élevé implique une marge plus serrée, ce qui accélère la liquidation. Votre tableau de marge lie ces paliers à votre marché, donc si vous fixez un levier déraisonnablement élevé sur un marché peu liquide, les liquidations seront concentrées.

Quand la Liquidation Devient ADL

Le vrai cauchemar commence lorsque les ordres de liquidation ne trouvent pas d’acheteurs. Imaginez que votre prix de référence montre 3 000 $ (calculé à partir de votre définition d’oracle), mais que la profondeur réelle du carnet est faible. Les ordres de liquidation s’exécutent à 2 910 $ — un écart de 3%. Si cet écart est suffisamment grand pour que les pertes de liquidation dépassent la marge du trader, vous avez créé une « dette mauvaise ».

Le système ne tolère pas la dette mauvaise. Il déclenche ADL (Auto-Deleveraging) : les positions profitables de l’autre côté sont forcées à la fermeture au prix de référence précédent ($3 000), pas au prix actuel du marché. Les profits sont récupérés pour combler le gap, transférant la perte aux gagnants.

Du point de vue d’un constructeur, l’ADL est un avertissement de contagion. Chaque événement ADL indique que votre marché est sous tension — soit votre définition d’oracle est cassée, soit vos paramètres de levier ont invité trop de risque dans des carnets peu profonds.

Paramètres Critiques : Configurer l’Oracle et le Levier pour Votre Marché

Votre implémentation de setOracle est un réglage avec un levier énorme. Les erreurs se propagent.

Fréquence de l’Oracle & Règles de Mise à Jour

Vous devez appeler setOracle au moins toutes les 10 secondes, sinon le système revient au prix du carnet local (laissant le prix de référence si vos flux sont mieux informés). La plupart des constructeurs envoient des mises à jour toutes les 2-5 secondes en période volatile.

Mais voici le piège : chaque appel setOracle peut faire bouger le prix de référence d’au plus ±1%. Si les conditions du marché évoluent de 5% en une seconde (ce qui n’est pas rare pour des altcoins à faible capitalisation ou des événements black swan), votre définition d’oracle devient nécessairement obsolète. Les liquidateurs voient des prix obsolètes et frappent le marché.

Définition Oracle pour Actifs Non 24/7 : Le Problème du Week-end

Les actions et actifs traditionnels ne se négocient pas le week-end. Un constructeur planifiant des perpétuels actions sur HIP-3 doit décider : comment définir les prix oracle le samedi matin quand aucune bourse n’est ouverte ?

Approches actuelles :

Approche 1 : Conservatrice – Suspendre le trading ou les liquidations en dehors des heures. C’est ce que font Light et Optium. Les traders perdent l’accès 24/7, mais le marché reste stable.

Approche 2 : Tarification interne – Utiliser « dernier prix externe + pression interne du carnet » pour continuer à fonctionner. C’est ce que trade.xyz a tenté avant leur incident de décembre.

L’approche 2 expose une faiblesse critique de la définition de l’oracle : le plafond de variation de ±1/maxLeverage devient un plafond pour le risque. Sur une action peu liquide un dimanche, même un mouvement de 10% peut se produire avec quelques ordres importants. Votre définition d’oracle doit empêcher cela, mais les garde-fous ne sont pas assez serrés.

Une meilleure définition pour les actifs non 24/7 inclut des ancrages complémentaires :

• Blue Ocean ATS : fournit des prix après-heures pour les actions. Moins liquide que les heures normales, mais ce sont de vrais prix de marché, pas des estimations internes.
• Cotation CFD IG Weekend : donne des signaux de « mouvement attendu à l’ouverture ». Combiné avec le dernier clôture + prix interne, cela donne une chance à votre définition d’oracle de rester ancrée.

Ces compléments n’ont pas pour but de remplacer une conception rigoureuse de l’oracle — ils l’augmentent. Votre définition d’oracle devrait être : « Pendant les heures de marché, Pyth. En dehors, dernier Pyth ajusté par Blue Ocean ATS mid + pression interne, plafonné à ±X%. »

Contrôle du Risque Oracle : Stratégies de Surveillance en Temps Réel pour la Stabilité des Flux de Prix

C’est ici que la théorie rencontre l’opérationnel. Votre définition d’oracle n’est aussi bonne que son système de surveillance.

Détection de la Panne du Flux de Prix

Votre relais est un point de défaillance unique. Si le processus plante ou perd la connexion réseau, setOracle cesse de fonctionner. En moins de 10 secondes, le système revient au prix du carnet d’ordres pur. Pour les marchés liquides avec des spreads serrés, c’est acceptable. Pour tout le reste, c’est un piège à liquidation.

Plan d’action :

• Alerte Niveau 1 : Flux de prix down >2,5 secondes. Vérifier immédiatement l’état de vos nœuds relais. Passer à une infrastructure de secours. Publier un rapport d’état.
• Alerte Niveau 2 : Flux de prix down >10 secondes. Appeler setOpenInterestCaps pour geler de nouvelles positions. Les positions existantes peuvent encore se fermer. Cela évite une cascade de liquidations pendant que vous reconstruisez le pipeline de l’oracle.

Désancrage de l’Oracle : Quand votre Définition d’Oracle dérive

Même si votre relais est en ligne, vos prix d’oracle peuvent s’éloigner de la réalité. Cela se produit lorsque :

• Votre flux Pyth est légèrement obsolète (en cas de congestion).
• Le prix médian du carnet interne diverge à cause d’une faible liquidité.
• Les prix externes CEX (utilisés dans externalPerpPx) évoluent plus vite que vos mises à jour.

Définissez la désancrage de façon quantitative :

• Seuil A : |oraclePx - externalPerpPx| > 2%.
• Seuil B : |markPx - médian du carnet local| > 1%.
• Seuil C & D : mesures similaires pour des déviations soutenues (>5 secondes).

Plan d’action :

• Niveau 1 : Si 2+ seuils sont déclenchés, appeler setOpenInterestCaps pour limiter la croissance des nouvelles positions.
• Niveau 2 : Mettre à jour progressivement les tableaux de marge, en réduisant le levier maximum paliers par paliers. Activer le clamp ±1% de setOracle comme mécanisme de sécurité.
• Niveau 3 : Continuer les actions du Niveau 2 tout en émettant des alertes. Si les déviations persistent >30 secondes, invoquer haltTrading en dernier recours.

Dégradation du Carnet d’Ordres : Détection des Marchés Fin

La liquidité peut disparaître sans que votre définition d’oracle ne faille. Surveillez :

• Profondeur dans ±x% : volume total dans x% du prix médian. Typiquement : profondeur ±0,5%.
• Spread : différence entre le meilleur ask et le meilleur bid. Sain : <0,1%. Dangereux : >1%.
• Volume agressif : volume taker dans les Δt dernières secondes. Si ce volume dépasse la profondeur, vous avez un problème.

Lorsque la profondeur s’effondre alors que le volume agressif explose, les ordres de liquidation subiront du slippage. C’est votre signal pour réduire les caps d’intérêt avant qu’une ADL ne se propage.

Actifs Non 24/7 : Définition de l’Oracle Pendant les Fermetures de Marché

Entrons dans le cauchemar spécifique : perpétuels actions un vendredi soir. La bourse ferme à 16h ET. Votre définition d’oracle configurée par le constructeur doit faire passer le marché durant le week-end.

( La Défaillance de Trade.xyz en décembre 2025

Le 14 décembre 2025, des attaquants ont exploité précisément ce scénario. Ils ont construit une grosse position short sur XYZ100 )un perpétuel NASDAQ-100### lorsque le marché était peu liquide. L’attaque :

1. Positionnement hors heures : après la clôture, avec peu de prix externes et des carnets fins, ils ont créé une pression de vente massive.
2. Défaillance de la définition d’oracle : le prix de référence interne (basé sur peu de trades internes + dernier prix externe) a divergé à la hausse par rapport à la présence d’acheteurs.
3. Cascade de liquidation : les positions longues ont été margin-callées à des prix artificiellement élevés. Les ordres de liquidation ont encore fait baisser le marché.
4. Cascade ADL : le système a forcé la fermeture de positions short profitables (y compris celles de l’attaquant) à des prix de référence obsolètes, mais l’écart était si grand que des cascades ADL se sont produites.

La cause racine : la définition d’oracle pour les actifs non 24/7 hors heures était trop lâche. Une limite de prix à 10% de levier paraît rigide jusqu’à ce que vous réalisiez que cela donne 10 points de latitude sur une action qui ne bouge que de 2-3% en dollars réels en trading normal.

( Une meilleure définition pour les actifs hors heures

Votre définition d’oracle pour les actifs non 24/7 doit inclure :

1. Ancrage principal en heures de marché : Pyth ou flux d’échange.
2. Ancrage supplémentaire hors heures : Blue Ocean ATS ou cotations CFD IG pour signaler les gaps attendus à l’ouverture.
3. Vérification interne : Si le médian du carnet interne dévie >X% de l’ancrage supplémentaire, déclenchez des alertes et réduisez le levier.
4. Gestion asymétrique du risque : En heures de marché, vous pouvez utiliser 10x. Hors heures, réduisez à 2-5x max. Cela limite le risque de cascade de liquidation quand la définition d’oracle est handicapée par l’absence de prix externes.

Construire votre Tableau de Bord de Risque : Surveillance des Prix, Profondeur et Positions

Les constructeurs professionnels utilisent trois canaux de surveillance simultanément :

) Canal 1 : Indicateurs côté prix

Surveillez la santé de l’oracle toutes les 1-2 secondes :

• Latence du flux $13M temps depuis le dernier setOracle###
• Déviation du prix par rapport aux références externes
• Breaches de plafonds ###prix à ±1% pour des périodes soutenues(

) Canal 2 : Indicateurs du carnet d’ordres

Surveillez la profondeur et le spread toutes les 5-10 secondes :

• Profondeur dans ±0,5%, ±1%, ±2% du médian
• Tendances du spread bid-ask
• Volume agressif d’achat/vente en corrélation

Un volume agressif élevé + profondeur qui s’effondre = signal de pré-liquidation.

( Canal 3 : Indicateurs de position

Suivez l’intérêt ouvert et la concentration horaire :

• OI total notionnel vs. volume sur 24h )ratio croissant = mode spéculation###
• Taille de la plus grande position en % de la marge disponible
• Longs vs. shorts ###plusieurs côtés( P&L non réalisé en % de la marge

Quand le P&L majoritaire dépasse 80-90% de la marge à des prix extrêmes, tout choc de marché déclenche l’ADL.

La plupart des constructeurs utilisent ces tableaux de bord de façon réactive — alertes déclenchées, ils réagissent. Les constructeurs avancés automatisent les réponses :

• Flux de prix down >10 secondes → réduction automatique des caps d’OI à 50%.
• Effondrement de la profondeur + volume agressif élevé → réduction automatique du levier par palier.
• P&L majoritaire >80% de la marge → déclenchement d’alerte, considération d’un arrêt du marché.

De la Définition de l’Oracle à la Stabilité du Marché : Cadre de Responsabilité du Constructeur

HIP-3 a donné aux constructeurs l’autonomie. Elle leur a aussi donné une responsabilité.

Si votre marché dysfonctionne — que ce soit à cause d’une mauvaise définition d’oracle, d’un levier irréaliste ou d’une surveillance insuffisante — les validateurs peuvent voter pour réduire votre mise de 500k HYPE. Le protocole ne distingue pas la malveillance de l’incompétence. Il juge uniquement les résultats : les positions se sont-elles correctement clôturées ? Les prix de l’oracle ont-ils été correctement ancrés ? Le marché est-il resté stable ?

La voie pour les constructeurs est la responsabilisation par la standardisation :

1. Publiez votre définition d’oracle : divulguez précisément quelles sources alimentent oraclePx, à quelle fréquence vous mettez à jour, et votre logique de secours. La transparence construit la confiance et permet de détecter les failles avant qu’elles ne provoquent un crash.

2. Implémentez des systèmes de preuve : pour chaque appel setOracle, générez une preuve )données sources, étapes de calcul, résultat(. Signez-la et engagez-la dans un arbre de Merkle publié sur la chaîne toutes les heures. Cela permet un audit public de vos décisions de tarification.

3. Surveillez de façon obsessionnelle : mettez en place des tableaux de bord en temps réel pour suivre prix, profondeur et santé des positions. Installez des coupe-circuits automatisés qui réduisent les caps d’OI et le levier avant qu’une crise ne survienne.

4. Concevez avec soin pour les actifs non 24/7 : si vous lancez des perpétuels actions, utilisez des ancrages complémentaires )Blue Ocean ATS, cotations CFD( et levier asymétrique )plus faible hors heures(. Apprenez de l’effondrement de trade.xyz en décembre.

5. Établissez des procédures d’escalade : documentez quand et comment vous invoquez haltTrading. Ne le traitez jamais comme un levier occasionnel — c’est votre frein d’urgence du marché.

L’innovation de HIP-3 ne réside pas dans la friction de déploiement. Elle réside dans la standardisation du déploiement — permettant accès, opération et responsabilisation. La réussite ou l’échec de votre marché dépend de la rigueur avec laquelle vous implémentez la définition d’oracle, surveillez les flux de prix, et réagissez aux signaux d’alerte précoces.

Les )milliards de volume déployés par les constructeurs montrent l’opportunité. L’incident trade.xyz montre le risque. Votre succès dépend de traiter la définition d’oracle non pas comme une case à cocher technique, mais comme l’engagement fondamental qui détermine si vous gérez un marché ou une ferme de liquidation.

Pour un accompagnement continu en sécurité, audit, et infrastructure de surveillance des risques, envisagez de faire appel à des cabinets spécialisés comme BlockSec, capables de traduire ces principes en systèmes de production. Le coût de la consultation est une fraction de ce qu’un attaque bien coordonnée pourrait coûter.