Summary
This is a report against the /info API endpoints, specifically the types: delegatorHistory and delegatorRewards.
Filing issue here instead of SDK repo because this is the most direct official Hyperliquid-maintained repo I can find, and this is not an issue in caused by the SDK's code. Info.delegator_history()/Info.delegator_rewards() simply pass through what the API returns, so the SDK exhibits the same behavior, but the feature request is server-side.
The API hard-caps responses at exactly 2000 entries per address, silently returning only the most recent 2000 with no error and no indication that older data was dropped. There is no pagination, cursor, or time-range parameter to retrieve entries beyond that window — unlike sibling endpoints (e.g. funding history) which do support startTime/endTime.
Reproduction
curl -s -X POST https://api.hyperliquid.xyz/info -H "Content-Type: application/json" \
-d '{"type":"delegatorHistory","user":"0x393d0b87ed38fc779fd9611144ae649ba6082109"}'
# Returns exactly 2000 entries, on repeated fetches.
curl -s -X POST https://api.hyperliquid.xyz/info -H "Content-Type: application/json" \
-d '{"type":"delegatorHistory","user":"0x393d0b87ed38fc779fd9611144ae649ba6082109","startTime":0,"endTime":1}'
# Identical 2000-entry response — startTime/endTime are silently ignored.I also tested cursor, offset, limit, page, pageSize, maxResults, since, after, before, fromTime, toTime, and snake_case variants of each, against both api.hyperliquid.xyz and a third-party RPC provider — all silently ignored.
Why this matters
Neither the response shape nor the docs (the /info endpoint reference or the rate-limits page) expose a total-count field, cursor, or "has more" flag — there is no way for a caller to know their data has been truncated except by independently proving it (as above), which isn't generally possible. Any application reconstructing a delegator's full position history from these endpoints — for accounting, reconciliation, or auditing purposes — will silently produce an incorrect result for any address active enough to exceed 2000 lifetime entries, with no error surfaced anywhere.
Ask
- Add pagination (
startTime/endTime, or a cursor) to delegatorHistory/delegatorRewards
Summary
This is a report against the
/infoAPI endpoints, specifically the types:delegatorHistoryanddelegatorRewards.Filing issue here instead of SDK repo because this is the most direct official Hyperliquid-maintained repo I can find, and this is not an issue in caused by the SDK's code.
Info.delegator_history()/Info.delegator_rewards()simply pass through what the API returns, so the SDK exhibits the same behavior, but the feature request is server-side.The API hard-caps responses at exactly 2000 entries per address, silently returning only the most recent 2000 with no error and no indication that older data was dropped. There is no pagination, cursor, or time-range parameter to retrieve entries beyond that window — unlike sibling endpoints (e.g. funding history) which do support
startTime/endTime.Reproduction
I also tested
cursor,offset,limit,page,pageSize,maxResults,since,after,before,fromTime,toTime, and snake_case variants of each, against bothapi.hyperliquid.xyzand a third-party RPC provider — all silently ignored.Why this matters
Neither the response shape nor the docs (the
/infoendpoint reference or the rate-limits page) expose a total-count field, cursor, or "has more" flag — there is no way for a caller to know their data has been truncated except by independently proving it (as above), which isn't generally possible. Any application reconstructing a delegator's full position history from these endpoints — for accounting, reconciliation, or auditing purposes — will silently produce an incorrect result for any address active enough to exceed 2000 lifetime entries, with no error surfaced anywhere.Ask
startTime/endTime, or a cursor) todelegatorHistory/delegatorRewards