TraderX 第一阶段如何落地（内部）

2026年9月11日 · 阅读需 9 分钟

Founder

本文是内部思维草稿 / 复盘思考，只给内部人看。定位与产品理念见《TraderX 到底在做什么》，本文只谈落地。

临时注释：定位里提到的是“事件”，而非之前的“新闻”（过于狭义）

社交侧的技术细节

传播“归因链”：谁的动作 -> 被谁看到 -> 谁下了单

Attribution {
  source_user_id      # 谁的动作
  target_user_id      # 谁下的单
  trade_id
  channel             # link | in_app_click | follow_window
  weight              # 不同渠道不同权重
}

有哪些归因路径？（参考fomo）

channel	机制	可靠度
`link`	分享链接带 `?ref=user_id`	最高，归因主体
`in_app_click`	从 feed 里某人的行为卡/观点卡点入下单	高 —— 这就是"无需额外操作"的真正含义
`follow_window`	A 关注 B，B 买入后 A 在 N 分钟内买同一标的	低，噪音大，需权重折扣（前期可以不要）

AI 侧

注：待深度思考

新闻AI分析得出json结果，Meme的AI叙事识别（高潜力安全代币+自动发币），跨腿敞口提示、安全过滤、叙事归因，用户的AI Agent代理决策，突发事件的AI预置模板填充，事件的AI预筛（高置信度AI自动放行；低置信度人工放行：前期内部+后期谨慎开放；低置信度也可“只进信息流，不给下注入口”）

第一阶段如何落地

大致五层架构

统一信号层（Signal Layer）三路输入合流：新闻 API + X/Telegram 社交 + 链上聪明钱（PolyEdge 已有的 wallet scoring、SeaShell 的 Pons 聪明钱分析）。AI 归一化成 Event 对象：叙事标签、置信度、时效窗口、受影响标的。

这一层是现在最有积累但最分散的部分——PolyEdge 的 smart money scoring 和 SeaShell 的叙事分析本质是同一套东西，应该合并成一个服务。

表达路由层（Expression Router）把 Event 映射成三类可执行头寸，并列出各自的赔率 / 资金费 / 滑点 / 预期回报 / 最大亏损。让用户看到"这个事件有三种下注方式，成本分别是多少"。

这一层是整个平台不可替代性的来源。 Hyperliquid 做不了（不知道 Polymarket 的赔率），Polymarket 做不了（不碰 meme），pump.fun 更做不了。

统一资金层一个账户、一份 USD 余额，跨 Polymarket / HyperLiquid / 链上自动路由。Swap 不该是一个功能 tab，应该沉到底层做静默路由——用户永远不该知道钱在哪条链上。

无缝的第一层是"钱"，不是"UI"。这一点最容易被低估。

统一执行层现有的签名机 + session key 架构直接复用到三条腿。高频下单走 session key，高价值动作留给 Turnkey/Privy/AWS-KMS，这个设计对三条腿都成立。
统一持仓与归因跨三类资产的统一 PnL，按事件/叙事归因，而不是按资产归因。"你在'降息'这个叙事上总共赚了多少、通过哪种工具赚的"——这个视图目前市面上没有任何一家能做。

必须做

统一身份与账户模型，统一入金路由，统一账本展示（目的：基于信息流卡片的“3合1”一键直达的前提。特别强调：不会做保证金的统一），贯穿三条腿（永续/预测/meme）
- 统一账本: 展示总资产，拆分到各腿。纯读取聚合，不动资金
- 统一入金: 充一笔 USDC，自动路由到目标链和形态
- EOA（前端不展示，防止误充） + 合约钱包 (交易前可直接充值，首笔交易随交易完成部署)
  
  方案需定型，幸好工厂合约地址各链一致，这也是为何目前不做solana
- 只需充值USDC到用户的“合约钱包”，基于USDC的高频路径借助CCTP资金划拨（既快且无损耗；这是个异步任务，必须给用户明确状态），其余路径靠LI.FI（已经实现）
- 免桥，手续费代付（Paymaster，从用户的USDC支付）
  
  要求：一个 user_id 贯穿三条腿，各腿账户作为子账户。资金不用统一，身份必须统一。
```
总资产 $12,480
├ 永续（HyperLiquid）  $6,200   可用 $2,100
├ 预测（Polymarket）    $4,300   持仓 3 个市场
└ Meme（多链）          $1,980   最大持仓 $890
```

事件Event的数据结构（目的：既需满足“事件驱动”，同时是第二阶段的预留扩展位）

前期预先选择高质量事件

比如可以基于Polymarket反向生成Event -> 观点卡？

比如仓位上的事件戳，visibility字段
Event 的规范化质量

Event
    id
    canonical_key        # 去重键
    title                # 命题化、可判真假 ← 唯一不能凑合的字段
    entities[]
    status               # scheduled | active | resolved | expired
    trading_window
    resolution_time
    sources[]
    confidence           # 第一阶段先合成一个

传播归因链（目的：社交侧）

传播归因链：谁的动作 → 被谁看到 → 谁下了单

Attribution {
  source_user_id      # 谁的动作
  target_user_id      # 谁下的单
  trade_id
  channel             # link | in_app_click | follow_window
  weight              # 不同渠道不同权重
}

三条归因路径（参考了fomo）

channel	机制	可靠度
`link`	分享链接带 `?ref=user_id`	最高，归因主体
`in_app_click`	从 feed 里某人的行为卡点入下单	高 —— 这就是"无需额外操作"的真正含义
`follow_window`	A 关注 B，B 买入后 A 在 N 分钟内买同一标的	低，噪音大，需权重折扣

这条链是以后所有分成、返佣、社区长激励的计算基础。 没有它，以后想给社区长分钱会发现算不出来。它和 src_event 是同一套管道 —— 一笔交易同时记录"因为什么事件"和"因为谁"。

仓位(Position)的三字段落地并写入

仓位Position的数据结构
Position
	event_links[]        # { event_id, origin, confidence }
	visibility           # public | clan | private
	market_ref

event_links 的 origin 三档：

origin	来源	用途
`click`	从卡片点入，URL/session 带 `src_event`	敞口计算 + 行为卡 + 质量系数
`manual`	用户手动关联	同上
`inferred`	后验推断（标的在映射表内 + 时间窗内）	仅内部分析

event_links = 用户实际的行为归因 → 敞口计算、行为卡、质量系数

社交关系表

市场映射表 MarketMapping：系统认为的对应关系 -> "这件事可以在哪下注"

MarketMapping
    event_id, venue, market_ref, direction
    mapping_type         # direct | proxy | narrative
    origin               # exact | ai_inferred | user_submitted
    correlation_strength

在已有的永续 / 预测 / Meme 基础交易功能之上（前提是统一身份，统一账户），叠加一层“事件信号流”（目的：核心入口）。
原始事件信号的全量留存 + 价格快照
- 前期信号可以不那么及时，但必须高质量+“事件降级形态”
- 全量事件信号，是为了后期回溯和AI学习以评估质量
钱包的极致非托管

老实说，我不信任我们自己的服务端，但也受限于TurnKey/Privy的高额费用。因此暂定优先 AWS-KMS。高价值/高风险动作调用签名，其余走session-key来快速且省成本的日常交易。
最简的跨腿敞口提示（目的：表达核心且独特的跨端资产敞口风险）
- 优先聚焦在永续上的BTC/ETH 和预测上的BTC/ETH快速涨跌，即基于“信号卡”提示你在诸如“XXX CPI数据”事件上已经跨端投入8000U （80%的持仓）
  
  意义大不大，暂时不是很明确：有可能是高质量的亮点，也有可能是毫无用处的自欺欺人。
关系表
- follow + clan membership。建表极便宜，但关系是慢变量，越早积累越好。即使第一阶段前端只有一个"关注"按钮、没有 feed，表也要先建、数据先攒。

不做什么

不拼流动性、不拼撮合速度、不在 meme 侧和 fomo 拼社交密度、不做统一账户的极致体验（追平即可）、不给投资建议、不 pool 资金（虽然可能快速启动，且已有资源在手，但务必酌情考虑），暂时不做Solana（不是商业考虑，而是前期技术架构不能过于复杂的权衡），不卖信号排序位

产品形态

主推: App客户端
子产品: 网页永续合约/链上美股: 预测市场: Meme币:

主推产品（重新思考，有机重构），是公司统一对外的拳头应用；子产品（保持现状），是公司面向各个合作方的各种合作。

如何赚钱

暂不详聊，稍后更新

原则: 三条腿全部用协议原生的 fee 机制，不自建记账扣费

一旦开始"从用户余额里扣钱"，托管性质就更明确了。原生 fee 机制天然兼容非托管：费用在交易发生的那一刻就分走，我们从来没有持有过用户的钱。 这里肯定有人会不同意，但暂定如此。

可能的来源：

腿	机制	现状	备注
Meme swap	聚合器 fee 参数（`feeRecipient` + `feePercent`，编排进 calldata）	OKX+LI.FI 已有	OKX和LI.FI都会抽成但值得
永续	Hyperliquid builder code（下单带 builder 地址 + bps，需用户一次性授权）	FlowMax 5–8 bps	授权签名是新用户摩擦，可用智能账户batch掉
预测市场	Polymarket builder code	PolyEdge 已有	目前PolyEdge需重构
发币	SeaShell 发行费	已ok
平台币	平台币在交易的各个环节都有切入的空间，让其有价值场景	待
法币入金	利润最大，风险最高	暂不考虑

社交侧的技术细节​

AI 侧​

第一阶段如何落地​

大致五层架构​

必须做​

不做什么​

产品形态​

如何赚钱​