SIP-2: 持仓收益 Position Yield
| 字段 | 值 |
|---|---|
| SIP | 2 |
| 标题 | 持仓收益 Position Yield |
| 状态 | Draft |
| 作者 | StandX Team |
概述
本提案引入 Position Yield(持仓收益),一种面向 StandX 永续合约持仓者的手续费分配机制。
SIP-2 将协议手续费收入中可配置的一部分,按照协议规则分配给持续持仓的用户。这一机制将手续费的参与方式从单次交易事件拓展到基于持仓时间的持续参与,同时不改变现有的撮合、资金费率、保证金和清算逻辑。
SIP-2 适用于 StandX 上所有符合条件的永续合约仓位,不论其开仓方式,只要满足统一的资格、记账和风控要求即可。
本提案建立了以下框架:
- 定义仓位何时有资格参与手续费分配
- 通过协议周期性观测来衡量持仓价值随时间的变化
- 计算时间加权持仓价值,用于奖励分配
- 通过全局奖池分配奖励,部分交易对可设立独立奖池
- 通过明确的协议规则约束不合规行为
动机
StandX 目前通过已有的执行架构支持永续合约交易。
随着协议的发展,一个自然的问题是:协议是否也应该认可持续持仓的价值,而不仅仅将手续费参与限定在交易执行的那一刻。
当前系统中,激励主要与离散的交易行为挂钩——比如下单、成交等事件驱动的操作。本提案提出了一个不同的参与维度:符合条件的持仓。
其背后的逻辑是结构性的。
未平仓量不仅是交易活动的副产品,也是协议市场状态的一部分。持仓的久期、分布和构成,会影响协议活动在时间上的延续方式、执行机制与持仓行为的交互方式,以及手续费在系统内的流转。
SIP-2 提出了一套框架,让符合条件的仓位可以参与协议手续费分配,并受到明确的规则、参数化配置和风控约束。
具体来说,它在以下方面拓展了协议:
- 将持仓时长引入为可衡量、可奖励的协议变量
- 将手续费参与与持续持仓挂钩,而不仅仅与开仓行为相关
- 建立一套跨所有开仓方式的统一框架
- 在不修改撮合和清算核心语义的前提下,扩展协议支持的行为集合
因此,SIP-2 的目的不是重新定义交易本身,而是在现有体系之上引入一个围绕时间维度持仓参与的协议层。
本提案旨在以如下方式将这一层形式化:
- 透明
- 可参数化配置
- 与现有永续合约基础设施兼容
- 受明确的协议和风控约束
SIP-2 应被理解为 StandX 永续合约系统的市场结构扩展,增加了一种将持仓量、时间和手续费分配关联起来的新机制。
规格说明
角色
持仓者(Position Holder) 在 StandX 上拥有一个或多个符合条件的永续合约仓位的账户。
协议(Protocol) 负责计算资格、维护记账状态、执行协议规则和结算 Position Yield 的 StandX 系统。
费用池管理器(Fee Pool Manager) 决定手续费收入中多少比例进入 Position Yield 的协议功能、国库策略或治理配置。
适用范围
Position Yield 仅适用于 StandX 永续合约系统中记录的仓位。
符合条件的仓位可以来自任何支持的开仓方式,包括但不限于:
- 标准订单簿撮合
- 市价单
- 限价单
- 区块交易(Block Trade)结算
- 其他协议批准的执行路径
SIP-2 关注的是最终形成的持仓,而非开仓方式本身。
以下不构成 SIP-2 下的合格仓位,除非后续提案另行批准:
- 闲置钱包余额
- 现货余额
- 金库存款
- 未撮合订单
- 待结算状态
- 协议外仓位
定义
分配周期(Distribution Epoch)
Position Yield 计算和结算所依据的固定记账区间。
在每个分配周期内,协议按照预定义的间隔对所有持仓进行周期性观测。每次观测记录每个合格仓位当时的标记价格持仓价值。一个周期内的全部观测结果汇总后,用于计算时间加权持仓价值——它反映的不仅是仓位是否存在,更是仓位在整个周期内的持续程度。
周期长度、观测方式和结算节奏均可通过治理配置调整。
奖励资产(Reward Asset)
Position Yield 分发所使用的资产,可以是:
- DUSD
- 其他指定的协议资产
- 如协议记账支持,也可为多种资产
奖励资产可配置。
持仓收益池(Position Yield Pool)
每个分配周期,协议计算一个 Position Yield Pool——该周期内可分配给合格持仓者的总奖励。
奖池来源于协议的交易手续费净利润:
Position Yield Pool = 配置比例 × 交易手续费净利润
其中:
配置比例为协议定义的参数,决定净利润中多大份额分配给 Position Yield交易手续费净利润为该周期内交易手续费收入扣除协议成本、排除项和调整后的净值
手续费收入基础包括:
- 永续合约交易手续费(Maker 和 Taker)
- 订单簿执行费
- 区块交易(Block Trade)执行费(SIP-1)
- 其他明确批准的永续合约费用类别
以下项目不计入手续费收入基础:
- 清算罚金
- 保险基金注入
- 坏账回收
- 国库转账
- 外部补贴分发
- 一次性管理调整
这一区分确保 Position Yield 来源于常规的、持续性的交易活动,而非非交易性资金流动或一次性事件。
奖池结构
协议默认运行一个全局奖池(Global Pool),在所有支持的市场间共享。此外,协议可以为特定交易对设立独立奖池(Market-Specific Pool)。
- 全局奖池: 从所有参与市场的交易手续费净利润汇总计算。所有市场的合格仓位共同竞争该奖池的分配。
- 独立奖池: 针对指定交易对,从该市场的手续费净利润中独立计算。该市场的合格仓位同时从全局奖池和独立奖池获得分配。
独立奖池是可选的、叠加的——它补充全局奖池,而非取代它。协议可根据治理决策随时增减独立奖池。
资格条件
仓位必须满足所有相关条件才有资格参与 Position Yield。
1. 有效持仓记录
仓位必须在 StandX 永续合约系统中成功开仓并记录。
资格从仓位进入协议认可的有效持仓状态后才开始。
2. 最短持仓要求
仓位必须持续持有至少 Min Hold Time 后才能参与 Position Yield 记账。
该参数可配置。
满足最短持仓要求本身不保证获得整个周期的完整收益;仓位还必须在该周期的观测和记账规则下持续保持合格状态。
3. 风控有效状态
仓位仅在对应账户处于协议有效状态时累积收益。
以下情况下仓位可能被排除在收益累积之外:
- 账户健康度低于设定阈值
- 账户进入清算流程
- 仓位受到协议施加的限制
- 协议将仓位状态标记为不合格
4. 支持的市场
只有明确启用 SIP-2 的市场才有资格。
协议可以将 SIP-2 应用于:
- 所有支持的市场
- 部分市场
- 具有差异化参数的市场
5. 可奖励杠杆约束
为防止通过极高杠杆以极少保证金撬动大量名义价值来套取奖励,协议可定义 Max Rewardable Leverage(最大可奖励杠杆)。
执行方式可以是:
- 硬性排除阈值
- 超过阈值后的折扣
- 分层可奖励模型
具体执行方式可配置。
奖励累积
原则
SIP-2 旨在按照时间合格、风控有效、可奖励的持仓敞口来分配手续费参与。
它不打算奖励:
- 未撮合的交易意图
- 短暂的名义价值飙升
- 纯粹形式上的开仓而无持久持仓
- 不满足协议资格条件的仓位状态
奖励分数(Reward Score)
协议为每个合格仓位计算一个 Reward Score,反映该仓位在分配周期内对协议未平仓量的时间加权贡献。
Reward Score = 时间加权持仓价值 × 市场权重 × 方向权重 × 调整因子
时间加权持仓价值
奖励分配的核心指标。在每个周期内的每次观测中,协议记录每个合格仓位的标记价格持仓价值(仓位数量 × 当前标记价格)。周期结束时,协议计算:
时间加权持仓价值 = 周期内所有观测值的平均值
其中:
- 仅包含仓位满足最短持仓要求之后的观测
- 仓位不合格时(如账户正在清算、仓位已关闭)的观测贡献为零
- 每次观测时持仓价值上限为
min(标记价格名义价值, 账户上限, 市场上限)
使用标记价格名义价值而非开仓价格名义价值,使奖励记账反映当前持仓敞口而非历史成交条件。
时间加权平均天然奖励在整个周期内持续维持的仓位,而仅存在于部分周期的仓位会获得相应减少的分数。这种平均方式本身就抑制了在周期边界附近短暂冲高持仓的行为。
市场权重(Market Weight)
协议可以为不同市场分配不同的权重,用于:
- 标准化各市场的处理方式
- 强调特定市场
- 降低对容易被操纵的市场的敞口
方向权重(Side Weight)
协议可以按市场为多头和空头仓位分配不同的权重。
这可用于治理认为方向差异化权重有助于改善市场结构或奖池平衡的场景。
调整因子(Adjustment Factors)
当仓位行为不符合协议规定的资格条件时,协议可以削减或排除其 Reward Score,包括但不限于:
- 在周期边界附近的短时间循环操作
- 不合格的风控状态
- 协议定义的异常参与模式
- 其他与 SIP-2 设计意图不一致的行为
分配
每个分配周期结束时,按比例分配奖励:
用户奖励 = Position Yield Pool × (用户总 Reward Score / 全体 Reward Score)
其中:
用户总 Reward Score为用户在该周期内所有合格仓位的 Reward Score 之和全体 Reward Score为该周期内所有用户所有合格仓位的 Reward Score 总和
全局奖池分配
所有合格仓位根据各自的 Reward Score 占比,从全局奖池中获得分配。
独立奖池分配
对于设有独立奖池的交易对,该市场的合格仓位还可从独立奖池中获得额外分配。公式相同,但范围限定于该市场内的仓位:
市场奖励 = 独立奖池 × (用户在该市场的 Reward Score / 该市场全体 Reward Score)
在设有独立奖池的市场中持仓的用户,同时从全局奖池和独立奖池获得奖励。
开仓路径中立性
SIP-2 在奖励资格方面不区分仓位的开仓方式。
只要仓位合法开仓、被协议记录、且持续满足 SIP-2 规则,就适用同一套奖励框架。
具体来说:
- 通过订单簿开仓的仓位与任何其他方式享有相同资格
- 通过区块交易(Block Trade)结算开仓的仓位与任何其他方式享有相同资格
- 执行方式本身不会增加或减少 Position Yield 资格
奖励记账基于最终形成的持仓及其随时间变化的合格特征,而非仓位的创建方式。
资格审核与风控
SIP-2 创建了新的手续费参与面,协议可能需要在标准撮合和清算逻辑之外实施额外的控制措施。
这些控制应主要关注仓位是否满足协议定义的资格条件,而非对用户或执行路径做不必要的区分。
1. 最短持仓与冷却规则
协议可强制执行:
- 最短持仓要求
- 新增名义价值的冷却期
- 大幅加仓后的延迟累积
这能减少短期循环操作和周期末的名义价值注入。
2. 奖励上限
协议可对以下内容设置上限:
- 每账户可奖励名义价值
- 每市场可奖励名义价值
- 每周期 Reward Score
- 每账户奖励发放额
3. 仓位状态审核
当仓位进入与 SIP-2 参与不一致的状态时,协议可削减或排除其收益累积,包括:
- 保证金不健康状态
- 清算相关状态
- 受限仓位状态
- 其他协议定义的不合格状态
4. 自动化与自由裁量执行
当发现记账异常、规则违规或异常参与模式时,协议可延迟、调整、作废或追回奖励。
持续或严重的违规可能导致:
- 被排除出 SIP-2
- 临时暂停奖励
- 根据平台政策进行更广泛的账户限制
结算
每个分配周期结束后,计算完成的奖励将结算给合格用户。
结算频率
默认结算频率为每日。协议可按交易对配置不同的结算频率——例如,某些交易对可能根据市场特性和治理决策采用更长或更短的结算周期。
结算方式
协议支持以下结算方式:
自动到账 — 周期结算后,奖励自动计入用户交易账户余额,无需用户操作。
可领取余额 — 奖励累积至可领取余额,用户需主动发起领取操作将奖励转入交易账户。
具体结算方式将在上线前确定。两种方式在架构上均已支持,上线后也可通过治理进行调整。
协议还可设定:
- 最低奖励阈值
- 相对于周期结束的结算延迟
- 领取窗口(若采用可领取方式)
以上参数均可配置。
治理与参数
以下参数可配置,可由治理或授权的协议配置进行调整:
- Position Yield 费率比例
- 奖励资产
- 分配周期长度
- 观测方式
- 最短持仓要求
- 支持的市场
- 市场权重
- 方向权重
- 最大可奖励杠杆
- 账户或市场级别上限
- 独立奖池的指定与参数
- 冷却规则
- 资格阈值
- 结算方式(自动到账或可领取)
- 最低奖励阈值
除非另有说明,参数更新应前瞻性生效,不追溯修改已结算的周期。
设计依据
SIP-2 为 StandX 永续合约系统引入了新的记账与分配层。
其目的是让持仓时长和有效未平仓量与手续费参与产生关联,同时保持与现有执行逻辑的兼容性,并保留协议对资格审核和风控的控制权。
本提案不根据执行路径区分奖励资格,而是定义了一套框架:任何符合协议约束条件的永续合约仓位都可获得奖励。
SIP-2 应被理解为 StandX 永续合约系统的持仓层扩展,将手续费参与与持续的合格未平仓量挂钩。
向后兼容性
SIP-2 不改变:
- 撮合语义
- 订单优先级
- 资金费率机制
- 保证金记账
- 清算语义
- 行情数据行为
它在现有仓位状态之上引入了一个额外的奖励记账层。
不参与 SIP-2 的协议、账户和仓位继续正常运作,不受影响。
安全考量
SIP-2 在奖励记账、周期结算、资格逻辑和参数治理方面引入了额外复杂性。主要风险包括短周期循环操作套取奖励、在周期边界附近注入仓位规模、奖励集中在少数账户,以及复杂资格状态引发的记账争议。为防范超短期套利,仓位必须至少经历一个完整的资金费率结算周期才有资格累积 Position Yield——在单个资金费率区间内开仓又平仓的仓位不纳入奖励记账。任何生产上线都应从保守的参数开始,配合清晰的可观测性,并保留暂停、折扣或修改奖励逻辑的能力,以应对异常模式。
未来扩展
后续提案可能扩展 SIP-2 以支持:
- 基于持仓时长的忠诚度乘数
- 市场专属子计划
- 手续费贡献者加权
- 动态多空平衡
- 可选的归属制奖励处理
- 与后续 SIP 的深度组合
这些扩展应在 SIP-2 基础框架经过生产环境验证、相关行为模式被充分理解之后再引入。