SIP-1: 区块交易 Block Trade

概述

区块交易 Block Trade 是一种跨链订单执行机制，连接来源链（如 BSC、Solana）与 StandX 结算引擎。订单在来源链上发布并撮合，而最终结算由 StandX 执行并权威确认——交易生命周期的每一步都公开、透明、可链上追溯。用户可以从任何支持的链上广播交易意图，通过一笔交易将链上行为与 StandX 的永续合约执行连接起来。

它提供两种撮合策略：

• 灵活模式（Flexible） — 随着对手方到来逐步撮合并结算。
• 全额撮合模式（FullMatch） — 仅当整个区块在链上完全撮合后才开始结算；否则不执行。

“Block Trade”（区块交易）之名源于 Blockchain（区块链）——建立在链上的交易——同时也呼应了传统金融中大宗协商交易的术语。一语双关，恰如其分。

动机

拥有大额订单需求的机构参与者通常寻求协商式多方交易，以减少市场冲击。现有解决方案往往在透明度和执行质量之间有所取舍。StandX 区块交易 Block Trade 通过以下方式解决这一问题：

• 透明的链上订单发现
• StandX 侧的风控验证和结算
• 中央限价订单簿上难以表达的执行方式
• Block Trade 执行完全与价格发现隔离
• Taker 最小撮合数量约束，确保区块可预期地完成

规格说明

角色

Maker（挂单方） — 发布区块交易 Block Trade 订单的一方。成功结算时收取 Maker 手续费。

Taker（吃单方） — 撮合现有区块交易 Block Trade 订单的一方（即对手方）。成功结算时收取 Taker 手续费。

订单参数

创建或参与区块交易 Block Trade 时，需指定以下参数：

成交价格

由于来源链与 StandX 执行层之间存在延迟，成交价格决定了结算价格的确定方式：

• 标记价格（Mark Price） — 结算使用 StandX 结算引擎在结算时观测到的标记价格。执行时间由引擎决定，用户无法控制。
• 限价（Limit Price） — 结算使用 Maker 指定的固定价格。该价格仍需通过风控验证（见下文”风控验证”）。

未来版本可能启用 BBO（最佳买入价 / 最佳卖出价）策略。

价格隔离

区块交易 Block Trade 的执行独立于 CLOB（中央限价订单簿）。Block Trade 价格 不会 影响：

• 标记价格（Mark Price）
• 最新成交价（Last Trade Price）
• 公开成交记录 / 最近成交（Recent Trades）
• K 线图构建
• CLOB 价格发现
• 资金费率计算
• 清算触发

此隔离机制确保 Block Trade 价格不会影响平台更广泛的定价基础设施。

撮合策略

撮合策略决定了链上撮合引擎如何处理对手方参与。撮合发生在来源链上；StandX 对已撮合的交易进行尽力结算——链上撮合成功不保证结算成功。

单笔区块交易 Block Trade 最多支持 25 个对手方。当满足以下任一条件时，Block Trade 结束：

1. 总数量 100% 被撮合。
2. 当前时间超过设定的过期时间。

撮合按先到先得原则处理。

链上撮合不可逆： 一旦撮合在来源链上记录，被撮合的数量将从区块的剩余额度中永久扣除——无论 StandX 结算结果为 Filled 还是 Failed，链上撮合均不可逆转，已消耗的额度不会返回区块。但若 Taker 在链上撮合发生之前主动关闭（Close）自己的订单（即订单仍处于 Open 状态），其预留的数量将返还至区块的可用额度中。

Taker 撮合数量验证

每笔 Taker 撮合必须满足以下条件之一，以确保后续 Taker 仍可参与区块：

1. 精确剩余： remaining_qty - match_qty = 0 — Taker 撮合了全部剩余数量。
2. 充足剩余： remaining_qty - match_qty ≥ taker_min_qty — 撮合后的剩余数量仍足够下一个 Taker 参与。

任何导致剩余数量处于 0（不含）和 taker_min_qty（不含）之间的撮合请求，将被链上撮合引擎 拒绝。

灵活模式（Flexible）

• 对 Maker： 每次 Taker 成功撮合后，StandX 立即尝试结算。若结算成功，仓位开立并为最终状态——不受剩余区块规模是否在到期前撮合完毕的影响。若结算失败，该撮合部分变为 Failed（失败）——链上已撮合的数量不会返回区块；其他部分继续独立处理。
• 对 Taker： Taker 愿意接受部分成交。如果剩余区块规模少于 Taker 请求的数量，Taker 将以剩余数量进行撮合（须满足 Taker 最小数量要求）。

全额撮合模式（FullMatch）

• 对 Maker： Taker 逐步加入直至总规模在链上完全撮合。在此之前不会发生任何结算。总规模撮合完成后，StandX 对每个参与者逐一尝试结算。若某个参与者结算失败，该参与者被标记为 Failed（失败） 并跳过，其占用的额度不会补回区块。其他参与者的结算不受影响。如果在过期时间前区块规模未 100% 撮合，则整个区块关闭。
• 对 Taker： Taker 的撮合必须全额执行。如果剩余区块规模无法满足 Taker 请求的数量，该撮合将被拒绝。

过期时间

每笔区块交易 Block Trade 都有过期时间。一旦过期，Block Trade 自动关闭，不再接受任何撮合。

执行与结算

结算语义

链上撮合事件 不 构成 StandX 执行。撮合事件（如 BSC 上的 BlockMatched）代表来源链上的一次成功撮合；StandX 随后对已撮合的交易进行尽力结算。StandX 是结算真相的权威来源。

Block Trade 使用两套状态模型：一套用于区块本身，一套用于每个参与者的订单。

区块状态（Block Status）：

订单状态（Order Status）：

仅 Filled 状态会导致仓位开立。

结算流程

当 Taker 提交交易以撮合 Maker 的 Block Trade 时，来源链以其原生格式发出撮合事件。

StandX 结算引擎监控这些事件，对每个有效撮合：

1. 验证撮合事件（链终局性、合约白名单、去重）。
2. 对 Maker 和 Taker 双方执行风控验证（见下文）。
3. 若验证通过，结算交易——原子性地开立仓位并扣除手续费。
4. 若验证失败，将该撮合标记为 Failed。其占用的额度不会补回区块。

风控验证

结算前，StandX 对 Maker 和 Taker 双方检查交易后账户健康状况。

当 Block Trade 成交价格与标记价格存在偏差时，仓位在开立时可能立即产生未实现亏损（开仓亏损）。为确保每笔仓位从开立之初即有充足的保证金支撑，StandX 要求用户的可用保证金在承担开仓亏损之后，仍须满足该仓位的初始保证金要求。

换言之，开仓亏损被视为进入交易的前置成本。若扣除开仓亏损后，剩余保证金不再满足初始保证金要求，结算将被拒绝。这一机制防止用户以不足的抵押品开仓，降低 Block Trade 执行后立即触发清算的风险。

此规则同时适用于 Maker 和 Taker。具体计算方式和参数可能根据平台风控策略进行调整。

继承的风控规则

Block Trade 必须 继承标准交易路径的所有现有风控规则，包括但不限于：

• 各档位最大杠杆
• 保证金模式约束（全仓 / 逐仓）
• 临界杠杆阈值下的仅减仓（Reduce-only）限制
• 各档位仓位规模限制

在标准 CLOB 路径上因风控规则被拒绝的交易，通过 Block Trade 也必须被拒绝。

结算失败

由于 Block Trade 涉及跨链协调，来源链撮合事件与 StandX 结算之间存在预期延迟。在此期间，用户的可用保证金可能发生变化——例如资金被分配至其他仓位。

如果任一方在结算时保证金不足或风控验证失败：

• 灵活模式： 该撮合部分变为 Failed。链上撮合不可逆转——已消耗的数量不会返回区块，且不为该笔撮合开仓。同一区块中的其他撮合不受影响。
• 全额撮合模式（FullMatch）： 结算失败的参与者被标记为 Failed 并跳过，其占用的额度不会补回区块。其他参与者的结算不受影响。

为维护平台完整性，因用户原因导致的反复结算失败可能会导致其 Block Trade 参与权限受到限制。具体执行政策可能会根据实际使用情况进行调整。

事件处理保障

鉴于跨链架构，StandX 结算引擎执行以下保障措施：

• 终局性（Finality）： 仅在来源链交易达到足够终局性后处理撮合事件。
• 去重（Deduplication）： 每个撮合事件通过唯一键（链、合约/程序地址、交易哈希、日志/指令索引）标识，仅处理一次。
• 合约白名单： 仅接受来自已验证 Block Trade 合约/程序的事件。
• 原子结算： 对每笔成交，双方的仓位开立、手续费扣除和保证金更新作为单个原子操作提交。不得出现部分写入（如一方已记账而另一方未记账）。

可扩展性

未来版本的 Block Trade 可能引入：

• 区块费用（Block Fee） — Maker 与 Taker 之间的可选费用，由一方支付给另一方，以促进更灵活的协商。
• 区块保证金（Block Margin） — 任一方额外质押的保证金，以增强结算确定性。
• BBO 策略 — 基于结算时最佳买入价 / 最佳卖出价的成交价格选项。

这些设置将根据平台条件和安全验证逐步推出。

场景示例

背景： BTC 标记价格为 100,000 USDT。

场景一：基本灵活模式撮合

Jack 希望以 98,000 USDT 的固定价格做多 20 BTC。他在 StandX 上创建了一笔 Block Trade，参数如下：

• 交易对： BTC-USD
• 规模： 20 BTC
• 方向： 做多（Long）
• 成交价格： 限价（98,000 USDT/BTC）
• 撮合策略： 灵活模式（Flexible）
• Taker 最小数量： 0.8 BTC（= max(20/25, 平台最小交易量)）
• 过期时间： 1 天

StandX 验证 Jack 的保证金是否充足，且限价通过风控验证（做多方在 98,000 vs. 标记价格 100,000 的开仓亏损为 0%，价格有利）。验证通过后，Jack 使用钱包签署交易，订单发布至来源链。

Alice 浏览 StandX Block Trade 页面，看到 Jack 的订单。她愿意在 98,000 USDT 的价格做空 BTC，决定作为对手方参与。Alice 选择撮合 8 BTC（≥ taker_min_qty 0.8 BTC；剩余 12 BTC ≥ 0.8 BTC ✓），签署交易并提交至来源链。撮合事件在链上发出。

StandX 检测到撮合事件，对双方执行风控验证（Alice 以 98,000 做空 vs. 标记价格 100,000 的开仓亏损为 2%，须在开仓亏损上限范围内），若验证通过则结算交易：

• Jack（Maker）开多 8 BTC，价格 98,000 USDT/BTC
• Alice（Taker）开空 8 BTC，价格 98,000 USDT/BTC

Bob 随后看到 Jack 的订单还有 12 BTC 未撮合。他决定撮合剩余的 12 BTC（剩余 = 0 ✓），签署并提交交易。另一个撮合事件在链上发出。StandX 结算：

• Jack（Maker）开多 12 BTC，价格 98,000 USDT/BTC
• Bob（Taker）开空 12 BTC，价格 98,000 USDT/BTC

Jack 的 20 BTC Block Trade 已 100% 撮合并结算完成。Maker 手续费从 Jack 的账户中扣除；Taker 手续费分别从 Alice 和 Bob 的账户中扣除。

场景二：Taker 最小数量约束

Jack 创建了一笔 20 BTC 的 Block Trade（灵活模式，taker_min_qty = 0.8 BTC）。

Alice 希望撮合 19.5 BTC。撮合后仅剩 0.5 BTC——但 0.5 < 0.8（taker_min_qty）且 0.5 ≠ 0。链上撮合引擎 拒绝 Alice 的撮合请求。

Alice 有两个有效选择：

1. 撮合 19.2 BTC — 剩余 0.8 BTC（= taker_min_qty ✓）。Bob 可随后撮合最后的 0.8 BTC。
2. 撮合 20 BTC — 吃下整个区块（剩余 = 0 ✓）。

场景三：多个 Taker 同时提交

Jack 创建了一笔 20 BTC 的 Block Trade（灵活模式，taker_min_qty = 0.8 BTC）。两位 Taker——Alice 和 Bob——几乎同时提交了各 11 BTC 的撮合请求。

撮合按先到先得原则处理：

1. Alice 的交易先到达，撮合 11 BTC（剩余 9 BTC ≥ 0.8 ✓）。撮合事件在链上发出。StandX 在风控验证通过后结算。
2. Bob 的交易随后到达。此时仅剩 9 BTC，因此 Bob 撮合 9 BTC（剩余 = 0 ✓）。撮合事件在链上发出。
3. 区块交易已 100% 撮合。此后的任何 Taker 提交将被拒绝。

场景四：全额撮合模式（FullMatch）— 结算失败

Jack 创建了一笔 20 BTC 的 Block Trade（FullMatch，限价 98,000）。Alice 撮合 12 BTC，Bob 撮合 8 BTC。区块已在链上完全撮合。

StandX 对每个参与者逐一尝试结算。Jack vs Alice（12 BTC）结算成功，仓位开立。Jack vs Bob（8 BTC）结算时发现 Bob 保证金不足，Bob 的撮合被标记为 Failed。Bob 占用的 8 BTC 额度不会补回区块。最终结果：Jack 与 Alice 各开立 12 BTC 仓位，Bob 未开仓。

场景五：风控验证拒绝

BTC 标记价格为 100,000。Jack 希望创建 Block Trade：以限价 110,000 做多 10 BTC，使用 20x 杠杆。

Jack 在 20x 杠杆下的初始保证金 = 名义价值的 5% = 55,000 DUSD。以 110,000 做多 vs. 标记价格 100,000，开仓亏损 = 名义价值的 10% = 110,000 DUSD。扣除开仓亏损后，Jack 的剩余可用保证金不再满足初始保证金要求。Jack 的 Block Trade 创建被风控验证 拒绝。

若要通过验证，Jack 需要降低杠杆（增加可用保证金相对于开仓亏损的比例）或将限价设置为更接近标记价格（减少开仓亏损）。

场景六：FullMatch — Taker 在完全撮合前取消订单

Jack 创建了一笔 10 BTC 的 Block Trade（FullMatch，做多）。

1. Alice 接入 4 BTC——区块剩余额度降至 6 BTC。由于区块为 FullMatch 模式，链上撮合尚未发生。Alice 的订单处于 Open 状态，仍可取消。
2. Bob 接入 2 BTC——剩余额度降至 4 BTC。Bob 的订单同样处于 Open 状态，可取消。
3. Alice 取消了她的订单。她的 4 BTC 返还至区块——剩余额度回到 8 BTC。
4. Jimmy 接入 8 BTC——区块现已完全撮合。区块状态转为 OnchainMatched。所有 Taker 订单（Bob 和 Jimmy）进入 Matching 状态，不可再取消。
5. StandX 对每个参与者进行结算。

场景七：Flexible — 立即撮合，无取消窗口

Jack 创建了一笔 10 BTC 的 Block Trade（Flexible，做多）。

1. Alice 接入 4 BTC。由于区块为 Flexible 模式，链上撮合立即发生——Alice 的订单进入 Matching 状态，无法取消。区块剩余额度为 6 BTC。
2. Bob 接入 6 BTC。链上撮合立即发生——Bob 的订单进入 Matching 状态。区块现已完全撮合。
3. StandX 按到达顺序独立结算每笔撮合。