状态：草案 v0.1 · 2026-09-28
范围：TraderX 主推 App 的社交 / 社群聊天能力（客户端 React + React Native，服务端 Rust）
所属仓库：TraderX_BackEnd（crates/social-*）

产品侧该做什么、不做什么，见《社交聊天该做什么》；本文只谈怎么实现。

不做通用 IM。这个模块只解决两件 Telegram 做不到的事：让发言者身上带着可验证的仓位和战绩，让看到信号到下单之间没有跳转。下面是开源选型、三条架构决策、crate 分层、消息管线和数据模型。

1. 背景与目标​

TraderX 的定位是基于事件和社交双驱动的 AI 交易平台，覆盖永续合约、预测市场和 Meme 币三条腿。社交机制中「发现」（看到别人买所以想买）为重，「执行」（跟单 / clan 自动跟）为辅；事件与社交的耦合中「社交信号因事件归因被打分」为重，「事件流因社交图谱排序」为辅。

社群聊天模块的目标不是再造一个通用 IM，而是做出 Telegram / Discord 天然给不了的两样东西：

1. 可信：发言者身上带着可验证的真实仓位和历史战绩。
2. 可执行：从看到信号到下单之间零跳转。

模块成败的核心指标是来自社交入口的成交占比，而不是聊天 DAU。

2. 功能优先级​

2.1 第一梯队（首发必做，构成差异化）​

2.2 第二梯队（上线后迭代）​

Clan 成交流（成员开启后成交自动推送到 clan 频道，配 clan 排行榜与 clan 自动跟）；AI 成员，定位为「事实核查员」而非「喊单员」，负责群聊摘要（「过去一小时谁有真实仓位在讨论什么」）以及贴出合约地址时的自动风险检查（貔貅盘、持币集中度、开发者钱包动向、流动性锁定）；仓位门槛群（按持币或 30 天已实现 PnL 准入）。

2.3 早期不投入​

语音房、画布、复杂话题串、表情包生态、文件分享等通用 IM 功能。付费带单群需谨慎：涉及代收费分账可能触及托管属性与投资建议合规问题，与极致非托管路线冲突。

2.4 前提条件（非功能，但必须随首发上线）​

限流与反垃圾。公开交易社群上线第一天就会遭遇机器人刷假币与钓鱼链接。

2.5 分发策略补充​

用户的社群本来就在 TG 上。可同步做一个 TG Bot 桥接：在 TG 群贴出的地址与市场由 bot 渲染成带 TraderX 一键交易链接的卡片，并显示已绑定用户的仓位徽章。App 内的事件房间与 clan 承接迁移过来的高价值用户。

3. 开源参考项目​

没有单一开源项目能同时满足 React + React Native + Rust 且贴合交易社群场景，因此按层选取参考。

3.1 Buzz 评估结论​

适合作为参考实现，不适合直接 fork 作为社群后端。

契合点：Rust/Axum + Postgres + Redis 与 TraderX 栈完全同构；crate 分层干净（buzz-core 零 I/O，子系统互不调用，由 relay 统一编排）；幂等写入对应去重键；签名事件模型天然适合喊单存证；agent 作为频道成员的模式可直接用于 AI 分析员。

不匹配点：限流仅有测试桩，未实际生效；审核只停留在 VISION 文档；推送通知未实现；移动端（Flutter）仍在开发；面向几十到几百人的团队频道，历史查询单 filter 上限 500 条，在线状态只在单节点扇出；协议要求客户端对每条消息做 Schnorr 签名，与 Privy 托管的用户主密钥冲突；Postgres FTS 使用 simple 分词，中文不可用；git 托管、语音会议、画布等模块体量大且与需求无关，fork 后维护成本高。

3.2 Stoat 要点​

后端纯 Rust，按服务拆分：delta（REST）、bonfire（WebSocket）、services/autumn（文件）、services/january（代理 / 链接预览）、daemons/pushd（推送）、daemons/crond（定时清理），core 层有 config、database、files、models、permissions、presence、result、coalesced。存储为 MongoDB + RabbitMQ，与 TraderX 的 Postgres 路线不同，数据层不照搬。

许可证注意：整体 AGPL-3.0，但个别 crate 可能自带许可证。依赖前逐个核实 Cargo.toml 的 license 字段，未确认前一律按 AGPL 处理。

3.3 XMTP（不采用为主干）​

LibXMTP 为 Rust 核心、有官方 React Native SDK、身份绑定钱包地址。但端到端加密使服务端无法做归因打分、反垃圾和持仓徽章校验，MLS 群组也不面向数千人公开房间。仅在未来做「按钱包地址私信交易员」时考虑。

4. 架构决策​

决策一：协议用「Nostr 形状」，不用「Nostr 身份」​

线协议沿用 Buzz 的帧结构与 kind 整数分发：

认证改用 TraderX session，由服务端标记发送者，不要求客户端逐条签名。「喊单可验证」由服务端哈希链存证保证。新功能 = 新 kind，老客户端不受影响。

决策二：多 crate，单进程部署​

代码按 crate 分层，编译为单一二进制部署。两人团队无法维护 Stoat 式微服务集群；待压力出现再将 social-gateway 单独拆出。

决策三：不引入额外中间件​

队列用 Redis Streams 替代 RabbitMQ，存储统一 Postgres，媒体用 S3。

5. Crate 结构​

5.1 Buzz 中值得原样保留的机制​

三级订阅索引：DashMap 按 (channel_id, kind) O(1) 查找，其次频道通配索引，最后全局订阅线性扫描；频道消息不投递给全局订阅，这是安全边界。

订阅前鉴权：REQ 先校验频道权限再注册订阅，避免非成员在注册与校验之间收到私有频道消息。

先实时后历史：客户端重建频道状态时，必须先（或重叠地）打开实时订阅，再拉历史分页，否则中间空档会静默丢消息。服务端发送终止性 CLOSED 后，客户端必须同步释放本地订阅状态。

慢客户端背压：发送使用 try_send，缓冲区连续 3 次满即断开。

ephemeral 与持久化分离：在线状态 SET EX 带 TTL（心跳间隔的 3 倍），输入中提示用 ZSET 维护 5 秒窗口，二者均不入库。

6. 消息管线（social-pipeline）​

同步段（决定是否接受）
 1. RATE LIMIT      令牌桶；新账号发地址 / 链接额外限额
 2. AUTH            session 有效，服务端确定 sender_id
 3. PERMISSION      频道权限位 + 条件门槛（持仓 / PnL）
 4. SPAM CHECK      钓鱼域名黑名单、重复内容指纹
 5. ENRICH          ① 解析 ticker / 合约地址 / Polymarket 链接 → MarketMapping → cards
                    ② 读统一账本，为涉及市场打持仓快照 position_snapshot
 6. DB INSERT       ON CONFLICT DO NOTHING
 7. REDIS PUBLISH
 8. FAN-OUT         → 返回 OK

异步段（fire-and-forget，失败不影响发送）
 9. SIGNAL EXTRACT  带方向的发言写入 raw_signals，关联 event_id   ← 归因链入口
10. AUDIT CHAIN     喊单存证（含持仓快照）
11. PUSH            提及 / 私信 / clan 警报
12. SEARCH INDEX    （第二阶段）
13. AGENT TRIGGER   （第二阶段）

持仓快照在第 5 步生成并随消息入库，第 10 步进入哈希链，保证事后不可篡改。

7. 数据模型草案​

-- 频道：clan / 事件房间 / 私信 / 普通群统一建模
CREATE TABLE channels (
  id            uuid PRIMARY KEY,
  kind          smallint NOT NULL,      -- 1 clan / 2 event_room / 3 dm / 4 group
  clan_id       uuid NULL,
  event_id      uuid NULL,
  visibility    smallint NOT NULL,
  gate_rule     jsonb NULL,             -- {"min_position_usd": ..., "min_30d_pnl": ...}
  default_perms bigint NOT NULL,
  created_at    timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE channel_members (
  channel_id  uuid NOT NULL,
  user_id     uuid NOT NULL,
  role_id     uuid NULL,
  joined_at   timestamptz NOT NULL,
  removed_at  timestamptz NULL,         -- 软删除
  muted_until timestamptz NULL,
  PRIMARY KEY (channel_id, user_id)
);

CREATE TABLE roles (                    -- 参考 Stoat
  id       uuid PRIMARY KEY,
  scope_id uuid NOT NULL,               -- clan 或频道
  name     text NOT NULL,
  perms    bigint NOT NULL,
  rank     int NOT NULL
);

CREATE TABLE channel_role_overrides (
  channel_id uuid NOT NULL,
  role_id    uuid NOT NULL,
  allow      bigint NOT NULL,
  deny       bigint NOT NULL,
  PRIMARY KEY (channel_id, role_id)
);

-- 消息：按月分区
CREATE TABLE messages (
  id                uuid NOT NULL,      -- UUIDv7
  channel_id        uuid NOT NULL,
  sender_id         uuid NOT NULL,
  kind              int  NOT NULL,
  content           text NOT NULL,
  tags              jsonb NULL,
  reply_to          uuid NULL,
  thread_root       uuid NULL,
  cards             jsonb NULL,
  position_snapshot jsonb NULL,
  content_hash      bytea NOT NULL,
  created_at        timestamptz NOT NULL,
  PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

CREATE TABLE reactions    (message_id uuid, user_id uuid, emoji text, created_at timestamptz);
CREATE TABLE mentions     (message_id uuid, user_id uuid, created_at timestamptz);  -- 索引 (user_id, created_at)
CREATE TABLE read_markers (channel_id uuid, user_id uuid, last_read_id uuid);       -- 未读数

-- 与第一阶段模型对接
CREATE TABLE raw_signals (
  id            uuid PRIMARY KEY,
  message_id    uuid NOT NULL,
  user_id       uuid NOT NULL,
  market_id     uuid NOT NULL,          -- MarketMapping
  event_id      uuid NULL,              -- Event
  direction     smallint NOT NULL,
  price_at_call numeric NOT NULL,
  created_at    timestamptz NOT NULL,
  perf_1h       numeric NULL,           -- social-cron 回填
  perf_24h      numeric NULL,
  perf_7d       numeric NULL
);

CREATE TABLE push_tokens           (user_id uuid, platform smallint, token text, updated_at timestamptz);
CREATE TABLE notification_settings (user_id uuid, scope_id uuid, level smallint);
CREATE TABLE audit_chain (
  seq        bigint NOT NULL,
  scope_id   uuid NOT NULL,
  message_id uuid NOT NULL,
  prev_hash  bytea NOT NULL,
  hash       bytea NOT NULL,
  created_at timestamptz NOT NULL,
  PRIMARY KEY (scope_id, seq)
);

事件房间无需单独建表：事件进入 active 状态时创建 kind = 2 的频道并关联 event_id。clan 频道挂在第一阶段已有的 follow + clan 关系表上。

8. 完全自研部分​

以下四块没有任何开源参考，是 TraderX 的差异化所在，也是开发精力的重点：

1. social-signal：喊单提取、信号表现追踪、归因打分与信誉分。
2. 持仓徽章服务：读取统一账本，生成快照与实时徽章。
3. 事件房间编排：订阅 Event 生命周期，自动创建、归档房间并关联市场。
4. 卡片解析中的 MarketMapping 查询与跨三条腿的一键下单链路。

9. 开发节奏（4 周）​

中文搜索建议直接采用 Tantivy + jieba 分词（纯 Rust），而非 Postgres 中文扩展。

10. 待决问题​

1. 持仓徽章默认公开粒度：仅方向，还是方向 + 规模区间？
2. 喊单识别规则：显式指令（如 /long）还是 NLP 自动识别，或两者并存？
3. 存证链作用域：全局单链还是每个 clan 一条链？
4. TG Bot 桥接是否纳入首发范围？
5. 私信是否需要端到端加密（影响反垃圾与合规审计能力）？

内部讨论稿。产品定位见《TraderX 到底在做什么》，第一阶段的落地细节见《TraderX 第一阶段如何落地》。

单纯的聊天本身对我们 TraderX 的用户几乎没有价值，有价值的是聊天里那些 Telegram 做不到的东西。

定位​

我们的目标 Web3 用户早就泡在 TG 群、Discord 和 X 上，单纯再提供一个群聊，没有理由让他们迁移。

TraderX 能提供而 TG 天然给不了的只有两样：

• 发言者身上可验证的真实仓位和战绩；
• 从看到信号到下单之间零跳转的执行。

所以值得做的功能，都应该围绕让社交信号可信和让信号可执行来设计。

即对应我们定下的发现为重、执行为辅和社交信号因事件归因被打分。

第一里程碑：必须有的差异化​

1. 发言带持仓徽章​

用户在讨论某个市场时，他的消息旁边实时显示他在这个市场的真实仓位：方向、大致规模区间、浮盈亏。

统一身份和统一账本已经在第一阶段范围内，这个功能几乎是白送的。它直接打掉加密圈最大的痛点：喊单的人嘴上看多，自己却在空，或者根本没仓位。用户可以选择隐藏具体金额，但「有没有仓位、什么方向」最好默认公开，这是整个社区的信任底座。甚至持仓才能发言。

2. 交易卡片 + 一键跟​

消息里出现的 meme 代币、Polymarket 市场、HyperLiquid 交易对，自动渲染成卡片，带实时价格和一键下单，三条腿都覆盖。

这是把「发现」转化成成交的关键漏斗，也是变现路径：跟单成交走 builder fee 这类协议原生费用，符合我们不自建扣费的原则。衡量社交模块成败的指标，应该是「来自社交入口的成交占比」，而不是聊天 DAU。

3. 事件房间​

每个事件（一次议息会议、一场选举、一个热点发币）自动生成一个房间（用户可以通过「信号流」中的「事件卡片」，直接进入房间），把相关的永续合约、预测市场和 meme 币通过 MarketMapping 聚在一起。

这是 TraderX「事件 + 社交」双驱动定位最具体的产品形态，也是三条腿融合最自然的场景：用户在同一个房间里看到有人在 Polymarket 押「降息」，同时有人在 HyperLiquid 开多 ETH。竞品大多是按单一资产组织讨论，我们按事件组织，这是结构性差异。

4. 可验证战绩与喊单打分​

每条带方向的发言都是一次有时间戳的「喊单」，系统追踪其后 1 小时、24 小时、7 天的表现，沉淀为发言者的信誉分。群内排序和推荐按信誉分而不是活跃度。这就是归因链的落地，也是长期护城河：战绩数据只能在我们的平台上积累，带不走。

评分 UI 可以晚一点上，但原始信号从第一天就要全量留存（已经在我们第一阶段清单里），否则后面没有历史可算。

第二里程碑：放大留存，上线后迭代​

5. Clan 成交流​

Clan 成员的成交（本人开启后）自动推送到 clan 频道，配上 clan 排行榜和 clan 自动跟单。

这是「执行」那条腿，适合在发现链路跑通之后再加强。

6. AI 成员，定位是「事实核查员」而非「喊单员」​

最有价值的两个用途：一是群消息摘要，比如「过去一小时在讨论什么，其中谁有真实仓位」；二是有人贴 meme 合约地址时自动做风险检查，包括貔貅盘、持币集中度、开发者钱包动向、流动性是否锁定。后者对 meme 玩家价值极高，而且能保护社区的信誉。

让 AI 直接给交易建议，合规风险和翻车风险都大，不能作为卖点。

7. 仓位门槛群​

只有持有某币，或者 30 天已实现盈亏为正的用户才能发言（群可以进，发言有门槛）。

这是用可验证数据做质量过滤的手段，大户群、高手群都能自然长出来。

非功能但很重要的事​

反垃圾和限流不是功能，而是前提。

• 只有注册账号（Apple / Google / Twitter 社媒注册）才能发言；
• 一律不允许发链接；
• 携带合约地址的消息，先验证合约安全性再放出；
• 发言必须有门槛并限流——既防垃圾信息，也防服务器被塞爆。

公开的交易社群上线第一天就会有机器人刷假币和钓鱼链接，这部分要和聊天一起上线。

妥协之计​

既然用户的社群本来就在 TG 上，与其第一阶段就强求他们搬家，不如同时做一个 TG Bot 桥接：

在 TG 群里贴出的地址和市场，由 bot 渲染成带 TraderX 一键交易链接的卡片，并显示已绑定用户的真实仓位徽章。这样就把我们 TraderX 的核心差异（可信 + 可执行）注入用户已有的社群，App 内的事件房间和 clan 则承接迁移过来的高价值用户。

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

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

社交侧的技术细节​

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

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

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

AI 侧​

注：待深度思考

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

第一阶段如何落地​

大致五层架构​

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

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

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

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

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

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

4. 统一执行层 现有的签名机 + session key 架构直接复用到三条腿。高频下单走 session key，高价值动作留给 Turnkey/Privy/AWS-KMS，这个设计对三条腿都成立。

5. 统一持仓与归因 跨三类资产的统一 PnL，按事件/叙事归因，而不是按资产归因。"你在'降息'这个叙事上总共赚了多少、通过哪种工具赚的"——这个视图目前市面上没有任何一家能做。

必须做​

1. 统一身份与账户模型，统一入金路由，统一账本展示（目的：基于信息流卡片的“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
   

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

   • 前期预先选择高质量事件

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

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

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

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

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

   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 = 用户实际的行为归因 → 敞口计算、行为卡、质量系数

   • 社交关系表

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

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

5. 在已有的永续 / 预测 / Meme 基础交易功能之上（前提是统一身份，统一账户），叠加一层“事件信号流”（目的：核心入口）。

6. 原始事件信号的全量留存 + 价格快照

   • 前期信号可以不那么及时，但必须高质量+“事件降级形态”
   • 全量事件信号，是为了后期回溯和AI学习以评估质量

7. 钱包的极致非托管

   老实说，我不信任我们自己的服务端，但也受限于TurnKey/Privy的高额费用。因此暂定优先 AWS-KMS。高价值/高风险动作调用签名，其余走session-key来快速且省成本的日常交易。

8. 最简的跨腿敞口提示（目的：表达核心且独特的跨端资产敞口风险）

   • 优先聚焦在永续上的BTC/ETH 和 预测上的BTC/ETH快速涨跌，即基于“信号卡”提示你在诸如“XXX CPI数据”事件上已经跨端投入8000U （80%的持仓）

     意义大不大，暂时不是很明确：有可能是高质量的亮点，也有可能是毫无用处的自欺欺人。

9. 关系表

   • follow + clan membership。建表极便宜，但关系是慢变量，越早积累越好。即使第一阶段前端只有一个"关注"按钮、没有 feed，表也要先建、数据先攒。

不做什么​

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

产品形态​

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

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

如何赚钱​

暂不详聊，稍后更新

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

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

可能的来源：

何为“事件”驱动？​

大白话：在每一条值得下注的事件消息，和用户能下注的地方之间，把路“铺通”，高速公路！

支点一：事件是现实世界的一等公民，市场交易只是它的表达。

“铺通”的含义是该具有时效性和状态的“事件”：

• 宏观/机构等事件，只映射那些高关联度的“永续合约加密代币/美股”（并提供“利好”/“利空”标签，提供同等历史事件所引起的时间范围和价格影响幅度）；
• 只映射高关联度的“预测市场盘口”（并提供“？”）；
• 网络热点事件（含梗/叙事）只映射高潜力&安全的meme币（含平台自发币）（并提供“？”）；
• Clan事件（下单，结算收益等），只汇流给那些位于同一Clan的成员；
• 其它“降级形态事件”

竞品都是从"资产"出发的：Hyperliquid 有合约、Polymarket 有盘口、fomo 有代币。而 TraderX 从"事件Event"出发。 用户的真实心智是"我看到一条事件消息，该消息附带了相关的合约/盘口/meme币及可参与度，可立刻一键参与"：

• 而不是"我今天要交易 BTC，然后去查找宏观新闻，机构动向，巨鲸动作，支撑阻力位，再评估看多/看空的概率和敞口"，
• 也不是“我今天要买某个盘口，然后去社媒查看资讯，赛事预告，然后挑选盘口”，
• 也不是“我今天要冲这个meme币，然后去查看该币的叙事，该币的起源，参考聪明钱入场密集程度，评估入场时机，再决定投入资金量”。

TraderX 跳出纷繁复杂的“信息获取->信号评估->趋势进度->标的选择->风险敞口”的冗长决策链路，抹平用户心智成本，以最简心流的模式促成最值得的交易。

因此：前期“高质量事件”尤为重要，真正值得下注的高质量事件，一天可能就 3-8 条，深夜和周末可能一条都没有。也就是说用户大部分时间看到的是“降级形态”。降级形态不能是"没有信号"，应该是强度更低但不断流的内容：

• 进行中的事件（未结算，赔率在动）
• 昨日结算回顾（谁看对了）
• 行为型信号（主体）
• 社区公告
• 你现有仓位关联事件的进展

这样"信号流"就永远不空，只是强度有高有低。这一点会反过来影响我们的数据模型——Event（事件） 需要有生命周期状态，而不只是"出现/消失"。

何为“社交”驱动？​

“社交”驱动，准确的说是“观点”社交驱动。即社交的对象是“观点”，而不是代币。社交的结果会正/负反馈于“可结算的观点信誉”。

fomo 已经赢下了"围绕代币的社交"。但代币涨跌不构成对错，撑不起信誉体系。我们的差别只在一个字段上：

fomo：      @某某 买入了 $AAA
TraderX：   @某某 因为「美联储加息」做空了 BTC

支点二: 社交对象是“带信誉分的观点”，不是代币。

如何体现社交：

1. 每个用户有公开身份和主页，有稳定的Handle，战绩统计口径。

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

3. 同一 Clan的用户可以看到 “社区长/公会长”的“观点卡”/“行为卡”，这些观点和行为会事后结算并统计入信誉分

   当然了，社区长/公会长，也会cc从这些卡片入口而促成的交易中获益，这是权利；表现不佳会降低信誉分，这是义务。

   基于“观点社交”的唯一前提是“观点”必须是可验证对错的。当Title不能判断真假时，基于信誉分的观点，下游结算，校准全部崩盘。

即“行为卡”混在“信号流”里，不会单独做“社交”Tab，用户不需要学新东西。

所谓“Clan（战队/公会）”：全站 feed 太吵，关注单个人又太窄。 Clan 是中间的粒度——一小群你信任的人，形成一个有归属感的小圈子。

何为“AI”交易平台？​

支点三： AI 用来保护用户，不是催促用户。

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

基于以上理论而暂定的一些零散草案​

结合“事件/社交”双驱动和“永续/预测/meme”三腿，可以将统一的“信号流”分为三种渲染卡片：

• “观点卡/行为卡”————有对错->可结算而进信誉体系（核心是永续和预测）；
• “热点卡”————无对错->只是情绪表达而不进信誉体系（核心是meme币）；
• “行为卡/社区卡”————社交驱动的主要载体。

┌────────────────────────────────────┐
│ 美联储 9 月加息至少 25bp            │
│ 9 月 18 日结算 · 来源 3 条          │
│                                    │
│ 平台观点：加息 34% / 不加息 66%     │
│ (共 128 人表态)                     │
│                                    │
│ ─── 在这里下注 ───                 │
│ 预测市场  YES 0.34 / NO 0.66  [去]  │
│ 永续      做空 BTC（弱相关） [去]   │
│                                    │
│ ⚠️ 你已有 8,000 U 押在这件事上      │
└────────────────────────────────────┘

┌──────────────────────────────────────────┐
│ 🔥 @某KOL 发推："..."                     │
│ 12 分钟前 · 2.4 万转发 · 热度↑↑           │
│ 叙事标签：XXX                             │
│                                          │
│ ─── 相关代币 ───                          │
│                                          │
│ $AAA   市值 $2.1M  4分钟前上线            │
│        🅣 TraderX 发行                    │
│        流动性 $180K · LP已锁 · 无铸造权    │
│                                    [买入] │
│                                          │
│ $BBB   市值 $890K  9分钟前上线            │
│        市场发行 · 持仓 Top10 占 62% ⚠️     │
│        流动性 $40K                        │
│                                    [买入] │
│                                          │
│ $CCC   市值 $310K  2分钟前上线            │
│        市场发行 · ⚠️ 合约保留铸造权        │
│                                    [买入] │
│                                          │
│ ─── 聪明钱 ───                            │
│ 6 个高分地址已进场，集中在 $AAA / $BBB     │
│                                          │
│ ⓘ meme 与新闻无从属关系，价格由情绪驱动    │
└──────────────────────────────────────────┘

建议的meme筛选逻辑，按优先级：

1. 安全性先做硬性过滤，不是排序因子。铸造权未放弃、LP 未锁、貔貅合约、持仓过度集中——直接不进候选，不管热度多高。宁可卡片是空的。
2. 流动性下限。深度太浅的不进，因为用户进得去出不来，那不是机会是陷阱。
3. 聪明钱信号。这是 PolyEdge 那套 wallet scoring 和 SeaShell 的 Pons 分析能直接复用的地方——高分地址进场的，权重高。
4. 叙事匹配度。AI 判断这个币的名字/图/描述和 KOL 那条推的叙事契合度，防止蹭无关热点的。
5. 最后才是热度和涨幅。

┌────────────────────────────────────┐
│ 👤 @某某 · 高分用户 · 12 分钟前     │
│                                    │
│ 因为「美联储 9 月加息」            │
│ 做空 BTC · 3x · $8,000             │
│                                    │
│ 该事件上：做空 8 人 / 做多 2 人     │
│ TA 近 30 天：14/19 应验             │
│                                    │
│           [ 关注 ] [ 我也参与 ]     │
└────────────────────────────────────┘

社区卡：社区长/项目方自助推送（对表team tag），对社区长吸引力直接（能在平台内触达自己的群）。

不做什么​

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

产品形态​

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

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

如何赚钱​

暂不详聊，稍后更新

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

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

可能的来源：