GitHub MCP RegistryListed
Vike Data API
Crypto data for AI agents: on-chain wallets, Hyperliquid, HL Cohorts, Polymarket and Predict.fun.
First seen 31 Oct 2026. Evidence as of 13 Nov 2026.
83
Tools
From an anonymous probe
1
Source listings
Each with its own history
21
Recorded changes
Since first seen
Tools
| Tool | Description | Behaviour |
|---|---|---|
| alerts_create | Create an alert rule for the current user: an on-chain transfer alert (the default), a Hyperliquid or a Polymarket alert, chosen by `alert_type`. TRANSFER ('transfer'): fires when a transfer on ONE chain (eth, bsc, base or hyperevm) matches: token_symbol if given, min_value_usd if given, and, if `address` is given, that wallet on the side `address_role` says. `address` = ONE 20-byte EVM address ('0x' + 40 hex); ENS names, entity names and non-EVM addresses are refused. Without min_value_usd EVERY transfer touching the address matches (dust and unpriced tokens too); with min_value_usd or max_value_usd only transfers that already carry a USD value do. min_amount (needs token_symbol) is a floor in whole tokens, priced or not; set with a USD bound, both must hold. An alert with an `address` notifies on EVERY matching transfer: no cooldown, no daily cap. A token-wide alert (no address) sends one notification per cooldown_minutes for the newest match, at most 10 a day. HYPERLIQUID (perpetuals only; leave out chain, address, address_role and max_value_usd): hl_wallet = every fill of `wallet` (required), narrowed by `actions`, `token_symbol` (the coin) and min_value_usd; hl_cohort_fill = every fill by wallets in `pnl_cohorts` / `size_cohorts` (at least one cohort is REQUIRED, or it would match every large fill on Hyperliquid), REQUIRES min_value_usd >= 10000; hl_liquidation = every liquidation, optionally of one `wallet`, of cohorts, of one coin, above a min_value_usd floor; hl_cohort_bias = the cohort `index` of `token_symbol` (required) crossing `threshold` by `band`, filtered by `direction`; hl_liq_proximity = `wallet` (required) getting `threshold` of the way from entry to liquidation price. Fill and liquidation alerts notify on every event; a wallet alert once per coin, action and side of each evaluator pass (about every 10 s): the fills merged into one event, `fills` their count, min_value_usd applied to the merged total. Bias and proximity alerts notify once per crossing and re-arm after the value retreats by `band`. POLYMARKET (leave out chain, address, address_role, max_value_usd and token_symbol): pm_wallet_trade = every trade of the proxy `wallet` (required), optionally in one `condition_id` and above min_value_usd; pm_market_trade = every trade in `condition_id` (required) at or above min_value_usd (REQUIRED, >= 1000); pm_price_move = a move of 0.05 or more within 5 minutes in the price of the market's first outcome (Yes), filtered by `direction`; pm_resolution = the market resolved. Each notifies on every event. cooldown_minutes does not apply to Hyperliquid or Polymarket alerts. They are delivered by a webhook channel (register one with alerts_register_webhook) and/or e-mail, or only read with alerts_events (channels left empty); `channels` = ['email'] mails the account address: one mail per evaluator pass listing its events, and (but for hl_wallet) none after the alert's 10th event of the UTC day. `label` is the user-visible name. `channels` = ['email'], ['webhook'] or both (Discord is temporarily off and is refused). One address and one chain per transfer alert: create several alerts to watch more. Returns the new alert row including its id, its `policy` and, for a Hyperliquid or Polymarket alert, an `hl` or `pm` object. | Destructive |
| alerts_delete | Delete one of the user's alerts by id. Soft-delete (pauses it, keeps history) by default; pass hard=true to remove permanently. Returns {ok: true} on success. | Destructive |
| alerts_edit | Partial update of one of the user's alerts. Only the fields you pass are modified; pass alert_id to identify which one (get it from alerts_list). Use is_active=false to pause an alert without deleting it. `address` replaces the alert's wallet condition (one per alert; same rules as alerts_create); address='' removes it; `address_role` alone moves the existing address to that side. The fields mean what they mean in alerts_create, and a Hyperliquid alert (its type cannot change) is re-validated whole after the edit: '' or [] clears an optional field such as token_symbol or pnl_cohorts, and a field its type does not use is an error. `channels` replaces the list (email or webhook; Discord is off); [] leaves a Hyperliquid or Polymarket alert feed-only, read with alerts_events. | Destructive |
| alerts_events | Read the events the current user's alert rules produced, oldest first (the feed behind GET /v1/alerts/events). Page forward by passing the returned `next_cursor` back as `cursor`; an empty page returns the same cursor, so a poller keeps it and asks again. Each event has id, rule_id, alert_label, alert_type, created_at, `event` (what happened: the transfer, fill, liquidation, bias flip, proximity crossing, Polymarket trade, price move or resolution) and `delivery`: one item per channel it went to with id, channel, channel_key, status, attempts, last_attempt_at, next_attempt_at (while it waits) and last_error as a code only (http 500, timeout, network). A delivery's id is what alerts_resend_delivery takes. Events are kept for 15 days. Read-only; only the user's own rules appear. | Read-only |
| alerts_list | List the current user's alert rules. Returns active alerts by default; pass include_inactive=true to include paused/deleted ones. Also use this to look up an alert_id before editing or deleting. Each row has `alert_type`, `policy` (per_event, cooldown or hysteresis: how often it notifies) and, for a Hyperliquid alert, an `hl` object holding its parameters (a `pm` object for a Polymarket alert). | Read-only |
| alerts_list_channels | List the user's enabled email + webhook notification channels. Use before creating an alert to confirm which channels are available (a Hyperliquid or Polymarket alert mails the account address, needs a webhook, or is read with alerts_events). Returns a list of {id, channel_type, is_verified, label} rows. | Read-only |
| alerts_register_webhook | Register an HTTPS webhook as an alert delivery channel for the current user. We POST signed JSON to the URL when alerts fire, and once right now: a signed `test` event whose result comes back as `test` ({ok, status} or {ok, error}); a failing test does not refuse the channel. Every POST is signed with HMAC-SHA256: pass your own `secret` (>=16 chars) or we generate one and return it as `secret` in this answer (show it to the user now; it is shown at registration and again any time on Account -> Alerts -> channels, Show secret; alerts_rotate_webhook_secret issues a new one). The test is signed with that secret, so a receiver that checks signatures answers 401/403 until it has it: if your receiver needs the secret first, install it and call alerts_test_webhook. Recipients verify by computing HMAC-SHA256(secret, '{X-Vike-Timestamp}.{body}') over the RAW body and comparing it, in constant time, to EVERY `sig=` value of X-Vike-Signature: accept the delivery if ANY of them matches (during a secret rotation the header carries two). Replays should be rejected if timestamp is more than ~5 min old. Payload, headers and a verification example: https://vike.io/data/api#mcp-alerts | Destructive |
| alerts_resend_delivery | Send one of the user's own alert deliveries again (the same as POST /v1/alerts/deliveries/{id}/resend): the webhook or e-mail of an event that failed, expired or was lost on the receiving side. Take the delivery `id` from the `delivery` list of an event in alerts_events. Works whatever the delivery's status, up to 15 days after its event; it is queued for an immediate attempt with the same event id and a fresh signature, then retried as usual. Returns {id, status, result} where result is queued, already_queued or sending. Queued is a request, not a promise: the sender checks the rule and the channel again, so a delivery whose rule is off or whose channel is disabled or deleted is skipped again, and a paused channel delays the attempt. An error for a delivery that is not the user's own, is older than 15 days or is `unsupported` (its channel cannot carry that kind of event, so it would fail the same way). | Destructive |
| alerts_rotate_webhook_secret | Rotate the signing secret of one of the user's webhook channels (ids from alerts_list_channels). A new secret is generated and returned as `secret` (show it to the user now; it is shown again any time on Account -> Alerts -> channels, Show secret). When the channel had a secret, the old one keeps signing for 24 hours (`previous_secret_valid_until`): until then every delivery carries TWO `sig=` values in X-Vike-Signature (the new secret's first, the old one's second). A receiver must accept a delivery if ANY `sig=` value matches its secret; one that compares a single value rejects deliveries during those 24 hours. Rotating again inside them ends the first overlap. A legacy channel that had no secret rotates without overlap (`previous_secret_valid_until` is null, one `sig=`). Install the new secret, then call alerts_test_webhook to check it. | Destructive |
| alerts_test_webhook | Send the signed `test` event to one of the user's webhook channels again (ids from alerts_list_channels), for example after the receiver installed a new secret from alerts_register_webhook or alerts_rotate_webhook_secret. Signed like a real delivery: the current secret and, inside a rotation's 24 hours, the previous one too (two `sig=` values; accept if ANY matches). Returns {ok, channel_id, test}, where `test` is {ok, status} when the endpoint answered (ok = HTTP 2xx) or {ok: false, error: timeout | network | ssrf_refused | ...}. Nothing is queued, retried or stored. | Read-only |
| hl_archive | Index of the Hyperliquid Parquet archive and download links to its files. One file per UTC day for `fills` (every fill), `positions` (every 5-minute snapshot of every open position), `positions_hourly` (every position as last seen in each hour), `cohorts_hourly` (the hourly cohort matrix of every asset) and `wallets_hourly` (each wallet's native perp account per hour), from 2026-05-01, plus `latest`, one `positions` file of the current open positions replaced every 5 minutes. view='datasets' (default) lists the published days with each file's `rows` and `bytes`, the column `schema` of every dataset and the free samples' folder. view='url' resolves exactly ONE file (`dataset` and `date`) to a link valid for 7 days (`expires_at`) that needs no API key: this tool never downloads anything, so fetch it yourself and do not share it. A day appears once it is complete (the early UTC morning after). Same data as GET /v1/hyperliquid/archive/datasets and /archive/url. | Read-only |
| hl_builders | Hyperliquid builder codes (front-ends and bots that attach their address to an order and take a slice of the taker fee), by `view`. `leaderboard`: builders ranked by fee revenue, routed volume, unique users or fills over a window. `stats`: venue-wide builder economics. `profile`: one builder's totals with per-symbol and per-dex breakdowns, user-volume deciles and lifetime totals. `users`: the wallets routing through one builder. `fills`: its raw routed fills (sum `fee_usd`; `fee` is in its own `fee_token`). `series`: fee, volume, users and fills per hour or day (`users` is NOT additive across buckets). `fee_usd` is the builder's own cut, `trader_fee_usd` what the trader paid; every `*_pct` is percentage points 0-100. History depth differs by builder: compare `active_days` and `window` before comparing windows. Same data as GET /v1/hyperliquid/builders and its sub-routes. | Read-only |
| hl_cohort_metrics | Hourly long/short positioning of ONE Hyperliquid perp split by cohort: every bucket of one ladder, every hour, in one call (the matrix behind 'are whales / smart money long or short BTC'). `axis` picks the ladder: `size` (account value), `pnl` (percentile of cumulative realized PnL), `pnl_abs` (realized PnL in dollar bands), `pnl_unrealized` (currently onside), `tier` (each position's own notional). Data from 2026-04-07 (the first hour cohort labels are correct); an older `start` is served from there and the envelope says `data_from`. Rows are hour x cohort: `n_wallets` (wallets in the cohort holding the symbol), notional in USD (`total_position_value`, `total_position_value_long`) and `bias` = (long - short) / (long + short), a fraction from -1 (all short) to +1 (all long), not a percent. BACKTESTS: by default the `pnl` cohort is TODAY's grading applied to past hours (look-ahead); pass label_basis=point_in_time for each hour's label as it was, and read `label_computed` and `freshness` in the envelope. The hour in progress is never included. The response holds about `hours` x 12-13 rows: pass a small `hours` (1-24) for a current read and page older data with `cursor`. With `include` (`volume`, `median_pnl`; `size` or `pnl` axis) the newest hour's rows also carry each cohort's 24-hour fill volume and the median realized PnL of its wallets, in USD, computed at request time. Same data as GET /v1/hl-cohorts/symbols/{symbol}/cohort-metrics. | Read-only |
| hl_hype_holders | The HYPE holder leaderboard: each wallet's spot HYPE balance plus staked HYPE, largest first, valued at one current HYPE price, with its `pnl_cohort` resolved at query time (`label_basis` is `current`; balances are last-known, so a stale balance can sit beside a fresh label) and `account_value`, the wallet's perp account value in USD (null for a holder with no perp account on record, never 0). Keyset-paged with `cursor`. Same data as GET /v1/hyperliquid/hype/holders. | Read-only |
| hl_leaderboard | Rank Hyperliquid wallets with the full risk set, by `view`. `ranking`: precomputed per-window metrics sorted on any of 20 keys (PnL, ROI, win rate, Calmar, profit factor, drawdown, streaks, ...), filtered by cohort and by minimum trades / win rate / volume, cursor-paged. A window is what was REALIZED in it (the trades closed in it) and a wallet needs 3 closed trades in it unless `min_trades` says otherwise (0 = no floor). `flow_adjusted`: ranks FILLS-DERIVED realized trading PnL, which excludes deposits by construction, with deposits, withdrawals and daily attribution returned beside it, both of the NATIVE perp account only (`flow_unbalanced` marks rows whose attributed block is off the fills; `attributed` and `flow_unbalanced` are null for a wallet now in unified or portfolio-margin mode, whose native account follows margin). `account_value` and `roi` use the wallet's whole value in those two modes, which read null on the drawdown fields; `perp_account_value` and `account_mode` show the native account and the mode. UNITS differ from hl_perp_top_traders: here `win_rate` and `min_win_rate` are FRACTIONS (0.6 = 60%), there percents; `max_drawdown_pct` and `pnl_pct` are percents, and `pnl_pct` is null under $1 of equity (prefer it to the raw `roi`); money is USD. Same data as GET /v1/hyperliquid/leaderboard and /leaderboard/flow-adjusted. | Read-only |
| hl_ledger | Hyperliquid deposits, withdrawals, transfers and vault events ACROSS wallets, newest first, with `wallet` and `amount_usd` (USD) on every row; `min_usd` keeps the large ones (most events are small transfers). A transfer between two wallets is one row per affected wallet with the same `hash`. Without `wallet` the window defaults to the last 24 hours and is at most 31 days. `order=asc` follows the feed: pass each `nextCursor` back and stop on an empty page. One wallet's own ledger is also hl_wallet_activity view=ledger. Same data as GET /v1/hyperliquid/ledger. | Read-only |
| hl_leverage_changes | Hyperliquid positions whose leverage or margin mode differs between two consecutive complete position snapshots, newest first: one row per wallet and symbol with the previous and the new leverage, margin mode, side, size and entry price. `ts` is when the later snapshot was written, not when the venue changed the setting; positions are captured about every 12 minutes, so changes arrive in batches. Without `wallet` the window defaults to the last 24 hours and is at most 31 days. `order=asc` follows the feed (stop on an empty page). Same data as GET /v1/hyperliquid/leverage-changes. | Read-only |
| hl_liquidations | Hyperliquid liquidations, by `view`. `fills`: liquidation events, newest first, filtered by symbol, wallet, side and time. Since 2026-08-03 rows are EXACT, the liquidated wallet's own fill from the node (`liq_ts` the fill's millisecond, sizes what it closed, `mark_price` the venue's mark); older rows are INFERRED from ~5-minute position snapshots (a position over $100 whose mark was within 5% of its liquidation price and which is gone from the next snapshot; `liq_ts` is that snapshot's time and size/mark are the last values seen; a hand close that near liquidation counts, partial liquidations are missed); `direction` is the side of the position that was CLOSED (long = longs liquidated, price fell) and each row's `pnl_cohort` carries a `pnl_cohort_basis` saying how it was labelled. `risk`: per symbol, the share of open notional close to liquidation: `percent_risk` is a FRACTION from 0 to 1 despite its name, ranked by that fraction, so thin micro-cap markets can top it (read `total_value_usd`, or pass `min_value_usd`). `heatmap`: one symbol, where its open positions' own liquidation prices cluster, in equal-width price bins weighted by notional USD; positions outside +-50% of mark or without a liquidation price are left out and counted under `coverage`. Same data as GET /v1/hyperliquid/{liquidations, liquidations/risk, symbols/{symbol}/liquidation-heatmap}. | Read-only |
| hl_market | Hyperliquid market positioning, by `view`. `open_interest`: open interest per symbol at the latest snapshot beside the venue's own figure, so the two can be reconciled. `symbol_metrics`: the hourly open-interest, position-count and `bias` series (a fraction from -1 to +1) of ONE symbol, all cohorts summed or one cohort sliced; the newest row is `provisional` (the hour in progress). A cohort slice has data from 2026-04-07 (the first hour cohort labels are correct; `data_from`), all cohorts summed the whole history. A `pnl` cohort slice here uses TODAY's grading for past hours (look-ahead): use hl_cohort_metrics with label_basis=point_in_time for research. `size_breakdown`: one symbol's positioning by position-size bucket (ten dollar ranges, empty ones zero-filled). `positions`: individual position rows, current by default or historical with `start` (and optionally `end`; `end` alone is refused; bound it by `symbol` or `wallet`). `positions` is ordered by KEY, NOT by size (current: wallet, symbol, direction; historical: symbol, snapshot time, wallet), because the cursor pages on the primary key: `limit=10` is the first ten wallets in address order, never the ten biggest. For the biggest positions of ONE symbol pass `sort=size` (current only, `limit` at most 500, no `cursor`): rows come biggest first and each carries `account_value`, the wallet's NATIVE perp account value in USD (null when unknown, never 0; a builder DEX's separate account is not in it), `account_mode` (`default`, `unifiedAccount`, `portfolioMargin`, `disabled`) and `whole_account_value`: in the two modes whose margin lives outside the perp account, the native account plus the USDC held outside it, else equal to `account_value`; both null on a row that does not record the mode (before 2026-11-07 20:03 UTC or from the fallback poller); there is no per-position cumulative funding. For market-wide sizes use `size_breakdown`, `open_interest` or hl_cohort_metrics. `indices`: four cohort readings of ONE symbol, all RATIOS from -1 (all short) to +1 (all long), not percents, and null (never 0) when a cohort holds no positions: `latest` is the newest 5-minute snapshot and `series` the settled hourly rows, newest first, data from 2026-04-07 (the first hour cohort labels are correct; `data_from`) (`hours` sizes the window, `limit` caps the rows, `has_more` says older rows exist). `smi` = long share of the 3x smart / 2x smart / smart wallets minus long share of the rekt / 2x rekt / 3x rekt wallets; `wsi` = long share of the 4x whale .. whale wallets minus long share of the 2x shrimp / shrimp wallets; `whale_bias` and `smart_bias` = (long - short) / (long + short) over those whale / smart wallets (`latest` only). `latest.smi` and `latest.smart_bias` rank wallets by today's PnL grading (`latest.label_basis` is `current`), the hourly `series` by each hour's own grading (top-level `label_basis` is `point_in_time`). `large_fills`: one symbol's fills of at least `min_usd` (from $50,000) of the last `hours` (up to 24), newest first, the website's Whale Activity feed: `ts`, `wallet`, `direction` (`buy` | `sell`), `size_token`, `size_usd`, `price`, `order_type` (`market` = crossed the book, `limit` = rested), `size_cohort`, `pnl_cohort` (graded at the fill's own hour where that hour is labelled, else today; `pnl_cohort_basis` says which). The source keeps only the newest 200 fills over $50k per symbol, so on a busy symbol it reaches back minutes, not a day: `covered_from` is how far back the answer reaches (the oldest fill held when `truncated` is true, else the start of the `hours` window) and `truncated` is true when that cap may have cut older fills inside `hours` (they may all be below `min_usd`). `limit` defaults to 200, everything the source holds per symbol; `has_more` is true when a lower `limit` cut matching rows. Liquidations are not flagged. Notional is USD. `hourly`: an hourly panel of up to 64 `symbols` at once, the close (from fills) beside open interest, funding rate and premium (node snapshots averaged over the hour); `rows` are ARRAYS in `columns` order, not objects, `days` (default 120, at most 400) or `start` sizes the window, and `start` / `end` in the answer are the window actually read. `funding_rates`: without `symbol` the board, every perp's latest `funding_rate` (the venue's HOURLY rate as a fraction; Hyperliquid settles every hour, positive = longs pay), `funding_rate_annualized` (x 8760, simple), `premium`, `mid_price` and open interest (`open_interest` in coins, `open_interest_usd`), ranked by `sort` (`oi` default, `rate`, `abs_rate`), `as_of` the newest reading; with `symbol` that perp's hourly history from `data_from`, each hour the MEAN of its ~12 five-minute readings (`n_snapshots`), not the rate settled at the hour's end. Builder-DEX (HIP-3) perps are included; their hours from 2026-04-22 13:00 to 2026-11-03 are the SETTLED rate (rebuilt from the venue's history), `null` where the venue published none. Same data as GET /v1/hyperliquid/{positions/symbols, positions, symbols/hourly, funding-rates} and GET /v1/hl-cohorts/symbols/{symbol}/{metrics, size-breakdown, indices, large-fills}. | Read-only |
| hl_ohlcv | Historical OHLCV candles for a Hyperliquid market, aggregated from HL's own executed fills, by `view`. `candles` (default): one symbol's bars. Pass `symbol` as the HL asset (BTC, ETH, HYPE); `market` picks perps or HL spot and `dex` picks a builder-deployed HIP-3 perp DEX (default HL, the core venue). Buckets are left-aligned UTC and the window is half-open [start, end). Returns candles as {ts (epoch ms, UTC), open, high, low, close, volume, volume_usd, n_trades} ascending by ts, plus `source` naming the rollup that answered. `export`: the same, with `limit` defaulting to the maximum, 5000 (the REST export streams it as NDJSON). `latest`: the newest 1-minute bar of EVERY symbol that traded in the last hour in one call (takes only `market`, `dex` and `interval`; `dex` omitted = every DEX, each row naming its own; a bar may still be forming). Same data as GET /v1/hyperliquid/ohlcv, /ohlcv/export and /ohlcv/latest. | Read-only |
| hl_orders | Hyperliquid standing orders, by `view`. `open`: every order resting at one instant (`at`, default the newest snapshot) for a `symbol` and/or a `wallet`, in key order, with `snapshotTs` and `source`: `l4_5m` = the node's 5-minute order snapshot (from 2026-10-23 21:45 UTC), `state_12m` = rebuilt from the ~12-minute checkpoints (from 2026-07-29; before the 5-minute feed, or while it is stalled), where short-lived orders can be missing. `wallet`: what became of one wallet's orders in a window, newest placement first: each order seen resting or filled in it, its fills in the window and a `status` (open, filled, partially_filled, canceled_or_expired); `notes` says what a snapshot cannot tell. `clusters`: one symbol's standing orders within `range_pct` of the mid of the best resting bid and ask, bucketed by price (bids and asks by limit price, take-profit and stop-loss by trigger price; trailing stops are not bucketed), optionally one cohort's. Same data as GET /v1/hyperliquid/orders, /wallets/{address}/orders and /symbols/{symbol}/order-clusters. | Read-only |
| hl_perp_top_traders | Rank top Hyperliquid perp wallets by PnL / ROI / win rate / volume / trade count within a time window. Use for questions like 'top HL traders with win rate > 75%' or 'best HL perp wallets last 7d'. Data comes from the same pipeline that backs vike.io/hyperliquid/wallets. Use win_rate expressed as percent (0-100). roi_pct is window realized PnL over the CURRENT account value (a unified or portfolio-margin wallet's whole value, native + builder + USDC outside them; perp_account_value is the native perp account and account_mode default, unifiedAccount, portfolioMargin or disabled) and max_drawdown_pct is account-level and all-time (null when the wallet has too little equity history to say, and for unified and portfolio-margin wallets), both in percent (12.5 = 12.5%). | Read-only |
| hl_position_match | Reverse-lookup a Hyperliquid open position from share-card details (symbol + side + leverage + entry price). Given the info shown on a HL trader's share card, return wallet(s) with matching open positions, ranked by entry-price proximity. Useful for 'whose share card is this?' or 'who has a 25x ETH long open at $3,200?'. Walks tight (±0.05%) -> loose (±0.5%) -> fallback (±1.0%) entry bands and requires leverage within ±0.5. Reads from the latest position snapshot (freshness-gated to the newest 15-minute window). | Read-only |
| hl_segments | The Hyperliquid cohort vocabulary and its latest-snapshot positioning, by `view`. `cohorts`: the label sets per ladder, the exact spellings every `cohort` parameter accepts. `segments`: the catalogue with bounds, ranks and what each ladder measures (`size` is account value in USD; `pnl` is a percentile rank of cumulative realized PnL, not dollars; `pnl_abs` is dollars). `summary`: everything ONE cohort holds right now across all symbols: long/short notional in USD, `bias` a fraction from -1 to +1, `pct_wallets_in_profit` a FRACTION from 0 to 1 despite its name, `exposure_ratio` = notional / margin used, `perp_bias` = (long - short) / equity and `equity_exposure` = (long + short) / equity: positions on the main dex over the native perp account value, plus for a unified or portfolio-margin wallet the USDC it holds outside it (each wallet once, the whole account even under `opened_within`); builder-DEX positions are not included; wallets without a known positive equity are left out of perp_bias, equity_exposure and this share's numerator, see `equity_covered_share` (main-dex notional of the counted wallets / of the whole cohort). Unbounded ratios (above 1 = over 1x; null when equity <= 0); that equity is not `total_equity`, so perp_bias x total_equity != total_long_usd - total_short_usd. `heatmap`: the whole symbol x cohort board (large: every symbol with open interest; empty cells are omitted). Positions are the latest 5-minute snapshot. `history`: ONE cohort (`cohort` + `axis`, both required; `axis` is `size` or `pnl` only) hour by hour, summed over all symbols, newest first, from 2026-04-07: `long_usd` and `short_usd` in USD, `bias` = (long - short) / (long + short), a RATIO from -1 to +1 (null when both are 0), `position_count` = open positions, NOT wallets. Each hour carries the cohort label it had then (`label_basis` is `point_in_time`; `pnl` labels are daily before 2026-08-06, see `label_computed`). `hours` sizes the window, `limit` caps the rows, `has_more` says older rows exist. With `include=leverage` each hour also carries `perp_bias`, `equity_exposure` and `equity_covered_share`, the three `summary` ratios of that hour (null before 2026-08-11 and for a missing hour; `perp_bias` and `equity_exposure` are also null where no wallet has a known positive equity, and `equity_covered_share` is 0 when none is counted). An unknown cohort for the axis is an error. Same data as GET /v1/hl-cohorts/{cohorts, segments, segments/{cohort}/summary, heatmap, segments/{cohort}/history}. | Read-only |
| hl_stats | Hyperliquid venue-wide hourly series, newest hour first, by `view`. `ecosystem`: perp equity, open interest and position counts per hour. `volume`: traded perp notional per hour, of the whole venue (builder-DEX perps included; spot and outcome markets left out) or of one `symbol`: `volume` counts each trade ONCE (one side), the figure the candles report, while `n_fills` counts fill records, two per trade. Money is USD. Keyset-paged with `cursor`. Same data as GET /v1/hyperliquid/stats and /stats/volume. | Read-only |
| hl_twaps | Hyperliquid TWAP orders, one row per status line, newest first. A line is a status CHANGE (`activated`, `waitingForTrigger`, then `finished`, `terminated` or `stopped`), not a slice fill: `executed_size` and `executed_notional_usd` are the cumulative totals when the line was written. Rejected placements (`error`) are hidden unless `status=error`. Across all wallets the window defaults to the last 24 hours and is at most 31 days; with `wallet` or `twap_id` neither applies. `order=asc` follows the feed: pass each `nextCursor` back and stop on an empty page. Same data as GET /v1/hyperliquid/twaps; with `wallet` it is GET /v1/hyperliquid/wallets/{address}/twaps (one feed: the cursors are interchangeable). | Read-only |
| hl_vault | One Hyperliquid vault by address, by `view`. `profile`: TVL, APR, leverage, leader and top-5 shares, active depositors and all five windows (7d, 30d, 90d, 365d, all). `depositors`: every current depositor (not only the largest 100) with equity, PnL on the current position, all-time PnL, entry time, lockup end and PnL rank. `flows`: the vault's own ledger rows, newest first. `series`: equity, chained share price (`nav`), net flow and PnL per hour or day, oldest first (for a parent vault, its whole family). Its fills, trades and positions: hl_wallet and hl_wallet_activity with the vault address. Same data as GET /v1/hyperliquid/vaults/{vault} and its sub-routes. | Read-only |
| hl_vaults | Hyperliquid vaults across the platform, by `view`. `list`: one row per vault family (HLP and its sub-vaults are one row) with current TVL, APR (our 30-day share-price return, annualised) and the window's PnL, return, net flow, volume and fills, plus `leverage` (gross notional / equity) and the leader's and top-5 depositors' shares; `q` searches by name or address. A family is measured from the first day all its open vaults are recorded (`start`, `partial`); its flows are the parent's. `stats`: platform TVL, deposits, withdrawals and net flow over the window, vaults created per month. `flows`: deposits and withdrawals of at least `min_usd` across all vaults, newest first. A window ends on the newest recorded day; one shorter than asked says `partial`. Money is USD, `*_pct` percentage points. Same data as GET /v1/hyperliquid/vaults, /vaults/stats and /vaults/flows. | Read-only |
| hl_wallet | One Hyperliquid wallet, by `view`. `summary`: live equity, open positions, both cohort labels, the risk metrics of the window (`win_rate` is a FRACTION from 0 to 1; `max_drawdown_pct` and `pnl_pct` are percents, `pnl_pct` is null under $1 of equity), cumulative realized PnL since inception and lifetime deposits and withdrawals, all money in USD; `equity.account_value` is the wallet's whole value in the venue's unified and portfolio-margin modes (native perp account + builder accounts + USDC outside them, free spot tokens left out; those modes also read null on the drawdown fields), else the native perp account; `equity.perp_account_value` is always the native perp account and `equity.account_mode` is `default`, `unifiedAccount`, `portfolioMargin` or `disabled`; `open_positions.perp_bias` = (long - short) / `equity.perp_account_value` and `equity_exposure` = (long + short) / it, native perp account only: positions on the main dex over the native perp account value; builder-DEX positions are not included. Unbounded ratios, null with no main-dex position or no positive equity. `trades_summary`: closed round-trip trade statistics overall and per symbol, medians as well as means. An address we hold nothing for (`summary`) or that never traded (`trades_summary`) is an error, never a block of zeros. Find addresses with hl_leaderboard, hl_perp_top_traders or hl_position_match. Same data as GET /v1/hyperliquid/wallets/{address} and /wallets/{address}/trades/summary. | Read-only |
| hl_wallet_activity | A Hyperliquid wallet's event history, by `view`. `fills`: raw fills, newest first (`size_usd`, `closed_pnl` in USD; `fee` is in its own `fee_token`). `funding`: funding payments, `payment_usd` signed from the wallet's side (negative = the wallet PAID). `ledger`: deposits, withdrawals, transfers and vault events with `amount_usd`. `builders`: the builder codes the wallet's flow is routed through, by volume (`share_of_volume` is of its builder-routed volume only, not of all its trading). Keyset-paged: pass `nextCursor` back; it is null on the last page. Same data as GET /v1/hyperliquid/wallets/{address}/{fills, funding, ledger, builders}. | Read-only |
| hl_wallet_trades | One Hyperliquid wallet's CLOSED round-trip trades, newest close first, keyset-paged: per trade the symbol, direction, `open_ts` / `close_ts`, entry and exit price, the largest size held (`max_size_usd`), traded `volume_usd`, `realized_pnl` and `total_fee` in USD and the fill count. A trade still open is not listed. For statistics over these trades use hl_wallet view=trades_summary; for the raw fills hl_wallet_activity view=fills. Same data as GET /v1/hyperliquid/wallets/{address}/trades. | Read-only |
| perp_funding | Perpetual-futures funding rates. Pass `symbol` (e.g. 'BTC') to get current per-venue rates for one asset. Omit `symbol` to get top cross-venue funding-arbitrage opportunities (pre-ranked, normalised to daily %, spreads >= 0.3%). Each arb row includes long_exchange+long_daily_pct, short_exchange+short_daily_pct, spread_daily_pct. A halted or no-longer-polled venue (Coinbase International, halted 2026-10-01) is left out, and so is a venue silent for over an hour in the per-symbol list. | Read-only |
| perp_long_short | Long/short positioning that perp venues publish for one symbol: binance, bybit, gate, okx. The venues do NOT measure the same thing, so every row carries `basis`: binance = top traders by POSITIONS; okx and gate = top traders by ACCOUNTS; bybit = ALL accounts. Compare a venue with itself over time, never as a like-for-like average across venues. `long_share` / `short_share` are fractions of 1 (0.63 = 63 %); `long_short_ratio` = long / short (1.72 = 1.72 longs per short; above 1 is long-heavy). Without `hours`: the newest 5-minute print per venue and its age in seconds (`venues` printed within the last hour, `stale_venues` went silent). With `hours` (1-168): an hourly `long_short_ratio` series per venue, the last print in each UTC hour. Covers about 40 major symbols only; any other symbol returns empty lists and a note, never zeros. `symbol` is the canonical base asset ('BTC'). | Read-only |
| perp_open_interest | Open interest of one perpetual-futures symbol on each venue Vike polls: aster, binance, bitget, bybit, hyperliquid, kucoin, okx. `oi_usd` is USD NOTIONAL (open contracts x mark price when polled), not contracts or coins. Without `hours`: the newest print per venue and its age in seconds; `venues` printed within the last hour, `stale_venues` went silent (last print within 30 days) and must NOT be summed in. With `hours` (1-168): an hourly series per venue, the last print in each UTC hour. Venues are polled roughly every 5-8 minutes. `symbol` is the canonical base asset ('BTC', not 'BTCUSDT'). A symbol no venue lists returns empty lists and a note, never zeros. | Read-only |
| perp_spreads | Get top cross-venue spread-arbitrage opportunities for perpetual futures. Returns symbols where the price gap between the cheapest and most-expensive exchange is >= 0.5%. Each row includes buy_exchange+buy_price, sell_exchange+sell_price, and spread_pct. Pre-ranked — just cite the rows directly. Outliers (>400 bps from cross-venue median, typically unit-mismatch listings like 1000SHIB) are already filtered out. | Read-only |
| polymarket_archive | Index of the bulk Polymarket L2 archive: one Parquet file per UTC day and stream (book_events, trades, l1_quotes), either multi-asset ('flat') or per asset and tenor ('family', e.g. btc + 5m). view='datasets' (default) lists files, filtered and paged, with `bytes` and `rows` where recorded; view='url' resolves exactly one file to a download link (give `date` and `stream`, plus `asset` and `tenor` together for a family file). This tool never downloads anything: the link is valid for 7 days (`expires_at`) and needs no API key, so fetch it yourself and do not share it. `asset` and `tenor` match family files ONLY, so supplying either hides every flat file. Returns {datasets, limit, offset, total} for 'datasets', one dataset row for 'url'. | Read-only |
| polymarket_chainlink_prices | The price Polymarket's crypto up/down markets resolve on: Chainlink Data Streams prices, as Polymarket's live-data socket relays them for its crypto markets, for btc, eth, sol, xrp, doge, bnb, hype or zec in USD, from 2026-11-06 09:24:15 UTC to about a minute ago (rows are stored once a minute). series=price (default) is the price, about one tick a second; series=twap60 is its 60-second time-weighted average. interval=1s (default) returns every tick; 1m, 5m, 15m, 1h, 4h or 1d return one row per bucket aligned to UTC, the FIRST tick at or after the bucket's start: the price an up/down market compares at the start and the end of its window. For a 5-minute, 15-minute or hourly market from S to E pass interval = its length (5m, 15m or 1h), from_ms=S and to_ms=E+1: two rows, the price at its start and at its end. 4-HOUR AND DAILY MARKETS FOLLOW US EASTERN TIME, off the UTC grid of the 4h and 1d buckets: pass interval=1m with from_ms=S and to_ms=S+60000, and again with from_ms=E and to_ms=E+60000. Returns {rows, has_more, next_cursor}; each row {ts_ms (bucket start, epoch ms), price_ts_ms (the tick's own time), price (USD)}. `from_ms` is inclusive and `to_ms` exclusive, both on ts_ms. While has_more is true pass next_cursor back as `cursor`; a page can hold fewer rows than `limit` while has_more is true, and within the last two minutes a page ends at the last row stored so far. About 1.6% of seconds have no row and nothing is filled in: about 600 single seconds a day, about 17 gaps a day of 2 to 5 seconds, and about 85 a day of 6 to 30 seconds that nearly always every coin skips at once; the longest, 74 seconds, was 2026-11-06 11:15:33 to 11:16:46 UTC. Compare price_ts_ms with ts_ms. A page is 100 rows by default and at most 10,000. | Read-only |
| polymarket_leaderboard | Leaderboard of Polymarket wallets ranked by realized P&L, hit rate, volume or trade count, for all time or over a window, optionally within one market category. The same board vike.io/polymarket shows. Returns rows {rank, proxy_wallet, pseudonym, display_name, realized_pnl_usd (lifetime, USD, resolved markets only), realized_pnl_window_usd (USD over `window`, by resolution time), resolved_markets, hit_rate, hit_rate_ci, volume_all_usd, volume_window_usd (USD), trades_all, trades_window, avg_trade_usd, markets, first_seen, last_seen (UTC), tags}. `hit_rate` is a FRACTION from 0 to 1 (0.62 = 62%), volume-weighted (the share of the wallet's resolved dollar volume that sat in markets it won), not a count of wins; it is null, never 0, when the wallet has no resolved volume. `hit_rate_ci` is the +/- half-width of the 95% Wilson interval, also a fraction: read hit_rate +/- hit_rate_ci and distrust a hit_rate with a wide one; a near-100% rate on a sliver of P&L is an arbitrage pattern, not skill. `min_resolved` defaults to 20 so a hit rate rests on a real sample; 0 lists thinner wallets. `tags` are whale (lifetime volume $100k or more), bot (average trade under $20 over 100+ trades), hot / cold (lifetime P&L of +/-$1,000 on 5+ resolved markets). The top of a category is often bots with tens of thousands of resolved markets: check `tags` and `avg_trade_usd`, or pass min_avg_usd=20 to drop every bot-tagged wallet. `first_seen` is the wallet's first trade in the recorded tape, which starts on 2026-01-01, so it does not show that a wallet is new. The 24h / 7d / 30d windows are rebuilt hourly (hour-granular) and a market's resolution time can be corrected later, so a windowed figure can be revised; window=all is not affected. Page with `limit` and `offset`; ties break on the wallet address. Addresses are public on-chain data; this tool names no one. | Read-only |
| polymarket_market_detail | Deep-dive on one Polymarket market by condition_id: question, category, outcomes with their clob_token_ids, 24h and total volume, liquidity, a price series per outcome, the top 30 holders per side, the last 100 trades (with wallets), tape stats and resolution status. There is no live quote or smart-money block here: use polymarket_orderbook for quotes and polymarket_smart_money for the cohort. Use after polymarket_markets when the user asks about a specific market. | Read-only |
| polymarket_market_stats | Tape summary for ONE Polymarket outcome token: recorded events (`total_events`), `trades`, `trade_volume` in outcome SHARES (not USD), `snapshots`, and the first / last recorded timestamps (`first_ms` / `last_ms`, epoch ms). `token_id` is the ERC-1155 OUTCOME token id (decimal string from `clob_token_ids` in polymarket_market_detail or `outcomes[].token_id` in polymarket_markets); a condition_id (0x...) will NOT work. Always returns ONE row: a token that was never recorded answers all zeros with total_events = 0, which means 'never recorded', not 'quiet'. | Read-only |
| polymarket_market_trades | ONE Polymarket market's trades WITH the wallet behind each, newest first, paged: who traded, which side, how many shares and at what price, from 2026-01-01 to a few minutes ago, read from the on-chain trade tape. Takes the market's `condition_id` (0x plus 64 hex digits, from polymarket_markets or polymarket_market_detail), NOT an outcome token id. Returns {trades, has_more, next_cursor}; while has_more is true pass next_cursor back as `cursor` for the next, older page. `from_ms` is inclusive and `to_ms` exclusive (epoch ms). A page is 100 rows by default and at most 10,000; a row is ~430 characters (a 66-character transaction hash and a 42-character wallet), so ask for what the context window holds. ONE ROW IS ONE ORDER'S FILL, NOT ONE MATCH: a match is several rows (the resting `maker` orders that were hit, plus one `taker` row for the aggressor, whose size is the sum of theirs), so never add size * price over both roles. A few percent of fills are merged away, so a count can sit slightly under the on-chain total. `proxy_wallet` is Polymarket's proxy wallet, not necessarily the person's own address. For the recorded order book (no wallets) use polymarket_tape; for one wallet's whole record use polymarket_wallet. | Read-only |
| polymarket_markets | Polymarket markets, by `view`. `trending` (default): top prediction-market events ranked by 24h volume. Returns market title, slug, category, current Yes/No mid quotes, 24h volume, and end_date. Filter by category (Crypto | Sports | Politics | Pop-Culture | Tech | all). Use for 'what's hot on Polymarket' or 'top crypto prediction markets'. `search`: the recorded markets whose slug contains `query` (case-insensitive), optionally only active or only closed ones, newest end_date first, paged with `limit` and `offset`; rows {active, closed, condition_id, end_date (epoch), neg_risk, slug, tick_size, token_ids}, `active` / `closed` derived from the on-chain resolution and Polymarket's own flag (a filter on them is the slower read). `market`: one market by `condition_id` in that row shape, a list of 0 or 1 rows, from the recorded markets or else Polymarket's full catalogue (`source` says which; an unknown id is `[]`). Same data as GET /v1/polymarket/markets and /markets/{condition_id}. | Read-only |
| polymarket_ohlcv | Historical OHLCV candles for ONE Polymarket outcome token, from the recorded L2 tape. `token_id` is the ERC-1155 outcome token id — a market's condition_id will NOT work here; read the token ids off `clob_token_ids` from polymarket_market_detail. Prices are probabilities in [0, 1]. Returns bars OLDEST first as {ts (epoch ms, UTC), open, high, low, close, volume, trades}. There is no cursor, so a window wider than `limit` is truncated at the OLD end — raise `from` to reach the recent end. With `to` and no `from`, `limit` keeps the bars nearest `to` (`to`=X, `limit`=1 is the last bar at or before X). | Read-only |
| polymarket_orderbook | Order-book snapshot for ONE Polymarket outcome token: the nearest full-book snapshot at or before `ts` (the latest when omitted), flattened to price levels. `token_id` is the ERC-1155 OUTCOME token id (decimal string from `clob_token_ids` in polymarket_market_detail or `outcomes[].token_id` in polymarket_markets); a condition_id (0x...) will NOT work. Returns rows {as_of_ts (epoch ms, the snapshot actually used), side ('ask' | 'bid'), level (1 = best), price (probability in [0, 1]), size (shares)}, all asks before all bids. A book can be one-sided, so fewer than 2 x depth rows is normal. A level can repeat in one answer (the recorder writes several identical snapshot rows for one venue timestamp): keep one row per (side, level) and read a side's depth as its highest level, never as a row count. `as_of_ts` can be old for a quiet or finished market, so check it before quoting a spread. [] means no snapshot at or before `ts`, or a token that was never recorded. | Read-only |
| polymarket_settlement | On-chain resolution of ONE Polymarket market, keyed by its `condition_id` (the market's 0x... hex id from polymarket_markets or polymarket_market_detail; an outcome token id matches nothing here). Returns [] or one row {condition_id, slug, question, outcomes, winning_index, winning_outcome, winning_token_id, token_ids, payouts, resolved_block, resolved_ts_ms (epoch ms), market_known}. market_known false means the market list has no row for it: slug, question, outcomes, token_ids, winning_outcome and winning_token_id are then empty, the on-chain fields still exact. [] means the chain has not resolved this condition, NOT that the market is open: a market can be cancelled or voided with no on-chain resolution, so read polymarket_market_detail for the market's own status. | Read-only |
| polymarket_settlements_bulk | On-chain resolutions of MANY Polymarket markets in one call, oldest resolution first, paged: the list form of polymarket_settlement (same row fields), for 'which markets resolved in this window', 'every settled BTC 5-minute market' or a backtest set. `from_ms` is inclusive and `to_ms` exclusive (epoch ms, on resolution time); `slug_prefix` (lowercase letters, digits and `-`, e.g. `btc-updown-5m-`) keeps one family of markets. Returns {settlements, has_more, next_cursor}; while has_more is true pass next_cursor back as `cursor` for the next page. Only markets the chain resolved appear: a cancelled or voided market with no on-chain resolution is not here. Pages are rebuilt every 5 minutes, so a market that resolved in the last 5 minutes may not be listed yet; polymarket_settlement is always current. | Read-only |
| polymarket_smart_money | Detect smart-money signals on Polymarket. Two modes: 'flows' = markets with the largest net cohort inflow in the last N hours; 'mispricings' = markets where cohort bought meaningfully below current mid (potential edge). Cohort is wallets with $1k+ realized PnL over 5+ resolved markets. | Read-only |
| polymarket_tape | Raw Polymarket L2 event tape for ONE time window (at most 24 hours) on one or more outcome tokens, oldest first, from the recorded order-book feed. `token_id` / `token_ids` are ERC-1155 OUTCOME token ids (long decimal strings: read them off `clob_token_ids` in polymarket_market_detail or `outcomes[].token_id` in polymarket_markets); a market's condition_id (0x...) will NOT work. Event types: `trade` (price = probability in [0, 1], size = shares, side = buy | sell), `price_change`, `book` (the whole ladder in `bids` / `asks`, JSON carried as strings), `tick_size_change` (the new tick in `tick_size`, a field no other row has; from November 2026, earlier days have none), `status`. Always pass `event_type`: without it a page is mostly price_change and book rows. Returns {events, has_more, next_cursor}; pass next_cursor back as `cursor` for the next page. A 0 in `best_bid`, `best_ask`, `price` or `size` on a row type that does not populate it means absent, not a price of 0; `best_bid` and `best_ask` are recorded only since 2026-11-05 18:02 UTC, on `price_change` and `book` rows. The tape carries no wallet addresses. `to_ms` is EXCLUSIVE here, unlike `to` in polymarket_ohlcv. | Read-only |
| polymarket_wallet | Profile a Polymarket trader: realized P&L (24h / 7d / 30d / all-time), hit-rate on resolved markets, total volume, top categories traded, and recent positions. Use when the user gives a Polymarket wallet address. Also returns `correlated`: up to 8 other wallets that trade the same markets (each sharing at least 3 markets and $500 of volume with this one, compared over its 1,000 largest markets), most shared markets first, each with proxy_wallet, pseudonym, display_name, shared_markets, overlap_volume_usd, overlap_trades and last_seen; `[]` = none qualifies. Same data as GET /v1/polymarket/wallets/{address} plus /wallets/{address}/correlated. | Read-only |
| predictfun_leaderboard | Every Predict.fun wallet ranked by realized P&L (default), volume or fills over a window, or by today's unrealized P&L; each row carries realized and unrealized P&L, open value, open and resolved positions (outcome tokens), volume and fills for every window. Rebuilt hourly. Returns {rows, window, sort, label_basis, as_of_ts}; page with `offset` (max 1000). | Read-only |
| predictfun_market_book | The newest recorded order book of one Predict.fun market, priced on its first outcome (Yes): `bids` highest first and `asks` lowest first as [price, quantity], orders matched but not yet settled (`pending_*`), the last settled order, `ts` (Predict.fun's time) and `recorded_ts` (ours), epoch ms. Books are recorded for the ~1,000 most active open markets; none in 30 days is an error. | Read-only |
| predictfun_market_detail | One Predict.fun market by `market_id`: the market (title, question, status, category, fees, and `details`, Predict.fun's own record of it), its outcomes (token ids, names, WON/LOST once resolved, each one's last price) and stats (24-hour and total USD volume, 24-hour matches and wallets, `last_price` of the first outcome, Yes). The 24 hours are whole fill hours ending with the newest hour built (up to ~1.5 h behind the live tape). An unknown id is an error. | Read-only |
| predictfun_market_trades | One Predict.fun market's on-chain fills with the wallet behind each, newest first: ts (epoch ms), tx_hash, wallet, counterparty, role (maker/taker), side (BUY/SELL of token_id), outcome, size (shares), price (0-1), usd, fee. Returns {trades, next_cursor}. One row is one ORDER's fill, not one match: a match is a `maker` row per resting order hit plus one `taker` row for the order that took them (whose amounts are theirs added up), so add `usd` over ONE role, never both. | Read-only |
| predictfun_markets | Predict.fun markets with each one's 24-hour USD volume, matches and wallets (the 24 whole fill hours ending with the newest hour built, up to ~1.5 h behind the live tape), largest volume first (or newest first). Filter by `status` (open, closed, resolved) and `q` (a substring of the title or question). Returns {markets, next_cursor, as_of_ts}; each market has `market_id` (what the other predictfun tools take), `condition_id`, `title`, `question`, `status`, `trading_status`, `category_slug`, `created_at` (epoch ms). | Read-only |
| predictfun_overview | Predict.fun (prediction markets on BNB Chain) at a glance: open markets, and the USD volume, number of matches and number of wallets over the last 24 whole fill hours, ending with the newest hour built (`newest_trade_ts`, epoch ms, is the newest fill counted; rebuilt hourly, so up to ~1.5 h behind the live tape). Volume counts each match once, on the side that took liquidity. | Read-only |
| predictfun_wallet_flows | Where one Predict.fun wallet's money came from and went: its USDT deposits (`in`) and withdrawals (`out`) on BNB Chain, newest first, each with the counterparty address and our label for it, such as cex/binance; transfers with Predict.fun's own contracts (trading, splits, merges, redemptions) are left out. Returns {flows, totals, next_cursor, as_of_ts}; totals cover the whole history since 2025-11-21: deposited, withdrawn, net, and the first deposit with its sender (`first_funder`). It is the wallet's whole USDT traffic outside Predict.fun (a wallet also used elsewhere carries that activity too); dust under one cent and per-transaction fees are left out. | Read-only |
| predictfun_wallet_positions | One wallet's Predict.fun positions and P&L, per outcome token: net shares, cost, proceeds, mark (last price), value (net x 1 won, x 0 lost, x mark while open), pnl = proceeds - cost + value, state (open, won, lost, uncatalogued); totals over ALL positions with realized (resolved) and unrealized (open) P&L. At most 500 positions are listed (open first, then the largest |pnl|): `positions_total` counts them all, `truncated` says some were left out. Exchange fills only: shares split, merged, redeemed or transferred are not seen. | Read-only |
| predictfun_wallet_trades | One wallet's Predict.fun fills, newest first, each with its market (`market_id`, `market_title`) and `outcome`; otherwise the rows of predictfun_market_trades. Returns {trades, next_cursor}. One row is one ORDER's fill, not one match: a match is a `maker` row per resting order hit plus one `taker` row for the order that took them (whose amounts are theirs added up), so add `usd` over ONE role, never both. | Read-only |
| search | Search everything vike knows by name, symbol or address in one call, the same search as the vike.io search box. Sections: `tokens` (live price, 24h change and the page to open), `hl_markets` (Hyperliquid builder markets such as xyz:GOLD), `wallets` (labelled entities and wallets on Ethereum, BSC, Base and HyperEVM; an entity row has `wallet_count` and `url`, the vike.io page listing its wallets, and an `address` only when it is one wallet; a type word such as `cex`, `bridge` or `hacker` lists that type's biggest entities), `traders`, `vaults` and `builders` (Hyperliquid), `polymarket` (Polymarket wallets by name, pseudonym or address, with the owner of an account or the accounts a personal wallet owns), `markets` (open Polymarket markets holding every word, several markets of one event as one row {event_slug, title, markets_n}; closed ones only when nothing else matched), `predictfun` (open Predict.fun markets on BNB Chain whose title or question holds every word, the busiest (24 h volume) first, then the newest, each {market_id, title, question, status, url}; closed and resolved ones only when nothing else matched; a pasted address that has traded there is one {address, url} row) and `did_you_mean` (coins one typo away when no token matched). `q` may be free text, a 0x address (also inside a pasted URL), an ENS name (searched as the address it points to) or a polymarket.com link. Each section holds at most `limit` rows; a section whose read fails comes back empty rather than failing the call. `url` fields are vike.io paths. Use it to turn a name into an address or id before calling another tool. Same data as GET /v1/search. | Read-only |
| stream_check_filter | Validate a stream subscribe message (or a `channel` + `filter`) with the SAME validator the stream server runs, without connecting. Returns {valid: true, url, subscribe} with the filter exactly as the server will apply it (values normalised, lists sorted, defaults added: hl.fills gets min_usd 1000 unless given), or {valid: false, code, message} with the server's own error (`bad_subscription` naming the key, `unknown_channel` listing the path's channels). `path` checks the channel against the endpoint the connection would use (a channel of another path is `unknown_channel` there). Costs nothing. | Read-only |
| stream_connections | Your own recent stream connections (this account only, every API key and OAuth app of it), newest first: path, url, api_key_id (or oauth_client_id), connected_at, `state` open or closed, the subscribe count and, once closed, closed_at, duration_s, the channels, close_code (4410 = replaced by a newer connection) and events_sent. RECONSTRUCTED from the connect, subscribe and close records the stream writes, not read from the stream's live state, and it may lag a few seconds: `open` means no close has been recorded yet (a server crash records none), and an open connection's channels are named only when it closes. Use it to see why a socket was closed or whether two programs share a key (each closes the other with 4410). `truncated` is true when only the newest records of the window could be read. | Read-only |
| stream_events | Stored events of ONE stream channel after a cursor, oldest first, with the stream's own filters: the REST catch-up of wss://stream.vike.io, for what a socket missed or a quick look without a socket. Returns {events: [{cursor, event}], next_cursor, has_more}; `event` is byte for byte what the WebSocket frame carried. An idle window of the on-demand channel is an item {cursor, gap} in its place. Pass next_cursor back as `cursor` for the next page; a page at the end returns the channel head, so an empty page on a quiet channel returns the same cursor. Events are kept 3 days: an older cursor is refused with a resume cursor in the message. `since_ms` starts at an ARRIVAL time instead of a cursor. Delivery is at least once: dedupe on event.event_id. hl.fills without min_usd is min_usd 1000, as on the socket (0 = every fill). Every channel stream_info lists is accepted, including one the stream does not run yet (a subscribe there answers unknown_channel): its pages are empty, like a quiet channel's. Same data as GET /v1/{hyperliquid,onchain,polymarket}/stream-events. | Read-only |
| stream_info | How to use the vike WebSocket stream (wss://stream.vike.io/v1/stream/<path>), read off the server's own registry: every path (hl, hl-cohorts, onchain, polymarket) with its channels; per channel its filter keys, each a list (with its maximum length), one value, a number (min_usd and the other min_ keys) or a boolean (contract: true or false, not a string), with the allowed values or the server's own message for a bad one, and its defaults (hl.fills: min_usd 1000 unless given); the REST catch-up route of each path; the limits (ONE connection per API key per path and THREE per account per path, newest wins with close 4410; 100 subscriptions per connection; a ping every 15 s); the close codes; cursor retention (3 days) and the subscribe message's shape. Check a filter with stream_check_filter and read missed events with stream_events. | Read-only |
| token_holders | Top holders of an ERC-20 token by cumulative net inflow USD. Returns wallet, net flow USD, volume USD, tx count, first/last seen dates, and known labels. Use when the user asks 'top holders of X' or 'who holds the most of token Y'. sort='flow' (default) ranks by cumulative net inflow USD, a flow and not a holding. sort='balance' ranks by the on-chain balanceOf among candidate wallets chosen by net inflow and by volume (a holder outside both is not in it) and adds balance, value_usd, supply_pct, balance_basis, balance_approximate and candidate_coverage to each row; balance_basis is 'chain' for a balance read from the chain ('unsupported' means the row is still ranked by flow, as for a chain's native coin), balance_approximate is true when a candidate's balance could not be read or the total supply is unknown, and candidate_coverage is the share of the total supply the candidates' balances add up to. sort='balance' is not available on every chain (the error names it). exclude_exchanges=true drops wallets labelled as an exchange. | Read-only |
| token_screener | Discover tokens by activity within a window. Rank by volume, net inflow, holder count, or smart-money inflow. Filters: min volume USD, min holders, smart-money-only. Use when the user asks 'what tokens are trending today' / 'find tokens with smart money accumulating' / 'rising tokens under $100M cap'. | Read-only |
| token_search | Search for tokens by name or symbol. Returns matching symbols, names, addresses (0x-prefixed, lower case; pass them straight to token_holders and token_transfers), and logos. | Read-only |
| token_transfers | Get who bought and sold a specific token in a given period, ranked by net USD. tab=bought lists the top NET buyers (bought more than sold), tab=sold the top NET sellers, largest first, with quantities and USD values. Wallets that only pass the token through (routers, pools: bought ~= sold) are not listed; a row can still be a contract (a pool, vault or settlement contract), and `title` names the known ones; `hide_contracts` leaves out the contracts we know of. bought / sold / net_tokens are whole tokens, usd_spent / usd_received USD. net_usd = usd_received - usd_spent, so a net buyer's is NEGATIVE: its net USD bought is -net_usd. | Read-only |
| transaction_lookup | What happened in one transaction, by hash: `status` (success, failed, pending; unknown for Ethereum transactions before October 2017), `block`, `time`, `from` and `to` (each with its label: entity, wallet_type, label_confidence), `value` (the chain's coin sent at the top level: `amount` in whole coins, `amount_wei` exact, `amount_usd`), `fee` (gas_used, gas price and the fee in the chain's coin) and `token_transfers`: every ERC-20 transfer in it with token_address, symbol, decimals, from and to (labelled), `amount` in whole tokens, `amount_raw` exact and `amount_usd`. `usd_basis` says how each USD value was priced: transfer_time (the price at the transaction's minute) or latest_daily_price (only for a transaction from the last 24 hours not priced yet); null = no price. NFT transfers and internal (contract-call) coin transfers are not listed. `found` is false when the hash does not exist on that chain: the same hash format is used on every EVM chain, so try the chain it was sent on. Use when the user pastes a transaction hash or asks 'what happened in this transaction' / 'did it go through'. | Read-only |
| wallet_batch_labels | Bulk label + 30d summary lookup for many addresses in one call. Caps at 100 addresses. Returns one row per input address in input order, with: entity, wallet_type, risk_flag, 30d net flow, 30d volume, 30d tx count, read from `chain`'s own tables. The 30d fields are live and null only for an address with no label (found: false). A row whose address source provider_e knows also carries provider_e: a list of that source's labels (the same entries wallet_label_provenance returns for source='provider_e'), on any chain; it never changes entity, wallet_type or found. Use when the user pastes a CSV of addresses or asks to enrich a list. | Read-only |
| wallet_check | Everything we know about ONE address in one call: a wallet checker / address lookup. Each part is its own block: `ens` (reverse ENS name), `tags` (names attached to the address, e.g. a token's name), `labels` (per chain: entity and wallet type), `label_sources` (which source claimed what about the address, read for Ethereum; third-party providers are named provider_a to provider_e), `label_origins` (BNB Chain, Base, HyperEVM: the origins each chain's label records and what each claimed, `origin` one of third_party (provider_a), model (our heuristic, with its source, confidence (null = not scored) and tier), cross_chain (copied from the same address's label on `from_chain`) or unknown; a claim can differ from the label), `onchain` (transfer count per chain where the address is active), `code` (per chain, the code found at the address when last checked: contract, eip7702 delegated wallet, safe multisig or proxy; a chain absent means no code when checked, or not checked), `token` (name, symbol and chain when it is a token contract), `first_funder` (per chain: the earliest inbound coin and priced token transfers we hold, with sender and label; not proof of who funded the wallet), `exchanges` (per chain: the centralised exchanges it sent to and received from over 365 days, a lower bound), `hl_trader`, `hl_vault`, `hl_builder` (its Hyperliquid identity), `polymarket` (the Polymarket account at this address, its owner, and the accounts it owns), `predictfun` (its Predict.fun fills, counted up to 100,000, first and last trade in epoch ms, and its realized P&L and volume from the leaderboard once ranked; null when it never traded there), and `summary` (plain observed facts read off the blocks, never a verdict such as 'safe'). first_funder and exchanges cover every chain the address has transfers on, or only `chain`. A block missing from the answer could not be read; an empty one means we looked and found nothing. Use when the user pastes an address and asks 'whose wallet is this', 'what is this address' or 'check this wallet'; for one chain's funder or exchanges with other floors or windows, use wallet_first_funder / wallet_exchange_usage. | Read-only |
| wallet_compare | Compare two wallets: shared counterparties (both wallets transacted with these addresses) + shared tokens (both wallets touched these tokens) within a window. Use when the user asks 'are these two wallets related' / 'what do X and Y have in common'. | Read-only |
| wallet_counterparties | Top trading partners of an ETH/BSC/Base/HyperEVM wallet by combined transfer volume. Returns counterparty address, total volume, amount sent/received, tx count, first/last seen, and labels (when known). Use when the user asks 'who does this wallet trade with' / 'main counterparties of X'. | Read-only |
| wallet_discover | Find top wallets ranked by volume, inflow, outflow, net flow, tx count, or realized PnL. On base and hyperevm window=all always works; 24h/7d/30d/90d only while those windows were refreshed in the last 2 days, otherwise a 400. | Read-only |
| wallet_ens | Reverse ENS lookup: turn a 0x address into a human-readable name like 'vitalik.eth'. Returns null if the address has no ENS name set. Use whenever you have an address and want to display a friendlier identifier. | Read-only |
| wallet_exchange_usage | Which centralised exchanges a wallet sent to and received from over a window, computed from our transfers joined to the addresses the chain's label table marks as exchanges. Returns `exchanges` [{entity, sent_usd, recv_usd, sent_share, transfers, first_seen, last_seen, addresses, label_confidence, label_sources}] with USD in plain dollars (priced transfers only), and `activity` totals over ALL counterparties so shares can be checked. `pattern` is "sweeps_to_single_cex" when >=90% of the wallet's outgoing USD went to one exchange across >=3 outgoing transfers: an OBSERVED pattern, not a claim that the address is a deposit address. Exchange figures are a lower bound (an exchange address we have not labelled is invisible; labels are sparse on hyperevm) and labels are a consensus with a stated confidence, not a certainty. A very active wallet is refused with a message to narrow `window`. `found` is false when the wallet has no priced transfer in the window. Use when the user asks 'which exchanges does this wallet use' / 'does it send to an exchange'. | Read-only |
| wallet_first_funder | The earliest inbound transfers of a wallet, from our own transfer tables, as TWO separate answers: `first_native_in` (the first plain send of the chain's coin to the wallet, at least `min_native` WHOLE coins; `amount` in whole coins, `amount_wei` exact in wei) and `first_token_in` (the first token transfer priced at `min_usd` USD or more; `amount` in whole tokens). Each carries the sender, its label (entity, wallet_type, label_confidence), time, tx_hash, block and `amount_usd` in plain dollars (null = no USD price). This is NOT proof of who funded the wallet: native rows hold top-level sends only (coin moved by a contract call or a bridge is absent), history starts on a different date per chain (`coverage.history_from`), and the sender may be an exchange or a relay. `found` is false when neither exists. On hyperevm, protocol system addresses appear as senders and come back with wallet_type 'system' (no entity name). Use when the user asks 'who funded this wallet' / 'where did its first coins come from', and pass the coverage caveats on. | Read-only |
| wallet_label_provenance | Full multi-source label cascade for one ETH wallet. Returns labels from several third-party label providers and the heuristic classifier with per-source attribution and a consensus entity/type. Source provider_e covers addresses that are, control or funded Polymarket wallets (category pm_wallet / pm_owner / pm_funder, with n_wallets, volume_usd, realized_pnl_usd, top_wallet and its public name) and mass payers of those wallets (bridge, exchange, batch_sender, campaign, pm_rewards_payer, ...), with basis onchain_fact or behaviour_inferred / behaviour_corroborated (a guess from behaviour) and evidence; it answers for an address on any EVM chain, and never feeds the consensus. found is true when any source knows the address. Use when the user asks 'what do you know about this address', 'who labeled this wallet' or 'is this a Polymarket trader'. | Read-only |
| wallet_pnl_history | Daily net-flow series for a wallet over the last N days (proxy for daily PnL). Returns per-day net inflow USD + cumulative + gross volume + tx count. NOTE: this is net inflow USD, not true realized PnL (which would require WAC accounting per token). Useful as a directional indicator. | Read-only |
| wallet_positions | A wallet's per-token positions on one chain with real profit and loss. Per token: token_address, symbol, name, bought_qty and bought_usd, sold_qty and sold_usd, avg_buy_price and avg_sell_price (USD per token), realized_pnl_usd, balance (read from the chain at request time), price_usd (latest daily price), value_usd and unrealized_pnl_usd = balance x (price_usd - avg_buy_price), null when either is unknown. Bought and sold are the wallet's priced inbound and outbound transfers of the token (a swap, a move between its own wallets and an exchange deposit all count); a transfer with no USD price (a mint, a pre-listing airdrop) is neither. Realized PnL is average cost: only units that were bought are realized, the chain's coin and its wrapped token (WETH, WBNB, WHYPE) are one position under the zero address, and Ethereum stablecoins and disabled tokens are left out. `totals` cover EVERY token the wallet traded, not only the rows returned: realized_pnl_usd, unrealized_pnl_usd (over the tokens where it is known), tokens_traded, tokens_profitable and `as_of`, when the wallet's lifetime PnL in the wallet rankings was last recomputed (updated nightly at 04:00 UTC); the positions count trades up to the latest priced transfers, so the two differ only when the wallet traded since. USD in plain dollars. `found` is false for a wallet with no priced trade. Use when the user asks 'what did this wallet make on each token' / 'is it in profit' / 'what is it holding and at what cost'; wallet_pnl_history is a daily net-flow series, not this. | Read-only |
| wallet_summary | Get a wallet's aggregate metrics: volume, inflow, outflow, net flow, tx count, tokens traded across time windows (24h/7d/30d/90d/all). Without `chain` it 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; the result's `chain` says which. | Read-only |
| wallet_token_balances | Current token balances for a wallet on Ethereum, BSC, Base and HyperEVM, read from the chain at request time. Returns per-holding (chain, symbol, balance, USD value, USD price). On base and hyperevm, symbol, name, balance and USD exist only for tokens we map and price (about 170 on base, about 50 on hyperevm). Any other token is listed, with its address and balance_raw and the rest null, only when min_usd=0 is passed: the default floor of $1 keeps priced tokens only. A non-zero native balance is always listed, with a USD value where a price exists; HyperCore (spot or perp accounts) is not included. Use when the user asks 'what tokens does this wallet hold' / 'current portfolio of X' — pair with wallet_label_provenance for institutional context. | Read-only |
| wallet_trace | Trace a wallet's money through counterparties. direction=out follows where funds went, in where they came from, both (default) either way. At each hop, expand to the top N counterparties by USD volume in that direction. Returns nodes + edges of the resulting graph. Use when the user asks 'where did funds from X go' (out) / 'who funded Y' (in) / 'follow the money 3 hops from Z' / wallet investigation. | Read-only |
| wallet_transactions | Raw per-wallet transfer list (single transactions, not aggregates). Filter by direction (in/out/all), days back, min USD, and optionally a specific token and, for that token, an amount range in whole tokens. Returns time, tx_hash, from, to, token_address, symbol, amount (whole tokens; null when the token's decimals are unknown), value_usd, direction, block. Use when the user asks 'show me recent transfers for X' / 'last 100 transactions of wallet Y' / forensic audit queries. | Read-only |
Change history
- Description changed (GitHub registry)
- wallet_check: description changed (+"`predictfun` (its Predict.fun fills, counted up to 100,000, first" +"last trade in epoch ms, and its realized P&L and volume from the leaderboard once ranked; null when it never traded there), and")
- search: description changed (+"matched), `predictfun` (open Predict.fun markets on BNB Chain whose title or question holds every word, the busiest (24 h volume) first, then the newest, each {market_id, title, question, status, url}; closed and resolved ones only when nothing else matched; a pasted address that has traded there is one {address, url} row)" -"matched)")
- predictfun_wallet_trades: tool added
- predictfun_wallet_positions: tool added
- predictfun_wallet_flows: tool added
- predictfun_overview: tool added
- predictfun_markets: tool added
- predictfun_market_trades: tool added
- predictfun_market_detail: tool added
- predictfun_market_book: tool added
- predictfun_leaderboard: tool added
- polymarket_chainlink_prices: tool added
- hl_segments: input schema changed
- hl_segments: description changed (+"equity:" +"value, plus for a unified or portfolio-margin wallet the USDC it holds outside it" -"equity, native perp account only:")
- hl_perp_top_traders: description changed (+"them; perp_account_value is the native perp account and account_mode default, unifiedAccount, portfolioMargin or disabled)" +"unified and portfolio-margin wallets)," -"them)")
- hl_market: input schema changed
- hl_market: description changed (+"it), `account_mode` (`default`, `unifiedAccount`, `portfolioMargin`, `disabled`) and `whole_account_value`: in the two modes whose margin lives outside the perp account, the native account plus the USDC held outside it, else equal to `account_value`; both null on a row that does not record the mode (before 2026-11-07 20:03 UTC or from the fallback poller);" -"it);" -"of up to 64 `symbols` at once, the close (from fills) beside open interest, funding rate and premium (node snapshots averaged over the hour); `rows` are ARRAYS in `columns` order, not objects, `days` (default 120, at most 400) or `start` sizes the window, and `start` / `end` in the answer are")
- hl_archive: input schema changed
- hl_archive: description changed (+"fill)," +"`positions_hourly` (every position as last seen in each hour), `cohorts_hourly` (the hourly cohort matrix of every asset) and `wallets_hourly` (each wallet's native perp account per hour)," +"every dataset")
- Listed (GitHub registry)
| Source | Listing | First seen | Last seen | Versions |
|---|---|---|---|---|
| GitHub MCP Registry | io.vike/data | 31 Oct 2026 | 13 Nov 2026 | 2 |