/wallets/compare

Are these two wallets related? Returns the counterparties both wallets transacted with and the tokens both touched, within a window.

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

Are these two wallets related? Returns the counterparties both wallets transacted with and the tokens both touched, within a window. Declared before /wallets/{address} so that compare is not read as an address.

summary counts what was returned, not what exists

Both counts read 3 against a limit=3 call — they are the length of the returned arrays, already truncated by limit. A shared_token_count of 3 therefore does not mean these two wallets share exactly three tokens; it means you asked for three. Raise limit (applied cap 50) until the count stops rising if you need the true overlap.

Choose both addresses for activity, or the answer is empty and says nothing

Run against a quiet address and shared_counterparties comes back [] — a truthful result that reads identically to "unrelated". The captured pair are both high-traffic wallets, which is why the overlap is populated. a_volume_usd of 101.77817 against b_volume_usd of 782907715.73 on the third row is the useful shape here: a shared counterparty can be central to one wallet and incidental to the other, so weigh the two columns rather than treating any shared row as evidence of a link.

cURL

# are these two wallets related: the counterparties and tokens both touched over 30 days, three of each
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/compare?address_a=0x28C6c06298d514Db089934071355E5743bf21d60&address_b=0xeae7380dd4cef6fbd1144f49e4d1e6964258a4f4&limit=3&window=30d"

# a wider cut of the overlap: summary counts what was returned, so at the cap of 50 a count of 50 may still be truncated
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/compare?address_a=0x28C6c06298d514Db089934071355E5743bf21d60&address_b=0xeae7380dd4cef6fbd1144f49e4d1e6964258a4f4&limit=50&window=30d"

# a longer window: does the overlap persist, or was it a month's coincidence
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/compare?address_a=0x28C6c06298d514Db089934071355E5743bf21d60&address_b=0xeae7380dd4cef6fbd1144f49e4d1e6964258a4f4&limit=50&window=180d"

# and the narrowest: this week only
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/compare?address_a=0x28C6c06298d514Db089934071355E5743bf21d60&address_b=0xeae7380dd4cef6fbd1144f49e4d1e6964258a4f4&limit=50&window=7d"

# weigh the two sides of each shared counterparty: one that is central to A and incidental to B is not evidence of a link
curl -s -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/compare?address_a=0x28C6c06298d514Db089934071355E5743bf21d60&address_b=0xeae7380dd4cef6fbd1144f49e4d1e6964258a4f4&limit=50&window=30d" \
  | jq '[.shared_counterparties[] | {wallet, entity, a_volume_usd, b_volume_usd}]'

# the same pair on BSC
curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/wallets/compare?address_a=0x28C6c06298d514Db089934071355E5743bf21d60&address_b=0xeae7380dd4cef6fbd1144f49e4d1e6964258a4f4&limit=50&window=30d&chain=bsc"

address_aqueryrequired

First wallet

address_bqueryrequired

Second wallet

chainqueryoptional

ethereum | bsc | base. Default ethereum

windowqueryoptional

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

limitqueryoptional

Max shared items per category. Route default 100; applied cap 50

Binance 14 against a Wintermute market-making wallet, captured 2026-09-03. The full response is shown except that shared_tokens is trimmed from three entries to one.

Example response

{
  "address_a": "0x28C6c06298d514Db089934071355E5743bf21d60",
  "address_b": "0xeae7380dd4cef6fbd1144f49e4d1e6964258a4f4",
  "window": "30d",
  "chain": "ethereum",
  "shared_counterparties": [
    {
      "wallet": "0x51c72848c68a965f66fa7a88855f9f7784502a7f",
      "a_volume_usd": 3124737069.567188,
      "b_volume_usd": 27413487685.73743,
      "a_tx_count": 361,
      "b_tx_count": 1434,
      "entity": "wintermute",
      "wallet_type": "market_maker"
    },
    {
      "wallet": "0xf8191d98ae98d2f7abdfb63a9b0b812b93c873aa",
      "a_volume_usd": 8952220569.76122,
      "b_volume_usd": 6464235700.270625,
      "a_tx_count": 518,
      "b_tx_count": 1472,
      "entity": "wintermute",
      "wallet_type": "market_maker"
    },
    {
      "wallet": "0xa9d1e08c7793af67e9d92fe308d5697fb81d3e43",
      "a_volume_usd": 101.77817,
      "b_volume_usd": 782907715.73214,
      "a_tx_count": 3,
      "b_tx_count": 752,
      "entity": "coinbase",
      "wallet_type": "cex"
    }
  ],
  "shared_tokens": [
    {
      "token_address": "0x5a98fcbea516cf06857215779fd812ca3bef1b32",
      "a_volume_usd": 261683883072.97073,
      "b_volume_usd": 80125236671.59358,
      "a_tx_count": 2266,
      "b_tx_count": 378
    }
  ],
  "summary": {
    "shared_counterparty_count": 3,
    "shared_token_count": 3
  }
}

Both addresses are required, and both are query parameters rather than path segments. Omitting either is a 422 carrying a validation list ({"detail":[{"type":"missing","loc":["query","address_b"],…}]}, measured live). Sending both but leaving one blank is a different failure: a 400 reading address_a and address_b are required.