HIP-3 (Proposition d’Amélioration Hyperliquid 3) déployée sur le réseau principal depuis environ 3 mois, le volume total des marchés personnalisés tiers a dépassé 13 milliards de dollars depuis son lancement. Cela signifie que la « mise en ligne » n’est plus simplement un processus interne à la plateforme d’échange, mais devient une infrastructure de base pouvant être directement appelée par des développeurs externes.
Dans les échanges centralisés, « mettre en ligne » est naturellement un pouvoir de la plateforme : quels actifs peuvent être négociés, quand ils sont lancés, comment définir les paramètres, 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 lourdes, sont souvent contraints par le rythme de déploiement et de gouvernance d’une minorité d’équipes.
L’innovation de HIP-3 consiste à transformer cette étape du « validation par 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 de mise en ligne 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 : le matching, la liquidation et le règlement sont fournis de manière unifiée par la couche de 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：为合约交易优化的定制化 L1 区块链，每秒可处理 20 万笔订单，并具备确定性最终性。#HyperEVM : couche applicative, capable d’exécuter des contrats intelligents compatibles EVM.
Le marché perpétuel natif d’Hyperliquid (perps gérés par validateurs) ressemble encore à un processus traditionnel de CEX : l’équipe officielle peut lancer des contrats perpétuels selon la volonté de la communauté ; la suppression se décide par vote des validateurs.
Le protocole Hyperliquid supportera les perps déployés par les constructeurs (HIP-3), une étape clé vers une décentralisation complète du processus de listing.
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 de mise en marché.
0x2 HIP-3 : Marchés déployés par des développeurs
Le principe de HIP-3 est simple : sans modifier la couche de base de Hyperliquid pour le trading et le règlement, 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, « mise en ligne » devient une interface standard accessible.
En résumé : un constructeur peut lancer un marché perpétuel basé sur le moteur HyperCore, en fixant lui-même les prix et en ajustant les paramètres du marché.
Les responsabilités 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) : l’équipe officielle 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 : incluant le prix initial oraclePx et 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 un prix oraclePx précis, 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 commande / levier maximal » (coin, szDecimals, maxLeverage, etc.).
Choix du DEX : le constructeur déploie d’abord un DEX perpétuel (chaque DEX avec marges, carnet d’ordres, déployeur configurés séparément), et peut choisir n’importe quelle devise de cotation comme collatéral pour ce DEX (par exemple USDC). Chaque marché perpétuel correspondra à 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 associant une table de marges (margin table) à l’actif, pour limiter le levier maximal — la limite de levier est définie par tranches en fonction de la taille de la position, pour restreindre le levier disponible dans la plage prédéfinie.
Liquidation si nécessaire : le constructeur peut utiliser l’interface haltTrading pour suspendre le marché, déclenchant la liquidation — annuler toutes les ordres, régler la position au prix de marquage 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étuel. Chaque DEX perpétuel constitue un espace de trading indépendant : marges, carnet d’ordres, paramètres déployés séparément.
-
Définir la collatéralité : le collatéral de ce DEX peut être choisi comme n’importe quelle devise de cotation (quote asset), mais si cette devise perd la qualification de quote asset permissionless (décision du vote des validateurs), le DEX perpétuel utilisant cette devise comme collatéral sera désactivé.
-
Ajouter des marchés : les 3 premiers marchés peuvent être déployés directement ; pour ajouter d’autres marchés, il faut obtenir une « quota » via une enchère hollandaise (Dutch auction).
-
Exploiter les marchés : une fois déployés, le travail du constructeur consiste à « faire fonctionner le marché de manière stable », c’est-à-dire assurer son exploitation.
-
Unstake : lorsque tous les marchés du DEX ont été liquidés, la garantie de 500k HYPE peut être débloquée. Après la demande de unstake, une file d’attente de 7 jours s’ouvre, durant laquelle la garantie peut encore être pénalisée ou saisie.
Enchère hollandaise : cycle actuel de 31 heures par tour, 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 marquage (mark price) sert pour la marge, la liquidation et d’autres scénarios de gestion des risques (également pour déclencher TP/SL).
Sur 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é parmi plusieurs CEX perpétuels : (perp mid prices)
La fonction de oracle price et de mark price n’a pas changé dans HIP-3, mais leur mécanisme de calcul a évolué :
1. Entrée setOracle
a. oraclePx (obligatoire) )
Défini conformément à HyperCore.
b. markPx (optionnel)
Il peut soumettre 0 à 2 ensembles de prix externes comme candidats pour le vrai mark price.
c. externalPerpPx (obligatoire)
Une valeur de référence pour le mark price, pour éviter des déviations soudaines.
Le constructeur déploie souvent un relayer pour alimenter en prix, oraclePx
La valeur est calculée par le relayer en combinant plusieurs sources externes ; le markPx est calculé par une algorithme personnalisé du relayer ; externalPerpPx est la médiane pondérée des prix mid de plusieurs CEX perpétuels.
2. Le vrai mark price
Le mark price dans HIP-3 n’est pas directement le prix alimenté par setOracle :
Calcul du mark local : médiane(best bid, best ask, last trade).
En combinant le mark local et les ensembles de markPx (0-2), on en extrait la médiane pour obtenir le nouveau mark price.
3. Limites de setOracle
Fréquence de mise à jour : au moins 2,5 secondes entre deux appels, si le markPx n’est pas mis à jour en 10 secondes, il revient au mark local.
Amplitude : chaque mise à jour de markPx ne doit pas dépasser ±1 % ; tous les prix sont plafonnés dans une plage de 10× la valeur d’ouverture de la journée (start-of-day).
Mécanismes de tarification 7×24H vs 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) et non 7×24H (seulement à certains horaires, pas de trading en dehors des heures de marché spot).
Les caractéristiques de trading de ces deux types d’actifs déterminent leur mode d’obtention des prix.
Pour les actifs 7×24H (ex : BTC), on peut obtenir un prix stable via CEX/DEX ou oracle de confiance :
Pour les actifs non 7×24H (ex : actions), il faut uniquement pendant les heures d’ouverture du marché pour obtenir des cotations externes suffisantes et stables. Pour faire fonctionner ces actifs en mode 24/7 dans HIP-3, il faut utiliser une autre mécanique de tarification pendant la fermeture.
Prenons l’exemple du marché perpétuel d’actions sur trade.xyz :
Pendant l’ouverture, utiliser un oracle externe comme Pyth pour fournir un prix stable.
Pendant la fermeture, ajuster le prix basé sur la dernière clôture, en tenant compte de la pression interne du carnet d’ordres. Le prix de marquage est limité à ±1/max_leverage (par ex., Tesla 10x -> 10 %).
Liquidation
Les marchés HIP-3 réutilisent principalement la logique de liquidation d’HyperCore, donc la logique de déclenchement est la même : si la valeur nette d’une position isolée ne couvre pas la marge de maintien, elle devient liquidable.
Les décisions de liquidation se basent sur le mark price, pas sur un prix de transaction spécifique.
Formule de liquidation :
side = 1 (long), -1 (short)
l : taux de marge de maintien
La valeur de levier de maintenance (MAINTENANCE_LEVERAGE) provient du niveau de marge associé à la position (margin tier) : on lit d’abord le taux de marge de maintien (mmr) dans ce niveau :
S’il y a plusieurs niveaux, la valeur de liquidation correspond à la tranche où la valeur nominale de la position se trouve, en utilisant le mmr de cette tranche.
margin_available
isolated : isolated_margin - maintenance_margin_required
Une fois en liquidation, le système priorise la liquidation par ordre de carnet d’ordres avec ordre au marché ; si le risque est ramené dans une zone sûre, le reste de la marge reste au trader.
Mais en cas de faible profondeur ou de gap, le prix réel de liquidation peut être très différent du mark price, créant un « écart de liquidation ».
La valeur nette de position isolée : valeur nette d’une position isolée au prix de marquage actuel (après gains/pertes), moins la marge liée à cette position.
ADL :
Dans ce cas, le mécanisme ADL (Auto-Deleveraging) peut intervenir en cas d’extrême :
Si la valeur nette d’une position isolée devient négative, l’ADL se déclenche, en réduisant ou fermant des positions à l’aide des pertes non réalisées et du levier, en utilisant le mark price précédent pour forcer la réduction ou la liquidation, en comblant le déficit avec les profits de contreparties, pour éviter la faillite du système.
Le tri des positions à réduire se fait selon :
previous mark price : prix de marquage précédent, enregistré avant l’activation de l’ADL.
Exemple :
Avant l’activation, le mark price est 3 000.
En raison de la contrainte setOracle, le nouveau mark price ne peut dépasser 2 970 (-1%).
Mais la profondeur du carnet est faible, et après une liquidation au marché, le prix moyen réel de transaction est 2 910 (-3 % par rapport à 3 000).
La perte sur la position longue est réglée à 2 910, ce qui peut faire tomber la valeur nette de la position isolée en dessous de zéro (écart), déclenchant l’ADL.
L’ADL sélectionne alors des positions de contrepartie (gagnantes en short) pour réduire ou liquider à partir du previous mark price = 3 000, transférant ainsi le déficit vers les profits passifs, évitant une faillite systémique.
Vue d’ensemble des risques : responsabilités et risques clés
Mécanisme de pénalisation (Slashing) : responsabilité
HIP-3 confie le « pouvoir de mise en ligne et d’exploitation » au constructeur, tout en intégrant une règle de pénalisation exécutable dans le protocole : le constructeur doit déposer des HYPE en garantie, et en cas de mauvaise gestion, les validateurs peuvent voter pour pénaliser et détruire (burn) cette mise en garantie.
Exigences de dépôt
Le réseau principal exige que le constructeur dépose 500 000 HYPE, même si tous ses marchés sont suspendus, cette garantie doit être maintenue 30 jours.
Procédure de déclenchement et vote
En cas d’opérations malveillantes, les validateurs peuvent initier un vote pondéré par la mise (stake-weighted vote) pour décider de pénaliser le constructeur.
Critères de jugement
L’équipe officielle précise que la pénalisation ne dépend pas de la cause (malveillance, incapacité, vol de clé privée), mais du fait que le comportement du constructeur a entraîné un état invalide, une panne prolongée ou une dégradation des performances.
Taux de pénalisation
Le pourcentage de pénalité est décidé par vote, avec des plafonds :
-
pour un état invalide ou panne prolongée : jusqu’à 100 %
-
pour une panne courte : jusqu’à 50 %
-
pour une 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 d’attaque DDoS, le prix oracle dans le marché pourrait être manipulé ou déconnecté durablement.
haltTrading
Le constructeur peut utiliser haltTrading pour annuler tous les ordres du marché et liquider au prix actuel. Cette opération doit être utilisée avec prudence, notamment dans des scénarios comme :
- détection d’une manipulation malveillante du marché, en appelant haltTrading pour liquider au mark price, ce qui pourrait réaliser des profits de l’attaquant (, mais aussi provoquer des pertes importantes.
setMarginTableIds / InsertMarginTable
InsertMarginTable : définit une nouvelle table de marges, avec exigences et levier maximal pour une catégorie d’actifs.
setMarginTableIds : associe un marché à une table de marges spécifique.
Pour un marché peu liquide ou avec faible capacité de market making, un levier maximal 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 de liquidations.
setMarginModes
Actuellement, HIP-3 ne supporte que le marge isolée (isolated margin). À l’avenir, le mode croisé (cross margin) pourrait être supporté. Dans un DEX, la coexistence de marchés à haute et faible liquidité pourrait faire que le mode cross margin propage le risque de faible liquidité vers des marchés à haute liquidité. En l’absence de solution mature, il n’est pas recommandé d’introduire le mode cross margin.
Risques liés aux oracles
Pour les actifs 7×24H, le principal risque est la dépendance à la fiabilité et à la stabilité des services oracle externes, ainsi que la centralisation du relayer mentionnée plus haut.
Pour les actifs non 7×24H, le risque majeur concerne la récupération ou le calcul du prix oracle en dehors des heures de marché. Par exemple, sur trade.xyz, en dehors des heures de marché, le prix est basé sur la dernière cotation externe combinée à la dernière valeur interne. En cas de faible liquidité ou de manipulation du marché, ce prix peut s’écarter fortement, provoquant des liquidations massives ou des événements ADL.
Le 14 décembre 2025, sur trade.xyz, le marché XYZ100-USDC ), indexé sur NASDAQ100 (, a été manipulé, un attaquant a créé une position short de 398 XYZ100 (~10M USDC), déconnectant fortement le prix, entraînant la liquidation de nombreux longs, et provoquant une chute supplémentaire du prix, avec environ 13M USDC de positions longues liquidées.
![图片])https://img-cdn.gateio.im/social/moments-46485922603bcc451881e82987685518(![图片])https://img-cdn.gateio.im/webp-social/moments-3f11b34efd760ad2a07f657c92b39ba7.webp(
https://x.com/bartdothl/status/2000292798755684839
De plus, en dehors des heures de marché, l’absence d’un prix oracle stable et continu limite la capacité à ancrer le prix, et le marché ne peut se baser que sur la dernière cotation externe + la pression interne du carnet d’ordres. En cas de forte variation ou de gap lors de la réouverture, le système risque de continuer à être plafonné ou de faire face à une revalorisation rapide, ce qui peut entraîner une concentration de liquidations ou d’événements ADL.
Les risques augmentent lors de la réouverture : si le prix externe diffère fortement du prix interne, le système peut soit continuer à être plafonné, soit effectuer une revalorisation rapide, ce qui peut provoquer une forte pression de liquidation en peu de temps, voire des événements ADL.
![图片])https://img-cdn.gateio.im/social/moments-43ed3e020660f17493f6412f8c8e651a) Stratégies de contrôle des risques
- ( Prix oracle stable
Pour les actifs non négociés 24/7, le principal défi est la tarification en dehors des heures de marché : manque de cotations externes stables, manipulation ou dérive en profondeur.
Les solutions courantes sont :
-
Arrêter la mise à jour de l’oracle, suspendre ou limiter la négociation durant cette période ), par exemple, le protocole Lighter ne permet que de réduire la position en dehors des heures.
-
Ajuster le levier maximal en période de fermeture, en forçant la liquidation des positions excessives.
-
Utiliser un mécanisme de tarification interne comme trade.xyz, où en l’absence de données externes, la tarification repose sur la liquidité interne et des algorithmes.
Ces approches reflètent un compromis entre sécurité et expérience utilisateur : la première privilégie la sécurité avec des mécanismes stricts, au prix d’une expérience limitée ; la seconde maintient la continuité, mais avec un risque accru de déconnexion entre prix interne et valeur réelle.
Pendant la fermeture, il faut éviter que la tarification devienne purement interne, en introduisant une référence externe pour réduire le risque de déconnexion ou de gap. Des sources possibles :
-
Blue Ocean ATS : plateforme de trading après clôture ou de nuit, fournissant une cotation continue pour aider à générer un prix oracle ou à surveiller la dérive.
-
IG weekend CFD quotes : cotations CFD du week-end, fournissant une anticipation du marché, utile pour la tarification ou la surveillance en période de fermeture, pour anticiper un gap potentiel.
Ces sources offrent des signaux de prix en période de fermeture, mais ne remplacent pas totalement le marché spot, elles servent plutôt d’ancrage ou de signal d’alerte.
- ) Vérification des prix
Les prix oracle dans HIP-3 proviennent du relayer configuré par le 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 hors chaîne la véracité et l’équité du prix (, à l’image de RedStone, en packant la valeur, la source et la signature dans une preuve sur la blockchain ).
Données publiques
-
Spécification de l’algorithme : divulguer en détail la méthode et le processus.
-
Liste des sources de données : chaque source doit être publique, non manipulable par le constructeur, avec une API et des paramètres accessibles.
-
Normes de push de prix : permissions, fréquence de déclenchement, limites de volatilité.
b. Preuve de prix
Pour chaque appel setOracle, générer une preuve correspondante (Proof), comprenant :
-
Entrées : réponse brute de chaque source à ce moment, ou champs normalisés, avec timestamp.
-
Calculs : résultats intermédiaires reproductibles.
-
Sorties : prix oracle publié.
Sérialiser la preuve, obtenir proofHash, et faire signer ce hash par l’oracleur.
c. Publication de la preuve
Maintenir une liste, stocker chaque proofHash dans un Merkle tree, et publier périodiquement (par exemple toutes les heures/journées) le MerkleRoot sur la blockchain.
d. Vérification
Fournir un outil open source ou une interface web permettant d’entrer le timestamp ou le tx hash de setOracle, et de vérifier toutes les données, la signature, le MerkleRoot, etc., puis de recalculer le prix oracle pour comparaison.
- ) Surveillance des risques
La vérification des prix rend le processus de setOracle « récalculable et auditable », mais ne peut empêcher une dérive du marché en temps réel — interruption de l’alimentation, déviation de prix, dégradation de la profondeur — surtout si la taille des positions ouvertes est importante (OI), ce qui peut rapidement transformer une anomalie locale en une crise systémique via des liquidations en chaîne ou des événements ADL. Il faut donc détecter précocement ces anomalies et déclencher des mesures correctives pour contenir le risque.
- Sur le prix
a. Défaillance de l’oracle
Indicateurs de surveillance :
Utiliser des mesures on-chain pour vérifier si l’alimentation oracle est bloquée :
Seuils par niveaux :
Actions :
Niveau 1 : Vérifier la santé du relayer, basculer vers un relayer de secours, et émettre une alerte avec rapport de santé.
Niveau 2 : Diminuer le plafond d’Open Interest via setOpenInterestCaps :
b. Déviation de prix
Indicateurs :
Seuils :
Niveau 1 : si 2 des 3 indicateurs (A, B, D) dépassent le seuil
Niveau 2 : si 3 des 4 indicateurs (A, B, C, D) dépassent le seuil et persistent X secondes
Actions :
Niveau 1 : réduire le plafond d’Open Interest
Niveau 2 : en cas de déviation prolongée, ajuster progressivement la table de marges, réduire le levier maximal par tranches, activer le clamp du relayer.
Niveau 3 : en cas de déviation persistante, émettre une alerte, et en dernier recours, le constructeur peut décider d’arrêter le marché via haltTrading.
- Sur le carnet d’ordres
a. Analyse de la profondeur
Surveillance :
depth_band(±x%) : volume réel d’ordres dans une bande de prix autour du prix médian.
spread = bestAsk - bestBid : écart entre l’offre et la demande.
aggressiveVolume_Δt : volume d’ordres agressifs (taker) dans Δt.
impact_ratio = aggressiveVolume_Δt / depth_band : ratio d’impact.
: risque accru si :
- depth_band diminue, tout en augmentant spread et impact_ratio.
Actions :
Niveau 1 : réduire le plafond d’Open Interest
Niveau 2 : réduire le levier via setMarginTableIds, et liquider certains positions à haut levier.
b. Fausse apparition d’ordres
Surveillance :
depth_band qui augmente puis chute brutalement en peu de temps.
Actions :
Niveau 1 : réduire le plafond d’Open Interest
Niveau 2 : si prix s’écarte fortement, envisager l’arrêt du marché.
- Sur la position
L’objectif n’est pas de prévoir la direction, mais d’identifier si le marché passe d’un mode purement transactionnel à un mode de positionnement stratégique : accumulation rapide, positions concentrées, P&L proche des extrêmes, rendant le marché plus sensible aux perturbations.
a. Sur-accumulation à court terme
Surveillance :
OI_notional : taille de la position ouverte
Volume_24h_notional : volume de transactions sur 24h
Calcul : ratio OI_notional / Volume_24h_notional, augmentation rapide indique une spéculation accrue, risque de volatilité.
Actions :
Niveau 1 : alerte lors du dépassement du seuil
b. P&L majoritaire
Surveillance :
Majority Side : la partie avec le plus de positions (Long ou Short)
avgEntry_major : prix moyen d’ouverture de la majorité
size_major : taille de la majorité
P&L majoritaire :
Proportion P&L majoritaire :
Actions :
Niveau 1 : alerte lors du dépassement du seuil
Niveau 2 : si cela persiste, réduire le plafond d’Open Interest.
0x5 Conclusion
Le cœur de HIP-3 est : transformer « mise en ligne » d’un processus réservé à quelques-uns en une capacité standardisée accessible via protocole — en déposant une garantie, le constructeur peut lancer son propre DEX perpétuel sur HyperCore, commencer par quelques marchés gratuits, puis obtenir plus de quotas via enchères, pour faire évoluer la croissance du marché d’un « attente d’approbation » à un « déploiement selon règles ».
Mais il est clair que HIP-3 ne supprime pas les risques, il en modifie simplement la localisation et la forme. La partie auparavant couverte par la gestion des risques de la plateforme repose désormais davantage sur la qualité des entrées et de l’exploitation du constructeur : feed oracle, fréquence, choix et contraintes du markPx, tranches de marge et levier, tarification en dehors des heures pour les actifs non 7×24H, et pouvoirs comme haltTrading qui peuvent à la fois limiter ou amplifier les pertes. Toute erreur dans ces étapes peut entraîner une liquidation concentrée en profondeur, provoquant des écarts et des événements ADL — le problème n’est plus « peut-on mettre en ligne », mais « une fois en ligne, peut-on assurer une stabilité opérationnelle ».
Au niveau protocolaire, la réponse à cette externalisation des risques consiste à rendre les permissions responsables : la mise en garantie + le vote des validateurs pour pénaliser ou détruire en cas de mauvaise gestion, afin d’établir une responsabilité claire. Par ailleurs, les contraintes sur les prix et le levier (clamp, fréquence de mise à jour, limite de volatilité, isolation) tentent de contenir les scénarios extrêmes dans des limites contrôlables. La véritable problématique de HIP-3 devient donc : l’expansion par ouverture contrôlée, la sécurité par contraintes, et la pérennité par vérifiabilité et responsabilité.
HIP-3 ne vise pas à rendre la mise en ligne plus libre, mais à la rendre plus standardisée — déployable, exploitable, et responsable. Pour assurer une stabilité opérationnelle, cela dépend en fin de compte de la qualité de la mise en œuvre des oracles, des paramètres de levier, des contrôles de gestion des risques et du monitoring en temps réel. Si vous concevez des processus d’accès au marché, de modélisation des paramètres, d’alerte ou de gestion d’urgence selon HIP-3, ou si vous avez besoin d’audits et de support continu en sécurité, n’hésitez pas à contacter BlockSec.
