Skip to content
Smart Account 策略交易
概述
通过 TEE（Trusted Execution Environment）解决方案，使用智能账户（Smart Account）实现自动化策略交易，涵盖限价单、止盈止损（TP/SL）、清仓等场景，同时支持 Solana 和 EVM 链。
一、Smart Account（SA）核心概念
1.1 SA 定义
已将账户下的多链私钥安全传送给 TEE 服务器的用户被标记为 SA 用户：
- 通过升级现有 EOA 助记词 wallet 的 account 激活
- 或创建新的 account
- 只有 SA 用户可以进行策略交易，其他用户为普通 EOA 用户
- 一旦标记为 SA，永久保持该标记（即便关闭 TEE 功能）
- SA 只能在助记词类 wallet 下使用
1.2 使用有效期
- 默认 7 天有效期（从激活/延长 SA 起算）
- 过期后 TEE 删除用户私钥，SA 被 disable
- 关闭期间：SA 订单暂停，不可触发执行，但可正常过期
- 重启后：用户可选择主动唤醒所有暂停订单，或取消所有订单
二、订单鉴权
2.1 鉴权机制
钱包鉴权接口参数：
| 方向 | 字段 |
|---|---|
| 入参 | accountId、address、chainId、teeId、command、signMsg、signature |
| 出参 | accountId、address、chainId、teeId、teeIsActive、command |
2.2 意图签名（Intent Signing）
下策略单签名示例：
Chain Index: 501
Strategy Type: Swap
Recipient: jqJw52AgRtdHNmKuxaXSg1ATtTK6JXwTxe4RAuG97jg
Created At: 2025-09-02T10:30:00+09:00
Expired At: 2025-10-24T15:30:00+09:00
From Token: 11111111111111111111111111111111
To Token: So11111111111111111111111111111111111111112
From Amount: 1000000000
Min Return Amount: 1000000000查询订单签名：
Strategy Type: ReadOrders
Created At: 2023-09-24T18:00:00+09:00
Expired At: 2025-09-24T18:30:00+09:00取消订单签名：
Strategy Type: CancelSingleOrder / CancelAllOrders
Order Id: 1234562.3 JWT 认证
通过钱包静默签名完成 JWT 生成，保护敏感数据（用户订单数据），授权一次全站通用。
三、订单存储与查询
3.1 多数据源查询
订单列表查询需融合多个数据源：
| 入口 | 说明 |
|---|---|
| PC OpenOrders | 当前活跃订单 |
| PC OrderHistory | 历史订单 |
| App Orders | order + orderHistory 按时间倒序 |
| Transactions | order + orderHistory 按时间倒序（cursor: createTime, orderId） |
3.2 多数据源分页方案
游标分页 + 内存排序：
四、订单流程
4.1 市价 Swap + TP/SL + 清仓
4.2 TEE 状态变更对订单影响
五、EVM 支持
5.1 授权流程
- 授权时机：触发消息发送后，策略交易验证是否需要授权
- 确定 from token 的策略（市价+TP/SL、限价）：下单时授权
- 不确定 from token 的策略（Copy Trade）：触发时再授权
- 授权金额：默认无限授权
5.2 Nonce 管理
EVM 链上的 nonce 管理面临两大挑战：
| 问题 | 描述 |
|---|---|
| 低 gas 卡单 | 需要获取卡单交易 nonce 进行加速 |
| Nonce 冲突 | 同一用户多策略被同一信号并发触发 |
方案对比：
| 维度 | 方案一（不管理 nonce） | 方案二（本地 nonce 管理） |
|---|---|---|
| 实现 | 每次从链上查最新 nonce，批内内存自增 | 本地派发 nonce，管理生命周期 |
| 优点 | 方案简单，支持批量广播 | 保证 nonce 连续，支持 nonce 重用和卡单解锁 |
| 缺点 | 卡单影响后续订单，并发场景成功率低 | 方案复杂 |
| 结论 | ✅ 采用 | — |
5.3 回滚处理
回滚场景分析：
| 回滚类型 | 影响 | 处理方式 |
|---|---|---|
| 失败 → 成功 | 正常创建 TP/SL | Trigger 正常处理 |
| 成功 → 失败 | 资损风险 | 回滚删除 TP/SL |
| 成功 → 成功（数量变化） | 可能资损 | 用最新状态覆盖 TP/SL |
结论：Auto Sell 场景实时处理，如果回滚到达时 TP/SL 已触发则跳过，未触发则覆盖。
六、Trigger 业务
6.1 订单状态流转
6.2 Trigger → Trade 交互
json
{
"eventType": 7,
"chain": 501,
"userWalletAddress": "XXX",
"orderInfo": {
"strategyOrderId": "123456",
"strategyMode": 3,
"fromTokenAddress": "XXX",
"fromTokenAmount": "100.0",
"toTokenAddress": "XXX",
"teeVerifyData": { }
},
"executeUntilMillis": 1750390482000
}七、Trade 交易流程
7.1 Solana 流程
主要复用 TG TEE 交易流程，改动：验证服务与签名服务合并到签名服务中，通过 SDK 接入。
7.2 EVM 交易流程
7.3 TEE 验证 & 签名 SDK
签名接口合并验证和签名：/external/api/v2/sign
新增 intent 字段：
intent.signature：用户意图签名（Base64），端上透传intent.data：签名原文（UTF-8 编码）intent.extra：附加验证数据（pool token0/token1、fee 等）
八、SA 校验流程
前端 SA 状态校验链（15+ 检查状态）：