/wallets/discover

The leaderboard: most active wallets over a window, ranked by the metric you pick.

GET https://data.vike.io/v1/onchain/wallets/discover

The leaderboard: most active wallets over a window, ranked by the metric you pick. Use it to find addresses worth investigating, then move to the per-wallet routes.

total is the size of the matching population — 8,330,571 wallets — not the number of rows returned. With size capped at 20 this route is a top-of-leaderboard view; there is no way to page deep into that population from here.

realized_pnl is a ranking key, not a dollar figure

Row 1 reports volume of 2.55e12 alongside realized_pnl of 1.13e16 — a realized profit four thousand times the wallet's own gross volume, which no honest profit can be. It is not a unit mix-up: the route divides every USD column, realized_pnl included, by 1e6 exactly once, so do not divide it again. The fault is in the stored values themselves. The PnL state behind them is fed by a view that re-adds a token's whole history on every reprice, and the cost-basis product then wraps past the 128-bit integer limit on the inflated sums. A measurement on 2026-10-12 found 233 of 500 random Ethereum leaderboard wallets storing a realized_pnl at least ten times the value a rebuild gives. Use realized_pnl and tokens_profitable only to order wallets against each other (a wrapped value can still misplace a wallet), and note that pnl_available: 1 only asserts that a value was computed, not that it is right.

first_seen here is not a lifetime first-seen either

All three rows report June 2026 against a window=30d call — earlier than the window, so it is not simply clamped to it as on /counterparties, but it is also far too recent for wallets of this size to be genuinely new. Read it as "first seen in the dataset behind this route". /wallets/{address} reported 2016-08-05 for a wallet on the same day, so the two routes do not agree on what the field means.

cURL

# the busiest wallets by volume over 30 days, three of them (only wallets that have a computed PnL, pnl_available 1, are listed)
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/discover?size=3&window=30d"

# the largest net buyers of the week: net_flow is inflow minus outflow, so the biggest positive values lead
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/discover?window=7d&sort=net_flow&order=desc&size=20"

# the largest net sellers of the week: the same sort ascending, most negative net_flow first
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/discover?window=7d&sort=net_flow&order=asc&size=20"

# the most active wallets by transaction count over 24h
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/discover?window=24h&sort=tx_count&size=20"

# rank by stored realized_pnl over 90d, as an ordering only: the realized_pnl warning above says why it is not a dollar figure
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/discover?window=90d&sort=pnl&size=20"

# all recorded history rather than a sliding window, for a lifetime ranking
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/discover?window=all&sort=volume&size=20"

# the same leaderboard on BSC
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/discover?chain=bsc&window=7d&sort=volume&size=20"

windowqueryoptional

24h | 7d | 30d | 90d | all. Default 30d

sortqueryoptional

orderqueryoptional

asc | desc. Default desc

chainqueryoptional

ethereum | bsc. Default ethereum

sizequeryoptional

Results per page. Default 10, max 20 — one of the two routes in this namespace whose accepted and applied caps agree, alongside /tokens/search

The full response for size=3, captured 2026-09-03 — all three wallets plus the total.

Example response

{
  "wallets": [
    {
      "address": "0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcb",
      "volume": 2552546474138.343,
      "inflow": 1276307059282.2302,
      "outflow": 1276239414856.1125,
      "net_flow": 67644426.117664,
      "tx_count": 367347,
      "tokens_traded": 33,
      "first_seen": "2026-06-04",
      "last_active": "2026-09-02",
      "realized_pnl": 11268691976748202,
      "tokens_profitable": 18,
      "pnl_available": 1
    },
    {
      "address": "0x06cff7088619c7178f5e14f0b119458d08d2f5ef",
      "volume": 695617826252.817,
      "inflow": 347809463499.2067,
      "outflow": 347808362753.6103,
      "net_flow": 1100745.596406,
      "tx_count": 174226,
      "tokens_traded": 245,
      "first_seen": "2026-06-04",
      "last_active": "2026-09-02",
      "realized_pnl": 2399649170518083.5,
      "tokens_profitable": 76,
      "pnl_available": 1
    },
    {
      "address": "0xd226997439ecfbeff8e110c8c78c8a7eefd19f89",
      "volume": 424200696674.0756,
      "inflow": 212100372292.9297,
      "outflow": 212100324381.146,
      "net_flow": 47911.7837,
      "tx_count": 70510,
      "tokens_traded": 155,
      "first_seen": "2026-06-05",
      "last_active": "2026-09-03",
      "realized_pnl": 3120711434553757.0,
      "tokens_profitable": 33,
      "pnl_available": 1
    }
  ],
  "total": 8330571
}

Note the parameter is size, not limit, and the chain enum is narrower here than elsewhere in the namespace: ethereum and bsc only, no base.

Each row carries address, volume, inflow, outflow, net_flow, tx_count, tokens_traded, first_seen, last_active, realized_pnl, tokens_profitable and pnl_available, alongside a total.

Every USD-denominated column reaches you as plain USD

The columns are already scaled — do not rescale them.