@vike-io/cli 0.14.0 → 0.16.0

package/skills/vike-token-holders/SKILL.md

@@ -9,7 +9,7 @@ allowed-tools: Bash(vike-data:*)
 ## Command
 
 ```bash
-vike-data token holders <token_address> [--chain ethereum|bsc|base] [--limit N] [--json]
+vike-data token holders <token_address> [--chain ethereum|bsc|base|hyperevm] [--limit N] [--json]
 ```
 
 ## Examples
@@ -34,10 +34,12 @@ vike-data token holders 0x6982508145454ce325ddbe47a25d4ec3d2311933 --limit 20
 
 ## Anti-patterns
 
-- "Top holders" here means cumulative net inflow over our recorded transfer history — NOT current on-chain balance. A wallet that bought $10M and sold $9M shows `net_flow_usd = $1M`, even if current balance is zero. The top rows are very often intermediaries (exchange wallets, lending protocols, MEV bots) with huge `volume_usd` against a small net: read this as "who moves the most of this token". **Always call this out** when reporting top holders. For what one specific wallet holds right now use `vike-data wallet balances <addr>` (Ethereum and BSC).
-- There is no concentration metric (top-N share of supply) in the output; don't compute one from `net_flow_usd`.
+- "Top holders" here means cumulative net inflow over our recorded transfer history — NOT current on-chain balance. A wallet that bought $10M and sold $9M shows `net_flow_usd = $1M`, even if current balance is zero. The top rows are very often intermediaries (exchange wallets, lending protocols, MEV bots) with huge `volume_usd` against a small net: read this as "who moves the most of this token". **Always call this out** when reporting top holders. For the largest current BALANCES use `vike-data call token_holders --args '{"token_address":"0x...","chain":"ethereum","limit":50,"sort":"balance"}'` (adds `balance`, `value_usd`, `supply_pct`; not on every chain), and for what one wallet holds `vike-data wallet balances <addr> --chains <chain>`.
+- Don't compute a share of supply from `net_flow_usd`; the balance ranking above has `supply_pct`.
 - Don't list `tx_count = 1` whales as "smart money" without context — could be an airdrop receiver who never sold.
-- For BSC tokens, pass `--chain bsc` explicitly; default is ethereum.
+- Pass `--chain` explicitly for anything but Ethereum (`bsc`, `base`, `hyperevm`); the default is ethereum.
+- **It is slow on busy tokens**: the tool scans the whole chain for the token (tens of seconds). Run it once and don't retry in a loop.
+- To classify the top holders (exchange, contract, fresh, risk-flagged) use `vike-token-holder-diligence`.
 
 ## Pairs well with
 

package/skills/vike-token-research/SKILL.md

@@ -18,13 +18,12 @@ Multi-call token research workflow. It characterises WHO is moving the token (th
 
 2. **Recent buyers + sellers** (parallel calls)
    ```bash
-   vike-data token transfers <addr> --tab bought --period 24h --chain <chain> --json
-   vike-data token transfers <addr> --tab sold   --period 24h --chain <chain> --json
+   vike-data token transfers <addr> --tab bought --period 24h --chain <chain> --hide-contracts --json
+   vike-data token transfers <addr> --tab sold   --period 24h --chain <chain> --hide-contracts --json
    ```
-   Each call returns the top 10 wallets for one side.
+   Each call returns the top 10 net buyers or net sellers, ranked by net USD; `--hide-contracts` leaves out the pools and routers we know of.
 
-3. **Read `net_tokens`, not `bought`.** `bought` counts every inbound transfer (flash-loan and router round trips included). Merge the two lists by `address`, then:
-   - drop rows where `|net_tokens|` is below 1% of `max(bought, sold)`: they are round trips, not a position;
+3. **Read `net_tokens` and `net_usd`** (a net buyer's `net_usd` is negative). Merge the two lists by `address`, then:
    - label the rest with `vike-data wallet batch <addrs...> --chain <chain>` and drop CEX / router / contract rows if the user wants "real" flow;
    - split what is left into net accumulators (`net_tokens > 0`) and net distributors (`net_tokens < 0`) and add up each side's `|net_usd|`.
 
@@ -54,5 +53,6 @@ Step 1: free. Step 2: 2 calls × 2 credits. Step 3 labels: 2 credits. Total ≈
 
 ## Pairs well with
 
-- `vike-smart-money-discovery` to see whether the smart-money cohort is flowing into the token
+- `vike-smart-money-discovery` to see whether the smart-money cohort is flowing into the token; `vike-token-smart-money-trend` for its direction over time
+- `vike-token-holder-diligence` for who sits at the top (exchanges, contracts, fresh wallets, risk flags)
 - `vike-perp-funding` if the token has a perp listing (BTC/ETH/SOL/major alts)

package/skills/vike-token-screener/SKILL.md

@@ -10,7 +10,7 @@ allowed-tools: Bash(vike-data:*)
 
 ```bash
 vike-data token screener
-  [--chain ethereum|bsc|base]
+  [--chain ethereum|bsc|base|hyperevm]
   [--window 24h|7d|30d|90d]
   [--sort volume|net_inflow|holders|smart_inflow]
   [--limit N]                (default 20, max 100)
@@ -20,7 +20,7 @@ vike-data token screener
   [--json]
 ```
 
-`--smart-money-only` and `--sort smart_inflow` exist for `--chain ethereum` only; on `bsc` and `base` they are a 400.
+`--smart-money-only` and `--sort smart_inflow` exist for `--chain ethereum` only; on `bsc`, `base` and `hyperevm` they are a 400.
 
 ## Examples
 
@@ -76,7 +76,7 @@ vike-data token screener --min-volume 1000000 --min-holders 100 --sort net_inflo
 - Don't use `--window 24h --sort smart_inflow` for hot-new-token discovery: smart money usually positions before the 24h window; try `--window 7d`.
 - Don't omit `--min-holders` when sorting by `holders`: junk airdrops with 50,000 one-transaction addresses dominate the top otherwise.
 - Don't omit `--min-volume` when sorting by `net_inflow`: tiny tokens with $100 net flow can rank high in % terms.
-- Don't use `--smart-money-only` on `bsc` or `base`: it is a 400, not an empty result.
+- Don't use `--smart-money-only` on `bsc`, `base` or `hyperevm`: it is a 400, not an empty result.
 
 ## Cost note
 

package/skills/vike-token-search/SKILL.md

@@ -11,7 +11,7 @@ Symbol/name → address resolver.
 ## Command
 
 ```bash
-vike-data token search <query> [--chain ethereum|bsc|base] [--limit N] [--json]
+vike-data token search <query> [--chain ethereum|bsc|base|hyperevm] [--limit N] [--json]
 ```
 
 ## Example
@@ -26,6 +26,7 @@ vike-data token search PEPE --chain ethereum --limit 5
 ## When to use
 
 - Any time the user mentions a token by symbol — always confirm the address before downstream calls.
+- `--chain hyperevm` searches a small registry (about 50 tokens), so no match may only mean the token is not in it. For a name across every chain, plus live price and the vike.io page, `vike-data search <name>` (its `tokens` section).
 - The default chain is **ethereum**; if the user asks "what's the address of CAKE", default to **bsc** if the symbol is bsc-native.
 
 ## Anti-patterns

package/skills/vike-token-smart-money-trend/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: vike-token-smart-money-trend
+description: Is the smart-money cohort entering, holding or exiting one Ethereum token over time - the cohort's net flow across 24h, 7d, 30d and 90d, differenced into disjoint slices, then the wallets behind the latest move. Use when the user asks "is smart money still buying X" / "did smart money exit X" / "how long has smart money been accumulating X" / "smart money trend for X".
+allowed-tools: Bash(vike-data:*)
+---
+
+# vike-token-smart-money-trend
+
+Direction over time for ONE token, on **Ethereum only** (`--smart-money-only` and `--sort smart_inflow` are a 400 on bsc, base and hyperevm). For "which tokens is the cohort buying right now" use `vike-smart-money-discovery`. About 18 credits.
+
+## Chain
+
+```bash
+vike-data token search ENA --chain ethereum --limit 3 --json            # 0  the address
+vike-data token screener --chain ethereum --window 24h --sort smart_inflow --smart-money-only --limit 100 --json   # 3
+vike-data token screener --chain ethereum --window 7d  --sort smart_inflow --smart-money-only --limit 100 --json   # likewise 30d, 90d
+                                                                        # find the token's row in each
+vike-data token transfers <addr> --tab bought --period 7d --chain ethereum --hide-contracts --json   # 2  top 10 net buyers
+vike-data token transfers <addr> --tab sold   --period 7d --chain ethereum --hide-contracts --json   # 2  top 10 net sellers
+vike-data wallet batch <those addresses> --chain ethereum --json        # 2  drop cex / dex / market_maker rows
+```
+
+## Reading
+
+In smart-money mode a row is the COHORT's flow in that token: `net_flow_usd` = `in_usd` - `out_usd`, `unique_holders` = cohort wallets active, `tx_count`. Rows are sorted by `net_flow_usd`. The token absent from the top 100 means its cohort net flow is below the 100th row's, not that the cohort has no flow. Skip `0x000...0` (the native coin).
+
+**The windows overlap, so difference them** into disjoint slices before reading a trend. A window of N days is every UTC calendar day from `today - N` to today (today still in progress), so `24h` is yesterday plus today, not a rolling 24 hours:
+
+| Slice | = | Calendar days |
+|---|---|---|
+| newest | 24h | today and yesterday |
+| rest of the week | 7d - 24h | the 6 days before |
+| rest of the month | 30d - 7d | the 23 days before that |
+| rest of the quarter | 90d - 30d | the 60 days before that |
+
+**Compare signs, not magnitudes**: the slices differ in length and today is partial. Example, ENA on 2026-10-19: 24h +$14.9M, 7d +$38.3M, 30d +$27.9M, 90d +$54.0M, so newest +$14.9M, rest of the week +$23.4M, rest of the month -$10.4M, rest of the quarter +$26.1M: the cohort sold for three weeks, then came back in the last week.
+
+| Newest | Rest of week | Rest of month | Read |
+|---|---|---|---|
+| + | + | + | sustained accumulation |
+| + | + | - | re-accumulation: turned from seller to buyer |
+| + | - | any | a short buy after a quiet or selling week: weak until the week confirms |
+| - | + | any | reducing after a build |
+| - | - | - | distribution |
+
+Then name the wallets behind the latest slice from the two `token transfers` lists. They are ranked by net USD (`--tab bought` = net buyers, whose `net_usd` is NEGATIVE: net USD bought is `-net_usd`); `net_tokens` is the net in whole tokens. `--hide-contracts` leaves out the pools and routers we know of; still drop the rows `wallet batch` calls `cex`, `dex` or `market_maker`: an exchange hot wallet can top the net-buyer list.
+
+## Anti-patterns
+
+- No tool lists cohort members, and the `token transfers` lists are the top 10 net movers, not the cohort: say the named wallets are the largest net movers, not proven cohort members.
+- Don't read a 1-day sign as a trend, and don't read a screener sign as a price call.
+- Don't use it on bsc, base or hyperevm; there the answer is "no cohort data", not "no smart money".
+
+## Pairs well with
+
+- `vike-smart-money-discovery` (which tokens), `vike-token-screener` (columns), `vike-token-holder-diligence` (who holds it)
+- `vike-perp-crowding` if the token has a perp listing

package/skills/vike-token-transfers/SKILL.md

@@ -12,7 +12,8 @@ allowed-tools: Bash(vike-data:*)
 vike-data token transfers <token_address>
   [--tab bought|sold]            # default sold; ONE side per call
   [--period 1h|24h|7d|30d]       # default 24h
-  [--chain ethereum|bsc|base|all]
+  [--chain ethereum|bsc|base|hyperevm|all]
+  [--hide-contracts]             # leave out the pools, routers and other contracts we know of
   [--json]
 ```
 
@@ -20,8 +21,8 @@ There is no `--limit`: every call returns the top 10 wallets for that side. For
 
 ## When to use
 
-- "Who's accumulating X?" → `--tab bought --period 24h`, then read `net_tokens`
-- "Who's dumping X?" → `--tab sold --period 24h`, then read `net_tokens`
+- "Who's accumulating X?" → `--tab bought --period 24h --hide-contracts`
+- "Who's dumping X?" → `--tab sold --period 24h --hide-contracts`
 - "Smart money on X this week" → `--tab bought --period 7d`, label the addresses with `vike-data wallet batch`
 
 ## Output columns
@@ -32,7 +33,7 @@ There is no `qty`, `usd_value`, `label` or `tx_count` column. To label an addres
 
 ## Reading tips
 
-- **`bought` is every inbound transfer, not purchases.** It includes flash-loan and router round trips. A wallet at the top of `--tab bought` with `bought ≈ sold` and `net_tokens ≈ 0` is a bot or venue passing tokens through, not a buyer. **Rank and judge by `net_tokens`** (bought − sold): positive = net accumulator, negative = net distributor.
+- **The rows are the top 10 NET buyers (`--tab bought`) or net sellers, ranked by net USD.** Wallets that only pass the token through (bought ≈ sold) are not listed, but a row can still be a pool, vault or settlement contract: `--hide-contracts` leaves out the ones we know of, and `wallet batch` labels the rest. `net_tokens` (bought − sold) is the net in whole tokens.
 - **Signs differ by convention.** `net_usd = usd_received − usd_spent`, so a net buyer has `net_tokens > 0` and `net_usd < 0`, and a net seller has `net_usd > 0`. Do not read a positive `net_usd` as "bought".
 - The two sides of the same period are separate top-10 lists. The same wallet in both = market maker / churn, not a signal.
 - The window ends at the token's newest PRICED row, not at the current time. For an illiquid token it can be hours behind "now".
@@ -41,12 +42,13 @@ There is no `qty`, `usd_value`, `label` or `tx_count` column. To label an addres
 
 ## Anti-patterns
 
-- Don't call a wallet a buyer or seller from `bought` / `sold` alone. Check `net_tokens`.
+- Don't call a contract row a buyer: use `--hide-contracts`, then label what is left.
 - Don't request `--chain all` unless you really need cross-chain: it maps the address to the token's address on each chain and is slower.
 - 1h period is sparse for low-liquidity tokens. Use 24h as the default starting window.
-- Don't treat the 10 rows as the token's whole market: they are the top 10 by volume on one side.
+- Don't treat the 10 rows as the token's whole market: they are the top 10 net movers on one side.
 
 ## Pairs well with
 
 - `vike-data wallet batch <addr...>` to label the rows and drop CEX / router rows
 - `vike-data wallet summary <addr>` to profile any interesting buyer/seller
+- `vike-token-smart-money-trend` to put the buyers next to the smart-money cohort's flow over time

package/skills/vike-wallet-balances/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vike-wallet-balances
-description: Current token balances for a wallet on the chains the server scans (Ethereum and BSC today), read from the chain at request time, with a USD value where the token is priced. Use when the user asks "what does this wallet hold" / "current portfolio of X" / "show top holdings".
+description: Current token balances for a wallet on Ethereum, BSC, Base and HyperEVM, read from the chain at request time, with a USD value where the token is priced. Use when the user asks "what does this wallet hold" / "current portfolio of X" / "show top holdings".
 allowed-tools: Bash(vike-data:*)
 ---
 
@@ -10,12 +10,12 @@ allowed-tools: Bash(vike-data:*)
 
 ```bash
 vike-data wallet balances <address>
-  [--chains ethereum,bsc]   (default: every chain the server scans)
+  [--chains ethereum,bsc,base,hyperevm]   (default: all four)
   [--min-usd 1]             (hide holdings worth less; default 1)
   [--json]
 ```
 
-`vike-data schema --pretty` shows the current chain list. A chain the tool does not scan is not silently skipped: it is named in `chain_errors`.
+Scanning all four chains is slow (tens of seconds for a busy wallet): pass `--chains` with the chain you need. Any other chain (arbitrum, polygon...) is not skipped silently: it is named in `chain_errors`. Each holding carries its own `chain`, so this is also the quickest way to see WHERE a wallet's value is before choosing `--chain` for the per-chain wallet commands.
 
 ## Example
 
@@ -33,17 +33,19 @@ vike-data wallet balances 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 --chains et
   "holdings": [
     { "chain": "ethereum", "symbol": "ENS", "name": "Ethereum Name Service", "address": "0xc183...", "balance": 1144.04, "balance_raw": "1144036076063671431479", "usd_value": 6843.62, "usd_price": 5.982 },
     { "chain": "ethereum", "symbol": "WEI", "address": "0x0000...", "balance": 1.0, "balance_raw": "1", "usd_value": null, "usd_price": null },
-    { "chain": "ethereum", "symbol": "ETH", "name": "ETH", "address": null, "balance": 2.5, "balance_raw": "2500000000000000000", "usd_value": null, "usd_price": null }
+    { "chain": "ethereum", "symbol": "ETH", "name": "ETH", "address": null, "balance": 2.5, "balance_raw": "2500000000000000000", "usd_value": 9500.0, "usd_price": 3800.0 }
   ]
 }
 ```
 
-Holdings are sorted by `usd_value` descending with unpriced rows (the native coin among them) last. `chain_errors` appears only when a requested chain was refused or failed.
+Holdings are sorted by `usd_value` descending with unpriced rows last. `chain_errors` appears only when a requested chain was refused or failed.
 
 ## Reading
 
 - **`usd_value: null` is a holding, not an error**: the token has no price feed. `total_usd` sums only priced holdings, so read it as a floor, never as net worth, and never infer "worthless" from a null.
-- **The chain's native coin (ETH, BNB) is a row** with `usd_value: null`, and it is **left out of `total_usd`**. Report the native balance from its own `balance` field. It is always listed, whatever `--min-usd` says.
+- **The chain's native coin (ETH, BNB, HYPE) is a row** whenever its balance is not zero, whatever `--min-usd` says, with a USD value (counted in `total_usd`) where a price exists.
+- **On `base` and `hyperevm` a row has `symbol`, `name`, `balance` and `usd_value` only for tokens we map and price** (about 170 on base, about 50 on hyperevm). `--min-usd 0` adds every other token the wallet holds, with its contract `address` and `balance_raw` and the rest `null`: often thousands of airdrop-spam rows, so use it deliberately.
+- `hyperevm` is the HyperEVM chain only: HyperCore (Hyperliquid spot or perp accounts) is not included; Hyperliquid perp equity is `vike-data hl wallet <address>`.
 - **Any `--min-usd` above 0 also drops unpriced holdings** (an unpriced holding cannot show it clears the floor). `--min-usd 0` lists everything, including airdrop spam.
 - `total_usd` covers `chains_scanned` only. The wallet may hold value on chains the tool does not scan: say so when relevant.
 - Stablecoin-heavy wallet → likely waiting for a buy / parked dry powder
@@ -53,7 +55,7 @@ Holdings are sorted by `usd_value` descending with unpriced rows (the native coi
 
 ## Anti-patterns
 
-- Don't report `total_usd` as the wallet's value without "of priced tokens" and the native balance next to it.
+- Don't report `total_usd` as the wallet's value without "of priced tokens".
 - For wallets with 100+ tokens, the response is large — use `--min-usd 100` or higher to focus on meaningful holdings.
 - This is a point-in-time read, not history. For how the wallet got here use `wallet pnl-history`.
 

package/skills/vike-wallet-batch/SKILL.md

@@ -10,7 +10,7 @@ allowed-tools: Bash(vike-data:*)
 
 ```bash
 vike-data wallet batch <addr1> <addr2> <addr3> ...
-  [--chain ethereum|bsc|base]     # default ethereum; labels and flows are read from THAT chain's tables
+  [--chain ethereum|bsc|base|hyperevm]     # default ethereum; labels and flows are read from THAT chain's tables
   [--json]
 ```
 
@@ -37,8 +37,8 @@ One row per INPUT address (preserves input order — useful when joining back to
 ## Chain behaviour
 
 - `--chain` picks the label table and the 30-day flow table. Before 2026-10-19 it was accepted and ignored (`bsc` and `base` returned Ethereum labels), so earlier results for those chains are Ethereum's.
-- **The four 30-day fields (`net_30d_usd`, `volume_30d_usd`, `tx_30d`, `tokens_30d_count`) are `null`, not 0,** where we hold no flow data: every `bsc` address, and any address we have no label for (`found: false`). Don't report null as zero activity.
-- `found: false` = the address is not in that chain's label table. It is not proof the wallet is new or clean.
+- **The four 30-day fields (`net_30d_usd`, `volume_30d_usd`, `tx_30d`, `tokens_30d_count`) are `null`, not 0,** for an address we have no label for (`found: false`). Don't report null as zero activity.
+- `found: false` = the address is not in that chain's label table. It is not proof the wallet is new or clean. Labels are sparse on `hyperevm`, so most rows there will be `found: false`.
 
 ## Reading
 

package/skills/vike-wallet-compare/SKILL.md

@@ -10,13 +10,13 @@ allowed-tools: Bash(vike-data:*)
 
 ```bash
 vike-data wallet compare <address_a> <address_b>
-  [--chain ethereum|bsc|base]
+  [--chain ethereum|bsc|base|hyperevm]
   [--window 24h|7d|30d|90d|180d|all]
   [--limit N]   (max 50)
   [--json]
 ```
 
-Compares exactly two wallets. `--chain base` is accepted, but per-wallet transfer data is documented for Ethereum and BSC: treat an empty Base result as "not covered", not "no shared activity".
+Compares exactly two wallets on one chain (`ethereum`, `bsc`, `base` or `hyperevm`; shared-counterparty labels come from that chain's own label table). Busy wallets are slow (about 20 s for a pair of market makers). For the full verdict with exchanges and routers removed, use `vike-wallets-related`.
 
 ## Output
 

package/skills/vike-wallet-counterparties/SKILL.md

@@ -10,13 +10,13 @@ allowed-tools: Bash(vike-data:*)
 
 ```bash
 vike-data wallet counterparties <address>
-  [--chain ethereum|bsc|base]
+  [--chain ethereum|bsc|base|hyperevm]
   [--window 24h|7d|30d|90d|180d|all]
   [--limit N]   (max 50)
   [--json]
 ```
 
-`--chain base` is accepted, but per-wallet transfer data is documented for Ethereum and BSC: treat an empty Base result as "not covered", not "no activity".
+Chains: `ethereum`, `bsc`, `base`, `hyperevm`. `entity` / `wallet_type` come from THAT chain's label table (empty string when unlabelled). `wallet summary` names the chain it answered for; run this per chain for the others.
 
 ## Example
 

package/skills/vike-wallet-discover/SKILL.md

@@ -13,11 +13,13 @@ vike-data wallet discover
   [--window 24h|7d|30d|90d|all]
   [--sort volume|inflow|outflow|net_flow|tx_count|pnl]
   [--order asc|desc]
-  [--chain ethereum|bsc]
+  [--chain ethereum|bsc|base|hyperevm]
   [--size N]      # default 10, max 20
   [--json]
 ```
 
+**On `base` and `hyperevm` pass `--window all`**: the command sends `30d` by default, and the shorter windows there answer only while they were rebuilt in the last 2 days (otherwise a 400). `ethereum` and `bsc` take every window.
+
 ## When to use
 
 | Question | Flags |

package/skills/vike-wallet-ens/SKILL.md

@@ -25,12 +25,12 @@ vike-data wallet ens 0x28c6c06298d514db089934071355e5743bf21d60
 ## When to use
 
 - Right after any tool returns a wallet address — show ENS as a secondary label
-- When the user pastes an address and asks "what is its ENS name" (for "who is this", start with `vike-data labels <addr>`; ENS is a display name, not an identity)
+- When the user pastes an address and asks "what is its ENS name" (for "who is this", use `vike-wallet-who-is`; ENS is a display name, not an identity)
 - When you're about to display a leaderboard with addresses — enrich each row with ENS if available
 
 ## Direction
 
-**Reverse only: address → name.** There is no name → address lookup: if the user gives `vitalik.eth`, say the tool cannot resolve it and ask for the address. The only parameter is `address`.
+**Reverse only: address → name.** This command has no name → address lookup; for `vitalik.eth` run `vike-data search vitalik.eth`, which searches the address the name points to. The only parameter is `address`.
 
 ## Anti-patterns
 

package/skills/vike-wallet-label-provenance/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vike-wallet-label-provenance
-description: Multi-source label cascade for an Ethereum wallet — shows what each upstream label source AND our in-house heuristic classifier says about an address, with consensus entity/type and per-source attribution. Use when the user asks "who is this address" / "what do you know about this wallet" / "is this address labeled" / "why is this wallet labeled X".
+description: Multi-source label cascade for an Ethereum wallet — shows what each upstream label source AND our in-house heuristic classifier says about an address, with consensus entity/type and per-source attribution. Use when the user asks "what do the label sources say about 0x..." / "is this address labeled" / "why is this wallet labeled X" / "do the sources agree on this label".
 allowed-tools: Bash(vike-data:*)
 ---
 
@@ -14,7 +14,7 @@ The headline differentiator: we don't just show a label, we show **which sources
 vike-data labels <address> [--json]
 ```
 
-Ethereum wallets only. For another chain, or many addresses, use `vike-data wallet batch --chain ethereum|bsc|base`, which reads each chain's own label table.
+Ethereum wallets only. For another chain, or many addresses, use `vike-data wallet batch --chain ethereum|bsc|base|hyperevm`, which reads each chain's own label table. For "who is this wallet" as a whole (labels, ENS, chain, exchanges, counterparties) use `vike-wallet-who-is`.
 
 ## Example
 
@@ -56,7 +56,7 @@ Sources are anonymised on the wire (`provider_a`, `provider_b`, ...). There are
 - **Only 1 source (± heuristic)** → moderate; mention "labeled by one source"
 - **Only the heuristic** → low; mention "predicted by heuristic"
 - **`found: true` with no sources** → the wallet is in our label table but no raw source labels it
-- **`found: false`** → the wallet is missing from our labelled-wallet table, and no source is consulted at all. It does NOT prove that no provider labels it. Say "not in our label table", not "unlabeled" or "clean".
+- **`found: false`** → every source was read and none knows the address, and it is not in our label table (`found` is true when ANY source knows it). It does NOT prove the wallet is clean or new: our sources do not cover every wallet. Say "no label source knows it", not "clean".
 
 Early answers (before 2026-10-19) carried only the Arkham-derived source and the heuristic, so older transcripts undercount sources.
 
@@ -64,7 +64,8 @@ Early answers (before 2026-10-19) carried only the Arkham-derived source and the
 
 - Don't quote any single provider's category field as "the category" — provider taxonomies vary; the `consensus.wallet_type` is the unified field.
 - A `risk_flag` of `scam` / `sanctioned` / `phishing` is high-stakes — always mention it explicitly, never bury it.
-- Don't use this for a BSC or Base address: it reads Ethereum tables only.
+- Don't use this for a BSC, Base or HyperEVM address: the consensus reads Ethereum tables only (only source `provider_e`, Polymarket wallets and their funders, answers on any EVM chain).
+- `consensus.wallet_type` can be wrong when sources disagree (the entity "vitalik buterin" read `dex` because one source says sushiswap): read the `sources` before trusting the type.
 
 ## Pairs well with
 

package/skills/vike-wallet-pnl-history/SKILL.md

@@ -10,12 +10,12 @@ allowed-tools: Bash(vike-data:*)
 
 ```bash
 vike-data wallet pnl-history <address>
-  [--chain ethereum|bsc|base]
+  [--chain ethereum|bsc|base|hyperevm]
   [--days N]   (max 365, default 30)
   [--json]
 ```
 
-`--chain base` is accepted, but per-wallet transfer data is documented for Ethereum and BSC: treat an empty Base result as "not covered", not "no activity".
+Chains: `ethereum`, `bsc`, `base`, `hyperevm`, one chain per call.
 
 ## Output
 

package/skills/vike-wallet-portfolio/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: vike-wallet-portfolio
-description: Composite wallet view — combines ENS + labels + token balances + recent flow + top counterparties in one report. Use when the user gives a wallet address and asks for a complete picture ("full report on X" / "everything about this wallet" / "wallet snapshot" / "who is this wallet").
+description: Holdings-and-activity snapshot of one wallet — ENS, labels, token balances across Ethereum, BSC, Base and HyperEVM, recent flow and top counterparties in one report. Use when the user gives a wallet address and asks for a complete picture ("full report on X" / "everything about this wallet" / "wallet snapshot" / "what does this wallet hold and do").
 allowed-tools: Bash(vike-data:*)
 ---
 
 # vike-wallet-portfolio
 
-Multi-call playbook for a complete wallet snapshot. It reports what the tools return: identity, token balances, flows and counterparties. There is **no DeFi-position data** in any tool, so never report protocol positions.
+Multi-call playbook for a complete wallet snapshot. It reports what the tools return: identity, token balances, flows and counterparties. There is **no DeFi-position data** in any tool, so never report protocol positions. For identity alone ("who is this", "is it an exchange") use `vike-wallet-who-is`.
 
 ## Workflow (run in parallel where possible)
 
@@ -15,20 +15,20 @@ ADDR=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
 
 vike-data wallet ens     $ADDR --json &     # 1 credit
 vike-data labels         $ADDR --json &     # 1 credit
-vike-data wallet summary $ADDR --json &     # 2 credits
-vike-data wallet balances $ADDR --json &    # 3 credits (Ethereum and BSC)
-vike-data wallet counterparties $ADDR --window 30d --limit 10 --json &   # 2 credits
+vike-data wallet summary $ADDR --json &     # 2 credits - names its `chain`
+vike-data wallet balances $ADDR --json &    # 3 credits - all four chains; add --chains to narrow (faster)
 wait
+vike-data wallet counterparties $ADDR --chain <summary.chain> --window 30d --limit 10 --json   # 2 credits
 ```
 
-Then label the counterparties in one call: `vike-data wallet batch <cp1> <cp2> ... --json` (2 credits). A top counterparty that is a CEX tells you which exchange the wallet uses; an unlabelled high-volume counterparty is worth a `wallet compare` or `wallet trace`.
+Then label the counterparties with an empty `entity` in one call: `vike-data wallet batch <cp1> <cp2> ... --chain <summary.chain> --json` (2 credits). A top counterparty that is a CEX tells you which exchange the wallet uses; an unlabelled high-volume counterparty is worth a `wallet compare` or `wallet trace`.
 
 ## Report template
 
 > **`<ENS or 0x...>` — wallet snapshot**
 > - **Identity:** `<ens.eth>` · `<entity (from labels)>` · `<wallet_type>` (confidence: `<H/M/L>`). If `labels` says `found: false`, say "not in our label table".
-> - **Priced token holdings:** `$X` (floor: unpriced tokens and the native coin are excluded from the total) across `<chains_scanned>`. Top 3 by USD: `<symbol1 $X>`, ... Native balance: `<n ETH/BNB>`.
-> - **30d flow:** `+/-$Z` net (`summary["30d"].net_flow`), one chain.
+> - **Priced token holdings:** `$X` (floor: unpriced tokens are excluded; on Base and HyperEVM only mapped and priced tokens show) across `<chains_scanned>`. Top 3 by USD: `<symbol1 $X on chain>`, ... Native balance: `<n ETH/BNB/HYPE>`.
+> - **30d flow on `<chain>`:** `+/-$Z` net (`summary["30d"].net_flow`), one chain.
 > - **Activity:** `<tx_count>` transfers in 30d, `<tokens_traded>` tokens traded all-time.
 > - **Top counterparties:** `<entity or address>` · `$volume`, ...
 > - **Vibe check:** `<saver / trader / farmer / institutional / inactive / fresh>`
@@ -51,9 +51,11 @@ Then label the counterparties in one call: `vike-data wallet batch <cp1> <cp2> .
 
 ## When to use a focused skill instead
 
+- "Who is X" / "is it an exchange" → `vike-wallet-who-is`
 - "Just labels for X" → `vike-wallet-label-provenance`
 - "What does X hold" → `vike-wallet-balances`
 - "Top counterparties of X" → `vike-wallet-counterparties`
+- "X's Hyperliquid account" → `vike-hl-trader-profile`
 
 ## Pairs well with
 

package/skills/vike-wallet-summary/SKILL.md

@@ -12,19 +12,19 @@ allowed-tools: Bash(vike-data:*)
 vike-data wallet summary <address> [--json]
 ```
 
-No chain flag: one call returns every window, for one chain.
+No chain flag: one call returns every window, for one chain. To ask a given chain use the tool directly: `vike-data call wallet_summary --args '{"address":"0x...","chain":"base"}'` (`ethereum`, `bsc`, `base` or `hyperevm`).
 
 ## Output
 
-A JSON object keyed by window: `all`, `90d`, `30d`, `7d`, `24h`. Each window holds:
+A JSON object with a `chain` field and one block per window: `all`, `90d`, `30d`, `7d`, `24h`. Each window holds:
 
 `total_volume`, `total_inflow`, `total_outflow`, `net_flow` (USD), `tx_count`, `tokens_traded`, `first_seen`, `last_active`.
 
-- **One chain only.** The figures are for the chain where the wallet was most recently active, never summed across chains, and the response does not say which. For a specific chain use `wallet transactions --chain` or `wallet pnl-history --chain`.
-- **`tokens_traded`, `first_seen` and `last_active` are all-time** and repeat in every window: read them from `all` and ignore the copies. There is no per-window token count.
+- **One chain only, named in `chain`.** Without a chain the figures are for the more recently active of Ethereum and BSC, never summed; Base or HyperEVM answer only for a wallet with no priced Ethereum or BSC volume. Always say which chain the numbers are for; `wallet balances` shows which chain holds the value.
+- **`tokens_traded` is per window** (distinct tokens moved in it). **`first_seen` and `last_active` are all-time** and repeat in every window: read them from `all`.
 - A window with no activity is present and zeroed (`24h` often is), not omitted.
 - Refreshed nightly: a wallet active in the last hours may not show yet.
-- It carries no PnL, no holdings, no labels and no Hyperliquid data. For those: `wallet balances`, `labels` / `wallet batch`, and `perp top-traders`.
+- It carries no PnL, no holdings, no labels and no Hyperliquid data. For those: `wallet balances`, `labels` / `wallet batch`, and `hl wallet`.
 
 ## Reading tips
 
@@ -39,7 +39,7 @@ A JSON object keyed by window: `all`, `90d`, `30d`, `7d`, `24h`. Each window hol
 
 - Don't claim a wallet is "smart money" based on summary alone: it has no PnL. Check labels with `vike-data labels <addr>` or `vike-data wallet batch`.
 - A single big inflow can dominate `net_flow` for a window — eyeball `tx_count` to gauge whether it's one trade or many.
-- Don't describe the result as "across ETH/BSC/Base": it is one chain.
+- Don't describe the result as "across ETH/BSC/Base/HyperEVM": it is one chain.
 
 ## Pairs well with
 

package/skills/vike-wallet-trace/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vike-wallet-trace
-description: Counterparty graph traversal from a root wallet outward. At each hop, expand to the top N counterparties by USD volume; edges carry the direction of the flow. Use when the user asks "where did funds from X go" / "follow the money 3 hops out" / "trace the network around this wallet" / wallet investigation.
+description: Counterparty graph traversal from a root wallet outward. At each hop, expand to the top N counterparties by USD volume; edges carry the direction of the flow. Use when the user asks for "the counterparty graph of X" / "trace 3 hops around this wallet" / "show the network around X" / "who is connected to this wallet within N hops".
 allowed-tools: Bash(vike-data:*)
 ---
 
@@ -10,7 +10,7 @@ allowed-tools: Bash(vike-data:*)
 
 ```bash
 vike-data wallet trace <address>
-  [--chain ethereum|bsc|base]
+  [--chain ethereum|bsc|base|hyperevm]
   [--depth N]    (1-5, default 2)
   [--width N]    (1-10, default 5)
   [--window 24h|7d|30d|90d|all]
@@ -18,7 +18,7 @@ vike-data wallet trace <address>
   [--json]
 ```
 
-`--chain base` is accepted, but per-wallet transfer data is documented for Ethereum and BSC: treat an empty Base result as "not covered", not "no activity".
+Chains: `ethereum`, `bsc`, `base`, `hyperevm`; node labels come from that chain's own label table. The command expands each hop by combined volume in both directions; the tool also takes `direction` `out` (where funds went) or `in` (where they came from), reached with `vike-data call wallet_trace --args '{"address":"0x...","direction":"out","depth":2}'`.
 
 ## Output
 
@@ -87,3 +87,4 @@ Tell them to click the **Graph** tab. It renders the same trace data as a force-
 - `vike-data labels <addr>` / `vike-data wallet batch <addr...>` — identify the nodes
 - `vike-data wallet compare <addr_a> <addr_b>` — confirm relatedness once trace surfaces candidates
 - `vike-data wallet transactions <addr>` — drill into specific transfers between two nodes
+- `vike-follow-the-money` — the incident playbook (order of calls, stop rules, a live watch); `vike-wallets-related` — evidence of a shared owner

package/skills/vike-wallet-transactions/SKILL.md

@@ -10,7 +10,7 @@ allowed-tools: Bash(vike-data:*)
 
 ```bash
 vike-data wallet transactions <address>     # alias: vike-data wallet txs
-  [--chain ethereum|bsc|base]
+  [--chain ethereum|bsc|base|hyperevm]
   [--direction in|out|all]
   [--days N]   (max 365)
   [--limit N]  (max 500)
@@ -19,7 +19,7 @@ vike-data wallet transactions <address>     # alias: vike-data wallet txs
   [--json]
 ```
 
-`--chain base` is accepted, but per-wallet transfer data is documented for Ethereum and BSC: treat an empty Base result as "not covered", not "no activity".
+Chains: `ethereum`, `bsc`, `base`, `hyperevm`. The same address has a separate history per chain: pass `--chain` for each.
 
 ## Examples
 

package/skills/vike-wallet-who-is/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: vike-wallet-who-is
+description: Say who is behind one EVM address from vike's search, its label sources, ENS name, the chain it is active on, the exchanges it uses and its biggest counterparties. Tells an exchange, fund, market maker or contract from an ordinary user. Use when the user asks "who is 0x..." / "whose wallet is this" / "is this an exchange or a fund" / "which exchange does this wallet use" / "what kind of wallet is this".
+allowed-tools: Bash(vike-data:*)
+---
+
+# vike-wallet-who-is
+
+Identity playbook for ONE address: what vike already calls it, labels, ENS, the chain that matters, which exchanges and wallets it moves money with. About 12 credits. For holdings and a flow snapshot use `vike-wallet-portfolio`.
+
+## Chain
+
+```bash
+ADDR=0x28C6c06298d514Db089934071355E5743bf21d60
+vike-data search $ADDR --json                    # 1  entity, HL trader, vault, builder, Polymarket wallet: whatever vike knows it as
+vike-data labels $ADDR --json                    # 1  label sources + consensus (Ethereum label table)
+vike-data wallet ens $ADDR --json                # 1  reverse ENS; "ens" can be null
+vike-data wallet summary $ADDR --json            # 2  READ its `chain` field before anything else
+vike-data wallet exchange-usage $ADDR --chain <summary.chain> --window 365d --json        # 3  which exchanges, with USD and shares
+vike-data wallet counterparties $ADDR --chain <summary.chain> --window 90d --limit 20 --json   # 2
+vike-data wallet batch <counterparties with an empty entity> --chain <summary.chain> --json    # 2, max 100 addresses
+```
+
+Chains: `ethereum`, `bsc`, `base`, `hyperevm` on every wallet command here. The user gave a name, not an address? `vike-data search vitalik.eth` searches the address an ENS name points to.
+
+## Reading each step
+
+- **`search`**: its `wallets`, `traders`, `vaults`, `builders` and `polymarket` sections say where vike already knows the address (a labelled entity, a Hyperliquid trader, a Polymarket proxy and its owner). Empty sections are not evidence of anything.
+- **`labels`**: `found: false` = not in our label table; it is not proof the wallet is an ordinary user. Otherwise read `consensus` (`entity`, `wallet_type`, `confidence`, `risk_flag`) AND `sources[]`. When sources disagree the consensus type can be wrong: for `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045` the entity is "vitalik buterin" but `wallet_type` read `dex` because one source says "sushiswap". Report the entity the sources agree on, not the type.
+- **`summary.chain`** is the more recently active of ethereum and bsc, never a sum; base or hyperevm only for a wallet with no priced ethereum/bsc volume. If the figures look tiny, run `vike-data wallet balances $ADDR` (each holding carries its `chain`) and ask that chain directly: `vike-data call wallet_summary --args '{"address":"0x...","chain":"base"}'`.
+- **`exchange-usage`**: `exchanges[]` with `sent_usd`, `recv_usd`, `sent_share`, first and last seen; `pattern: "sweeps_to_single_cex"` means 90%+ of its outgoing USD went to one exchange: an OBSERVED pattern, not proof it is a deposit address. Figures are a lower bound (an unlabelled exchange address is invisible; labels are sparse on hyperevm). A very active wallet is refused over a long window: narrow `--window`.
+- **`counterparties`** rows already carry `entity` and `wallet_type` (empty string when unlabelled); only the empty ones need `wallet batch`, which adds `confidence`, `risk_flag` and 30-day flow from that chain's own tables.
+- **The wallet itself is `cex`**: it is the exchange's own wallet, not a person. `wallet_type: dex` on a counterparty is a router or pool: many of them = an active trader, not a relationship.
+- Optional, "who funded it": `vike-data wallet first-funder $ADDR --chain <chain>` gives the earliest inbound coin and token transfers with the senders' labels. It is not proof of the funder: contract calls and bridges are absent and history starts on a different date per chain (`coverage.history_from`).
+
+## Answer template
+
+> `<ENS or 0x...>` is `<entity>` (`<wallet_type>`, confidence `<c>`, `<n>` sources agree). Active on `<chain>`; 90d volume `$X`, last active `<date>`. Exchanges: `<entity>` `$sent` / `$received`. It mostly deals with `<top labelled counterparties>`; the largest unlabelled counterparty is `<0x...>` ($V). `<Not labelled: say so.>`
+
+## Anti-patterns
+
+- Don't name a real-world person from a label, and don't claim two wallets share an owner: that is `vike-wallets-related`, and it is evidence, not proof.
+- Don't read `summary` as the wallet's whole activity: it is one chain.
+- Don't call a wallet "clean" because `risk_flag` is empty or `found` is false.
+
+## Pairs well with
+
+- `vike-wallet-label-provenance` for the raw per-source labels, `vike-wallet-portfolio` for holdings
+- `vike-follow-the-money` to see where its money went, `vike-wallets-related` to test a link between two addresses
+- `vike-hl-trader-profile` when `search` lists it as a Hyperliquid trader, `vike-polymarket-trader` for a Polymarket wallet