Rank traders on one chain
Traders ranked over a rolling window, filtered on win rate, volume, holding time, capital tier and behaviour.
exclude_bots removes market makers as well as bots: their edge is inventory and latency rather than directional skill, so ranking them beside discretionary traders compares two different games.
Sorting on win_rate only ranks wallets with enough rated positions for the ratio to carry information. A wallet that clearly has winning trades but reports win_rate 0 has too small a rated sample — read trade_win_rate instead, and rated_positions for the sample size.
Query Parameters
chain slug (ton) or numeric chain id (950000)
1 <= length <= 32rolling window the metrics are computed over
"30d"Value in
- "1d"
- "7d"
- "30d"
- "1y"
- "all"
total_pnl ranks on realised profit plus open positions marked to market, so a wallet sitting on a large unrealised gain is not ranked below wallets that merely took profit. realized_pnl ranks on taken profit alone. win_rate ranks only wallets with enough rated positions for the ratio to carry information. user_score ranks on the wallet score.
"total_pnl"Value in
- "total_pnl"
- "realized_pnl"
- "volume"
- "win_rate"
- "trades"
- "user_score"
"desc"Value in
- "asc"
- "desc"
doubledoubledouble0..1
double0 <= value <= 1uint32int64uint320 <= value <= 100only wallets with no abuse evidence at all, not merely little
comma-separated capital tiers
items <= 8page size; plans above startup may raise the ceiling
int321 <= value <= 10010opaque cursor from next_cursor or prev_cursor
length <= 512Header Parameters
payment methods the client can use, comma-separated, case-insensitive. With x402 in the list, a spent keyless budget answers 402 with the x402 challenge instead of 429.
base64 x402 v2 payment payload for this request. A paid request skips the keyless budget and is settled only when it answers 2xx. The v1 header X-PAYMENT is accepted too.
Response Body
application/json
application/problem+json
application/problem+json
application/json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
curl -X GET "https://example.com/wallets?chain=string"{ "items": [ { "address": "string", "chain": { "slug": "hyperliquid", "chain_id": 0 }, "tier": "string", "type": "unknown", "labels": [ { "kind": 0, "name": "string", "confidence": 0.1, "token_address": "string" } ], "copy_eligible": true, "user_score": { "value": 0, "status": "unknown" }, "scammer_score": { "value": 0, "band": "none" }, "metrics": { "window": "1d", "realized_pnl_usd": 0.1, "unrealized_pnl_usd": 0.1, "total_pnl_usd": 0.1, "rated_pnl_usd": 0.1, "gross_profit_usd": 0.1, "gross_loss_usd": 0.1, "invested_usd": 0.1, "volume_usd": 0.1, "roi": 0.1, "win_rate": 0.1, "trade_win_rate": 0.1, "median_roi": 0.1, "profit_factor": 0.1, "avg_trade_usd": 0.1, "avg_hold_seconds": 0, "trades": 0, "winning_trades": 0, "losing_trades": 0, "tokens_traded": 0, "closed_positions": 0, "open_positions": 0, "rated_positions": 0, "excluded_transfer_only": 0, "excluded_untracked": 0, "excluded_no_outcome": 0 } } ], "next_cursor": "string"}One yield farm GET
The farm at one LP contract address, in the row shape the screener serves. `404` when the address is not a farm this API indexes on that chain — which is not the same as a farm with nothing staked, and is why watching one pool does not mean paging the screener.
Trader population per chain GET
Population-level counts of the traders on each chain — the wallet counterpart of the chain header in `/config`. It is a separate call on purpose: these aggregates live in the wallet-analytics store, and folding them into the bootstrap config would put every page load behind them. Omit `chains` for every chain whose wallet data is served.