Builder à lire absolument : Comment le marché HIP-3 identifie et atténue les risques

HIP-3（Proposition d’Amélioration Hyperliquid 3） en ligne depuis trois mois sur le réseau principal, le volume cumulé des marchés personnalisés déployés par des constructeurs tiers a dépassé 13 milliards de dollars. Qu’est-ce qui se cache derrière ce chiffre ? C’est la décentralisation du pouvoir : le pouvoir de “lancement” qui était autrefois monopolisé par des exchanges centralisés a été transformé en un standard ouvert d’interfaces. Les Builders n’ont qu’à staker 500 000 HYPE pour déployer un marché de contrats perpétuels sur la plateforme unifiée de trading et de règlement d’Hyperliquid.

Mais cette décentralisation du pouvoir s’accompagne aussi d’une externalisation des risques. Comment identifier ces risques et comment détecter rapidement les signaux d’alerte en opération devient une compétence essentielle que chaque Builder doit maîtriser.

Fondations de l’architecture : comprendre l’origine des risques de HIP-3

Pour repérer les risques liés à HIP-3, il faut d’abord comprendre sa conception architecturale.

HIP-3 repose sur une architecture à double couche d’Hyperliquid. HyperCore est une blockchain L1 personnalisée optimisée pour le trading de contrats, capable de traiter 200 000 ordres par seconde avec une finalité déterministe ; HyperEVM est la couche applicative, capable d’exécuter des smart contracts. La finesse de cette architecture réside dans le fait que : l’appariement, le règlement et la compensation sont fournis de manière unifiée par le protocole, permettant aux Builders de déployer des marchés sans repartir de zéro.

Cependant, cette séparation claire des responsabilités rend aussi le périmètre de responsabilité plus fragile — clairement défini, mais entièrement externalisé (le contrôle des risques étant entre les mains du Builder).

Le Builder doit staker 500k HYPE et assumer deux responsabilités principales :

• Définition du marché : choisir la source de prix de l’oracle, spécifier les caractéristiques du contrat (levier, unité minimale, etc.), sélectionner les actifs en garantie
• Gestion du marché : alimenter en prix en continu, ajuster la marge (limite de levier), suspendre le marché si nécessaire

Une fois le marché lancé, le staking est bloqué 30 jours avant de pouvoir demander le déblocage. Cela signifie que toute gestion inadéquate peut entraîner une sanction par vote des validateurs — mais avant cela, le Builder doit d’abord détecter l’existence d’un problème.

Mécanisme de tarification à trois niveaux : comment évaluer la santé du prix de l’oracle

Le point le plus critique, et aussi celui où le risque apparaît le plus facilement dans HIP-3, concerne le mécanisme d’alimentation en prix. Le Builder doit comprendre les trois entrées de prix de l’interface setOracle :

oraclePx (obligatoire) : calculé par le relayer du Builder, servant d’ancre pour le coût du financement.
markPx (optionnel) : 0 à 2 groupes de prix externes soumis par le Builder, servant de valeur candidate pour le prix de marché (mark price).
externalPerpPx (obligatoire) : médiane pondérée provenant du perp CEX, pour éviter que le mark price ne s’écarte brutalement.

Le prix final du mark n’est pas directement celui alimenté par l’oracle, mais la médiane entre le prix médian du carnet local (médiane des meilleures offres/bids/dernière transaction) et le markPx. Qu’est-ce que cela implique ?

Cela signifie que le calcul du prix comporte plusieurs points de défaillance :

• Si le relayer est hors ligne ou victime d’un DDoS, oraclePx ne sera pas mis à jour
• Si l’algorithme de calcul de markPx est défectueux, cela peut entraîner des arbitrages malveillants
• Si le carnet local est peu profond, la médiane peut déformer le prix

Les contraintes sur setOracle semblent strictes :

• Fréquence de mise à jour : intervalle ≥ 2,5 secondes entre deux appels, sinon retour automatique au prix local après 10 secondes
• Limites de fluctuation : markPx ne peut varier de plus de ±1% à chaque mise à jour, et tous les prix sont plafonnés à 10x la valeur d’ouverture du jour

Mais ces contraintes offrent une protection limitée pour des actifs non négociés 7×24 (ex. actions).

Risques liés aux actifs non 7×24 : pièges en période de fermeture

Pour des actifs comme le BTC, qui se négocient 7×24, le Builder peut s’appuyer sur des flux de prix continus provenant d’exchanges centralisés/décentralisés. Mais pour des actifs comme les actions, comment évaluer le prix pendant la fermeture ?

Actuellement, la méthode consiste à : se baser sur le dernier prix de clôture + une mécanique de tarification spécifique basée sur la pression du carnet interne. Concrètement, le mark price est limité à ±10% du dernier prix de clôture (si levier=10).

Ce mécanisme pose problème : lorsque le marché externe manque de liquidité, la profondeur du carnet interne est très faible. En cas d’ordres importants, cela peut provoquer des fluctuations artificielles, surtout si la position est majoritairement longue.

Le 14 décembre 2025, le marché XYZ100-USDC de trade.xyz (contrepartie du NASDAQ100) a été manipulé : un attaquant a créé 398 positions short (environ 10M USDC), en abaissant artificiellement le prix, ce qui a entraîné la liquidation massive de positions longues en peu de temps, avec environ 13M USDC de positions longues forcées.

La racine du problème :

• absence de prix de référence externe en période de fermeture
• profondeur interne insuffisante pour supporter la découverte de prix hors limites
• la liquidation amplifie la chute du prix

Risque lié à l’oracle : comment repérer la menace de centralisation et le décalage

Le serveur relayer déployé par le Builder comporte un risque centralisé intrinsèque. La fuite de clé privée, une attaque DDoS ou une erreur algorithmique peuvent interrompre ou manipuler la mise à jour des prix.

Les quatre signaux clés pour détecter ce risque :

1. Retard ou interruption de l’alimentation en prix

   • Surveillance : timestamp du dernier setOracle observable sur la chaîne
   • Seuil d’alerte : si >10 secondes sans mise à jour, le système revient automatiquement au prix local, augmentant le risque de déconnexion
   • Réponse : basculer vers un relayer de secours, alerter sur la santé du système

2. Décalage de prix (déconnexion)

   • Indicateurs :
     • écart entre oraclePx et le médian du perp CEX
     • différence entre markPx et oraclePx
     • divergence entre carnet local et marché externe
   • Méthode de détection : si ≥2 indicateurs dépassent leurs seuils, considérer comme déconnexion
   • Actions : réduire progressivement le levier max, activer un mécanisme de clamp plus strict

3. Saut de prix à l’ouverture pour actifs non 7×24

   • Surveillance : écart entre prix interne et prix d’ouverture anticipé
   • Sources de référence : Blue Ocean ATS (marché après-clôture) ou cotations CFD du week-end
   • Alerte : si risque de saut >5%, prévenir en avance

4. Fausse liquidité

   • Surveillance : profondeur du carnet et ratio d’absorption (impact_ratio)
   • Signes : profondeur qui chute rapidement, spread qui s’élargit, impact_ratio en hausse
   • Actions : réduire l’OI, limiter l’ajout de nouvelles positions

Pièges de configuration : risques que le Builder sous-estime

Beaucoup pensent qu’en fixant des paramètres, tout est réglé. En réalité, l’ajustement dynamique des paramètres est la partie la plus difficile.

Risques liés à la configuration :

1. Leverage excessif Pour un marché peu liquide, un levier trop élevé augmente la probabilité de déclenchement de l’ADL (auto-dérégulation). Lorsqu’un grand nombre de positions s’accumulent, toute fluctuation peut entraîner une cascade de liquidations.

2. Ajustements brusques de la marge Changer la marge de maintien du jour au lendemain revient à modifier la sécurité de tous les comptes instantanément. Cela peut provoquer des liquidations massives. Ces opérations doivent être annoncées à l’avance et faites par étapes.

3. Abus de haltTrading Le Builder peut appeler haltTrading pour suspendre le marché, annuler toutes les ordres, et régler au mark price. Mais si mal utilisé, cela peut profiter à un attaquant : en réglant au mark price, il peut verrouiller ses gains, surtout si le carnet est peu profond.

4. Mode cross-margin (risque futur) Actuellement, HIP-3 ne supporte que le marge à position unique. Si le mode cross-margin est introduit, le risque de marché peu liquide se transmettra à des marchés plus liquides. En attendant une solution mature, le Builder ne doit pas s’y aventurer.

Système complet de surveillance des risques : de la tarification à la position

Puisque le risque est partout, le Builder doit mettre en place un système de surveillance multi-niveaux, en temps réel.

Surveillance des prix

Niveau 1 (alerte de base) :

• Indicateur : intervalle entre setOracle > 5s
• Action : vérifier la santé du relayer, basculer vers un relais de secours
• Alerte : tous les relayers, avec détails

Niveau 2 (déconnexion) :

• Indicateur : écart oracle-CEX > 2% et persistant > 5s
• Action : réduire le max leverage via setOpenInterestCaps
• Suivi : diminuer progressivement le max leverage dans margin table

Niveau 3 (écart prolongé) :

• Indicateur : déconnexion > 30s
• Action : activer le mécanisme de clamp pour limiter la volatilité
• Ultime décision : le Builder peut appeler haltTrading pour arrêter le marché

Surveillance du carnet

Signaux de dégradation de la liquidité :

• Indicateur : profondeur réelle dans un intervalle de ±2% (depth_band)
• Alerte : baisse simultanée de depth_band, élargissement du spread, impact_ratio en hausse
• Détection : si ces trois indicateurs se produisent, marché en crise
• Actions : réduire l’OI, interdire l’ajout de nouvelles positions

Détection de fausses ordres :

• Signaux : profondeur qui monte rapidement puis disparaît
• Actions : réduire l’OI, voire arrêter le marché si prix déraille

Surveillance des positions

L’objectif n’est pas de prévoir le prix, mais de détecter si le marché est passé d’un mode “trading” à un mode “holding”.

Signaux d’OI excessif :

• Calcul : OI_notional / volume sur 24h
• Détection : si ce ratio augmente rapidement, risque de volatilité extrême
• Actions : alerter, réduire le levier

Signaux de majorité en profit ou perte :

• Indicateurs : prix d’ouverture moyen, taille de position, ratio P&L
• Alerte : si la majorité est en profit >20%, risque de cascade de liquidations
• Actions : réduire le levier en avance

Vérification de l’oracle : rendre la mise à jour vérifiable et auditable

La surveillance ne suffit pas. Le Builder doit rendre le processus d’alimentation en prix “vérifiable”.

Établir une preuve de prix :

1. Publication des algorithmes et sources

   • Décrire la logique de setOracle, les paramètres
   • Lister toutes les sources de données et leur poids
   • Fréquence de mise à jour et limites de volatilité

2. Génération de preuves hors chaîne

   • Produire une preuve (Proof) pour chaque setOracle, contenant :
     • Entrées : réponses des sources, horodatage
     • Calculs intermédiaires
     • Résultat final (oracle price)
   • Signer et hasher la preuve (proofHash)

3. Publication périodique de MerkleRoot

   • Rassembler tous les proofHash dans un Merkle tree
   • Publier la racine (MerkleRoot) sur la chaîne périodiquement (heure/jour)
   • Permettre à tout utilisateur de vérifier la validité d’un prix

4. Outils de vérification open source

   • Vérification automatique par l’utilisateur à partir du tx ou du timestamp
   • Vérification de la signature, du MerkleRoot, des horodatages
   • Recalcul du prix oracle à partir des données

Ce système permet, même si le relayer est compromis, à l’utilisateur de détecter une anomalie et de fournir des preuves pour la responsabilité du Builder.

Isolation des risques : stratégies adaptées à chaque actif

Les risques diffèrent selon le type d’actif. La surveillance doit s’adapter.

Actifs 7×24 (BTC, ETH) :

• Avantages : flux de prix externes continus
• Surveillance : stabilité du relayer, déviation oracle-CEX
• Seuils : déviation >3% pour alerter

Actifs non 7×24 (actions) :

• Inconvénients : absence de prix en dehors des heures
• Surveillance : détection de gaps à l’ouverture, volatilité artificielle
• Seuils : déviation >1%
• Sources : Blue Ocean ATS, cotations CFD
• Précautions : réduire le levier avant les heures critiques

Liquidation et ADL : comprendre la chaîne de risque en cas d’extrême

La liquidation n’est pas un risque en soi, mais la réaction en chaîne qu’elle peut provoquer.

HIP-3 reprend la logique de HyperCore : en cas de valeur nette insuffisante, déclenchement de la liquidation. La liquidation se fait d’abord via le carnet, mais si la profondeur est insuffisante, le prix de liquidation peut s’écarter du mark price, créant un “écart de liquidation”.

Ce décalage peut activer le mécanisme d’ADL (auto-dérégulation) :

• Sélectionner des positions gagnantes pour réduire la position
• Utiliser le mark price précédent pour réduire la position
• Compenser la perte avec la contrepartie

Mais l’ADL indique que le marché est en situation extrême. Son déclenchement doit être surveillé via :

• concentration des positions
• volume OI
• profondeur du carnet

Il faut anticiper en réduisant le levier et en limitant l’ouverture de nouvelles positions.

Vers une responsabilité vérifiable : standardisation, preuve et supervision

L’innovation majeure de HIP-3 est de “décentraliser le pouvoir tout en inscrivant la responsabilité dans le protocole”.

Les vérificateurs peuvent voter pour sanctionner un Builder en cas de mauvaise gestion, avec des pénalités proportionnelles :

• 100% de la mise en jeu en cas de défaillance grave ou de longue indisponibilité
• 50% en cas de panne courte
• 20% en cas de dégradation de performance

Les fonds saisis sont brûlés, pas redistribués. Cela crée une forte incitation à une gestion responsable.

Pour que cela soit efficace, il faut que :

1. Les risques soient observables : systèmes de monitoring complets
2. La responsabilité soit traçable : preuves vérifiables de la mise à jour des prix
3. La décision soit exécutable : mécanisme de vote transparent et efficace

En résumé : passer de “déployer” à “gérer stablement”

HIP-3 remplace l’approbation par une interface ouverte, et le volume de marchés déployés le prouve. Mais cette ouverture a un coût : la gestion des risques, autrefois assurée par la plateforme, revient désormais au Builder.

Le Builder doit maîtriser non seulement “comment déployer un marché”, mais surtout “comment détecter et réagir aux risques”.

Il faut :

1. Comprendre les sources de risques à partir de l’architecture, de la tarification, des paramètres, de la liquidité
2. Mettre en place un système de surveillance en temps réel
3. Rendre la mise à jour de l’oracle vérifiable et traçable
4. Préparer des plans d’urgence : baisse de levier, limitation d’OI, arrêt du marché

La sécurité à long terme dépend de la capacité du Builder à déployer une solution d’oracle fiable, à ajuster raisonnablement ses paramètres, et à surveiller en continu l’état du marché.

HIP-3 ne vise pas à rendre le lancement plus libre, mais à le rendre plus standardisé — déployable, exploitable, responsable. La réussite de cette standardisation dépend en fin de compte de la compréhension approfondie et de l’application rigoureuse des risques par le Builder.

Si vous travaillez sur la conception de normes d’accès au marché, la définition de modèles paramétriques, la construction de systèmes d’alerte ou la réalisation d’audits de sécurité, BlockSec et d’autres équipes spécialisées peuvent vous accompagner dans la consultation technique et l’audit approfondi.