Ledger feed

Deposits, withdrawals, transfers and vault events across all wallets, newest first, about a minute behind the venue, with a USD floor and an oldest-first mode for following the feed.

GET https://data.vike.io/v1/hyperliquid/ledger

Deposits, withdrawals, transfers and vault events for every wallet at once, newest first. It is the cross-wallet form of /wallets/{address}/ledger: the same event types and the same row, plus the wallet it belongs to. min_usd keeps only events of at least that size, so a call can ask for the large ones, and order=asc follows the feed forward. Naming a wallet reads one wallet's events through the same route.

cURL

# the 3 newest events of 1000000 USD or more in the last 24 hours
curl -s "https://data.vike.io/v1/hyperliquid/ledger?min_usd=1000000&limit=3" \
  -H "X-API-KEY: $VIKE_API_KEY"

# next page of the call just above: NEXT is its nextCursor, passed back verbatim
curl -s "https://data.vike.io/v1/hyperliquid/ledger?min_usd=1000000&limit=3&cursor=$NEXT" \
  -H "X-API-KEY: $VIKE_API_KEY"

# deposits of 100000 USD or more
curl -s "https://data.vike.io/v1/hyperliquid/ledger?event_type=deposit&min_usd=100000&limit=100" \
  -H "X-API-KEY: $VIKE_API_KEY"

# withdrawals of 100000 USD or more
curl -s "https://data.vike.io/v1/hyperliquid/ledger?event_type=withdraw&min_usd=100000&limit=100" \
  -H "X-API-KEY: $VIKE_API_KEY"

# one wallet's events through the same feed
curl -s "https://data.vike.io/v1/hyperliquid/ledger?wallet=0x25773676902085225ae5751075e4161369334897&limit=100" \
  -H "X-API-KEY: $VIKE_API_KEY"

# follow the feed: every event of 100000 USD or more since a moment, oldest first
curl -s "https://data.vike.io/v1/hyperliquid/ledger?order=asc&start=2026-10-27T12:00:00Z&min_usd=100000&limit=500" \
  -H "X-API-KEY: $VIKE_API_KEY"

walletqueryoptional

One wallet, 0x plus 40 hex, any case

event_typequeryoptional

One of accountClassTransfer, borrowLend, deposit, internalTransfer, rewardsClaim, send, spotTransfer, subAccountTransfer, vaultCreate, vaultDeposit, vaultDistribution, vaultLeaderCommission, vaultWithdraw, withdraw. Validated against this fixed set

min_usdqueryoptional

Minimum absolute amount_usd, 0 or more. Default 0: no floor

startqueryoptional

ISO-8601 UTC. Default: the 24 hours before end (before now when end is empty), unless wallet is given. Resuming an order=asc cursor starts from the cursor instead; a desc cursor keeps the 24-hour floor

endqueryoptional

ISO-8601 UTC. Default: now. A window wider than 31 days is a 400 unless wallet is given

orderqueryoptional

asc | desc. Default desc, newest first. order=asc returns the oldest events first and is the mode for following a feed: pass each nextCursor back verbatim. It orders by key, so a row the writer inserts late with an older key is not seen by a poller already past it: re-read a small overlap. An asc page with rows always carries a cursor; an empty one returns the cursor you sent, or on a first call with no start or wallet, a cursor at the lower bound of the default window (null when one of them already pins the place). So stop on an empty page, not on a null cursor. A desc page the read finds short carries no cursor, but duplicate rows are dropped from a page after it is read, so a page with fewer than limit rows can still carry one: stop on an empty page. Anything else is a 400

limitqueryoptional

Default 100, max 5000

cursorqueryoptional

nextCursor from the previous page, verbatim. It pins the call that returned it: the feed, order, every filter and the start and end you sent. Changing or dropping any of them, start included, is a 400. Without wallet, an asc cursor more than 31 days before end (before now when end is empty) is a 400 too: restart with start

Example response

{
  "items": [
    {
      "ts": "2026-10-27T11:00:24.413000+00:00",
      "wallet": "0xb695651daa495f59dd2725c6fe98322d8b51a92d",
      "event_type": "send",
      "amount_usd": -1000000.0,
      "fee": 2e-05,
      "token": "USDC",
      "counterparty": "0x2000000000000000000000000000000000000000",
      "hash": "0x7ec13659f90166f3803a04477825630207b9003f940485c52289e1acb80540de"
    },
    {
      "ts": "2026-10-27T11:00:24.413000+00:00",
      "wallet": "0x2000000000000000000000000000000000000000",
      "event_type": "send",
      "amount_usd": 1000000.0,
      "fee": 2e-05,
      "token": "USDC",
      "counterparty": "0xb695651daa495f59dd2725c6fe98322d8b51a92d",
      "hash": "0x7ec13659f90166f3803a04477825630207b9003f940485c52289e1acb80540de"
    },
    {
      "ts": "2026-10-27T10:26:51.893000+00:00",
      "wallet": "0x7fdafde5cfb5465924316eced2d3715494c517d1",
      "event_type": "send",
      "amount_usd": -2500000.0,
      "fee": 2e-05,
      "token": "USDC",
      "counterparty": "0x2000000000000000000000000000000000000000",
      "hash": "0x4bde398d23f90e414d57044777b7a90205620072befc2d13efa6e4dfe2fce82b"
    }
  ],
  "nextCursor": "<opaque cursor>"
}

Choose the window. Without a wallet, a call with no start covers the 24 hours before end (before now by default). That floor slides with the clock, and a newest-first cursor without start stops at it, so pass start to read further back. A window of more than 31 days is a 400: from start to end (or now), from an order=asc cursor to end (or now), or from start to a newest-first cursor. An order=asc cursor replaces start as the window's lower edge (keep sending the same start and end: they are pinned in the cursor), so one more than 31 days old is a 400 too: restart with start (ISO 8601, UTC) and read a longer span in slices. Naming a wallet removes all of these rules and reads back through that wallet's history. Events are kept for one year. limit takes 1 to 5000 and defaults to 100; a value above 5000 is a 422. An unknown order is a 400. A call costs 1 credit (Rate limits).

Filter by type or size. event_type takes the same fixed set as the per-wallet route, listed in the parameter table, and is validated against it, because an unknown value would read as an empty feed. min_usd compares the size of amount_usd as stored, whatever its sign (see the warning on units). Most rows are transfers: deposits and withdrawals were about 2% of the feed on 2026-10-27, so a read for capital in or out wants event_type, and a read for large moves wants min_usd.

Page and follow. Newest first is the default, and a page the read finds short has nextCursor: null. Duplicate rows are dropped from a page after it is read, though, so a page with fewer rows than limit after that may still carry a cursor: stop a walk on an empty page, not on a short one. With order=asc the feed runs oldest first from start (or from your cursor), which is how to follow it: keep the last nextCursor and send it back with the same filters. In this mode nextCursor is never null once you hold a cursor, so stop a walk at the first empty page, not at a null; an empty page returns the cursor you sent, so a poller keeps its place. An empty first page with no start and no wallet returns a cursor at the lower edge of the 24-hour window, and with a start or a wallet it returns null: poll again with the same parameters. Rows with the same ts are ordered by hash and then wallet, and the cursor carries all three, so on a table that does not change between your calls a page boundary between the two sides of one transfer neither repeats nor drops a row. A poller that moves forward by cursor never sees a row added late with an older key, nor a row that lands in the same millisecond as its cursor row but sorts before it. The newest two hours come from the live read and can still receive a late row; each hour is read once more in full about two hours after it ends (from about 2 h 5 min), which can add one. If you must not miss one, re-read an overlap with start and drop what you already hold, by ts, hash and wallet: a few seconds back on every poll for the second case, and for the first each hour once, about two hours after it ends (from about 2 h 5 min). Following a feed has the rules, and Freshness says how far behind the venue the feed runs.

A transfer appears once per wallet

A transfer between two wallets is two rows, one for each, with the same ts and hash: the sender's has a negative amount_usd and the receiver's a positive one. Counting rows counts a transfer twice, and summing amount_usd over a feed that holds both sides nets them to zero. Group by hash, or filter to one wallet, before counting or summing.

amount_usd is signed for transfers only

Only transfers (send, spotTransfer, internalTransfer, subAccountTransfer) carry a negative amount, on the sender's row. Every other event type, withdraw included, is stored as a positive number: read the direction of a deposit or a withdrawal from event_type, never from the sign.

amount_usd is dollars except on borrowLend and rewardsClaim in other tokens

amount_usd is a USD value (0 when the venue gives none), except on borrowLend and rewardsClaim rows whose token is not USDC. There it is that token's own amount, not dollars: a borrowLend row of HYPE reading 100.0 is 100 HYPE, and a UBTC row is a number of coins. Check token before summing. min_usd floors on the number as stored, so those rows pass or fail on their token amount, not on what it is worth.

send is recorded one-sided

send is recorded one-sided for some events: the outflow is seen while the matching inflow is not. That is the same defect the flow_unbalanced flag on /leaderboard/flow-adjusted reports, so a net flow built from send rows alone can be wrong. The one-sided rows have a null counterparty, which is how to spot them.

Without a wallet the window is the last 24 hours

A call with no wallet and no start starts 24 hours back from now (or from end), not at the beginning of the feed, and an unfiltered read of that day holds well over a hundred thousand rows. Only an order=asc cursor lifts the floor; a newest-first cursor keeps it. Pass start (31 days at most) to read further back, and min_usd or event_type to keep the answer small.