Rédigé par : Blocksec
HIP-3（Hyperliquid Improvement Proposal 3） est en ligne sur la blockchain principale depuis environ 3 mois. Depuis son lancement, le volume total des transactions de marchés personnalisés tiers a dépassé 13 milliards de dollars, ce qui signifie que « l’ajout de nouveaux marchés » passe d’un processus interne à la plateforme à une capacité d’infrastructure accessible directement par des développeurs externes.
Dans les échanges centralisés, « l’ajout de nouveaux marchés » est naturellement un pouvoir de la plateforme : quels actifs peuvent être négociés, quand ils sont mis en ligne, comment paramétrer, tout cela est principalement décidé par les processus d’exploitation et de gestion des risques. Même sur la blockchain, les contrats perpétuels, qui sont des infrastructures fondamentales, sont souvent contraints par le rythme de déploiement et de gouvernance d’une minorité d’équipes.
L’innovation de HIP-3 réside dans le fait de transformer cette étape du « processus d’approbation de la plateforme » en « ouverture d’interface » : tant que les conditions sont remplies, des tiers peuvent déployer de nouveaux marchés perpétuels sur la même base de transaction et de règlement, externalisant systématiquement le pouvoir d’ajout de marché centralisé vers l’écosystème. Cette amélioration réduit non seulement la barrière à l’innovation, mais renforce aussi la scalabilité du marché. Cependant, l’ouverture d’interfaces comporte des risques de sécurité potentiels qu’il ne faut pas négliger. La question de garantir la conformité opérationnelle de ces marchés et l’absence d’actes malveillants reste un enjeu clé dans la conception de HIP-3.
0x1 Hyperliquid : la base de HIP-3
Hyperliquid est une infrastructure de trading perpétuel fonctionnant sur sa propre blockchain. Pour HIP-3, l’aspect le plus critique est que : la correspondance, la liquidation et le règlement sont fournis de manière unifiée par la base du protocole, permettant la réutilisation des capacités de marché, plutôt que de construire un système de trading à partir de zéro.
Hyperliquid adopte une architecture à double couche :
HyperCore : une blockchain L1 sur mesure optimisée pour les contrats, capable de traiter 200 000 ordres par seconde avec une finalité déterministe.
HyperEVM : une couche applicative, capable d’exécuter des contrats intelligents compatibles EVM.
Le marché perpétuel natif d’Hyperliquid (perps opérés par validateurs) reste plus proche d’un processus traditionnel de CEX : l’équipe officielle peut mettre en ligne des contrats perpétuels selon la volonté de la communauté ; la suppression se décide par vote des nœuds validateurs.
Le protocole Hyperliquid supportera les perp déployés par les constructeurs (HIP-3), une étape clé vers une décentralisation complète du processus de listing des perp.
Le protocole Hyperliquid supportera les marchés perpétuels déployés par des constructeurs (HIP-3), ce qui constitue une étape cruciale pour la décentralisation totale du processus d’ajout.
0x2 HIP-3 : marchés déployés par des développeurs
Le principe de HIP-3 est simple : sans modifier la base de transaction et de règlement Hyperliquid, ouvrir la capacité d’ajouter de nouveaux marchés perpétuels aux constructeurs qui remplissent les conditions. Ces constructeurs définissent les paramètres clés du marché et la responsabilité de la fixation des prix / gestion opérationnelle, tandis que le protocole utilise un moteur de marge et de liquidation unifié pour exécuter et gérer les risques ; ainsi, « l’ajout » devient une interface standard accessible.
En résumé : un constructeur peut mettre en ligne un marché perpétuel basé sur le moteur HyperCore, en fixant lui-même les prix et en ajustant les paramètres du marché.
Responsabilités et limites du constructeur
Dans HIP-3, le constructeur assume deux rôles pour un marché perpétuel (market) : définir le marché et l’exploiter.
Définition du marché (Market definition) :
Le gouvernement résume cela comme une définition d’oracle + spécifications du contrat. Sur le plan opérationnel, cela inclut au minimum :
Définition de l’oracle :
Inclut la définition de l’oracle initial et de la source de prix. Lors de la définition du marché, le constructeur doit clairement définir un actif ou une source de données avec une valeur précise, difficile à manipuler, et ayant une substance économique ; lors de l’enregistrement de l’actif, il doit fournir un oraclePx initial.
Spécifications du contrat :
Dans l’API, définir explicitement des paramètres de marché tels que « symbole de l’actif / unité minimale de trading / levier maximum » (coin, szDecimals, maxLeverage, etc.).
Choix du DEX :
Le constructeur déploie d’abord un DEX perp (avec marges, carnet d’ordres, paramètres du déployeur indépendants), et peut choisir n’importe quelle devise de cotation comme collatéral (par exemple USDC). Chaque marché perp correspond à un DEX.
Exploitation du marché (Market operation) :
L’équipe officielle liste des actions telles que la mise à jour des prix oracle / limites de levier / règlement du marché si nécessaire, plus en détail :
Mise à jour des prix :
Via l’interface setOracle pour alimenter en continu le prix oracle du marché.
Limite de levier :
En configurant une table de marges pour l’actif, pour limiter le levier maximum — la limite de levier est fixée par tranches selon la taille de la position, pour restreindre le levier disponible dans une plage prédéfinie.
Liquidation si nécessaire :
Le constructeur peut utiliser haltTrading pour suspendre le marché, déclenchant la liquidation — annuler toutes les ordres, régler les positions au prix de marque actuel (mark price) ; cette même action peut aussi servir à rétablir la négociation.
Actuellement, les marchés HIP-3 supportent uniquement le mode isolé (isolated-only), mais à l’avenir, le mode croisé (cross) pourrait être supporté.
Processus complet de mise en ligne d’un marché
- Stake
Le réseau principal exige que le constructeur dépose 500 000 HYPE en garantie ; même si tous ses marchés sur le DEX sont suspendus, cette garantie doit être maintenue pendant 30 jours.
- Build
Après avoir rempli le seuil de dépôt, le constructeur peut déployer un DEX perp. Chaque DEX perp est une zone de trading indépendante : marges, carnet d’ordres, paramètres du déployeur.
- Définir la collatéralité
Le DEX peut choisir n’importe quelle devise de cotation comme collatéral, mais si cette devise perd la qualification de quote asset permissionless (décision du vote des validateurs), le DEX sera désactivé pour ce collatéral.
- Ajouter des marchés
Les 3 premiers marchés peuvent être déployés directement ; pour ajouter d’autres marchés, il faut participer à une enchère hollandaise (Dutch auction) pour obtenir des « quotas supplémentaires ».
- Exploiter les marchés
Une fois en ligne, le travail du constructeur consiste à « faire fonctionner le marché de manière stable », c’est-à-dire assurer son exploitation.
- Unstake
Après que tous les marchés du DEX ont été liquidés, la garantie de 500k HYPE peut être débloquée. La demande de retrait (unstake) entre dans une file d’attente de 7 jours, durant laquelle la garantie peut encore être pénalisée ou saisie.
Enchère hollandaise : cycle actuel de 31 heures, prix de départ étant le double du dernier prix (prix de transaction / prix minimum).
setOracle : trois types d’entrée de prix
Dans HyperCore, le prix oracle sert principalement à ancrer et calculer le coût du financement (funding), tandis que le prix de marque (mark price) sert de référence pour la marge, la liquidation, et d’autres scénarios de gestion des risques (également pour déclencher TP/SL).
Dans le marché natif, le mark price n’est pas directement le résultat d’un prix alimenté, mais la médiane de trois prix :
oraclePx + EMA(midPx - oraclePx)
median(best bid, best ask, last trade) (prix du carnet local)
Prix médian pondéré des perp de plusieurs CEX (perp mid prices)
Mais avec HIP-3, le rôle de l’oracle et du prix de marque ne change pas, mais leur mécanisme de calcul évolue :
setOracle input
a. oraclePx (obligatoire))
Définition conforme à HyperCore.
b. markPx (optionnel)
Peut soumettre 0 à 2 groupes de prix externes comme candidats pour le vrai prix de marque.
c. externalPerpPx (obligatoire)
Référence pour le prix de marque, pour éviter une déviation soudaine.
Le relayer déployé par le constructeur calcule généralement :
oraclePx : via une source externe combinée
markPx : via une algorithme personnalisé
externalPerpPx : médiane pondérée des prix de marché de plusieurs CEX perp.
- Prix de marque réel
Le prix de marque dans HIP-3 n’est pas directement celui alimenté par setOracle :
Calcul du mark local : median(best bid, best ask, last trade).
En combinant ce mark local avec les 0-2 groupes de markPx, on en extrait la médiane pour obtenir le nouveau prix de marque.
- Limites de setOracle
Fréquence de mise à jour : au moins 2,5 secondes entre deux appels, si markPx n’est pas mis à jour en 10 secondes, il revient au prix local.
Amplitude : la variation de markPx ne doit pas dépasser ±1% à chaque mise à jour ; tous les prix sont plafonnés dans une fourchette de 10× la valeur d’ouverture de la journée.
Différences entre prix 7×24H et non 7×24H
Dans HIP-3, les marchés perpétuels supportent tout actif, qui peut être classé en actifs 7×24H (trading 24/7) ou non 7×24H (seulement à certaines heures). La différence de temps de trading influence la méthode d’obtention du prix.
Pour les actifs 7×24H (ex. BTC), on peut obtenir un prix stable via CEX/DEX ou oracle fiable :
Pour les actifs non 7×24H (ex. actions), il faut utiliser le dernier prix de clôture ou un prix de marché externe lors des heures d’ouverture, et appliquer une mécanique de prix différente en dehors des heures de trading.
Par exemple, pour le marché perpétuel d’actions sur trade.xyz :
Pendant l’ouverture, utiliser un oracle externe comme Pyth.
En dehors, ajuster le prix basé sur la dernière clôture, avec une marge de ±1 / max_leverage (ex. Tesla 10x -> 10%).
Liquidation
Les marchés HIP-3 réutilisent principalement la logique de liquidation d’HyperCore : la liquidation se déclenche lorsque la valeur nette d’une position isolée ne couvre plus la marge de maintien.
Les décisions de liquidation se basent sur le prix de marque, pas sur une transaction spécifique.
Formule de prix de liquidation :
side = 1 (long), -1 (short)
l : taux de marge de maintien
Le prix de liquidation dépend aussi du niveau de marge (margin tier) du positionnement, en utilisant le taux de marge de maintien (mmr) associé.
margin_available
isolated : isolated_margin - maintenance_margin_required
Une fois en liquidation, le système priorise la clôture par ordre au marché ; si le risque est ramené à un niveau sûr, la marge restante revient au trader.
Mais en cas de profondeur insuffisante ou de gap, le prix réel de clôture peut être très différent du prix de marque, créant un « gap de liquidation ».
Valeur nette de position isolée : valeur de la position à prix de marque, après P&L et déduction de la marge liée.
ADL (Auto-Deleveraging) :
En cas de valeur négative d’une position isolée, le mécanisme ADL peut intervenir pour limiter les pertes :
Il trie les positions adverses par P&L non réalisé et levier, puis force la réduction ou la clôture à un prix de marque précédent, en utilisant les profits adverses pour combler le déficit, évitant ainsi la faillite du système.
Le tri se fait selon :
prix de marque précédent : dernier prix de marque enregistré avant l’activation de l’ADL.
Exemple :
Avant l’activation, prix de marque = 3 000.
En raison des contraintes setOracle, le nouveau prix ne peut dépasser 2 970 (-1%).
Mais si le carnet est peu profond, une liquidation au marché à 2 910 (soit -3%) peut faire que la position long soit sous l’eau, déclenchant l’ADL.
L’ADL sélectionne alors des positions adverses (profitables en short) pour réduire ou clôturer à l’ancien prix de marque (3 000), transférant la perte à l’adversaire.
0x3 Vue d’ensemble des risques :
Responsabilités et risques clés
Mécanisme de pénalisation (Slashing) : pouvoir de sanctionner
HIP-3 confie « l’ajout et l’exploitation » à des constructeurs, tout en intégrant dans le protocole une règle de pénalisation exécutable : le constructeur doit déposer du HYPE en garantie, et en cas de mauvaise gestion, les validateurs peuvent voter pour pénaliser et détruire (burn) cette mise.
Exigences de dépôt
Le réseau principal exige 500k HYPE en garantie. Même si tous ses marchés sont suspendus, cette garantie doit être maintenue 30 jours.
Procédure de vote
En cas d’opérations malveillantes, les validateurs peuvent initier un vote pondéré par la mise pour décider de la pénalisation.
Critères de jugement
La règle officielle : la pénalisation ne distingue pas « malveillance / incapacité / vol de clé privée », mais se concentre sur si le comportement a causé un état invalide, une panne prolongée ou une dégradation des performances.
Taux de pénalisation
Le pourcentage de pénalité est voté par les validateurs, avec des plafonds :
-
État invalide ou panne prolongée : jusqu’à 100%
-
Panne courte : jusqu’à 50%
-
Dégradation des performances : jusqu’à 20%
Les tokens pénalisés sont brûlés, non remboursés aux utilisateurs affectés.
Risques liés aux paramètres
setOracle
Les prix oracle proviennent généralement du relayer du constructeur, ce qui comporte un risque de centralisation. En cas de fuite de clé ou attaque DDoS, le prix dans le marché peut être manipulé ou déconnecté durablement.
haltTrading
Le constructeur peut utiliser haltTrading pour annuler tous les ordres et clôturer au prix de marque. Cette opération doit être utilisée avec prudence, par exemple :
- Lorsqu’une attaque est détectée, un halt peut provoquer une liquidation immédiate, mais risque de réaliser des profits malveillants ou de créer des pertes importantes.
setMarginTableIds / InsertMarginTable
InsertMarginTable : définir une nouvelle table de marges avec exigences et levier maximum.
setMarginTableIds : associer un marché à une table de marges spécifique.
Un marché peu liquide ou avec faible capacité de market-making, si le levier maximum est trop élevé, augmente le risque de déclenchement d’ADL.
Un changement brutal de marginTableId revient à modifier la marge de maintien, ce qui peut faire passer de nombreux comptes en liquidation simultanément, provoquant une cascade.
setMarginModes
HIP-3 supporte actuellement uniquement la marge isolée (isolated), mais le mode croisé (cross) pourrait être supporté à l’avenir. Dans un DEX avec des marchés à haute et faible liquidité, le mode croisé pourrait transmettre le risque de faible liquidité à des marchés plus profonds. En l’absence de solution mature, il n’est pas conseillé d’introduire le mode croisé.
Risques liés aux oracles
Pour les actifs 7×24H, le principal risque est la fiabilité et la stabilité des oracles externes, ainsi que la centralisation du relayer.
Pour les actifs non 7×24H, le risque majeur est la récupération ou le calcul du prix oracle en dehors des heures de trading.
Par exemple, sur trade.xyz, en dehors des heures, le prix est basé sur le dernier prix de clôture combiné à une limite de volatilité (1 / max_leverage). En cas de manipulation ou de déconnexion, cela peut entraîner des liquidations massives ou des événements ADL.
En décembre 2025, sur trade.xyz, le marché XYZ100-USDC a été manipulé, provoquant une déconnexion du prix et une liquidation massive, avec environ 13 millions de USDC de positions longues liquidées.
Le problème est que, hors heures, il n’y a pas de prix oracle stable et continu, et le marché ne peut s’appuyer que sur le dernier prix externe + l’intérieur, ce qui peut causer des décalages importants lors de la réouverture.
Risques liés à la reprise de marché :
Une forte déviation entre le prix externe et interne lors de la réouverture peut provoquer des dérapages, des liquidations en cascade ou des événements ADL.
0x4 Stratégies de contrôle des risques
- Prix oracle stable
Pour les actifs non négociés 24/7, le défi est la fixation du prix en dehors des heures : manque de prix stable, manipulation ou dérive.
Les solutions courantes :
-
Arrêter la mise à jour de l’oracle, limiter ou suspendre la négociation (ex. Lighter limite la réduction de position en dehors des heures).
-
Utiliser un mécanisme de « prix interne » basé sur la liquidité interne et des algorithmes, en cas de données externes manquantes.
Ces approches reflètent un compromis entre sécurité et expérience utilisateur : la première privilégie la sécurité avec des contrôles stricts, la seconde maintient la continuité mais peut s’éloigner de la valeur réelle.
Pendant la période de non négociation, il faut éviter que le prix interne devienne totalement autonome, en introduisant des références externes pour réduire le risque de déconnexion ou de saut de prix. Des sources possibles :
-
Blue Ocean ATS : plateforme après-heure/night trading, fournissant une référence de prix plus réactive que la clôture.
-
IG weekend CFD quotes : prix de marché pour le week-end, servant de référence ou de surveillance.
Ces sources offrent des signaux de prix pour la période de non négociation, mais ne remplacent pas totalement le marché spot.
- Vérification des prix
Les prix oracle dans HIP-3 proviennent du relayer du constructeur, ce qui pose un risque de centralisation. Il est recommandé de mettre en place un mécanisme de vérification des prix, permettant à tout utilisateur ou institution de valider la véracité et l’équité des prix off-chain, par exemple :
- RedStone : packager le prix avec sa source et sa signature pour vérification.
Données publiques :
-
Algorithme : transparence sur la méthode de calcul.
-
Sources : liste ouverte et non manipulable.
-
Normes de push : permissions, fréquence, limites de volatilité.
b. Preuve de prix
Pour chaque setOracle, générer une preuve (Proof) comprenant :
-
Entrées : réponses brutes ou normalisées des sources, timestamp.
-
Calculs : résultats intermédiaires reproductibles.
-
Sorties : prix oracle validé.
Sérialiser la preuve, obtenir un hash (proofHash), signer avec la clé de l’oracle.
c. Publication de la preuve
Maintenir une liste de preuves, construire un Merkle tree, publier périodiquement le MerkleRoot sur la blockchain.
d. Vérification
Fournir un outil open source ou une interface web pour vérifier la preuve, la signature, le timestamp, le MerkleRoot, et comparer avec le prix calculé.
- Surveillance des risques
La vérification des prix rend le processus de setOracle « réproductible et auditable », mais ne prévient pas la dérive du marché en temps réel. La déconnexion ou la manipulation du prix, combinée à une forte position ouverte, peut rapidement entraîner des risques systémiques comme ADL ou faillite. Il faut donc détecter précocement ces anomalies et déclencher des mesures pour limiter le risque.
- Sur le prix
a. Défaillance de l’oracle
Indicateurs :
-
Surveillance de la santé du relayer (ex. changement de relayer).
-
Actions : basculer vers un relayer de secours, alerter.
b. Déconnexion ou déconnexion du prix
Indicateurs :
-
Surveiller la déviation par rapport à un seuil.
-
Actions : réduire la limite d’Open Interest, ajuster la marge, activer le clamp.
- Sur le carnet d’ordres
a. Profondeur anormale
Indicateurs :
-
Écart de profondeur, spread, impact des ordres.
-
Actions : réduire l’Open Interest, ajuster la marge, forcer la réduction de levier.
b. Faux ordres
Indicateurs :
-
Apparition soudaine et rapide d’ordres fictifs.
-
Actions : réduire l’Open Interest, arrêter le marché si nécessaire.
- Sur la position
a. Sur-accumulation
Indicateurs :
-
Ratio OI / volume, concentration des positions.
-
Actions : alerter, réduire l’Open Interest.
b. Pertes extrêmes
Indicateurs :
-
Pertes de la majorité, position moyenne.
-
Actions : alerter, réduire l’Open Interest.
0x5 Conclusion
Le cœur de HIP-3, c’est : transformer « l’ajout » d’un marché en une capacité standardisée accessible via une interface, permettant à tout développeur de déployer, exploiter et faire évoluer ses marchés dans un cadre contrôlé. Le processus de déploiement devient une opération encadrée par des règles, avec des responsabilités clairement assignées.
Mais il ne faut pas croire que cela élimine les risques : cela déplace simplement leur position et leur forme. La gestion des risques repose désormais sur la qualité des entrées (oracles, paramètres, marges), la surveillance en temps réel, et la capacité à réagir rapidement en cas de déviation ou de crise.
L’enjeu principal est de faire en sorte que la délégation de responsabilités ne devienne pas une faille, en introduisant des mécanismes de responsabilité, de vérification et de contrôle. La véritable réussite de HIP-3, c’est d’établir un équilibre entre ouverture, sécurité et responsabilité, pour que la croissance ne se fasse pas au prix de la stabilité.
