Vike Data API

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; hl_wallet_orders = the orders of wallet (required) worth at least min_value_usd (size x price, default 10000, >= 1000) that are placed or gone (events), narrowed by side and token_symbol, from the 5-minute order-book snapshots, as one event per evaluator pass (about every 5 minutes) whose orders lists every one of them with its action (placed or gone; a gone one with its outcome filled, partially_filled or canceled) and the pass totals beside it (a pass of more than 200 orders comes as parts events of 200, each with its part and the same totals); private to the alert's owner. 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.

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.

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.

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. A page also ends once its events pass about 2 MB (a wallet-orders event can list 200 orders), so it can hold fewer than limit events with has_more true: keep paging, nothing is skipped. Each event has id, rule_id, alert_label, alert_type, created_at, event (what happened: the transfer, fill, liquidation, bias flip, proximity crossing, a pass of wallet orders, 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.

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).

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.

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

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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}.

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}.

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.

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, each with its owner's sizeCohort, pnlCohort and pnlCumUsd (without at the current labels, with at those of the hour before the snapshot's own hour), optionally one cohort's, 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. book: one symbol's order book at one instant, the resting limit orders summed per price (px, sz, n orders), levels a side, bids highest first and asks lowest first; l4_5m from 2026-11-13 08:40 UTC, state_12m from 2026-07-28, and snapshotTs is the snapshot's own time. squeeze: one perp's price ladder at one instant, per bucket the resting book (size and USD value), the stop orders that would trade into it when triggered and the open positions that would be liquidated into it, and pressure = that forced selling over the USD value of the resting bids below the mid, forced buying over the asks above it (above 1: a squeeze); cohort keeps one cohort's stops and liquidations. book_cohorts: which cohorts own the resting book within band_bps of the mid over time, per point and cohort the bid and ask notional and its share, each owner labelled as of that 5-minute snapshot. open, clusters, book, book_cohorts and walls read the perp books unless market=spot. walls: the large orders (at least min_usd, default $1M; a stop or take-profit at its trigger price) of a symbol and/or a wallet whose last sighting falls in a window (default the last 24 hours, at most 7 days), newest first, each with outcome (filled, partially_filled, pulled = left the book with no fill, open, or unknown while the fills are not yet stored), filled_usd, lifetime_s, near_touch (the other side of the book within touch_bps of its price when it was last seen; null where that snapshot's book is not stored: 5-minute snapshots before 2026-11-13 08:40 UTC) and its owner's labels (current for an open wall, else those of the hour before it was last seen: each row's label_basis). order_stats: one wallet's walls of at least min_usd (default $100k) in a window (default and at most 7 days) in totals and for its 20 busiest symbols: counts per outcome, pulled_share (pulled / walls that left the book with a known outcome), cancel_to_fill_ratio (pulled / filled), pulled_near_touch_share (over its newest 1,000 pulled walls), median_lifetime_s, total_wall_usd and filled_usd. Same data as GET /v1/hyperliquid/orders, /wallets/{address}/orders, /symbols/{symbol}/order-clusters, /symbols/{symbol}/book, /symbols/{symbol}/squeeze-map, /symbols/{symbol}/book-cohorts, /walls and /wallets/{address}/order-stats.

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%).

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).

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}.

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.

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).

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.

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.

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.

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}.

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.

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.

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').

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.

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.

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'.

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.

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.

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.

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}.

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'.

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.

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).

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.

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.

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.

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.

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.

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.

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).

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

How to use the vike WebSocket stream (wss://stream.vike.io/v1/stream/), 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.

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.

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'.

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.

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.

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'.

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.

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.

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'.

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'.

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.

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.

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'.

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.

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'.

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.

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.

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.

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.

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.

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.