Guide sur le taux de maintien du staking HIP-3 : de la configuration des paramètres à l'exécution de la gestion des risques

Hyperliquid via HIP-3 (Proposition d’Amélioration Hyperliquid 3) a mis en place un nouveau marché de contrats perpétuels décentralisé, en ligne depuis environ trois mois. Les développeurs tiers peuvent déployer leurs propres marchés sur sa plateforme unifiée de trading et de compensation, avec un volume total de transactions dépassant 13 milliards de dollars. Cette innovation réduit considérablement la barrière à l’entrée pour l’innovation, mais s’accompagne également de nouveaux risques de sécurité. Parmi eux, la gestion du taux de maintien de la mise en jeu devient un facteur clé pour assurer la stabilité à long terme du marché.

Pour les Builders, la mise en jeu n’est pas seulement un “billet d’entrée” pour accéder au marché, mais aussi un cadre d’incitations économiques et de partage des risques. Par le biais de la mise en jeu et des contraintes de taux de maintien, HIP-3 favorise l’innovation ouverte tout en établissant une frontière de gestion des risques responsable.

Mécanisme de mise en jeu et cadre de taux de maintien de HIP-3

HIP-3 repose sur l’architecture à double couche de Hyperliquid : HyperCore (une chaîne L1 personnalisée optimisée pour le trading de contrats, capable de traiter 200 000 ordres par seconde) et HyperEVM (couche applicative compatible EVM). La force de cette architecture réside dans le fait que l’appariement, la compensation et le règlement sont fournis de manière unifiée par la base du protocole, permettant aux Builders de réutiliser ce moteur haute performance sans avoir à le construire à partir de zéro.

Signification économique de la mise en jeu

Dans HIP-3, le Builder doit mettre en jeu 5 millions de jetons HYPE. Cette mise en jeu a trois implications :

1. Mécanisme d’entrée : La mise en jeu constitue une condition préalable pour déployer un marché, garantissant que les participants ont un engagement économique suffisant.
2. Partage des risques : En cas de mauvaise gestion du marché, la mise en jeu peut être confisquée ou pénalisée, liant ainsi les intérêts du Builder à ceux des utilisateurs.
3. Contrainte de taux de maintien : La taille de la mise en jeu détermine directement le nombre de marchés que le Builder peut déployer et le niveau de risque qu’il peut supporter.

Relation directe avec le taux de maintien

Le taux de maintien de la mise en jeu (Maintenance Margin Ratio) est lié à la taille de la mise en jeu : la mise en jeu du Builder équivaut à un “capital tampon de risque” pour son marché. En cas d’anomalie (par ex., déconnexion du prix, retrait de liquidité, gap de liquidation), cette mise en jeu devient la dernière source de responsabilité et de compensation.

Les validateurs décident, via un vote pondéré par la mise en jeu (stake-weighted vote), s’il faut confisquer ou pénaliser le Builder. Les conditions de pénalisation incluent :

• Pour un état invalide du marché ou une panne prolongée : confiscation jusqu’à 100% de la mise en jeu
• Pour une panne courte ou une dégradation des performances : confiscation jusqu’à 20%-50%
• En cas de vol de clé privée entraînant une manipulation de prix : même risque de confiscation

Ce design lie intrinsèquement la responsabilité opérationnelle à l’intérêt économique — plus le taux de maintien est élevé, plus le tampon de risque est important, mais en cas de déclenchement, la perte pour le responsable est également plus grande.

Période de verrouillage de la mise en jeu

Même si le Builder arrête tous ses marchés, la mise en jeu doit rester bloquée 30 jours avant de pouvoir demander le déblocage. Cela signifie que la responsabilité en matière de risque ne se dissipe pas immédiatement en cas d’arrêt de marché — si de nouveaux problèmes de sécurité ou des controverses utilisateur apparaissent durant cette période, la mise en jeu peut encore être gelée ou confisquée.

Paramétrage et contraintes de taux de maintien lors de l’exploitation du marché

Une fois le marché déployé, le Builder doit configurer des paramètres pour maintenir la stabilité. Ces paramètres influencent directement les conditions de déclenchement de la liquidation et le risque associé, impactant la pression réelle sur le taux de maintien de la mise en jeu.

Oracles et mécanismes de tarification

Le Builder doit fournir en continu via l’interface setOracle trois types de prix :

• oraclePx (obligatoire) : prix de référence de l’actif, utilisé pour calculer les frais de financement
• markPx (optionnel) : 0-2 groupes de prix de référence externes
• externalPerpPx (obligatoire) : médiane pondérée des prix d’intermédiaire de plusieurs CEX perpétuels, servant de référence anti-déconnexion

Le prix de référence final utilisé par le système est la médiane entre le prix du carnet local et le markPx soumis par le Builder. Pour éviter toute manipulation malveillante, deux contraintes strictes sont appliquées :

• Fréquence de mise à jour : au moins 2,5 secondes entre deux appels, et si aucune mise à jour en 10 secondes, le prix revient automatiquement au mark local
• Amplitude de fluctuation : chaque markPx ne peut fluctuer de plus ou moins 1%, et tous les prix sont plafonnés dans une fourchette de 10 fois le prix d’ouverture du jour

Ces contraintes protègent en réalité la mise en jeu du Builder — en limitant la capacité de manipulation, elles réduisent le risque de pénalisation.

Configuration du levier et de la table de marge

Le Builder définit une table de marge (margin table) pour limiter le levier maximal. La table est généralement segmentée par taille de position, avec des exigences de marge de maintien (maintenance margin requirement) différentes selon le niveau.

Pour un marché peu liquide, un levier trop élevé augmente directement la probabilité de déclenchement d’ADL (auto-deleveraging). Par exemple, si un marché ne réalise que 10 millions de dollars de volume quotidien mais est configuré avec un levier de 20x, alors dès que l’Open Interest (OI) atteint un certain seuil, toute fluctuation de prix peut rapidement entraîner des liquidations en cascade, provoquant un gap et un événement ADL.

Lorsqu’un Builder change soudainement le marginTableId, c’est comme si toutes les positions des utilisateurs voyaient leur marge de maintien modifiée instantanément, ce qui peut faire passer un grand nombre de comptes d’un état sécurisé à un état liquidable, provoquant une réaction en chaîne de liquidations. Ce risque opérationnel est élevé : en cas de crise systémique, la mise en jeu du Builder peut être lourdement pénalisée.

Arrêt du marché et liquidation forcée

Le Builder peut utiliser la permission haltTrading pour suspendre le trading, annuler toutes les ordres, et procéder à une liquidation forcée de toutes les positions au prix mark actuel. Bien que cette fonction soit un outil de gestion des risques, une utilisation inappropriée peut amplifier les pertes.

Scénario extrême : si un attaquant ouvre une position short massive et manipule le prix à la baisse, le Builder peut, en appelant haltTrading, liquider au mark price, réalisant ainsi un “cash-out” de la position de l’attaquant. Si l’attaquant manque de liquidité pour contrebalancer, il sera forcé à la liquidation, et la perte se transforme en créance impayée pour le système.

Ce type d’événement entraînera la confiscation de la mise en jeu du Builder, car le vote des validateurs considérera que ses actions ont provoqué une invalidation du marché et des pertes pour les utilisateurs.

Risques liés aux oracles et lien avec le taux de maintien

Les oracles sont la colonne vertébrale de la tarification HIP-3. Le Builder déploie généralement un relayer indépendant pour alimenter les prix, mais plusieurs risques existent.

Différences de prix entre actifs 7×24 et non 7×24

Pour des actifs comme le BTC, qui se négocient 24h/24, on peut obtenir des prix de référence continus et relativement stables via CEX/DEX. Le rôle principal de l’oracle du Builder est d’agréger plusieurs sources fiables, dédupliquer et filtrer les anomalies, ce qui est relativement simple.

Pour des actifs non 7×24, comme des actions, la situation est plus complexe. Pendant les heures d’ouverture, le Builder peut s’appuyer sur Pyth ou d’autres oracles. En dehors, notamment la nuit ou le week-end, la liquidité externe disparaît, et le Builder doit utiliser une tarification interne basée sur le dernier prix de clôture plus la pression du carnet. Le prix mark est alors limité à ±10% du dernier prix de clôture (pour un levier de 10x).

Ce mécanisme interne comporte un risque : à la réouverture du marché, le prix réel peut faire un saut important par rapport à cette tarification interne, provoquant un gap de prix et une cascade de liquidations.

Ce scénario peut aussi mettre sous pression la mise en jeu, car les utilisateurs liquidés pourraient accuser le Builder d’avoir mal calibré la tarification hors marché.

Risques de centralisation des relais d’oracle

Si le serveur relayer du Builder est attaqué par DDoS ou si sa clé privée est compromise, le prix de l’oracle peut être manipulé ou déconnecté durablement. La détection de cette situation entraînera une confiscation immédiate de la mise en jeu.

Surveillance en temps réel : stratégies d’ajustement dynamique du taux de maintien

Dans la conception HIP-3, le Builder dispose d’une certaine autonomie pour ajuster ses paramètres, mais le système fournit aussi des outils pour une gestion dynamique. La compréhension de ces outils est essentielle pour maintenir la sécurité de la mise en jeu.

Surveillance côté prix

1. Défaillance de l’oracle : si le relayer est bloqué, deux appels setOracle espacés de plus de 10 secondes entraîneront un retour automatique au mark local. Il faut alors passer à un relayer de secours et signaler la situation aux validateurs. Si la coupure dure, le Builder doit envisager de réduire le plafond d’Open Interest via setOpenInterestCaps pour limiter l’impact d’une déconnexion prolongée.

2. Déconnexion ou déviation de prix : surveiller l’écart entre le mark price et les prix intermédiaires des perpétuels CEX. En cas de déviation :

   • Niveau 1 (≥3%) : réduire le plafond d’Open Interest
   • Niveau 2 (≥5% et persistant >30s) : diminuer progressivement le levier max dans la table de marge, activer le mécanisme de clamp pour limiter la volatilité
   • Niveau 3 (déviation persistante élevée) : envisager l’arrêt du marché via haltTrading

Surveillance côté carnet

1. Retrait de liquidité : surveiller la quantité réelle d’ordres dans une bande de prix (±3%), le spread, et le volume taker. Une baisse de profondeur couplée à une augmentation du spread et du ratio taker/depth indique un risque accru. Il faut alors réduire la taille des positions autorisées.

2. Ordres fictifs : détecter des modèles où la profondeur augmente puis chute brutalement, signe de manipulation ou de fausses liquidités. En cas de suspicion, bloquer l’augmentation de l’OI.

Surveillance côté positions

Suivre le ratio entre l’OI et le volume de transactions sur 24h. Une augmentation rapide indique une transition vers une stratégie de positionnement plutôt que de trading court terme, ce qui amplifie le risque de cascades de liquidations. Il faut aussi surveiller la situation des positions majoritaires (plus de positions d’un côté) : si leur profit ou perte approche un seuil critique, une fluctuation de prix peut entraîner une liquidation massive.

Ces signaux influencent la décision du Builder : ajuster le levier, réduire l’OI, activer un mode de risque, etc. Toute erreur peut mettre en danger la mise en jeu.

Calculateur de taux de maintien : outil pratique de gestion des risques

En s’appuyant sur ce système de gestion, le Builder doit disposer d’un outil pour calculer et suivre en temps réel la pression sur le taux de maintien.

Fonctionnalités clés du calculateur

Un calculateur complet doit pouvoir :

1. Évaluer la sécurité de la mise en jeu en temps réel : en entrant la taille de la mise, le nombre de marchés déployés, l’OI total, la probabilité de liquidation, il estime la perte maximale supportable en cas de scénario défavorable.

2. Classer le risque : en fonction de l’état actuel du marché (stabilité des prix, profondeur, ratio OI/volume), donner une évaluation du niveau de risque et une prévision de la “vitesse de consommation” de la mise en jeu.

3. Recommander des paramètres : proposer le levier max, la segmentation de la table de marge, le plafond d’OI, et la pression sur la mise en jeu.

4. Évaluer un portefeuille multi-marchés : si plusieurs marchés sont déployés, calculer le risque global et identifier celui qui est le plus vulnérable.

5. Simuler des scénarios extrêmes : déconnexion de prix de 5%, rupture de liquidité, événements ADL, pour prévoir la perte maximale.

Utilisation pratique

• Avant le lancement d’un marché : évaluer le risque et ajuster les paramètres initiaux.
• En opération : surveiller en continu la pression sur la mise en jeu, anticiper les risques.
• En période de stress : effectuer des tests de résistance, décider de suspendre ou réduire l’activité.
• Après incident : analyser la perte réelle et ajuster la stratégie.

Conclusion : l’ouverture à l’expansion nécessite des contraintes responsables

HIP-3, en permettant une interface ouverte, transforme la création de nouveaux marchés d’un processus contrôlé par la plateforme en une capacité accessible à tous, dès que les conditions sont remplies. Avec plus de 130 milliards de dollars de volume, cette approche prouve sa viabilité. Cependant, cette ouverture transfère une partie de la gestion des risques, auparavant centralisée, vers le Builder lui-même.

Le cadre de mise en jeu et de taux de maintien constitue une défense contre cette externalisation des risques. Le Builder exprime par la mise en jeu sa confiance dans sa capacité à gérer le marché, tandis que le validateur peut confisquer cette mise en cas de défaillance. La réussite de ce système dépend de :

1. La qualité des entrées du Builder : fiabilité des oracles, paramètres bien calibrés, surveillance efficace
2. Le cadre de l’accord au niveau du protocole : règles de confiscation, contraintes de prix, mécanismes de surveillance
3. Les outils et systèmes de support : calculateurs, outils de monitoring, automatisation

La sécurité à long terme repose sur la capacité du Builder à appliquer concrètement ces bonnes pratiques, et pas seulement à les concevoir théoriquement.