Modes de défaillance
Comportement du système pendant les pannes et les conditions dégradées.
Philosophie de conception
Hypercall maintient la négociation lorsque c'est possible et échoue de manière fermée (fail closed) lorsqu'une donnée de prix ou de marge est manquante. En cas de défaillance :
- La négociation continue lorsque les données requises sont valides
- Les composants défaillants sont isolés
- Les utilisateurs reçoivent des erreurs explicites plutôt que des données obsolètes ou des prix inventés
Indisponibilité de la L1
Si la L1 de Hyperliquid (HyperCore) devient indisponible :
| Fonction | Comportement |
|---|---|
| Appariement des options | Continue sur le carnet de Hypercall tant que les données de prix et de volatilité restent valides |
| Ordres sur perpétuels | Indisponibles. Les perpétuels s'exécutent sur Hyperliquid. |
| Règlements | Retardés jusqu'à ce que suffisamment d'échantillons d'oracle soient disponibles (voir ci-dessous) |
| Dépôts | Bloqués jusqu'au rétablissement de la L1 |
| Retraits | Bloqués jusqu'au rétablissement de la L1 |
Le rétablissement est automatique dès que la L1 est de nouveau disponible.
Défaillances d'oracle
Oracle de prix
Si l'oracle de prix devient indisponible :
| Impact | Comportement |
|---|---|
| Ordres augmentant le risque | Rejetés dès que le dernier prix spot enregistré date de plus de 30 secondes |
| Ordres réduisant le risque | Acceptés, valorisés au dernier prix enregistré |
| Valorisation pour la marge et la liquidation | Se poursuit au dernier prix enregistré. Aucun prix de substitution n'est produit. |
| Prix de règlement à l'échéance | Jamais tiré du dernier prix enregistré. Voir Oracle indisponible à l'échéance. |
Un flux sain réenregistre un prix inchangé au moins toutes les 10 secondes, de sorte qu'un marché stable ne déclenche pas la limite de 30 secondes. Le rétablissement est automatique au retour de l'oracle.
Oracle d'IV
Si l'oracle d'IV est défaillant :
| Impact | Comportement |
|---|---|
| Nouveaux ordres | Les ordres augmentant le risque sur l'actif sous-jacent concerné sont rejetés |
| Valorisation des options | Aucun prix de repli. Les calculs nécessitant l'IV manquante échouent. |
| Calculs de marge | Échouent de manière fermée plutôt que d'utiliser une volatilité de substitution |
Consultez Oracle de volatilité pour les conditions exactes.
Défaillances de règlement
Oracle indisponible à l'échéance
Les prix de règlement utilisent une fenêtre TWAP de 30 minutes avant l'échéance. Les règles de panne pour la valorisation ci-dessus ne s'appliquent pas au prix de règlement. Si les données d'oracle sont indisponibles :
- Panne partielle : le TWAP n'est calculé que si la fenêtre contient au moins 500 échantillons. Hypercall peut reconstituer une fenêtre courte à partir de l'historique archivé de l'oracle Hyperliquid, avec le même minimum.
- Panne complète : le règlement attend qu'une fenêtre d'au moins 500 échantillons soit disponible. Il ne se fait ni au dernier prix enregistré, ni sur une fenêtre partielle, ni sur un prix de substitution.
Le règlement peut également être retardé sans panne si le TWAP finalisé n'est pas disponible au tick exact de l'échéance. Dans ce cas, l'instrument reste à l'état Expired Pending Price, la négociation reste désactivée et le règlement est retenté automatiquement jusqu'à ce que le prix finalisé existe.
L'algorithme TWAP est conçu pour résister à la manipulation. Consultez Oracles pour plus de détails.
Indisponibilité de l'API
Si l'API Hypercall devient indisponible :
| Composant | Statut |
|---|---|
| Négociation | Indisponible. Les ordres sur options, les annulations et les ordres sur perpétuels passent tous par l'API Hypercall. |
| Positions et soldes | Conservés dans le journal durable du moteur et restaurés au redémarrage |
| Ordres ouverts | Font partie de l'état du moteur et sont restaurés au redémarrage. Vous ne pouvez pas les annuler avant le retour de l'API. |
| Positions sur perpétuels | Restent sur votre compte Hyperliquid |
| Abonnements WebSocket | Déconnectés |
Recommandations
- Implémentez une logique de reconnexion avec backoff exponentiel
- Mettez en cache localement les données critiques
- Vérifiez
GET /healthavant de négocier - Partez du principe que les ordres en attente restent actifs pendant une panne de l'API, et dimensionnez vos cotations en conséquence
Endpoint de santé
| Endpoint | Objectif |
|---|---|
GET /health | Vérification de base de la disponibilité |
GET /ready | Disponibilité complète, dépendances comprises |
Communication lors des incidents
Pendant les incidents, consultez :
- Page de statut : status.hypercall.xyz
- X : @SynapseProtocol
- Telegram : t.me/hypercall_trollbox
- Discord : discord.gg/4rMzuEnKqe