요청 한도 및 사용자 한도

다음 요청 한도는 IP 주소별로 적용됩니다:

REST 요청은 분당 1200의 집계 가중치 한도를 공유합니다.
문서화된 모든 exchange API 요청의 가중치는 1 + floor(batch_length / 40)입니다. 예를 들어, 배치되지 않은 액션의 가중치는 1이고 길이가 79인 배치 주문 요청의 가중치는 2입니다. 여기서 batch_length는 액션에서 배열의 길이, 즉 배치 주문 액션의 주문 수입니다.
다음 info 요청의 가중치는 2입니다: l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus.
다음 info 요청의 가중치는 60입니다: userRole .
문서화된 다른 모든 info 요청의 가중치는 20입니다.
다음 info 엔드포인트는 응답에서 반환되는 20개 항목당 추가 요청 한도 가중치가 있습니다: recentTrades, historicalOrders, userFills, userFillsByTime, fundingHistory, userFunding, nonUserFundingUpdates, twapHistory, userTwapSliceFills, userTwapSliceFillsByTime, delegatorHistory, delegatorRewards, validatorStats .
candleSnapshot info 엔드포인트는 응답에서 반환되는 60개 항목당 추가 요청 한도 가중치가 있습니다.
모든 explorer API 요청의 가중치는 40입니다. blockList는 블록당 1개의 추가 요청 한도가 있습니다. 최근에 조회되지 않은 오래된 블록은 더 높은 가중치가 적용될 수 있습니다. 대량 배치 요청의 경우 S3 버킷을 대신 사용하세요.
최대 10개의 websocket 연결
분당 최대 30개의 신규 websocket 연결
최대 1000개의 websocket 구독
사용자별 websocket 구독에서 최대 10명의 고유 사용자
모든 websocket 연결을 합쳐 분당 Hyperliquid로 전송되는 최대 2000개의 메시지
모든 websocket 연결을 합쳐 동시 진행 중인 최대 100개의 post 메시지
rpc.hyperliquid.xyz/evm에 대해 분당 최대 100개의 EVM JSON-RPC 요청. 다른 JSON-RPC 프로바이더는 더 정교한 요청 한도 로직과 아카이브 노드 기능을 갖추고 있습니다.

가장 낮은 지연 시간의 실시간 데이터를 위해서는 websocket을 사용하세요. 완전한 기능을 갖춘 예시는 Python SDK를 참조하세요.

주소 기반 한도

주소 기반 한도는 사용자별로 적용되며, 서브 계정은 별도의 사용자로 취급됩니다.

요청 한도 로직은 주소 생성 이후 누적 거래액 1 USDC당 1개의 요청을 허용합니다. 예를 들어, 주문 가치가 100 USDC라면 체결률 1%가 필요합니다. 각 주소는 10000개 요청의 초기 버퍼로 시작합니다. 요청 한도에 도달한 주소는 10초마다 1개의 요청이 허용됩니다. 취소의 누적 한도는 min(limit + 100000, limit * 2)이며, 여기서 limit는 다른 액션에 대한 기본 한도입니다. 이렇게 하면 주소 기반 요청 한도에 도달해도 미체결 주문을 여전히 취소할 수 있습니다. 이 요청 한도는 info 요청이 아닌 액션에만 적용됩니다.

각 사용자는 기본 1000개의 미체결 주문 한도에 더해 500만 USDC 거래량마다 1개의 추가 주문이 허용되며, 총 미체결 주문 수는 5000개로 제한됩니다. 동일 사용자의 다른 미체결 주문이 1000개 이상인 상태에서 주문이 접수되면, 축소 전용 주문 또는 트리거 주문인 경우 거부됩니다.

혼잡이 심한 기간에는 주소가 전일 메이커 점유율 비율의 2배에 해당하는 블록 공간 사용으로 제한됩니다. 메이커 점유율은 해당 자산의 수수료 티어에 대한 거래량 기여도와 동일한 계수로 조정됩니다. 예를 들어, 성장 모드의 HIP-3 자산은 이 요청 한도에 덜 가중됩니다. 메이커 점유율은 UTC 날짜별로 한 번 계산됩니다. 따라서 트래픽이 많은 기간에는 API를 통해 이미 결과가 반환된 취소를 다시 전송하지 않는 것이 도움이 될 수 있습니다. 혼잡 시 배치 액션의 가중치는 배치 크기와 액션당 상수 가중치 모두에 비례합니다. 따라서 취소 또는 주문을 함께 배칭하면 가중치가 확실히 감소하여 요청 한도 사용량이 줄어듭니다.

배치 요청

n개의 주문(또는 취소)이 포함된 배치 요청은 IP 기반 요청 한도에서는 하나의 요청으로 취급되지만, 주소 기반 요청 한도에서는 n개의 요청으로 취급됩니다.