chain-insights 0.56.4 → 0.56.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "chain-insights",
-  "version": "0.56.4",
+  "version": "0.56.5",
   "description": "AML investigation CLI and MCP proxy for blockchain risk screening and Chain Insights Graph access",
   "homepage": "https://chain-insights.ai",
   "repository": {

package/skills/chain-insights-cypher/SKILL.md

@@ -181,6 +181,16 @@ MATCH (a:Address {address: "0x04911a118f11c75667e4d0dfb8e640af5a353550"})
 RETURN a.degree_in AS senders, a.degree_out AS receivers, a.tx_total_count AS tx_count, a.total_volume_usd AS volume_usd, a.first_activity_timestamp AS first_active, a.last_activity_timestamp AS last_active LIMIT 1
 ```
 
+Which exchange an address cashed out to: its receivers that carry the exchange flag, one hop. Ask this first; it answers in under a second.
+
+```cypher
+USE topology
+MATCH (a:Address {address: "0x04911a118f11c75667e4d0dfb8e640af5a353550"})-[f:FLOWS_TO]->(b:Address) WHERE NOT a:Pool AND b.is_exchange IS NOT NULL
+RETURN a.address AS from_address, b.address AS to_address, f.amount_usd_sum AS amount_usd_sum, f.tx_count AS tx_count, f.first_seen_timestamp AS first_seen_timestamp, f.last_seen_timestamp AS last_seen_timestamp, a.labels AS from_labels, b.labels AS to_labels, a.is_exchange AS from_is_exchange, b.is_exchange AS to_is_exchange ORDER BY f.last_seen_timestamp DESC ORDER BY f.amount_usd_sum DESC LIMIT 25
+```
+
+When that is empty, one two-hop walk to an exchange at most (`{0,1}` in the route shape below, with `b.is_exchange IS NOT NULL` on the end and no address literal there). It can take the whole 60 s budget and end in `query_timeout` on a busy address: after one timeout, say no exchange was found within two hops and stop. Never widen to three or four hops, and never send the walk twice.
+
 Route between two addresses, one path. Only `MATCH SHORTEST 1` and `MATCH ANY SHORTEST` are served: a count above 1 is `route_search_refused`.
 
 ```cypher
@@ -301,7 +311,7 @@ The server serves five read-only catalog calls: `CALL db.labels()`, `CALL db.rel
 
 `USE facts` looks up rows you already know. A facts read names an address pair with one day. A transaction is read on `USE chain`, not here. A pair is both addresses, from then to, each as `{address: "<address>"}`, and the day is `t.block_date = "YYYY-MM-DD"`. One address, a day alone, a window of days, a block range and a bare `LIMIT` are not enough. It serves `TRANSFER`, `SWAP`, `LIQUIDITY_ADD`, `LIQUIDITY_REMOVE` and `BRIDGE_CROSSING` rows.
 
-- A reply holds at most 200 rows, whatever the `LIMIT`.
+- A reply holds at most 200 rows, whatever the `LIMIT`. When `count()` says the day holds more, give the count and one page, and say that the rest takes one read per 200 rows (a `t.block_timestamp >=` bound after the last row of the page). Read on only when the user asks for every row, and never beyond 5 pages in one turn: a loop of 61 reads once cost a user 131 seconds for one answer.
 - A facts read has one relationship and no hop. For a walk, go to topology.
 - A facts read takes no `ORDER BY`. Rows come in the server's own order. Sort the page yourself.
 - A facts read aggregates with `count()` and `sum()` only, over the whole page: no grouping key, no `min()`, `max()` or `avg()` (`unsupported facts query shape`). Read the rows and compute the rest yourself.