API 参考¶

Unify 的接口不是一个 REST 端点清单，而是两条独立的通道： 同步控制面**和**异步热路径。 分开设计的理由很直白——账户查询可以等几十毫秒，订单和成交不行。

接口分层¶

控制面用 RPC 是因为它是请求-响应语义，你要一个确定的答案。 热路径用事件流是因为行情和成交是推送，不是问答—— 把它们塞进 REST 轮询里，你会同时得到延迟和速率限制两种惩罚。

认证模型¶

Unify 不做「API Key + Secret」那套。 认证基于双密钥模型：

• Master Key：链上身份锚点，keccak256(CAIP-10) 得到 bytes32 account_hash。只有入金、出金、授权/撤销 Agent 三件事
• Agent Key / Shadow Session Key：Ed25519 会话密钥，签所有下单与撤单请求。没有托管权限，有 valid_until 有效期和 nonce 防重放

注册与撤销是链上合约调用（registerAgent / revokeAgent）， 日常下单签名是链下 Ed25519——不消耗 gas。 这个划分决定了你什么时候要等区块确认，什么时候不用。

请求语义¶

策略约束随请求生效¶

语义守卫在签名之前评估约束，约束写在授权阶段：

{
  "operation": "unify.perps.orderExecute",
  "constraints": {
    "allowedSymbols": ["BTC-USDC-PERP", "ETH-USDC-PERP"],
    "maxLeverage": 10,
    "maxOrderNotionalAtomic": "5000000000",
    "allowedSubaccounts": [0]
  }
}

超过 maxLeverage 或不在 allowedSymbols 里的意图拿不到签名。 这不是服务端的礼貌拒绝，是本地根本不签—— 意味着越权请求连网络都不会出。

环境隔离¶

主网与测试网用**环境域签名字符串**严格隔离。 同一份意图在两个环境得到不同的签名域， 所以测试网签名无法在主网重放，反之亦然。

官方接口文档¶

具体的端点路径、请求字段与 SDK 以 Unify 官方文档为准—— 接口在稳定但尚未冻结，写死在书里只会过期。 本页讲的是**分层与认证模型**，这部分不会随端点改名而失效。

• Unify 概览 — 架构分层与职责边界
• 协议与合约 — Agent Registry、PolicyV2、结算
• 快速开始 — 四步走通第一笔交易