@vike-io/cli 0.15.0 → 0.16.0

package/skills/vike-polymarket-market-detail/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vike-polymarket-market-detail
-description: Deep-dive on a single Polymarket market — question, outcomes, current quotes, 24h volume, smart-money flows, top wallets active in it, resolution status. Use after vike-polymarket-markets when the user asks about a specific market.
+description: Read one Polymarket market by condition_id - question, outcomes and their token ids, resolution, an hourly probability series, the top 30 holders of each side, the latest 100 trades with wallets, and trade statistics. Use after vike-polymarket-markets when the user asks about one specific market, its holders or what its token ids are.
 allowed-tools: Bash(vike-data:*)
 ---
 
@@ -9,35 +9,40 @@ allowed-tools: Bash(vike-data:*)
 ## Command
 
 ```bash
-vike-data polymarket market <condition_id> [--json]
+vike-data polymarket market <condition_id> [--json]     # 2 credits
 ```
 
-`condition_id` is a hex string (you'll have it from `vike-data polymarket markets` output).
+`condition_id` is `0x` + 64 hex digits, from `vike-data polymarket markets` (or `vike-data search <words or polymarket.com link>`). It is NOT a token id.
 
 ## Example
 
 ```bash
 vike-data polymarket markets --category Crypto --limit 5 --json
 #   → pick a condition_id from the output, then:
-vike-data polymarket market 0x1234abcd...
+vike-data polymarket market 0xbac62ac581be240787167755692fda4e07b3f42fb24f61a5d73c06731f8ed158 --json
 ```
 
 ## What it returns
 
-- Market metadata: question, slug, category, end_date, fee_rate_bps
-- Current quotes for both outcomes (Yes / No mid / bid / ask)
-- 24h volume + liquidity
-- Smart-money cohort activity on this specific market (recent net flow)
-- Top wallets (by trade count or volume) active here
-- Resolution status (resolved / open / awaiting resolution)
+- Metadata: `question`, `slug`, `category` (can be an empty string), `end_date`, `active`, `closed`, `accepting_orders`, `volume_24h`, total volume, `liquidity`.
+- `outcomes` (labels) and `clob_token_ids`, in the same order: these token ids feed `candles polymarket`, `polymarket orderbook`, `market-stats` and `tape`. Match outcomes to ids by position HERE and by label everywhere else: `polymarket markets` can list the outcomes in another order.
+- `resolution`: `null` while unresolved. Its `resolved_at` can repeat `end_date`; the on-chain time is `resolved_ts_ms` in `vike-data polymarket settlement <condition_id>`.
+- `yes_series` / `no_series`: hourly `mid` for the first and second outcome (named yes/no even on Up/Down or team markets).
+- `yes_holders` / `no_holders`: up to 30 wallets per side with `proxy_wallet`, `net_shares`, `cost_basis`, `volume_usd`, `trades`.
+- `trades`: the latest 100, WITH `proxy_wallet`, `outcome`, `side`, `size` (shares), `price` (probability), `usd`.
+- `stats`: trade and wallet counts, volume, first and last seen.
+
+There is no live quote block (take bid/ask/mid from `polymarket markets` or `polymarket orderbook`), no smart-money block (use `polymarket smart-money`) and no fee rate.
 
 ## Anti-patterns
 
-- Don't claim a market is "manipulated" from cohort flow alone. High cohort buy ≠ insider info — it might just be popular among the cohort.
-- Resolution-pending markets can show stale mids. Cross-check with `last_traded` timestamp.
+- Don't claim a market is "manipulated" or has "insiders" from holders or trades alone; they show who is on a side, not why.
+- `end_date` passed is not resolved: a market can stay `active` with `resolution: null`. Confirm with `polymarket settlement`.
+- Only the latest 100 trades are returned: for a window use `polymarket market-trades` (with wallets) or `polymarket tape` (no wallets).
 
 ## Pairs well with
 
-- `vike-polymarket-trader` — profile any interesting wallet you find in the top-wallets list
-- `vike-polymarket-smart-money` (`--mode mispricings`) — markets where cohort bought below current mid
-- `vike-candles` — probability history: the market's `clob_token_ids` are the `token_id` values
+- `vike-pm-market-diligence` — the full playbook (spread, depth, large prints, settlement, holders' records)
+- `vike-polymarket-trader` — profile any holder's `proxy_wallet`
+- `vike-polymarket-smart-money` (`--mode mispricings`) — markets where the cohort bought below the current mid
+- `vike-candles` — probability history for a token id

package/skills/vike-polymarket-markets/SKILL.md

@@ -28,7 +28,7 @@ One row per market, ranked by **24h volume only** (there is no liquidity or vola
 
 `condition_id`, `slug`, `question`, `end_date`, `ended` (true once `end_date` has passed), `volume_24h` (USD), `liquidity`, `latest_ts`, and `outcomes`: a list with one entry per outcome leg, each with `token_id`, `outcome` (Yes / No or the leg's name), `mid`, `bid`, `ask`, `snap_vol_24h`.
 
-The `token_id` of each leg is what `vike-data candles polymarket <token_id>` needs, so candles need no extra detail call.
+The `token_id` of each leg is what `vike-data candles polymarket <token_id>`, `polymarket orderbook`, `market-stats` and `tape --token-id` need, so none of them needs a detail call. Read the leg by its `outcome` label, not by position: rows have listed `No` before `Yes` and `Down` before `Up`. The `condition_id` is the other id (for `polymarket market`, `market-trades` and `settlement`); never pass it where a token id is wanted.
 
 ## Reading the data
 
@@ -45,5 +45,6 @@ The `token_id` of each leg is what `vike-data candles polymarket <token_id>` nee
 ## Pairs well with
 
 - `vike-polymarket-market-detail` — deep-dive on one market once you have its condition_id
+- `vike-pm-market-diligence` — spread, depth, large prints, holders and on-chain resolution of one market
 - `vike-polymarket-smart-money` — which markets cohort wallets are buying, and a full market overview
 - `vike-candles` — probability history for a leg's `token_id`

package/skills/vike-polymarket-smart-money/SKILL.md

@@ -80,4 +80,5 @@ Trim aggressively if the user asked a narrower question. About 5 credits for the
 
 - `vike-polymarket-markets` — the trending list without the cohort view
 - `vike-polymarket-market-detail` — drill into a flagged market
+- `vike-pm-market-diligence` — spread, depth, holders and resolution of a flagged market
 - `vike-polymarket-trader` — profile the top wallets active in flagged markets

package/skills/vike-polymarket-trader/SKILL.md

@@ -54,5 +54,6 @@ There is no `hit_rate_pct`, `volume_<window>_usd` or `trades_<window>` field.
 
 ## Pairs well with
 
-- `vike-polymarket-market-detail` — see which markets they're currently in
+- `vike-polymarket-market-detail` — see which markets they're currently in (its holder lists give the `proxy_wallet` addresses to profile here)
+- `vike-pm-market-diligence` — the market-level playbook that ends with this wallet check
 - `vike-polymarket-smart-money` — whether the profitable-wallet cohort is moving in the same markets

package/skills/vike-smart-money-discovery/SKILL.md

@@ -6,7 +6,7 @@ allowed-tools: Bash(vike-data:*)
 
 # vike-smart-money-discovery
 
-Composite playbook built on `token screener --smart-money-only`. Smart money here means the cohort behind the screener's `smart_inflow` and `--smart-money-only`, which exist for **Ethereum only** (a 400 on bsc and base).
+Composite playbook built on `token screener --smart-money-only`. Smart money here means the cohort behind the screener's `smart_inflow` and `--smart-money-only`, which exist for **Ethereum only** (a 400 on bsc, base and hyperevm).
 
 **What this can and cannot say.** It can say which tokens the cohort is flowing into and how much, and who the biggest net buyers of a token are. It cannot list which of those buyers belong to the cohort: no tool returns cohort membership. State that limit in the answer.
 
@@ -25,10 +25,10 @@ vike-data token screener --chain ethereum --window 7d --sort smart_inflow --smar
 ### B. Who is accumulating it?
 
 ```bash
-vike-data token transfers <addr> --tab bought --period 7d --json
+vike-data token transfers <addr> --tab bought --period 7d --hide-contracts --json
 ```
 
-The list is the **top 10 by volume**, not the cohort. **Rank on `net_tokens`**, not `bought`: `bought` counts every inbound transfer, flash-loan and router round trips included. Keep rows with a clearly positive `net_tokens`; drop rows where `net_tokens` is near zero.
+The list is the **top 10 net buyers by net USD**, not the cohort (a buyer's `net_usd` is negative; `net_tokens` is the net in whole tokens). `--hide-contracts` leaves out the pools and routers we know of; a row can still be an exchange or an unmarked contract.
 
 ### C. Strip the intermediaries
 
@@ -63,6 +63,7 @@ Screener (3 credits) + `token transfers` (2) + `wallet batch` (2) + up to 5 × `
 
 ## Pairs well with
 
+- `vike-token-smart-money-trend` for whether the cohort is entering, holding or exiting ONE token over 24h / 7d / 30d / 90d
 - `vike-token-screener` for the filters and the column meanings
 - `vike-token-research` for the price/flow context
 - `vike-perp-funding` if the token has a perp listing (positioning bias)

package/skills/vike-stream/SKILL.md

@@ -39,8 +39,8 @@ vike-data stream hl --channel hl.candles --filter coin=BTC,ETH --filter interval
 # Every liquidation and every fill of one wallet, on one connection
 vike-data stream hl --channel hl.liquidations hl.fills --filter wallet=0x1111111111111111111111111111111111111111
 
-# USDC transfers on base worth $1M+
-vike-data stream onchain --channel chain.transfers --filter chain=base --filter token=0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 --filter min_usd=1000000
+# USDC transfers on base of 1M USDC or more (min_amount is in tokens; min_usd would drop the unpriced events)
+vike-data stream onchain --channel chain.transfers --filter chain=base --filter token=0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 --filter min_amount=1000000
 
 # Keep only the events, with jq
 vike-data stream polymarket --channel pm.trades --filter min_usd=10000 | jq -c 'select(.type == "event") | .event'
@@ -75,7 +75,7 @@ the `hl.fills` default `min_usd` of 1000 added) or the server's error naming the
   subscribed). It does not mean nothing happened; read that window from the REST endpoints or the `hl` / `polymarket`
   commands. For what a socket missed while the channel was running, `vike-data stream events <channel> --cursor <c>`.
 - `hl.fills` without `min_usd` gets a $1,000 floor; `min_usd=0` is every fill (hundreds per second).
-  `chain.transfers` unfiltered is a firehose; `min_usd` on it drops unpriced transfers.
+  `chain.transfers` unfiltered is a firehose; transfers are priced after they are streamed, so `min_usd` on it drops almost every event: filter by `wallet`, `token` (with `min_amount`), `entity`, `wallet_type` or `contract=false`.
 
 ## One connection per key
 
@@ -96,3 +96,4 @@ Exit 1 also on `HTTP 401` / `4401` (the key) and on a refused subscription (`bad
 
 - `vike-alerts-setup`: a stored rule that notifies by webhook without a running process.
 - `vike-hl-top-traders`: pick the wallets to put in a `wallet` filter.
+- Playbooks with a live section: `vike-hl-liquidation-radar` (`hl.liq_risk`, `hl.liquidations`), `vike-follow-the-money` (`chain.transfers`), `vike-hl-cohort-positioning` (`hl.cohort_bias`, `hl.indices`), `vike-hl-trader-profile`, `vike-pm-market-diligence`.

package/skills/vike-token-holder-diligence/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: vike-token-holder-diligence
+description: Due diligence on who sits at the top of a token - the largest balances with their share of supply, how much of it is exchanges, contracts, labelled users, unlabelled or fresh wallets, which holders carry a risk flag, and whether they are selling now. Use when the user asks "is this token held by real wallets" / "are the top holders of X exchanges or contracts" / "how concentrated is X" / "holder quality of X" / "any fresh or flagged wallets among X holders".
+allowed-tools: Bash(vike-data:*)
+---
+
+# vike-token-holder-diligence
+
+Classify the top 50 wallets of one token by what they are. About 10 credits.
+
+## Chain
+
+```bash
+vike-data token search ENA --chain ethereum --limit 3 --json            # 0  take the canonical address
+# 2  top holders by on-chain BALANCE, with supply_pct (the `token holders` command ranks by net inflow only)
+vike-data call token_holders --args '{"token_address":"0x57e114b691db790c35207b2e685d4a43181e6061","chain":"ethereum","limit":50,"sort":"balance"}'
+vike-data token holders 0x57e114b691db790c35207b2e685d4a43181e6061 --chain ethereum --limit 50 --json   # 2  by net inflow: who moved the most
+vike-data wallet batch <the 50 wallets> --chain ethereum --json         # 2  one call (max 100)
+vike-data token transfers 0x57e114b691db790c35207b2e685d4a43181e6061 --tab sold --period 7d --chain ethereum --hide-contracts --json   # 2  are they selling now?
+```
+
+Chains: `ethereum`, `bsc`, `base`, `hyperevm`. `sort: "balance"` is not served on every chain (the error names it); fall back to the flow ranking and say so. Holder calls scan the whole chain for the token and can take tens of seconds on a busy one: run each once. Add `"exclude_exchanges": true` to the `call` arguments to drop exchange-labelled wallets.
+
+## Reading
+
+- **Balance ranking** adds `balance`, `value_usd`, `supply_pct`, `balance_basis`, `balance_approximate`, `candidate_coverage`. The candidates are the wallets with the largest net inflow and volume, so a holder outside both is not in the list: `candidate_coverage` is the share of total supply the candidates hold. `balance_approximate: true` = a balance could not be read or the supply is unknown. `balance_basis: "unsupported"` = that row is still ranked by flow (as for a chain's native coin).
+- **Flow ranking**: `net_flow_usd` is cumulative net inflow over recorded history, not a balance. A row with huge `volume_usd` and a small net is an intermediary.
+- Holder rows carry `entity` and `wallet_type`; `wallet batch` adds `confidence` and `risk_flag`.
+
+Group the 50 rows and sum `supply_pct` (or `net_flow_usd` on the flow list) per group:
+
+| Group | Rule | Meaning |
+|---|---|---|
+| Exchange / custody | `wallet_type = cex` | aggregates many retail holders |
+| Contract / system | `dex`, `system` or any other non-`user` type | pools, routers, vaults: not a holder opinion |
+| Labelled users | `user` with an `entity` | a named person or fund |
+| Unlabelled | empty | unknown, say so |
+| Fresh | `first_seen` within 7 days | new money; a launch-day cluster is a flag |
+| Risk-flagged | non-empty `risk_flag` | quote the flag verbatim |
+
+Also read: `tx_count` 1-2 with a large balance = an airdrop or OTC receiver that may never have sold; `last_active` months old = dormant. On the `--tab sold` list, a top holder among the net sellers is the signal; `--hide-contracts` leaves out the pools and routers we know of.
+
+## Answer template
+
+> Top 50 by balance hold `X%` of supply (candidates cover `C%`): exchanges `A%`, contracts `B%`, labelled users `D%`, unlabelled `E%`; `N` wallets first seen in the last 7 days hold `F%`; `K` wallets are risk-flagged (`<flags>`). `<M>` of them are net sellers this week. `<Balances approximate / flow ranking only on this chain: say so.>`
+
+For what one wallet holds across its tokens: `vike-data wallet balances <addr> --chains <chain>` (3 credits, cap at 5 wallets).
+
+## Anti-patterns
+
+- Don't present the top-50 sum as the token's full concentration: the list is candidates, not every holder.
+- Don't call a token a rug or safe from this alone. It is one signal.
+- Don't count the exchange group as "retail" or as one holder: it is custody for many.
+
+## Pairs well with
+
+- `vike-token-holders` (the flow list), `vike-token-transfers` (who is buying or selling now), `vike-wallet-who-is` on any single holder
+- `vike-wallets-related` when several unlabelled top holders look like one cluster

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