/tokens/{token_address}/transfers

Who bought and who sold a token over a period — the top buyers or the top sellers with quantities and USD values.

GET https://data.vike.io/v1/onchain/tokens/{token_address}/transfers

Who bought and who sold a token over a period — the top buyers or the top sellers with quantities and USD values. tab selects which side you get; it is one side per call, not both.

Half these fields are presentation, not data

addr_short, the six *_fmt strings, net_usd_raw and net_bar_pct are pre-rendered for a UI — net_bar_pct is a bar width, and net_usd_fmt: "-$904.41K" on the first row is a formatted string, not a number. A machine consumer wants address, bought, sold, net_tokens, usd_spent, usd_received, net_usd and chains, and should ignore the rest.

net_usd and net_tokens carry opposite signs by convention

The sign difference is a convention, not a defect: net_tokens is bought − sold and net_usd is usd_received − usd_spent, so a net buyer has a positive net_tokens and a negative net_usd (row 1 of the capture). The six amount fields are whole tokens and plain USD, and net_usd agrees with net_usd_raw up to cents. Until 2026-10-13 they came back 1,000,000 times too large; if you divided them yourself, stop.

bought and usd_spent are byte-identical on every captured row, as are sold and usd_received

In the capture that is a token quantity and a USD amount reported as the same number. For a stablecoin those are legitimately close, but they are exactly equal here, so do not assume usd_spent has been priced independently of the token count.

bought and sold count every transfer in and out, flash-loan round trips included

A row's bought is everything the wallet received in the period, not what it purchased. Over the 7d to 2026-10-18 the top USDT "buyer", 0x808c3ba97268dbf9695b1ec10729e09c7e67a9e3, showed $56.9B bought and $56.9B sold, all of it inside 524 transactions in under four hours on 2026-10-17: a bot borrowed about $40M from Morpho in a flash loan, passed it back and forth with that contract some 137 times per transaction, and repaid it. The figures match the chain to the dollar; what they measure is transfer volume. Read net_tokens before calling a wallet a buyer.

cURL

# who sold the most USDC over the 24h period (ten rows, one side per call)
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/tokens/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48/transfers?period=24h&tab=sold"

# the other side of the same period: who bought the most
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/tokens/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48/transfers?period=24h&tab=bought"

# only the past hour, to see what a move is made of while it is happening
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/tokens/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48/transfers?period=1h&tab=sold"

# a longer window: the biggest buyers over 7d (30d is the longest period)
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/tokens/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48/transfers?period=7d&tab=bought"

# one token across every chain at once: the address is mapped to the token's address on each chain
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/tokens/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48/transfers?period=24h&tab=sold&chain=all"

# a machine consumer's view: keep the data fields, drop the pre-rendered presentation strings
curl -s -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/tokens/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48/transfers?period=24h&tab=sold" \
  | jq '[.[] | {address, bought, sold, net_tokens, usd_spent, usd_received, net_usd, chains}]'

token_addresspathrequired

Token contract address, 0x-prefixed

periodqueryoptional

1h | 24h | 7d | 30d. Default 24h

tabqueryoptional

bought | sold. Default sold

chainqueryoptional

ethereum | bsc | base | all. Default ethereum

USDC sellers over 24h, captured 2026-10-18. The response is a bare array of exactly 10 rows, ranked by sold — confirming the fixed limit below. The first two rows are shown verbatim; the other eight have the same 18 fields.

Example response

[
  {
    "address": "0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcb",
    "bought": 17458677638.932724,
    "sold": 17457773225.279156,
    "net_tokens": 904413.653569,
    "usd_spent": 17458677638.932724,
    "usd_received": 17457773225.279156,
    "net_usd": -904413.653569,
    "chains": [
      "eth"
    ],
    "title": null,
    "addr_short": "0xbbbb...ffcb",
    "bought_fmt": "17.46B",
    "sold_fmt": "17.46B",
    "net_tokens_fmt": "904.41K",
    "usd_spent_fmt": "$17.46B",
    "usd_received_fmt": "$17.46B",
    "net_usd_raw": -904413.65,
    "net_usd_fmt": "-$904.41K",
    "net_bar_pct": 0
  },
  {
    "address": "0xd1c6aca7ea7ed44e1873dafa054c28ceb690c7eb",
    "bought": 12901699068.088577,
    "sold": 12901699068.088577,
    "net_tokens": 0.0,
    "usd_spent": 12901699068.088577,
    "usd_received": 12901699068.088577,
    "net_usd": 0.0,
    "chains": [
      "eth"
    ],
    "title": null,
    "addr_short": "0xd1c6...c7eb",
    "bought_fmt": "12.90B",
    "sold_fmt": "12.90B",
    "net_tokens_fmt": "0.0",
    "usd_spent_fmt": "$12.90B",
    "usd_received_fmt": "$12.90B",
    "net_usd_raw": 0.0,
    "net_usd_fmt": "$0.0",
    "net_bar_pct": 0
  }
]

The row count is fixed at 10 and there is no way to change it

The route exposes no limit parameter, and the MCP tool ignores one if you send it. For a longer ranking, use /holders.