Hyperliquid Orderbook per WebSocket in Echtzeit abonnieren
-
hyperliquid orderbook websocket
-
real time hyperliquid api
-
hyperliquid Echtzeit-Orderbook
-
hyperliquid websocket subscription
-
hyperliquid l2 book
Das Orderbook ist eine der zentralen Datenstrukturen jeder Exchange. Es zeigt in Echtzeit, zu welchen Preisen und in welchen Größen aktuell offene Kauf- und Verkaufsorders im Markt liegen. Für Quant-Bots, Arbitrage-Systeme und Marktanalyse-Tools kann der Zugriff auf ein aktuelles Orderbook mit möglichst geringer Latenz entscheidend sein.
Hyperliquid stellt dafür eine vollständige WebSocket-Schnittstelle bereit. Darüber kannst du L2-Orderbook-Snapshots und fortlaufende Updates abonnieren. In diesem Artikel schauen wir uns an, wie die Subscription funktioniert, wie die Nachrichten aufgebaut sind, wie du ein lokales Orderbook pflegst und welche Punkte bei Reconnects und produktionsnahen Setups wichtig sind.
Wenn du keine eigene Infrastruktur bauen möchtest und primär Perpetuals traden willst, ist OneKey Perps der praktischere Weg: Echtzeit-Marktdaten und Trading sind bereits integriert und direkt nutzbar.
WebSocket vs. REST-Polling
Bevor wir in die Implementierung gehen, lohnt sich der Unterschied zwischen WebSocket und REST-Polling.
Für ein Orderbook, das in Echtzeit aktualisiert werden soll, ist REST-Polling in der Regel keine gute Alternative. Polling erzeugt mehr Overhead, ist langsamer und kann zwischen zwei Abfragen wichtige Änderungen verpassen. WebSockets liefern Updates dauerhaft über eine offene Verbindung und sind deshalb für Orderbook-Daten deutlich besser geeignet.
Für die vollständige Spezifikation solltest du zusätzlich die offizielle Hyperliquid-Dokumentation zur WebSocket API prüfen.
WebSocket-Verbindung aufbauen
Endpoint
Der Hyperliquid-WebSocket-Endpoint lautet nach aktuellem Stand gemäß offizieller Dokumentation:
wss://api.hyperliquid.xyz/ws
Einfaches Verbindungsbeispiel
import asyncio
import json
import websockets
WS_URL = "wss://api.hyperliquid.xyz/ws"
async def connect_and_subscribe():
async with websockets.connect(WS_URL) as ws:
# Subscription-Nachricht senden
subscribe_msg = {
"method": "subscribe",
"subscription": {
"type": "l2Book",
"coin": "BTC"
}
}
await ws.send(json.dumps(subscribe_msg))
# Nachrichten fortlaufend empfangen
async for raw_msg in ws:
msg = json.loads(raw_msg)
handle_message(msg)
asyncio.run(connect_and_subscribe())
Format der Subscription-Nachricht
L2-Orderbook abonnieren
So abonnierst du das L2-Orderbook für BTC:
{
"method": "subscribe",
"subscription": {
"type": "l2Book",
"coin": "BTC"
}
}
Hyperliquid unterstützt mehrere Märkte über dieselbe Verbindung. Dafür sendest du einfach mehrere Subscription-Nachrichten, jeweils mit dem gewünschten Coin. Updates werden pro Markt separat übertragen.
Subscription beenden
{
"method": "unsubscribe",
"subscription": {
"type": "l2Book",
"coin": "BTC"
}
}
Nachrichtentypen: Snapshot und Delta
Initialer Snapshot
Nach der Subscription sendet der Server zunächst einen vollständigen Snapshot des aktuellen Orderbooks. Dieser enthält die vorhandenen Preislevel und deren Volumen:
{
"channel": "l2Book",
"data": {
"coin": "BTC",
"time": 1714500000000,
"levels": [
[
[{"px": "64000.0", "sz": "0.5", "n": 3}],
[{"px": "64010.0", "sz": "0.3", "n": 2}]
]
]
}
}
Die beiden Seiten stehen dabei für:
bids: Kauforders, üblicherweise von hohem zu niedrigem Preis sortiertasks: Verkaufsorders, üblicherweise von niedrigem zu hohem Preis sortiert
Die wichtigsten Felder:
px: Preissz: aggregiertes Volumen auf diesem Preislevel;0bedeutet, dass das Level leer istn: Anzahl der Orders auf diesem Preislevel
Delta-Updates
Nach dem Snapshot schickt der Server nur noch Preislevel, die sich geändert haben:
{
"channel": "l2Book",
"data": {
"coin": "BTC",
"time": 1714500000100,
"levels": [
[
[{"px": "63990.0", "sz": "0.0", "n": 0}],
[{"px": "64010.0", "sz": "0.8", "n": 4}]
]
]
}
}
Wenn sz den Wert "0", "0.0" oder numerisch 0 hat, ist dieses Preislevel vollständig gefüllt oder gecancelt worden. In deinem lokalen Orderbook musst du das Level dann löschen.
Lokales Orderbook pflegen
Das korrekte Pflegen eines lokalen Orderbooks ist der wichtigste Teil beim Arbeiten mit WebSocket-Daten. Du startest mit dem Snapshot und wendest danach jedes Delta in der richtigen Reihenfolge an.
from sortedcontainers import SortedDict
class LocalOrderBook:
def __init__(self, coin):
self.coin = coin
self.bids = SortedDict(lambda x: -float(x)) # Bids: hoher Preis zuerst
self.asks = SortedDict(lambda x: float(x)) # Asks: niedriger Preis zuerst
self.last_time = None
def apply_snapshot(self, data):
self.bids.clear()
self.asks.clear()
levels = data["levels"][0]
for bid in levels[0]:
if float(bid["sz"]) > 0:
self.bids[bid["px"]] = float(bid["sz"])
for ask in levels[1]:
if float(ask["sz"]) > 0:
self.asks[ask["px"]] = float(ask["sz"])
self.last_time = data["time"]
def apply_delta(self, data):
levels = data["levels"][0]
for bid in levels[0]:
px, sz = bid["px"], float(bid["sz"])
if sz == 0:
self.bids.pop(px, None)
else:
self.bids[px] = sz
for ask in levels[1]:
px, sz = ask["px"], float(ask["sz"])
if sz == 0:
self.asks.pop(px, None)
else:
self.asks[px] = sz
self.last_time = data["time"]
@property
def best_bid(self):
return next(iter(self.bids.items()), None)
@property
def best_ask(self):
return next(iter(self.asks.items()), None)
@property
def mid_price(self):
bid = self.best_bid
ask = self.best_ask
if bid and ask:
return (float(bid[0]) + float(ask[0])) / 2
return None
@property
def spread(self):
bid = self.best_bid
ask = self.best_ask
if bid and ask:
return float(ask[0]) - float(bid[0])
return None
Nachrichten verarbeiten
Du musst unterscheiden, ob du gerade den initialen Snapshot oder ein Delta verarbeitest:
order_book = LocalOrderBook("BTC")
is_initialized = False
def handle_message(msg):
global is_initialized
if msg.get("channel") != "l2Book":
return
data = msg["data"]
if not is_initialized:
order_book.apply_snapshot(data)
is_initialized = True
print(
f"Orderbook initialisiert: "
f"{len(order_book.bids)} Bid-Level, "
f"{len(order_book.asks)} Ask-Level"
)
else:
order_book.apply_delta(data)
# Aktuellen Top-of-Book-Zustand ausgeben
print(
f"Best Bid: {order_book.best_bid}, "
f"Best Ask: {order_book.best_ask}, "
f"Spread: {order_book.spread}"
)
Reconnects sauber behandeln
WebSocket-Verbindungen können durch Netzwerkprobleme, Timeouts oder serverseitige Disconnects abbrechen. Ein produktionsnahes System sollte deshalb automatisch reconnecten.
import asyncio
import json
import websockets
async def subscribe_with_reconnect(coin, handle_fn, max_retries=None):
retries = 0
while max_retries is None or retries < max_retries:
try:
async with websockets.connect(
WS_URL,
ping_interval=20,
ping_timeout=10
) as ws:
retries = 0 # Erfolgreiche Verbindung: Retry-Zähler zurücksetzen
is_initialized = False
await ws.send(json.dumps({
"method": "subscribe",
"subscription": {"type": "l2Book", "coin": coin}
}))
async for raw_msg in ws:
handle_fn(json.loads(raw_msg))
except (websockets.ConnectionClosed, ConnectionError, OSError) as e:
retries += 1
wait = min(2 ** retries, 60) # Exponential Backoff, maximal 60 Sekunden
print(f"Verbindung getrennt ({e}), neuer Versuch in {wait}s, Retry #{retries}")
is_initialized = False # Beim Reconnect neuen Snapshot erwarten
await asyncio.sleep(wait)
Wichtig: Beim Reconnect solltest du den Initialisierungsstatus zurücksetzen. Nach einer neuen Verbindung sendet der Server wieder einen vollständigen Snapshot. Du solltest nicht versuchen, Deltas über eine unterbrochene Verbindung hinweg fortzuschreiben.
Sequenz, Zeitstempel und Nachrichtenreihenfolge
Hyperliquid-WebSocket-Nachrichten enthalten ein Zeitfeld, das du zur Plausibilitätsprüfung nutzen kannst. Für produktionsnahe Systeme ist empfehlenswert:
- Speichere den Zeitstempel der zuletzt verarbeiteten Nachricht.
- Wenn eine neue Nachricht älter ist als die zuletzt verarbeitete, behandle sie als veraltet und verwerfe sie.
- Wenn über längere Zeit keine Nachricht kommt, sende aktiv einen Ping oder baue die Verbindung neu auf.
- Für latenzkritische Strategien können Netzwerkstandort, Infrastruktur und Routing entscheidend sein.
Ein Zeitstempel ersetzt keine vollständige Sequenznummer-Logik, hilft aber dabei, offensichtliche Ausreißer und veraltete Nachrichten zu erkennen.
Mehrere Märkte gleichzeitig abonnieren
Du kannst über eine einzelne WebSocket-Verbindung mehrere Märkte abonnieren. Für mehrere Coins bietet sich eine asynchrone Architektur an:
coins = ["BTC", "ETH", "SOL"]
order_books = {coin: LocalOrderBook(coin) for coin in coins}
async def multi_subscribe():
async with websockets.connect(WS_URL) as ws:
for coin in coins:
await ws.send(json.dumps({
"method": "subscribe",
"subscription": {"type": "l2Book", "coin": coin}
}))
async for raw_msg in ws:
msg = json.loads(raw_msg)
if msg.get("channel") == "l2Book":
coin = msg["data"]["coin"]
if coin in order_books:
order_books[coin].apply_delta(msg["data"])
In einer produktiven Variante solltest du pro Coin ebenfalls den Initialisierungsstatus verwalten. Der Snapshot jedes Marktes muss korrekt verarbeitet werden, bevor du Deltas zuverlässig anwenden kannst.
Typische Anwendungsfälle
Echtzeit-Orderbook-Daten werden häufig für folgende Zwecke genutzt:
- Trading-Bots: dynamische Anpassung von Limit Orders anhand von Spread und Tiefe
- Arbitrage-Systeme: Überwachung von Preisunterschieden zwischen Hyperliquid und anderen Exchanges wie dYdX oder GMX
- Marktanalyse-Dashboards: Visualisierung von Orderbook-Tiefe, Spread-Historie und Liquiditätsverteilung
- Risk-Systeme: Alerts bei ungewöhnlich weitem Spread oder plötzlich sinkender Liquidität
OneKey Perps: ohne eigene Infrastruktur traden
Ein eigenes WebSocket-Orderbook-System aufzubauen erfordert Engineering-Aufwand: Verbindungsmanagement, lokale State-Pflege, Monitoring, Reconnects, Datenvalidierung und im Zweifel eigene Speicherlogik für Tick-Daten.
Wenn dein Ziel nicht der Bau eines Quant-Systems ist, sondern du Perpetuals handeln möchtest, ist OneKey Perps der einfachere Workflow. OneKey Perps bietet Echtzeit-Marktdaten und Trading-Funktionen in einer integrierten Oberfläche. In Kombination mit der sicheren Signatur über eine OneKey Hardware Wallet kannst du dich stärker auf deine Handelsentscheidung konzentrieren, statt selbst Marktinfrastruktur zu betreiben.
Wenn du dApps über WalletConnect nutzen möchtest, findest du in der WalletConnect-Dokumentation die entsprechenden Integrationshinweise. OneKey unterstützt das standardisierte WalletConnect-Protokoll und kann sicher mit Web3-Anwendungen wie Hyperliquid interagieren.
Häufige Fragen
Q1: Gibt es Limits für parallele WebSocket-Verbindungen?
Ja, mit Limits solltest du immer rechnen. Die konkreten Werte solltest du in der offiziellen Hyperliquid-Dokumentation prüfen. Generell ist es sinnvoll, pro IP nicht unnötig viele parallele Verbindungen aufzubauen. Für mehrere Märkte solltest du möglichst eine gemeinsame WebSocket-Verbindung wiederverwenden.
Q2: Wird mein lokales Orderbook falsch, wenn ein Delta verloren geht?
Ja. Wenn ein Delta-Update wegen Netzwerkproblemen verloren geht, kann dein lokaler Zustand vom tatsächlichen Serverzustand abweichen. Wenn du Inkonsistenzen vermutest, etwa durch ungewöhnliche Spreads oder sprunghafte Top-of-Book-Änderungen, solltest du die Verbindung schließen und neu abonnieren, um einen frischen Snapshot zu erhalten.
Q3: Kann ich Echtzeit-Orderbook-Daten direkt für Backtests nutzen?
Nicht direkt. Backtests brauchen historische Daten, nicht nur einen Live-Stream. Wenn du Orderbook-basierte Strategien testen möchtest, solltest du die empfangenen Daten zeitlich geordnet speichern, zum Beispiel als Tick-Daten. Für erste Analysen können zusätzlich historische Candlestick-Daten hilfreich sein, falls die jeweilige API diese bereitstellt.
Q4: Wie erkenne ich, ob die WebSocket-Verbindung gesund ist?
Überwache mindestens diese Punkte:
- Zeit seit der letzten empfangenen Nachricht, zum Beispiel nicht länger als 5 Sekunden
- Ping/Pong-Roundtrip-Latenz
- Anzahl der Reconnects
- auffällige Sprünge oder inkonsistente Orderbook-Zustände
Wenn die Verbindung auffällig wird, sollte dein System automatisch reconnecten.
Q5: Beeinflusst eine OneKey Wallet die Trading-Latenz?
Die Signatur mit einer OneKey Hardware Wallet dauert typischerweise nur wenige hundert Millisekunden und ist für die meisten Trading-Setups vernachlässigbar. Für sehr hochfrequente Strategien, etwa viele Orders pro Sekunde, kann ein API-Agent-Subaccount oder eine Hot-Wallet-Struktur für Signaturen sinnvoll sein, während die Hauptmittel weiterhin durch OneKey geschützt werden. So trennst du aktive Ausführung und sichere Kapitalverwaltung.
Fazit
Eine Echtzeit-Orderbook-Subscription ist eine wichtige Datenquelle für anspruchsvolle Trading- und Analyse-Systeme. Hyperliquids WebSocket API ist klar strukturiert und ermöglicht Entwicklern, lokale L2-Orderbooks aus Snapshots und Delta-Updates aufzubauen.
Für Market-Making-Bots, Arbitrage-Systeme oder Analyse-Dashboards ist diese technische Basis wertvoll. Wenn du dagegen keine eigene Infrastruktur entwickeln möchtest und direkt On-Chain-Perpetuals handeln willst, ist OneKey Perps der praktischere Einstieg: Echtzeit-Marktdaten, Trading-Workflow und sichere Signatur mit OneKey in einem Setup.
Lade OneKey herunter oder öffne deine OneKey App, prüfe OneKey Perps in Ruhe und nutze es nur, wenn es zu deinem Risikoprofil und deinem Trading-Workflow passt.
Risikohinweis
Echtzeit-Orderbook-Daten zeigen nur den Marktzustand zu einem bestimmten Zeitpunkt und sollten niemals die einzige Grundlage für Trading-Entscheidungen sein. Automatisierte Strategien auf Basis von Orderbook-Daten können durch starke Volatilität, technische Störungen, Latenz oder Fehler im Strategiedesign erhebliche Verluste verursachen. Perpetuals sind hochriskant und können zum vollständigen Verlust des eingesetzten Kapitals führen. Dieser Artikel dient ausschließlich technischen Informationszwecken und ist keine Finanz-, Anlage- oder Rechtsberatung. Handle nur, wenn du die Risiken verstehst.
