Hyperliquid Änderungen an Foundation WebSocket: Was das für Sie bedeutet

Quicknode

12. Juni 2026 – 10 Minuten Lesezeit

Teilen

Als bevorzugte Quelle hinzufügen

Am 9. Juni 2026 gab „ equipe “, ein Kernmitglied von „ Hyperliquid “, bekannt, dass mehrere öffentliche WebSocket-API-Feeds nach dem nächsten Netzwerk-Upgrade Daten seltener übertragen werden. Am 11. Juni 2026 passte „ equipe “ die Einführung auf Grundlage von Nutzer-Feedback an: webData2 wird sein derzeitiges Push-Intervall von 5 Sekunden noch für ein weiteres Netzwerk-Upgrade beibehalten, Standard l2Book wird alle 2 Sekunden auf 20 Stufen angehoben, bevor später auf 5 Sekunden umgestellt wird, und eine neue fastAssetCtxs Der WebSocket-Feed speichert die Preisunterschiede der Schnittstellen im 5-Sekunden-Takt.

Zu den betroffenen Feeds gehören weiterhin die Tiefe des Orderbuchs, die Mittelkurse, der Vermögenskonttext, der gesamte DEX-Vermögenskonttext sowie webData2, das voraussichtlich noch auf webData3.

Für Dashboards, Portfolio-Monitore und benutzerorientierte Ansichten mögen die neuen Intervalle akzeptabel sein. Für automatisierte Handelssysteme ändern sie jedoch das Datenmodell. Eine Strategie, die Aufträge anhand öffentlicher WebSocket-Snapshots notiert, in der richtigen Größe ausführt, storniert oder weiterleitet, benötigt nun eine andere Datenebene.

Hyperliquid equipe , äußerte sich ganz offen über den erwarteten Verlauf dieser Arbeitslast:

In diesem Beitrag wird erläutert, was sich ändert, warum dies für Bots von Bedeutung ist und wie man latenzempfindliche „ Hyperliquid “-Workloads auf eine verwaltete Infrastruktur mit Quicknode.

Was hat sich an der öffentlichen WebSocket-API von „ Hyperliquid “ geändert?

Die l2Book Veränderungen sind für automatisierte Strategien von entscheidender Bedeutung. Ohne fast: true… gibt die öffentliche API nach dem nächsten Upgrade alle 2 Sekunden 20 Stufen zurück, wobei später eine Umstellung auf 5 Sekunden erwartet wird. Mit fast: true, gibt es alle 0,5 Sekunden 5 Preisstufen zurück. Keine der beiden Optionen bietet ein vollständiges Echtzeit-Orderbuch für Strategien, die von der Ordertiefe, dem Verhalten der Warteschlange oder schnellen Spread-Änderungen abhängen.

Es handelt sich hierbei weder um einen Ausfall noch um eine grundlegende Änderung im üblichen Sinne. Es ist eine Abgrenzung zwischen der gemeinsam genutzten öffentlichen Infrastruktur und dem Datenprofil, das automatisierte Handelssysteme benötigen.

Warum sind langsamere WebSocket-Aktualisierungen für Trading-Bots von Bedeutung?

Ein Bot empfindet ein veraltetes Buch nicht als Unannehmlichkeit. Er empfindet es als fehlerhafte Eingabe.

Market Maker benötigen aktuelle Marktdaten zur Ordertiefe, um Kurse auf Basis des aktuellen Bestands und des Spreads zu notieren. Ausführungs-Bots benötigen aktuelle Mittelkurse und Informationen zum Druck im Orderbuch, um die Ordergröße zu bestimmen. Für Liquidations-, Arbitrage- und Basis-Strategien ist es wichtig, dass die Differenz zwischen dem letzten Snapshot und dem aktuellen Block so gering wie möglich ist.

Wenn ein Buch in Intervallen von 2 oder 5 Sekunden aktualisiert wird, hinkt die Strategie nicht nur um dieses Intervall hinterher. Sie reagiert auf eine andere Marktlage. Das wirkt sich aus auf:

• Zeitpunkt der Angebotserstellung und des Rücktritts

• Berechnungen zu Spread, Slippage und adverser Selektion

• Positionsgrößenbestimmung und Risikoprüfungen

• Liquidations- und Finanzierungsüberwachungsmechanismen, die Aufträge auslösen

• Backtests, die von einem Datenfeed ausgehen, der dem im Produktivbetrieb ähnelt

Die öffentliche API kann nach wie vor für Benutzeroberflächen, passive Überwachung und nicht kritische Anzeigedaten sinnvoll sein. Handelslogik, die auf aktuelle Kursdaten angewiesen ist, benötigt einen speziell dafür konzipierten Datenfeed, sei es ein WebSocket-Abonnement oder ein „ gRPC “-Stream.

Was empfiehlt „ Hyperliquid “ für automatisierte Trader?

HyperliquidDie Empfehlung lautet, einen nicht validierenden Knoten für mehr Ebenen oder Echtzeit-Updates zu betreiben streams. Dadurch erhalten automatisierte Händler direkten Zugriff auf das von ihnen benötigte Datenprofil, was jedoch auch einen gewissen Aufwand für die Infrastruktur mit sich bringt: Betrieb der Knoten, Upgrades, Überwachung, Behandlung von Verbindungsabbrüchen, Kapazitätsplanung und Kundenintegration.

Quicknode ist eine Blockchain-Entwicklungsplattform, die über eine einzige Schnittstelle endpoint eine verwaltete „ Hyperliquid “-Infrastruktur für HyperCore und HyperEVM bereitstellt. Sowohl WebSocket als auch gRPC werden auf jeder Hyperliquid endpoint unterstützt. Für Teams, die von dieser Änderung der öffentlichen API betroffen sind, ist die Funktion „HyperCore gRPC -Streaming“ am relevantesten . Nicht, weil WebSocket das falsche Werkzeug wäre, sondern weil wir erkennen, wo WebSocket bei skalierten Anwendungen an seine Grenzen stößt: Wiederverbindungsstürme, Anfälligkeit paketgesteuerter Streams und Overhead bei der Nutzlast bei Abonnements für mehrere Märkte.

Quicknode's Hyperliquid Dokumente gRPC -Unterstützung für den gesamten HyperCore-Daten streams-Umfang, mit bidirektionalem Streaming, einer Latenz von unter einer Millisekunde für Marktdaten und nativer zstd-Komprimierung, die die Bandbreite um etwa 70 % reduzieren kann. Zugriff auf /hypercore JSON-RPC, /hypercore Für WebSocket und HyperCore gRPC ist der Build-Tarif oder ein höherer Tarif erforderlich.

Beginnen Sie mit der Dokumentation zu „Quicknode “ (Hyperliquid ) und der Referenz zur Streaming-API unter „Hyperliquid “ (gRPC ).

Welche HyperCore-Datensätze sollten automatisierte Händler verwenden?

Der entscheidende Unterschied besteht nicht nur in einem privaten endpoint. Es ist vielmehr der Zugriff auf HyperCore-Datensätze, die für automatisierte Handelsanwendungen geeignet sind.

QuicknodeDie Datensätze von „Hyperliquid “ umfassen ausgeführte Trades, Ereignisse im Auftragslebenszyklus, Aktualisierungen des Orderbuchs, TWAP-Ausführungsdaten, Konto- und Saldenereignisse, Schreibvorgänge von HyperCore zu HyperEVM, Rohdatenblöcke, L2-Orderbuch-Snapshots, L4-Orderbuch-Snapshots und -Diffs sowie Mempool-Transaktionen von „ testnet “.

Das ist wichtig, weil die Wahl des richtigen Ersatzes für einen öffentlichen WebSocket-Feed davon abhängt, welche Funktion die Strategie erfüllt. Ein Market Maker benötigt andere Daten als ein Liquidationsmonitor, und ein Dashboard benötigt andere Daten als ein Order-Router.

StreamL2Book für die aktuelle Preistiefe

StreamL2Book Liefert bei jedem Block eine vollständige, aggregierte Momentaufnahme des L2-Orderbuchs. Jede Nachricht enthält die aktuellen Kauf- und Verkaufskurse nach Preisstufen sowie das Gesamtvolumen und die Anzahl der Orders auf jeder Stufe.

Verwendung StreamL2Book wenn Ihre Strategie aktuelle Markttiefe nach Kursniveau benötigt, ohne ein lokales Orderbuch aus inkrementellen Differenzen aufzubauen. Der Stream unterstützt konfigurierbare Markttiefe mit n_levels bis zu 100, plus optionale Preisgruppierung für eine umfassendere Aggregation.

Im Vergleich zu einer öffentlichen l2Book Ein Feed, der alle 0,5 Sekunden 5 Levels oder alle 2 Sekunden 20 Levels übermittelt, bevor später auf 5 Sekunden umgestellt wird – dies ist die optimierte Lösung für Market Making, Spread-Überwachung, tiefengestützte Ausführung und orderbuchgesteuerte Benachrichtigungen.

StreamL4Book für den Status auf Einzelbestellungsebene

StreamL4Book Liefert das Orderbuch auf der Ebene einzelner Orders. Bei der Anmeldung sendet es eine vollständige Momentaufnahme der aktuellen Geld- und Briefkurse. Danach sendet es Differenzdaten pro Block.

Verwendung StreamL4Book wenn aggregierte Kursniveaus nicht ausreichen. Beispiele hierfür sind die Warteschlangenanalyse, Liquiditätsanalysen auf Order-Ebene, Untersuchungen zur Marktmikrostruktur sowie Systeme, die einzelne ausstehende Orders nachverfolgen müssen und sich nicht nur auf aggregierte Kurswerte beschränken.

StreamL2Book und StreamL4Book sind ausschließlich über „ gRPC “ verfügbar. Sie sind nicht über WebSocket oder JSON-RPC verfügbar.

Wie sollten Teams die „ Hyperliquid “-Bots an den neuen Rhythmus anpassen?

Sie müssen nicht jede Hyperliquid -Integration auf einmal umstellen. Beginnen Sie damit, die Eingaben für Entscheidungen von den Eingaben für die Anzeige zu trennen.

1. Ordnen Sie jedes Abonnement einer Kategorie zu.

   Feeds, die Aufträge, Stornierungen, Größenanpassungen oder Risikolimits auslösen, sollten vorrangig übertragen werden. Feeds, die Dashboards, für Benutzer sichtbare Diagramme oder die passive Überwachung versorgen, können oft weiterhin über WebSocket übertragen werden.

2. „public“ ersetzen l2Book für Handelsentscheidungen.

   Verwendung StreamL2Book wenn Ihre Strategie eine hohe Kurs-Tiefe, aktuelle Top-of-Book-Daten oder Spread-Berechnungen erfordert. Verwenden Sie StreamL4Book falls Einzelinformationen zum Auftragsstatus oder Details auf Warteschlangenebene benötigt werden.

3. Das Verhalten bei der Wiederherstellung der Verbindung sollte auf dem Stream-Modell basieren.

   Mit StreamL2Book, ist jede Nachricht ein vollständiger L2-Snapshot für diesen Block, sodass Ihr Consumer bei jeder Aktualisierung den lokalen Preisstand ersetzen kann. Mit StreamL4Book, aus dem Snapshot initialisieren, Diffs anwenden und bei erneuter Verbindung aus einem neuen Snapshot zurücksetzen.

4. Halten Sie Ausführung, Analyse und Warnmeldungen voneinander getrennt.

   Ein gängiges Produktionsmuster ist gRPC für die Live-Marktdaten der Strategie, die Handels-API unter Hyperliquid oder SDK für lokal signierte Orders, JSON-RPC für Batch- und historische Abfragen, Streams oder Webhooks für asynchrone Ereignis-Pipelines sowie SQL Explorer für Recherchen oder Untersuchungen.

5. Lassen Sie während der Übergangsphase beide Zuführungen laufen.

   Führen Sie vor der Netzwerkaktualisierung Ihren bestehenden öffentlichen WebSocket-Consumer parallel zum neuen „ gRPC “-Consumer aus. Vergleichen Sie das Alter des Orderbuchs, den beobachteten Spread, Aktualisierungslücken, die Ausführungsqualität sowie alle strategiespezifischen Risikokennzahlen. So erhalten Sie einen konkreten Plan für den Umstieg, anstatt in letzter Minute auf „ endpoint “ umsteigen zu müssen.

Welche anderen „ Quicknode “-Tools unterstützen „ Hyperliquid “-Handelssysteme?

gRPC sollte die erste Anlaufstelle für latenzempfindliche HyperCore-Marktdaten sein, muss aber nicht jede Arbeitslast bewältigen können.

• WebSocket ist auf jedem Hyperliquid endpoint verfügbar. Es bildet nach wie vor die Grundlage für Browser-Dashboards, Portfolioansichten, Überwachungsoberflächen und alle Handelsanwendungen, bei denen das Aktualisierungsprofil zur jeweiligen Strategie passt.

• JSON-RPC unterstützt Backfill, das Lesen ganzer Blöcke im Batch-Verfahren, den Portfoliostatus, den Clearinghausstatus sowie die Interaktion mit HyperEVM-Kontrakten.

• Streams und Webhooks kann gefilterte Ereignisse an Backend-Systeme und Alarmierungs-Pipelines weiterleiten.

• Der SQL Explorer kann über 500 Milliarden indizierte Zeilen von „ Hyperliquid “-Daten abfragen und Abfragen als programmierbare REST-Endpunkte bereitstellen.

QuicknodeAuf der Seite der „ Hyperliquid “-Kette werden außerdem eine SLA-Verfügbarkeit von 99,99 %, mehr als 6 Milliarden API-Anfragen an „ Hyperliquid “ pro Monat und mehr als 500 Milliarden Zeilen abfragbarer Daten aufgeführt. Diese Zahlen sind von Bedeutung, wenn es sich bei der Arbeitslast nicht um eine Demo, sondern um ein rund um die Uhr verfügbares Handelssystem handelt.

Wie fängt man mit „ Hyperliquid “ an?gRPC?

1. Erstellen Sie ein „ Quicknode “-Konto unter quicknode.com/signup.

2. Erstellen Sie über das Dashboard unter Quicknode eine „ Hyperliquid “ (endpoint ). Eine „ endpoint “ ermöglicht den verwalteten Zugriff auf HyperCore und HyperEVM.

3. Sehen Sie sich die verfügbaren Datensätze unter Hyperliquid an und ordnen Sie jede Strategie-Eingabe dem entsprechenden Datenstrom zu.

4. Nutzen Sie die Dokumentation zur Streaming-API unterHyperliquid gRPC , um Ihren Client anzubinden.

5. Wählen Sie den Stream, der zu Ihrer Strategie passt: StreamL2Book für die aggregierte Preisniveau-Tiefe, StreamL4Book für den Status einzelner Orders oder die Standarddatensätze für Geschäfte, Orders, Ereignisse und Aktualisierungen des Orderbuchs.

6. Klonen Sie das HyperCore-Repository „ gRPC “ mit Beispielen, um Abonnements in JavaScript, Python, Go oder Rust zu testen.

7. Sehen Sie sich die Anwendungsbeispiele in der Handbuchbibliothek „ Hyperliquid “ und in der Beispiel-App-Bibliothek an.

HyperliquidDie Aktualisierung der öffentlichen API ist ein Zeichen dafür, dass das Netzwerk gemeinsame Endpunkte in Richtung schlankerer und breiterer Zugriffsmuster verlagert. Automatisierte Händler benötigen einen anderen Ansatz: aktuelle Markt streams, mehr Ebenen, Echtzeit- und eine Infrastruktur, die für ständig aktive Systeme ausgelegt ist.

Quicknode bietet einen verwalteten Zugriff auf diese Konfiguration, ohne dass Sie die Node-Infrastruktur selbst betreiben müssen.

Beginnen Sie mit den Quicknode Hyperliquid Dokumentation.