Limiti di frequenza e limiti per utente

I seguenti limiti di frequenza si applicano per indirizzo IP:

• Le richieste REST condividono un limite di peso aggregato di 1200 al minuto.
• Tutte le richieste API exchange documentate hanno un peso pari a 1 + floor(batch_length / 40). Ad esempio, le azioni non raggruppate hanno peso 1 e una richiesta di ordine in batch di lunghezza 79 ha peso 2. Qui batch_length è la lunghezza dell'array nell'azione, ad es. il numero di ordini in un'azione di ordine in batch.
• Le seguenti richieste info hanno peso 2: l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus.
• Le seguenti richieste info hanno peso 60: userRole .
• Tutte le altre richieste info documentate hanno peso 20.
• I seguenti endpoint info hanno un peso aggiuntivo del limite di frequenza ogni 20 elementi restituiti nella risposta: recentTrades, historicalOrders, userFills, userFillsByTime, fundingHistory, userFunding, nonUserFundingUpdates, twapHistory, userTwapSliceFills, userTwapSliceFillsByTime, delegatorHistory, delegatorRewards, validatorStats .
• L'endpoint info candleSnapshot ha un peso aggiuntivo del limite di frequenza ogni 60 elementi restituiti nella risposta.
• Tutte le richieste API explorer hanno un peso di 40. blockList ha un limite di frequenza aggiuntivo di 1 per blocco. Si noti che i blocchi più vecchi che non sono stati interrogati di recente possono avere un peso maggiore. Per le richieste in batch di grandi dimensioni, utilizzare invece il bucket S3.
• Massimo di 10 connessioni websocket
• Massimo di 30 nuove connessioni websocket al minuto
• Massimo di 1000 sottoscrizioni websocket
• Massimo di 10 utenti univoci tra le sottoscrizioni websocket specifiche per utente
• Massimo di 2000 messaggi inviati a Hyperliquid al minuto su tutte le connessioni websocket
• Massimo di 100 messaggi post simultanei in volo su tutte le connessioni websocket
• Massimo di 100 richieste EVM JSON-RPC al minuto per rpc.hyperliquid.xyz/evm. Si noti che altri provider JSON-RPC dispongono di una logica di limitazione della frequenza più sofisticata e di funzionalità di nodo di archiviazione.

Utilizzare i websocket per dati in tempo reale con la latenza minima. Vedere il Python SDK per un esempio completo.

Limiti basati sull'indirizzo

I limiti basati sull'indirizzo si applicano per utente, con i subaccount trattati come utenti distinti.

La logica di limitazione della frequenza consente 1 richiesta per 1 USDC negoziato cumulativamente dalla creazione dell'indirizzo. Ad esempio, con un valore dell'ordine di 100 USDC, questo richiede un tasso di esecuzione dell'1%. Ciascun indirizzo inizia con un buffer iniziale di 10000 richieste. Quando è soggetto a limitazione della frequenza, a un indirizzo è consentita una richiesta ogni 10 secondi. Gli annullamenti hanno un limite cumulativo min(limit + 100000, limit * 2) dove limit è il limite predefinito per le altre azioni. In questo modo, raggiungere il limite di frequenza basato sull'indirizzo consente comunque di annullare gli ordini aperti. Si noti che questo limite di frequenza si applica solo alle azioni, non alle richieste info.

Ciascun utente ha un limite predefinito di ordini aperti pari a 1000 più un ordine aggiuntivo per ogni 5M USDC di volume, con un massimo complessivo di 5000 ordini aperti. Quando viene inserito un ordine con almeno 1000 altri ordini aperti da parte dello stesso utente, questo verrà rifiutato se è reduce-only o un ordine trigger.

Durante una congestione elevata, gli indirizzi sono limitati a utilizzare 2x la propria percentuale di quota maker del giorno precedente dello spazio dei blocchi. La quota maker viene scalata dello stesso fattore con cui il contributo di volume di quell'asset incide sui livelli di commissione. Ad esempio, gli asset HIP-3 in modalità growth incidono meno su questo limite di frequenza. La quota maker viene calcolata una volta per data UTC. Durante il traffico elevato, può quindi essere utile non reinviare gli annullamenti i cui risultati sono già stati restituiti tramite l'API. Durante la congestione, il peso di un'azione in batch è proporzionale sia alla dimensione del batch sia a un peso costante per azione. Pertanto, raggruppare insieme annullamenti o ordini riduce rigorosamente il loro peso e il consumo del limite di frequenza.

Richieste in batch

Una richiesta in batch con n ordini (o annullamenti) viene considerata come una sola richiesta ai fini della limitazione della frequenza basata su IP, ma come n richieste ai fini della limitazione basata sull'indirizzo.