Rate Limits und Nutzerlimits
Die folgenden Rate Limits gelten pro IP-Adresse:
- REST-Anfragen teilen sich ein aggregiertes Gewichtslimit von 1200 pro Minute.
- Alle dokumentierten
exchange-API-Anfragen haben ein Gewicht von1 + floor(batch_length / 40). Beispielsweise haben ungebündelte Aktionen das Gewicht1und eine gebündelte Orderanfrage der Länge 79 das Gewicht2. Hier istbatch_lengthdie Länge des Arrays in der Action, z. B. die Anzahl der Orders in einer gebündelten Orderaktion. - Die folgenden
info-Anfragen haben das Gewicht 2:l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus. - Die folgenden
info-Anfragen haben das Gewicht 60:userRole. - Alle übrigen dokumentierten
info-Anfragen haben das Gewicht 20. - Die folgenden
info-Endpunkte haben ein zusätzliches Rate-Limit-Gewicht pro 20 in der Antwort zurückgegebenen Elementen:recentTrades,historicalOrders,userFills,userFillsByTime,fundingHistory,userFunding,nonUserFundingUpdates,twapHistory,userTwapSliceFills,userTwapSliceFillsByTime,delegatorHistory,delegatorRewards,validatorStats. - Der
candleSnapshot-Info-Endpunkt hat ein zusätzliches Rate-Limit-Gewicht pro 60 in der Antwort zurückgegebenen Elementen. - Alle
explorer-API-Anfragen haben ein Gewicht von 40.blockListhat ein zusätzliches Rate Limit von 1 pro Block. Beachten Sie, dass ältere Blöcke, die nicht kürzlich abgefragt wurden, stärker gewichtet werden können. Verwenden Sie für große Batch-Anfragen stattdessen den S3-Bucket. - Maximal 10 WebSocket-Verbindungen
- Maximal 30 neue WebSocket-Verbindungen pro Minute
- Maximal 1000 WebSocket-Abonnements
- Maximal 10 eindeutige Nutzer über nutzerbezogene WebSocket-Abonnements hinweg
- Maximal 2000 Nachrichten pro Minute, die über alle WebSocket-Verbindungen hinweg an Hyperliquid gesendet werden
- Maximal 100 gleichzeitig ausstehende Post-Nachrichten über alle WebSocket-Verbindungen hinweg
- Maximal 100 EVM-JSON-RPC-Anfragen pro Minute für
rpc.hyperliquid.xyz/evm. Beachten Sie, dass andere JSON-RPC-Anbieter über eine ausgefeiltere Rate-Limiting-Logik und Archiv-Node-Funktionalität verfügen.
Verwenden Sie WebSockets für Echtzeitdaten mit der geringsten Latenz. Ein vollständiges Beispiel finden Sie im Python-SDK.
Adressbasierte Limits
Adressbasierte Limits gelten pro Nutzer, wobei Subkonten als getrennte Nutzer behandelt werden.
Die Rate-Limiting-Logik erlaubt 1 Anfrage pro 1 USDC, das seit Erstellung der Adresse kumulativ gehandelt wurde. Bei einem Orderwert von 100 USDC erfordert dies beispielsweise eine Ausführungsquote von 1%. Jede Adresse beginnt mit einem anfänglichen Puffer von 10000 Anfragen. Bei einer Rate-Limit-Beschränkung ist für eine Adresse eine Anfrage alle 10 Sekunden erlaubt. Stornierungen haben das kumulative Limit min(limit + 100000, limit * 2), wobei limit das Standardlimit für andere Aktionen ist. Auf diese Weise können offene Orders auch bei Erreichen des adressbasierten Rate Limits noch storniert werden. Beachten Sie, dass dieses Rate Limit nur für Aktionen gilt, nicht für Info-Anfragen.
Jeder Nutzer hat standardmäßig ein Limit von 1000 offenen Orders zuzüglich einer weiteren Order für jeweils 5M USDC Handelsvolumen, begrenzt auf insgesamt 5000 offene Orders. Wenn eine Order platziert wird, während derselbe Nutzer bereits mindestens 1000 weitere offene Orders hat, wird sie abgelehnt, wenn es sich um eine Reduce-Only- oder eine Trigger-Order handelt.
Bei hoher Überlastung dürfen Adressen nur das 2-fache ihres Maker-Anteils vom Vortag am Blockspace nutzen. Der Maker-Anteil wird mit demselben Faktor skaliert wie der Volumenbeitrag dieses Assets zu den Gebührenstufen. Beispielsweise zählen HIP-3-Assets im Growth Mode weniger stark für dieses Rate Limit. Der Maker-Anteil wird einmal pro UTC-Datum berechnet. Bei hohem Datenverkehr kann es daher hilfreich sein, Stornierungen nicht erneut zu senden, deren Ergebnisse bereits über die API zurückgegeben wurden. Während einer Überlastung ist das Gewicht einer gebündelten Aktion sowohl proportional zu ihrer Batch-Größe als auch zu einem konstanten Gewicht pro Aktion. Daher verringert die gemeinsame Bündelung von Stornierungen oder Orders deren Gewichtung strikt und reduziert die Nutzung des Rate Limits.
Gebündelte Anfragen
Eine gebündelte Anfrage mit n Orders (oder Stornierungen) wird für das IP-basierte Rate Limiting als eine Anfrage, für das adressbasierte Rate Limiting jedoch als n Anfragen behandelt.