Research data API · v1 preview
Use the records. Keep the context.
Read saved trader activity, account records and supported chain transfers. Financial totals describe the records available, not independently verified lifetime performance. This public preview requires no API key; authenticated plans and webhook delivery are still on the roadmap.
Trader records · Hyperliquid research preview
GET /api/v1/traders returns the tracked accounts, the latest 50 recorded perpetual fills, and collector status. GET /api/v1/traders/ADDRESS returns one tracked account, saved provider equity/P&L snapshots, market coverage, and collection timestamps. These account records are separate from the finalized transfer API below. No authentication is required during this bounded pilot; response fields may change.
Discovery paused · lifetime performance unverified
Existing accounts continue collecting records. Provider all-time and monthly summaries remain unverified references. A successful HTTP response, completed download or agreement between partial sources does not prove complete history.
Recorded P&L, capital and history quality
GET /api/v1/traders/{address}/record?start=YYYY-MM-DD&end=YYYY-MM-DDThe required start and end select the reporting interval. The response includes performance, capital, pnl and quality. Recorded perpetual results after fees exclude funding and current open P&L. performance.total, performance.markets and performance.curve use the same saved execution set; curve.change is the interval change. Empty periods have performance.total.available=false, not proof of zero trading. Decimal totals remain strings.
Inspect quality.fills, quality.funding and quality.capital for collection coverage. quality.lifetimeVerified is currently false. An incomplete funding collection keeps pnl.fundingCoverage.net null. Recorded deposits are capital contributions, not profit or proof of original starting capital. Source comparisons and account-value reconciliation are separate requirements before verification.
Execution and account activity
GET /api/v1/traders/ADDRESS/activity supports inclusive UTC start and end dates (YYYY-MM-DD), or exact ISO instants with milliseconds and Z (for example 2026-09-30T04:00:00.000Z). The website converts device-local date boundaries into these instants. Other filters are market, product (Perpetual, Spot, Account), kind (fill, funding, ledger), limit (1–100; default 50), and the returned nextCursor. Use position=closed for perpetual executions that reduce or reverse an existing position, including partial and break-even closes. This filter is applied before pagination and does not reconstruct completed trades. Pagination uses recorded event time and identity. Decimal source fields remain strings. Missing account profiles return 404; invalid parameters return 400; unavailable storage returns 503. Saved records may still be stale on a 200.
GET /api/v1/traders/ADDRESS/trades reconstructs saved perpetual positions before applying the required start/end dates. Dates select the closing time; a position’s earlier entries remain part of its result. Optional market, view (closed, partial, unclosed), limit (1–100; default 50), and cursor filters are supported. The response contains trades, nextCursor, summary, and coverage. Partial and unreconciled trades are excluded from completed-position statistics. P&L after fees and win rate use USDC execution fees at $1 and exclude funding. These statistics describe the saved sample, not lifetime performance. Requests exceeding 500,000 source fills return 422 with a request to select a market; records are never silently truncated. Derived data may be reused for up to one minute.
Inspect last_success, error, snapshot.failedDexes, and each coverage cursor. A drained available range does not prove lifetime completeness. Native Hyperliquid history is limited to the latest 10,000 fills; Dwellir backfills can extend the saved history beyond that limit, but their own progress and date boundaries still apply. Snapshots and activity are collected periodically, not on each page request. Neither source is assumed to establish lifetime profit. Verified returns, skill rankings and trading signals are not supplied by this preview.
Recorded transfers
GET /api/v1/transfers?chain=ethereum&limit=50
The response includes events, nextCursor, coverage, fetchedAt, and storage. A successful response can still contain a delayed or failed chain: inspect coverage before treating the history as current.
| Parameter | Meaning |
|---|---|
| chain | ethereum, solana, or polygon; omit for all three |
| address | Exact sender, receiver, or reported SPL token-account owner |
| asset | native, an ERC-20 contract address, or a Solana mint address |
| limit | 1–100 records; default 50 |
| cursor | The previous response’s nextCursor; preserve the other filters |
Records are newest-first by observation time and event ID. One transaction can produce multiple transfer events. Use id for deduplication; transactionHash alone is not unique.
Inspect an API response →Coverage and health
GET /api/v1/coverage
Each chain reports firstPosition, position, head, lastSuccess, state, error, and its asset thresholds. headCheckedAt records when the finalized head was last checked; it may be absent on older checkpoints. Positions are block numbers on EVM chains and slots on Solana.
“current” means the scan reached the last observed finalized head and its checks are recent. It does not include pending transactions. lastSuccess is the latest successful scan or caught-up check; it does not mean a new transfer was found. blockTime is the chain-provided block timestamp, or null if unavailable. observedAt is when the monitor observed the transfer.
A recorded scanning error produces state “error.” Otherwise, coverage becomes “delayed” if there is no successful check or if either lastSuccess or headCheckedAt is more than two minutes old. Older checkpoints without headCheckedAt use lastSuccess for both freshness checks. No saved checkpoint produces “not_started”; a fresh scan behind its observed head is “syncing.”
Both endpoints can return HTTP 200 while a chain is delayed or blocked. For each chain in the coverage array, inspect state, error, the timestamps, and the gap between head and position. Refreshing the page every ten seconds does not guarantee ten-second-old chain data.
Amounts and evidence
- amountRaw is an exact integer string. amount is an exact decimal string. Never parse either through a floating-point number for accounting.
- asset identifies the native asset, contract, or mint. A symbol is a display label, not a unique asset identifier.
- blockNumber, blockHash, transactionHash, and locator identify the evidence. finality is finalized. Failed transactions are excluded.
- valuationUsd is null. Thresholds are in asset units. No trading direction or wallet identity is inferred.
- For SPL transfers, from and to are token accounts; fromOwner and toOwner are included when chain metadata supplies them.
Scope and errors
Initial scope covers top-level ETH and POL transfers, parsed SOL transfers including successful inner instructions, and native USDC transfers using ERC-20 or the standard SPL Token program. Internal EVM calls, contract creation funding, Token-2022, minting, burning, and other assets are excluded. History starts at firstPosition.
400 indicates an invalid query. 503 means storage or configuration is unavailable. A 200 with empty events is not evidence that a chain is quiet: check coverage and the configured thresholds. The scanner stops that chain if required evidence is missing, a finalized checkpoint changes, or its scan policy changes.
For example, EXECUTION_TRACE_UNAVAILABLE means the execution details needed to verify an inner transfer are incomplete, including when transaction logs are truncated. Scanning stays at the last verified checkpoint. Previously saved history and other chains remain available. The terminal calls this “Scanning blocked” and keeps the error code under “Error details.”