Wallets
Summarize, rank, trace, compare and label EVM wallets, and read their raw transfers, balances and daily flows.
13 tools for wallet analytics on Ethereum, BSC, Base and HyperEVM. They divide into four jobs:
describe one wallet (wallet_summary, wallet_transactions, wallet_token_balances,
wallet_pnl_history), find or connect wallets (wallet_discover, wallet_counterparties,
wallet_trace, wallet_compare), name them (wallet_ens, wallet_batch_labels,
wallet_label_provenance), and say where one came from and which exchanges it uses
(wallet_first_funder, wallet_exchange_usage).
Addresses are 0x-prefixed EVM hex throughout. Numeric parameters accept either a number or its
string spelling — an agent that passes "30" instead of 30 is coerced, not rejected.
wallet_ens (Ethereum mainnet names) and wallet_label_provenance (Ethereum) are Ethereum only.
wallet_summary
2 credits. A wallet's aggregate metrics: volume, inflow, outflow, net flow, transaction
count and tokens traded, across the 24h / 7d / 30d / 90d / all windows. There is no window
parameter — one call returns every window. Without chain the tool answers for the more recently
active of ethereum and bsc, and for base or hyperevm only when the wallet has no priced
ethereum/bsc volume, so a dust transfer on another chain never changes the answer. Pass chain to ask for
one chain. The chain field of the result says which chain answered.
| Parameter | Type | Required | Notes |
|---|---|---|---|
address | string | yes | Wallet address (0x-prefixed hex) |
chain | enum | no | Answer for this chain only (default: see the tool description) One of ethereum, bsc, base, hyperevm. |
What has 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 been doing lately?
wallet_discover
2 credits. Top wallets ranked by a metric you choose — volume, inflow, outflow, net flow, transaction count, or realized PnL.
| Parameter | Type | Default | Notes |
|---|---|---|---|
window | enum | 30d; all on base and hyperevm | 24h, 7d, 30d, 90d, all. On base and hyperevm, all always works; the others only while that chain's window tables were refreshed within the last two days, otherwise a 400 |
sort | enum | volume | volume, inflow, outflow, net_flow, tx_count, pnl |
order | enum | desc | asc or desc |
chain | enum | ethereum | ethereum, bsc, base, hyperevm |
size | integer | 10 | Results per page, capped at 20 |
include_hubs | boolean | false | Also rank round-trip hubs (flash-loan/MEV/router pass-through wallets: volume of $10B or more, net flow and realized PnL each within 0.1% of it), hidden by default |
Returns {"wallets": [...], "total": n}. Each row carries address, volume, inflow,
outflow, net_flow, tx_count, tokens_traded, first_seen, last_active,
realized_pnl, tokens_profitable and pnl_available — the USD columns already converted to
whole dollars.
Top 20 BSC wallets by realized PnL over the last 7 days.
wallet_transactions
2 credits. The raw per-wallet transfer list — single transactions, not aggregates. This is the forensic tool: use it when the question is "show me the actual transfers", not "how much did this wallet do".
| Parameter | Type | Default | Notes |
|---|---|---|---|
address | string | required | Wallet address (0x-prefixed) |
chain | enum | ethereum | ethereum, bsc, base, hyperevm |
direction | enum | all | in, out, all |
days | integer | 30 | Days back, max 365 |
limit | integer | 50 | Max transactions, max 500 |
min_usd | number | 0 | Drop dust below this USD value |
token_address | string | — | Restrict to one token |
Returns per transfer: time, tx_hash, from, to, token_address, value_usd,
direction, block.
List the last 100 outgoing transfers over $10k from 0xabc… on Base.
wallet_token_balances
3 credits. Current balances for a wallet on ethereum, bsc, base and hyperevm — the chain's
native coin and its ERC-20 tokens — read from the chain at request time. Token holdings below $1 are
filtered by default; the native coin is listed whatever the floor.
| Parameter | Type | Default | Notes |
|---|---|---|---|
address | string | required | Wallet address (0x-prefixed) |
chains | array | ethereum, bsc, base, hyperevm | Chains to scan; only these four are served, and all four are scanned by default. Any other chain is reported in chain_errors |
min_usd | number | 1 | Drop token holdings below this USD value; the native coin is listed whatever the floor when non-zero |
Returns one row per holding: chain, symbol, balance, USD value, USD price.
On base and hyperevm, symbol, name, balance and usd_value exist only for tokens we map and
price (about 170 on base, about 50 on hyperevm). Any other token the wallet holds is listed
only with min_usd=0 (the default floor of $1 keeps priced tokens only): then it carries its contract
address and balance_raw, and those four fields are null. Native balances (ETH, BNB, HYPE) are priced
and counted in total_usd; their usd_value and usd_price are null only where we hold no price for the coin. hyperevm
means the HyperEVM chain only: assets in HyperCore (spot or perp accounts) are not included.
Pair it with wallet_label_provenance for institutional context.
What tokens does this wallet hold right now on Ethereum, BSC, Base and HyperEVM?
wallet_pnl_history
2 credits. A daily net-flow series for a wallet — per-day net inflow USD, plus cumulative net flow, gross volume and transaction count.
| Parameter | Type | Default | Notes |
|---|---|---|---|
address | string | required | Wallet address (0x-prefixed) |
chain | enum | ethereum | ethereum, bsc, base, hyperevm |
days | integer | 30 | Days back, max 365 |
This is net inflow, not realized PnL
The tool's own description says so: true realized PnL would need weighted-average-cost accounting per token, which this series does not do. Read it as a directional indicator of whether a wallet has been accumulating or distributing, not as a profit figure.
Plot the daily net flow of 0xabc… over the last 90 days.
wallet_counterparties
2 credits. Top trading partners of a wallet by combined transfer volume.
| Parameter | Type | Default | Notes |
|---|---|---|---|
address | string | required | Wallet address (0x-prefixed) |
chain | enum | ethereum | ethereum, bsc, base, hyperevm |
window | enum | 30d | 24h, 7d, 30d, 90d, 180d, all |
limit | integer | 10 | Max counterparties, max 50 |
Returns per counterparty: address, total volume, amount sent and received, transaction
count, first and last seen, and labels where known. Labels come from the requested chain's own
label table, not Ethereum's.
Who does this wallet trade with most?
wallet_trace
4 credits — the most expensive tool in the catalogue. Follows a wallet's money hop by hop:
at each hop it expands to the top N counterparties by USD volume and repeats, returning the
nodes and edges of the resulting graph. direction picks which money: out where it went, in
where it came from, both (the default) either way, ranked by the two summed.
| Parameter | Type | Default | Notes |
|---|---|---|---|
address | string | required | Root wallet to trace from |
chain | enum | ethereum | ethereum, bsc, base, hyperevm |
depth | integer | 2 | Hops to follow, 1–5 |
width | integer | 5 | Top N counterparties per hop, 1–10 |
window | enum | 30d | 24h, 7d, 30d, 90d, all |
min_usd | number | 10000 | Minimum USD per transfer to follow |
direction | enum | both | out = where funds went, in = where they came from, both = either (default both) One of both, out, in. |
Cost grows with depth × width, and so does noise. Lowering min_usd on a busy wallet
widens the graph fast; the $10k floor exists to keep a trace legible.
Follow the money three hops out from 0xabc…, top 5 counterparties per hop.
wallet_compare
3 credits. Asks whether two wallets are related, by intersecting what they touched: shared counterparties (addresses both wallets transacted with) and shared tokens (tokens both wallets traded) inside one window.
| Parameter | Type | Default | Notes |
|---|---|---|---|
address_a | string | required | First wallet |
address_b | string | required | Second wallet |
chain | enum | ethereum | ethereum, bsc, base, hyperevm |
window | enum | 30d | 24h, 7d, 30d, 90d, 180d, all |
limit | integer | 10 | Max shared items per category, max 50 |
An overlap is evidence, not proof — two wallets that both used a large exchange share that counterparty with everyone else.
Are 0xaaa… and 0xbbb… related? Compare them over 90 days.
wallet_ens
1 credit. Reverse ENS lookup: an address in, a name like vitalik.eth out, or null when
the address has no ENS name set.
| Parameter | Type | Required | Notes |
|---|---|---|---|
address | string | yes | EVM address (0x-prefixed, 42 chars) |
What is the ENS name for 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045?
wallet_batch_labels
2 credits. Bulk enrichment: labels plus a 30-day summary for many addresses in one call. Rows come back in input order, so a pasted CSV keeps its shape.
| Parameter | Type | Default | Notes |
|---|---|---|---|
addresses | array | required | Wallet addresses (0x-prefixed), max 100 |
chain | enum | ethereum | ethereum, bsc, base, hyperevm |
Returns one row per input address: entity, wallet_type, risk_flag, 30-day net flow,
30-day volume, 30-day transaction count.
chain selects which chain's labels and transfers are read: ethereum, bsc, base and
hyperevm each read their own. The four 30-day fields (net_30d_usd, volume_30d_usd, tx_30d,
tokens_30d_count) are computed live over the last 30 calendar days, the same window as the 30-day
figures of wallet_summary, on every chain. They are null only for an address with no label
(found: false); a labelled wallet with no transfer in the window reads 0. A wallet flagged exploit
is typed flagged, never cex. hyperevm has labels for only a few hundred wallets.
Here are 60 addresses — label them and tell me which ones moved money this month.
wallet_label_provenance
1 credit. The full label cascade for one Ethereum wallet, with per-source attribution: several third-party label providers and Vike's heuristic classifier, plus a consensus entity and type.
| Parameter | Type | Required | Notes |
|---|---|---|---|
address | string | yes | Wallet address (0x-prefixed hex) |
Use this when the answer matters enough that who says so matters: a single consensus label hides whether seven sources agreed or one source guessed.
Who labeled this address, and do the sources agree?
wallet_first_funder
2 credits. The earliest inbound transfers of a wallet, as two separate answers read from our own
transfer tables: first_native_in, the first plain send of the chain's coin, and first_token_in, the
first priced token transfer. Each carries the sender, the sender's label, the time, the transaction
hash, the block and the amounts. The two are kept apart on purpose: a wallet is often funded in coin
and first touched by a token, and one tool answering "the funder" would hide which.
| Parameter | Type | Default | Notes |
|---|---|---|---|
address | string | required | Wallet address (0x-prefixed) |
chain | enum | ethereum | ethereum, bsc, base, hyperevm; read from that chain's own transfer and label tables |
min_native | number | 0.0001 | Dust floor for the native coin in whole coins (ETH, BNB or HYPE; 0.01 is 0.01 coin, not wei). 0 means no floor: the very first inbound, probing dust included |
min_usd | number | 1 | Floor for the token side in USD. Tokens priced below it, or not priced, are skipped; 0 includes unpriced tokens, which are mostly spam |
Returns {address, chain, found, first_native_in, first_token_in, coverage}. first_native_in has
from, label, wallet_type, label_confidence, time, tx_hash, block, amount (whole coins),
amount_symbol, amount_wei (exact, as a string) and amount_usd; first_token_in has the same with
token_address, symbol and amount in whole tokens. amount_usd is plain dollars and is null
where we hold no price (an Ethereum transfer from 2015, a token we do not price), never 0. A side
with no inbound that clears its floor is null; found is false when both are.
The first inbound we hold, not proof of who funded the wallet
Native rows hold top-level sends only. Coin moved by a contract call, a bridge relay or a batch payout
is not in them, so the real first funding can be earlier than the one returned, and the sender may be an
exchange or a relay rather than a person. History also starts on a different date per chain: read
coverage.history_from (on 2026-10-19 it was 2015-08-07 on ethereum, 2020-11-06 on bsc, 2023-06-15
on base and 2025-02-18 on hyperevm). A sender's label is the label table's consensus entity with its
label_confidence. On hyperevm, protocol system addresses appear as senders and come back with
wallet_type system and no entity name, and labels there are sparse, so an unlabelled sender says little.
An address with a very long history can take several seconds; if a read does not finish in 20 seconds
the call is refused with a message saying to retry or to pass min_native=0 and min_usd=0.
Who first funded 0x556e9d5d9e64638edde632bbd4810c9fd0d88397, and was it an exchange?
wallet_exchange_usage
3 credits. Which centralised exchanges a wallet sent to and received from over a window, computed per request from the wallet's transfers joined to the addresses the chain's label table marks as exchanges. For each exchange: USD sent to it and received from it, transfer counts, first and last contact, how many of its addresses were involved, and how sure the labels are.
| Parameter | Type | Default | Notes |
|---|---|---|---|
address | string | required | Wallet address (0x-prefixed) |
chain | enum | ethereum | ethereum, bsc, base, hyperevm; read from that chain's own transfer and label tables |
window | enum | 365d | 30d, 90d, 180d, 365d, all. A very active wallet over a long window is refused with a message to narrow it |
Returns {address, chain, window, found, activity, exchanges, pattern, pattern_basis, coverage}.
activity totals the wallet's priced transfers with every counterparty, exchange or not
(sent_usd, recv_usd, transfers, counterparties), so a share can be checked. Each row of
exchanges has entity, sent_usd, recv_usd (plain dollars: sent is wallet to exchange, received
is exchange to wallet), sent_share (the exchange's part of all outgoing USD), transfers,
sent_transfers, recv_transfers, first_seen, last_seen, addresses, label_confidence (counts of
the pipeline's high, medium and unrated) and label_sources (counts of addresses labelled by a
third-party provider and by our own heuristic; an address can count in both). found is false when the
wallet has no priced transfer in the window.
An observed pattern, and a lower bound
pattern is "sweeps_to_single_cex" when at least 90% of the wallet's outgoing USD in the window went to
one exchange over at least three outgoing transfers. It describes the transfers; it does not say the
address is a deposit address or that the exchange operates it. Exchange figures are a lower bound: an
exchange address we have not labelled is invisible here, and hyperevm has labels for only a few hundred
wallets, so an empty exchanges there says little. Only priced transfers count, and native rows are
top-level sends, so a payout routed through a contract call shows only if it emits token transfers.
Which exchanges does 0x556e9d5d9e64638edde632bbd4810c9fd0d88397 use, and does it sweep to one of them?