SOC 2 Typ II-zertifiziert · ISO 27001

Am 9. Juni 2026 gab das Kernteam von Hyperliquid bekannt, dass mehrere öffentliche WebSocket-API-Feeds nach dem nächsten Netzwerk-Upgrade Daten weniger häufig übertragen werden. Am 11. Juni 2026 passte das Team 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, dimensioniert, storniert oder weiterleitet, benötigt nun eine andere Datenebene.

Das Team von Hyperliquid äußerte sich ganz offen über den voraussichtlichen Verlauf dieser Arbeitslast:

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

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 Trennlinie 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 ihre 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öße und Risikoprüfungen

• Liquidations- und Finanzierungsindikatoren, die Orders 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?

Hyperliquid empfiehlt, einen nicht validierenden Knoten zu betreiben, um mehr Ebenen oder Echtzeit-Update-Streams zu nutzen. Dies ermöglicht automatisierten Händlern direkten Zugriff auf das von ihnen benötigte Datenprofil, bringt jedoch auch einen gewissen Aufwand für die Infrastruktur mit sich: Knotenbetrieb, Upgrades, Überwachung, Behandlung von Verbindungsabbrüchen, Kapazitätsplanung und Kundenintegration.

Quicknode ist eine Blockchain-Entwicklungsplattform, die über einen einzigen Endpunkt eine verwaltete Hyperliquid-Infrastruktur für HyperCore und HyperEVM bereitstellt. Sowohl WebSocket als auch gRPC werden an jedem Hyperliquid-Endpunkt unterstützt. Für Teams, die von dieser Änderung der öffentlichen API betroffen sind, ist das HyperCore-gRPC-Streaming die relevanteste Funktion . Nicht, weil WebSocket das falsche Werkzeug wäre, sondern weil wir erkennen, wo WebSocket bei Skalierung an seine Grenzen stößt: Wiederverbindungsstürme, Anfälligkeit paketgesteuerter Streams und Payload-Overhead bei Abonnements für mehrere Märkte.

Quicknodes Hyperliquid-Dokumentation Umfasst gRPC-Unterstützung für die gesamte Palette der HyperCore-Datenströme, 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 Quicknode-Hyperliquid-Dokumentation und der Referenz zur Hyperliquid-gRPC-Streaming-API.

Welche HyperCore-Datensätze sollten automatisierte Trader verwenden?

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

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

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, einschließlich des Gesamtvolumens und der Anzahl der Orders auf jeder Stufe.

Verwendung StreamL2Book wenn Ihre Strategie eine aktuelle Ordertiefe nach Kursniveau benötigt, ohne ein lokales Orderbuch aus inkrementellen Differenzen aufzubauen. Der Stream unterstützt eine konfigurierbare Ordertiefe 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 optimalere Lösung für Market Making, Spread-Überwachung, tiefengestützte Ausführung und ordnungsbasierte Benachrichtigungen.

StreamL4Book für den Status auf Einzelbestellungsebene

StreamL4Book Liefert das Orderbuch auf der Ebene einzelner Orders. Bei der Anmeldung wird eine vollständige Momentaufnahme der aktuellen Geld- und Briefkurse gesendet. Danach werden Differenzdaten pro Block übermittelt.

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 gRPC-basiert. Sie sind nicht über WebSocket oder JSON-RPC verfügbar.

Wie sollten Teams ihre Hyperliquid-Bots an den neuen Rhythmus anpassen?

Sie müssen nicht alle Hyperliquid-Integrationen auf einmal verschieben. Beginnen Sie damit, die Eingaben für Entscheidungen von den Eingaben für die Anzeige zu trennen.

1. Ordnen Sie jedes Abonnement 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 jedem Update den lokalen Preisstand ersetzen kann. Mit StreamL4Book, beim Wiederverbinden aus dem Snapshot initialisieren, Diffs anwenden und anhand eines neuen Snapshots zurücksetzen.

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

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

5. Lassen Sie während der Umstellung beide Feeds laufen.

   Führen Sie vor der Netzwerkumstellung 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 Umstellungsplan, anstatt in letzter Minute den Endpunkt wechseln zu müssen.

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

gRPC sollte die erste Anlaufstelle für latenzkritische HyperCore-Marktdaten sein, muss jedoch nicht jede Arbeitslast bewältigen.

• WebSocket ist an jedem Hyperliquid-Endpunkt 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 können gefilterte Ereignisse an Backend-Systeme und Benachrichtigungspipelines weiterleiten.

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

Auf der Hyperliquid-Chain-Seite von Quicknode werden außerdem eine SLA mit einer Verfügbarkeit von 99,99 %, mehr als 6 Milliarden Hyperliquid-API-Anfragen pro Monat und mehr als 500 Milliarden Zeilen abfragbarer Daten aufgeführt. Diese Zahlen sind entscheidend, 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 gRPC an?

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

2. Erstellen Sie über das Quicknode-Dashboard einen Hyperliquid-Endpunkt. Ein einziger Endpunkt ermöglicht den verwalteten Zugriff sowohl auf HyperCore als auch auf HyperEVM.

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

4. Nutzen Sie die Dokumentation zur Hyperliquid gRPC-Streaming-API, um Ihren Consumer 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-gRPC-Beispiel-Repo, um Abonnements in JavaScript, Python, Go oder Rust zu testen.

7. Sehen Sie sich die praktischen Beispiele in der Hyperliquid-Handbuchbibliothek und der Beispiel-App-Bibliothek an.

Das Update der öffentlichen API von Hyperliquid 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 Markttiefe, mehr Ebenen, Echtzeit-Streams und eine Infrastruktur, die für ständig aktive Systeme ausgelegt ist.

Quicknode bietet einen verwalteten Weg zu dieser Konfiguration, ohne dass Sie die Node-Infrastruktur selbst betreiben müssen.

Beginnen Sie mit der Quicknode-Hyperliquid -Dokumentation.