核心用法
TradeRouter 是一套 Solana 链上交易执行基础设施，提供三类核心能力：即时兑换（Instant Swap）、钱包扫描（Portfolio Scanning）和高级订单管理（Limit/Trailing Orders）。
即时兑换流程：调用 POST /swap 构建未签名交易（base58 编码）→ 客户端本地签名 → 调用 POST /protect 提交（base64 编码），后者通过 Jito MEV 保护和质押连接通道确保交易优先上链。买卖参数严格区分：buy 用 amount（lamports），sell 用 holdings_percentage（基点，10000=100%）。
限价与追踪订单：通过 WebSocket wss://api.traderouter.ai/ws 实现，支持基于市值触发的 take-profit、stop-loss、dip-buy、breakout-entry 及追踪止损（trailing stop）。target 以下单时市值为基准（10000=100%），追踪订单的 trail 参数定义从峰值回调的触发阈值。
身份与认证：无 API 密钥，钱包公钥即身份。WebSocket 订单需 challenge-response 认证：服务器发送 nonce，客户端用 Ed25519 私钥签名后随 register 动作提交。
显著优点
- MEV 保护内建：
POST /protect集成 Jito 和质押通道，降低三明治攻击风险。 - 零 API 密钥摩擦：钱包即身份，降低集成门槛。
- 高级订单类型原生支持：市值追踪止损、限价订单等通常需链下基础设施的功能开箱即用。
- 弹性降级：
/protect503 或超时自动回退至 RPC 直连，保障可用性。 - 完备的安全护栏：参考实现内置每日亏损上限、单笔限额、代币冷却期、KILL_SWITCH 等风控机制。
潜在缺点与局限性
- WebSocket 强状态依赖：限价/追踪订单的成交通知
order_filled仅通过 WebSocket 推送，连接断开期间可能漏单，必须实现重连和重注册逻辑。 - 编码不一致风险：
/swap返回 base58，/protect要求 base64，转换步骤繁琐易出错。 - 市值数据可靠性：
filled_mcap可能为 0 或 null，需防御性处理；追踪订单依赖服务器端市值计算，存在延迟或偏差可能。 - 订单静默过期：
expiry_hours到期后服务器不主动通知，需轮询list_orders检测。 - 服务方信任假设：需硬编码服务器公钥验证
server_signature，密钥轮换机制虽文档化但仍依赖运营方透明度。
适合人群
- Solana 量化交易开发者、自动化策略工程师
- 需要 MEV 保护执行的交易 bot 运营者
- 希望实现 DCA、网格交易等高级策略的 DeFi 用户
- 具备 Ed25519 签名和 Solana 交易构造基础知识的开发者
常规风险
- 私钥管理风险：WebSocket 认证和交易签名均需本地私钥，泄露即资金损失。
- 智能合约与池子风险：底层路由通过 Raydium、Pump.fun、Orca、Meteora 等 DEX，存在合约漏洞、rug pull、流动性枯竭等链上固有风险。
- 服务器可用性与诚实性：订单执行依赖 TradeRouter 服务器持续监控市值并推送
order_filled，服务器宕机或作恶可能导致订单未执行或延迟执行。 - 滑点与价格冲击：低流动性代币需主动调高
slippage（1500-2500 bps），否则交易失败率极高。 - 网络拥堵与超时：
/protect阻塞至链上确认，高峰期 30 秒超时常见，需正确处理超时后的状态回查。