Quicknode

12 juin 2026 — 10 min de lecture

On June 9, 2026, Hyperliquid's core team announced that several public WebSocket API feeds will push data less frequently after the next network upgrade. On June 11, 2026, the team adjusted the rollout based on user feedback: webData2 conservera son intervalle de diffusion actuel de 5 secondes pendant encore une mise à niveau du réseau, selon la norme l2Book passera à 20 niveaux toutes les 2 secondes, avant de passer ensuite à 5 secondes, puis à un nouveau fastAssetCtxs Le flux WebSocket conservera les écarts de prix de référence toutes les 5 secondes pour les interfaces.

Les flux concernés comprennent toujours la profondeur du carnet d'ordres, les cours moyens, le contexte des actifs, le contexte de tous les actifs des DEX, ainsi que webData2, dont la migration vers webData3.

Pour les tableaux de bord, les outils de suivi de portefeuille et les interfaces destinées aux utilisateurs, ces nouveaux intervalles peuvent s'avérer acceptables. En revanche, pour les systèmes de trading automatisés, ils modifient le modèle de données. Une stratégie qui émet des cotations, calcule des volumes, annule ou achemine des ordres à partir d'instantanés WebSocket publics nécessite désormais un plan de données différent.

Hyperliquid's team was direct about the expected path for this workload:

Cet article explique quels sont les changements, en quoi ils sont importants pour les bots, et comment migrer Hyperliquid sensibles à la latence vers une infrastructure gérée avec Quicknode.

Quels sont les changements apportés à l'API WebSocket publique Hyperliquid?

Le l2Book Le changement est l'élément le plus important pour les stratégies automatisées. Sans fast : true, l'API publique renverra 20 niveaux toutes les 2 secondes après la prochaine mise à jour, un passage à 5 secondes étant prévu ultérieurement. Avec fast : true, elle renvoie 5 niveaux toutes les 0,5 seconde. Aucune de ces deux options ne fournit un carnet de commandes complet en temps réel pour les stratégies qui dépendent de la profondeur du marché, du comportement des files d'attente ou des variations rapides des écarts.

Il ne s'agit ni d'une panne ni d'un changement radical au sens habituel du terme. Il s'agit d'une distinction entre l'infrastructure publique partagée et le profil de données requis par les systèmes de trading automatisés.

Pourquoi la lenteur des mises à jour WebSocket est-elle importante pour les robots de trading ?

Pour un bot, un livre périmé n'est pas un désagrément. Il le considère comme une entrée erronée.

Les teneurs de marché ont besoin d'une profondeur de marché actualisée pour établir leurs cotations en fonction des stocks en temps réel et des écarts de prix. Les robots d'exécution ont besoin des cours moyens actuels et de la pression sur le carnet d'ordres pour dimensionner les ordres. Les stratégies de liquidation, d'arbitrage et de base nécessitent que l'écart entre le dernier instantané et le bloc actuel soit aussi faible que possible.

Lorsqu'un carnet de commandes est mis à jour toutes les 2 ou 5 secondes, la stratégie n'est pas simplement en retard de cet intervalle. Elle s'appuie sur une situation de marché différente. Cela a des répercussions sur :

• Délais de soumission des devis et d'annulation

• Calculs du spread, du glissement et de la sélection adverse

• Détermination de la taille des positions et contrôles des risques

• Contrôleurs de liquidation et de financement qui déclenchent des ordres

• Backtests reposant sur un flux de données similaire à celui de l'environnement de production

L'API publique peut tout de même s'avérer utile pour l'interface utilisateur, la surveillance passive et l'affichage de données non critiques. Les logiques de trading qui dépendent de la profondeur du marché en temps réel nécessitent un flux spécialement conçu à cet effet, qu'il s'agisse d'un abonnement WebSocket ou d'un gRPC .

Que Hyperliquid aux traders automatisés ?

Hyperliquid recommande d'exploiter un nœud non validateur pour bénéficier d'un plus grand nombre de niveaux ou streams de mise à jour en temps réel. Cela permet aux traders automatisés d'accéder directement au profil de données dont ils ont besoin, mais cela implique également des tâches liées à l'infrastructure : exploitation des nœuds, mises à jour, surveillance, gestion des reconnexions, planification des capacités et intégration des clients.

Quicknode une plateforme de développement blockchain qui fournit Hyperliquid gérée sur HyperCore et HyperEVM via un endpoint unique. Les protocoles WebSocket et gRPC tous deux pris en charge sur chaqueendpoint Hyperliquid . Pour les équipes concernées par cette modification de l’API publique, la fonctionnalité la plus pertinente est gRPC d’HyperCore. Non pas parce que WebSocket n’est pas l’outil adéquat, mais parce que nous constatons que WebSocket présente des faiblesses à grande échelle : tempêtes de reconnexions, fragilité des flux pilotés par paquets et surcharge liée à la charge utile sur les abonnements multi-marchés.

Quicknode Hyperliquid gRPC pour l'ensemble des streams de données HyperCore, avec une transmission bidirectionnelle, une latence inférieure à la milliseconde pour les données de marché et une compression zstd native permettant de réduire la bande passante d'environ 70 %. Accès à /hypercore JSON-RPC, /hypercore WebSocket et HyperCore gRPC le forfait « Build » ou un forfait supérieur.

Commencez par consulter Hyperliquid Quicknode Hyperliquid et la référence de l'APIgRPC Hyperliquid .

Quels ensembles de données HyperCore les traders automatisés devraient-ils utiliser ?

La différence essentielle ne réside pas seulement dans un endpoint privé. Il s'agit de l'accès aux ensembles de données HyperCore adaptés aux charges de travail liées au trading automatisé.

Hyperliquid Quicknode couvrent les transactions exécutées, les événements liés au cycle de vie des ordres, les mises à jour du carnet d'ordres, les données d'exécution TWAP, les événements liés aux comptes et aux soldes, les actions d'écriture de HyperCore vers HyperEVM, les blocs bruts, les instantanés du carnet d'ordres L2, les instantanés et les différences du carnet d'ordres L4, ainsi que les transactions testnet .

C'est important, car le choix du flux WebSocket public le plus adapté dépend de la fonction remplie par la stratégie. Un teneur de marché a besoin de données différentes de celles d'un outil de surveillance des liquidations, et un tableau de bord a besoin de données différentes de celles d'un routeur d'ordres.

StreamL2Book pour la profondeur du marché au cours actuel

StreamL2Book fournit à chaque bloc un aperçu complet et agrégé du carnet d'ordres de niveau 2. Chaque message comprend les cours acheteurs et vendeurs actuels par niveau de prix, ainsi que le volume total et le nombre d'ordres à chaque niveau.

Utilisation StreamL2Book lorsque votre stratégie nécessite une profondeur de marché actualisée par niveau de prix sans avoir à constituer un carnet d'ordres local à partir des écarts incrémentiels. Le flux prend en charge une profondeur configurable, avec n_niveaux jusqu'à 100, avec en option un regroupement par tranches de prix pour une agrégation plus large.

Par rapport à un établissement public l2Book un flux qui transmet 5 niveaux toutes les 0,5 seconde ou 20 niveaux toutes les 2 secondes, avant de passer ultérieurement à un intervalle de 5 secondes ; cette solution est la plus adaptée à la tenue de marché, à la surveillance des écarts, à l'exécution tenant compte de la profondeur du marché et aux alertes basées sur le carnet d'ordres.

StreamL4Book pour l'état au niveau de chaque commande

StreamL4Book fournit le carnet d'ordres avec un niveau de détail par ordre individuel. Lors de l'abonnement, il envoie un instantané complet des cours acheteurs et vendeurs en attente. Par la suite, il envoie des différences par bloc.

Utilisation StreamL4Book lorsque les niveaux de prix agrégés ne suffisent pas. On peut citer, à titre d'exemple, l'analyse des files d'attente, les études de liquidité au niveau des ordres, la recherche sur la microstructure du marché, ainsi que les systèmes qui doivent suivre les ordres en attente individuels plutôt que de se limiter aux totaux au niveau des prix.

StreamL2Book et StreamL4Book fonctionnent gRPC. Elles ne sont pas disponibles via WebSocket ou JSON-RPC.

Comment les équipes doivent-elles adapter Hyperliquid à ce nouveau rythme ?

Vous n'avez pas besoin de déplacer toutes Hyperliquid en même temps. Commencez par séparer les données d'entrée utilisées pour la prise de décision de celles destinées à l'affichage.

1. Classez chaque abonnement.

   Les flux qui déclenchent des ordres, des annulations, le dimensionnement ou la mise en place de limites de risque doivent être transférés en priorité. Les flux qui alimentent les tableaux de bord, les graphiques visibles par les utilisateurs ou la surveillance passive peuvent souvent rester sur WebSocket.

2. Remplacer « public » l2Book pour la prise de décisions de trading.

   Utilisation StreamL2Book si votre stratégie nécessite une profondeur de marché, des données actualisées en temps réel sur les cours les plus élevés ou des calculs de spread. Utilisez StreamL4Book s'il a besoin d'informations sur l'état d'une commande spécifique ou de détails au niveau de la file d'attente.

3. Concevoir le comportement de reconnexion en s'appuyant sur le modèle de flux.

   Avec StreamL2Book, chaque message correspond à un instantané L2 complet pour ce bloc ; votre consommateur peut ainsi remplacer l'état local du niveau des prix à chaque mise à jour. Avec StreamL4Book, initialiser à partir de l'instantané, appliquer les modifications et réinitialiser à partir d'un nouvel instantané lors de la reconnexion.

4. Veillez à séparer l'exécution, l'analyse et les alertes.

   Un modèle de production courant consiste à utiliser gRPC les données de marché en temps réel de la stratégie, l'API ou SDK Hyperliquid SDK les ordres signés localement, JSON-RPC pour les lectures par lots et historiques, Streams Webhooks les pipelines d'événements asynchrones, et SQL Explorer pour la recherche ou les analyses.

5. Faites fonctionner les deux alimentations pendant la transition.

   Avant la mise à niveau du réseau, exécutez votre consommateur WebSocket public existant en parallèle du nouveau gRPC . Comparez l'ancienneté du carnet d'ordres, le spread observé, les délais de mise à jour, la qualité d'exécution et tout indicateur de risque spécifique à votre stratégie. Cela vous permettra de disposer d'un plan de basculement concret, plutôt que de devoir procéder à endpoint à la dernière minute.

Quels autres Quicknode prennent en charge les systèmes Hyperliquid ?

gRPC être la première solution à envisager pour les données de marché HyperCore sensibles à la latence, mais il n'est pas nécessaire qu'il prenne en charge toutes les charges de travail.

• WebSocket est disponible sur tousendpoint Hyperliquid . Il continue d'alimenter les tableaux de bord dans le navigateur, les vues de portefeuille, les interfaces de surveillance et toute activité de trading dont le profil de mise à jour correspond à la stratégie.

• JSON-RPC prend en charge le « backfill », les lectures de blocs par lots, l'état du portefeuille, l'état de la chambre de compensation et l'interaction avec les contrats HyperEVM.

• Streams et Webhooks peuvent transmettre des événements filtrés vers les systèmes backend et les pipelines d'alerte.

• SQL Explorer permet d'interroger plus de 500 milliards de lignes indexées de Hyperliquid et de rendre ces requêtes accessibles sous forme de points de terminaison REST programmables.

La page Hyperliquid Quicknode mentionne également un SLA garantissant une disponibilité de 99,99 %, plus de 6 milliards de requêtes Hyperliquid par mois et plus de 500 milliards de lignes de données consultables. Ces chiffres sont importants lorsque la charge de travail ne relève pas d'une simple démonstration, mais d'un système de trading fonctionnant en continu.

Comment se lancer avec Hyperliquid gRPC?

1. Créez un Quicknode sur quicknode.com/signup.

2. Créez unendpoint Hyperliquid endpoint le Quicknode . Un seul endpoint un accès géré à la fois à HyperCore et à HyperEVM.

3. Passez en revue les Hyperliquid disponibles et associez chaque donnée d'entrée de la stratégie au flux correspondant.

4. Consultez la documentation de l'APIgRPC Hyperliquid pour connecter votre consommateur.

5. Choisissez le flux qui correspond à votre stratégie : StreamL2Book pour la profondeur du niveau des prix agrégés, StreamL4Book pour les informations spécifiques à chaque ordre, ou les ensembles de données standard relatifs aux transactions, aux ordres, aux événements et aux mises à jour du carnet d'ordres.

6. Clonez le dépôt gRPC HyperCore gRPC pour tester les abonnements en JavaScript, Python, Go ou Rust.

7. Consultez les exemples pratiques disponibles dans la bibliothèque Hyperliquid et dans la bibliothèque d'applications d'exemple.

La mise à jour de l'API publique Hyperliquid indique que le réseau oriente les points de terminaison partagés vers des modèles d'accès plus légers et plus étendus. Les traders automatisés ont besoin d'une approche différente : une profondeur de marché actualisée, davantage de niveaux, streams en temps réel et une infrastructure conçue pour des systèmes fonctionnant en continu.

Quicknode une solution gérée pour cette configuration, sans que vous ayez à gérer vous-même l'infrastructure Node.js.

Commencez par le Quicknode Hyperliquid .