ewardGPT/kinetic-risk-ontology

# 动态风险本体（KRO） ## 核心论点（30 秒） Polymarket 使用交易者自己的钱包在 Polygon 上进行结算。结果仓位是 Conditional Token Framework 中的 ERC-1155 代币，以 USDC.e 计价，并由 UMA 的 Optimistic Oracle 解析。**持有“YES — 第三季度前发生冲突”仓位的地址，与你可以追踪稳定币流入、跨链桥活动和交易所路由的地址是同一个。** 这不是两张图表之间的时间相关性——而是基于 `address` 的主键关联。 这就是 KRO 存在的全部原因。下游的一切（本体、实体解析、动态风险评分）都是为了利用这一关联而存在的。 ## 为什么这能与 Palantir 产生映射 Palantir 的核心抽象是 **Ontology** —— 类型化的 Objects、类型化的 Links 以及作用于其上的 Actions。Gotham（政府/情报产品）旨在让分析师能够从一个对象跳转到其关联关系，从而揭示一个网络。KRO 的结构也是一样的：我们将世界建模为一个类型化的本体，而“产品”则是分析师在 市场 → 钱包 → 集群 → 实体 → 流向 → 预警 之间进行联动排查的能力。 ## 架构 ``` Sources: Polymarket Gamma / CLOB WS / Data API Polygon RPC (eth_getLogs) OFAC SDN Ingestion: async Python collectors market-collector: CLOB WS price_change events chain-collector: Polygon USDC.e / USDT Transfer logs positions-collector: Polymarket trades feed + smart-money enrichment Bus: Redpanda (Kafka API) Stream proc: kinetic-risk engine - rolling z-score on per-market probability velocity - rolling z-score on per-cluster stablecoin flow - lead-lag cross-correlation - composite score → KineticRiskAlert Storage: TimescaleDB (hypertables, continuous aggregates) Neo4j (typed ontology, pivotable in Browser) pgvector (wallet embeddings, in same PG instance) Surfaces: Grafana (live time-series) Neo4j Browser (graph pivot) psql / cypher-shell (raw access) ``` ## 仓库结构 ``` docker-compose.yml Infra: Redpanda, Timescale, Neo4j, Grafana + all services PRD.md Original product requirements document libs/kro_common/ Shared types, config, db, bus, logging services/ market-collector/ Gamma metadata + CLOB WS ticks for curated basket chain-collector/ Polygon USDC.e / USDT Transfer logs (eth_getLogs) positions-collector/ Polymarket trades feed + smart-money enrichment entity-resolution/ OFAC + Leiden clustering + label propagation kinetic-risk/ Correlation engine: z-score, lead-lag, composite ontology-loader/ PG -> Neo4j ontology (Object/Link/Action) apps/ honesty-layer/ Wash-trade suppression, smart-money recompute infra/ timescaledb/init.sql Hypertables, continuous aggregates, schema grafana/ Datasources, dashboards (KRO main) neo4j/ Cypher constraints/indexes scripts/ bootstrap.sh Bring everything up seed_demo_alert.sh Inject a synthetic KineticRiskAlert for demos push_alerts_to_neo4j.py One-shot alert loader (bypasses slow loader path) data/ curated_markets.json Selected market basket (auto-generated) ``` ## 快速开始（VPS） ``` # 1. Sync rsync -az --delete --exclude=.git --exclude='.venv' \ ~/data-pool/Resume\ Projects/Palentir/ vps:~/projects/palentir/ # 2. 启动 infra + services ssh vps 'cd ~/projects/palentir && docker compose up -d --build' # 3. （可选）生成一个 demo alert，使 alert feed 不为空 ./scripts/seed_demo_alert.sh # 4. 打开 surfaces # Grafana: http://:3300/d/kro-main # Neo4j: http://:7474 # psql: docker exec -it palentir-timescaledb psql -U postgres -d kro ``` ## 核心指标（已运营化、站得住脚） | 指标 | 我们的报告内容 | |---|---| | **吞吐量** | 摄取了 15,000+ 个标准化事件（价格跳动 / 交易成交 / 解码的 Transfer）—— 在 Grafana 中展示实时*细分*。 | | **延迟** | *市场* 热路径上的 p99 tick-to-queryable 限制在 < 200 毫秒以内。链上路径受限于出块时间（约 2 秒），并且被*刻意排除*在该预算之外。 | | **实体解析** | 在保留的标注数据集上的成对 F1 分数；方法论是基于共同活动的贪婪 Jaccard 算法，结合 OFAC SDN + Leiden 整合。诚实的简短总结是：*“94% 的 F1 分数，而不是准确率——对于不平衡的成对问题，准确率毫无意义。”* | ## Cypher 中的本体（分析师的联动排查） 核心论点在这里体现：一个单一的市场、在上面进行交易的钱包、这些钱包发送的交易，以及它们解析到的集群（实体分组）和实体（现实世界的参与者）。 ``` MATCH (w:Wallet)-[:PLACED]->(t:Trade)-[:ON_MARKET]->(m:Market {curated: true}) OPTIONAL MATCH (w)-[:SENT]->(tx:Transaction) OPTIONAL MATCH (w)-[:MEMBER_OF]->(c:Cluster) OPTIONAL MATCH (w)-[:RESOLVES_TO]->(e:Entity) RETURN m.question AS market, w.address AS wallet, count(DISTINCT t) AS trades, count(DISTINCT tx) AS txs, c.cluster_id AS cluster, e.entity_id AS entity, e.risk_level AS risk ORDER BY txs DESC LIMIT 10; ``` ``` MATCH (a:KineticRiskAlert {state: 'open'})-[:FIRES_ON]->(m:Market), (a)-[:IMPLICATES]->(c:Cluster) RETURN a.composite_score, a.time, m.question, c.cluster_id, c.size ORDER BY a.composite_score DESC LIMIT 10; ``` 请参阅 [docs/CYPPER_QUERIES.md](docs/CYPPER_QUERIES.md) 获取 8 个可直接运行的查询。 ## 诚实的局限性 * **无 Polymarket 身份验证。** 需要 EIP-712 / HMAC 签名的 Data API 端点（按账户划分的单钱包成交记录、完整订单簿）是不可调用的。我们改用公开的 `trades` 数据流，这对于 钱包↔市场 的关联已经足够，但并未覆盖所有成交记录。 * **无 Kalshi。** Kalshi 需要 RSA-PSS 身份验证；我们没有密钥。PRD 将 Kalshi 列为跨场所的确认源——我们为此发布了一个存根，并且在其接入时，超前滞后检查（lead-lag check）保持相同的结构。 * **OFAC + 共同活动是一个薄弱的标签集。** 真正的成对 F1 测量需要一个人工标注的黄金数据集，其规模要大于公开的 OFAC + 共同活动所能提供的。我们诚实地报告了在自动构建的黄金数据集上的 F1 分数——面试中的任何人都可以对这种方法论提出质疑。 * **具备隐私意识的参与者会在设计上破坏聚类。** 混币器、新钱包的良好卫生习惯以及意图感知的中继器，其构建目的就是为了击败这种共同活动分析。我们将刻意的不可链接性本身视为一个微弱的信号；我们*不*声称完整性。 * **Polygon 出块时间的不对称性。** 链上热路径无法匹配市场数据 < 200 毫秒的预算——它受限于出块时间（约 2 秒）。相关性窗口的大小设计就是为了吸收这一差异。主动指出这一区别表明你了解区块链；假装不然是一个瞬间的危险信号。 ## 谈论它（面试脚本） ### 30秒推介 ### 2分钟推介 ### 可能的深入探讨问题（及诚实的回答） * **“这难道不是虚假的相关性吗？”** -> 钱包级别的关联（PRD 的第 0 部分）。我不是在对两个时间序列进行相关性分析；同一个地址位于两侧。而且我以流动性为门槛，用智能资金的 PnL 进行加权，并要求具备超前滞后（lead-lag）结构，而非巧合。 * **“94% 是怎么测量出来的？”** -> 在保留的标注黄金数据集上的成对 F1 分数，而不是准确率——对于不平衡的成对问题，准确率毫无意义。标签来自 OFAC SDN + 共同活动集群。 * **“你是如何达到 200 毫秒的？”** -> *市场* 热路径上的 p99 tick-to-queryable；这是该预算分配。链上路径受限于约 2 秒的出块时间，因此它被刻意*排除*在该数字之外，而相关性窗口吸收了这种不对称性。 * **“什么会破坏你的实体解析？”** -> 隐私工具——如混币器、新钱包的良好卫生习惯——其构建目的就是为了破坏聚类，因此对于复杂的参与者，召回率会下降。我将这种不可链接性本身视为一个微弱的信号。 * **“为什么选 Redpanda 而不是 Kafka？为什么选 Bytewax 而不是 Flink？”** -> 在这种规模下，运维负担是不合理的；两者都为我提供了正确的语义（Kafka API、流式窗口）而无需付出运维成本，而且如果规模有需求，我能够清晰地表述出其升级路径。

标签：区块链分析, 威胁情报, 开发者工具, 流处理, 请求拦截, 逆向工具, 金融风控, 预测市场