Recipe 23 of 65
Wash trading between two Hyperliquid addresses: did they trade with each other?
Fetch both wallets' fills for the same coin and window from /v1/hyperliquid/wallets/{address}/fills and join them on trade_id, which both sides of one trade share.
GET /v1/hyperliquid/wallets/{address}/fills answers it, one call per wallet. A fill names no counterparty, but it
carries trade_id, and the buyer's fill and the seller's fill of one trade carry the same value. Fetch each wallet's
fills for the same coin and window, then join the two lists on trade_id. Every id found in both lists, on opposite
sides, is one trade between them; sum its size_usd for the volume they traded together. The full parameter list is on
Wallet fills.
Quick answer
Fetch the first wallet's fills for one coin and window.
# wallet A's BTC fills in a three-second window
curl -H "X-API-Key: $VIKE_API_KEY" \
"https://data.vike.io/v1/hyperliquid/wallets/0x53136b4a7c432585f28903b77c7816a723e0271f/fills?symbol=BTC&start=2026-10-24T17:13:32Z&end=2026-10-24T17:13:35Z&limit=5000"Example response
Captured from the live API on 2026-10-24 at 17:15 UTC, all 1 row.
Wallet A bought 1.5211 BTC at 80,075 as the maker (is_maker: true). The same window for wallet B (the first
variation) returned 58 fills, all from one market sell that swept the book, and one of them is a sell of 1.5211 BTC at
80,075 with trade_id 610552908717507 and is_maker: false. Same id, opposite sides: A and B were the two sides of
that trade. size_usd is the notional in USD; side is the side of the wallet the response is for.
{
"wallet": "0x53136b4a7c432585f28903b77c7816a723e0271f",
"items": [
{
"ts": "2026-10-24T17:13:33.040000+00:00",
"symbol": "BTC",
"side": "buy",
"direction": "buy",
"size_token": 1.5211,
"price": 80075.0,
"size_usd": 121802.08249999999,
"fee": -3.654062,
"fee_token": "USDC",
"is_maker": true,
"crossed": false,
"closed_pnl": 0.0,
"order_id": 584769966996,
"trade_id": 610552908717507,
"dex_name": "HL"
}
],
"nextCursor": null
}Variations
The other wallet. Run the same window for the second address, then keep the trade_id values that appear in both responses.
# wallet B's BTC fills in the same window
curl -H "X-API-Key: $VIKE_API_KEY" \
"https://data.vike.io/v1/hyperliquid/wallets/0xb371766bcdcd556ce6b6cf164be6019d01441042/fills?symbol=BTC&start=2026-10-24T17:13:32Z&end=2026-10-24T17:13:35Z&limit=5000"A month, page by page. Over a long window each wallet needs every page. Pass nextCursor back until it is null.
# next page of a one-month read: NEXT is the previous response's nextCursor, passed back verbatim
curl -H "X-API-Key: $VIKE_API_KEY" \
"https://data.vike.io/v1/hyperliquid/wallets/0x53136b4a7c432585f28903b77c7816a723e0271f/fills?symbol=BTC&start=2026-10-01T00:00:00Z&end=2026-10-24T00:00:00Z&limit=5000&cursor=$NEXT"Every pair on a day, without naming the wallets. A day of the fills archive holds both sides of every trade, so a self-join on trade_id lists every pair of
counterparties, including ones you did not suspect.
# a temporary link to every fill of one UTC day, as Parquet
curl -H "X-API-Key: $VIKE_API_KEY" \
"https://data.vike.io/v1/hyperliquid/archive/url?dataset=fills&date=2026-10-23"Before you rely on it
There is no counterparty field
The API cannot tell you who a wallet traded with. You can only test a pair you already suspect, by pulling both
wallets' fills and matching them yourself. The match on trade_id is exact, but it needs every fill of both wallets
in the window: one taker order that sweeps the book is many fills (58 in three seconds in this capture), so page each wallet
until nextCursor is null.
One shared trade is not wash trading
Two active wallets meet in the book by chance. Treat a pair as suspect only when the matches repeat, the sizes offset
each other and neither wallet ends up with a position. In JavaScript, read trade_id as a string or BigInt: some
ids are above 2^53, where a plain number loses digits and two different trades can compare equal.
Ask your agent
Connected to the Vike MCP server (https://vike.io/mcp) in Claude, ChatGPT or Cursor, ask it in plain words.
The hl_wallet_activity tool answers with view: fills, one wallet per call, at 1 credit a call.
Fetch the BTC fills of 0x53136b4a7c432585f28903b77c7816a723e0271f and 0xb371766bcdcd556ce6b6cf164be6019d01441042 between 2026-10-24 17:13:32 and 17:13:35 UTC and list the trade_ids they share