永续合约系统设计(一):综述
永续合约绝非简单的"现货交易+杠杆",而是一套在高波动环境下维持市场秩序的操作系统。本文深度拆解定价引擎、流动性引擎、平衡引擎和风控引擎四大核心模块,揭示不同平台在价格真相、流动性承接和风险切割上的架构差异,带你穿透交易表象,理解真正决定平台生存能力的偿付逻辑。

很多小伙伴第一次看永续合约,会天然把它理解成“现货交易 + 杠杆”。
页面上看,似乎也确实如此:K 线、盘口、下单框、仓位、保证金、盈亏、强平价。无非是多了一层杠杆和清算逻辑。
但如果你真的站到产品设计或系统架构的视角去拆它,就会发现:永续合约不是一个功能,而是一套在高波动、高杠杆、高对抗环境中维持市场秩序的操作系统。

它最核心的任务,不是撮合买卖双方成交,而是:
在价格会被操纵、流动性会枯竭、仓位会失控、用户会穿仓的前提下,依然维持系统偿付能力。
这也是为什么,不同平台虽然都叫“永续合约”,但用户感知却差异巨大:
- 有的平台价格更平滑,体验更像“银行”;
- 有的平台反应更敏感,体验更像“赌场”;
- 有的平台爆仓来得更快,但系统坏账更少;
- 有的平台对用户更友好,但极端行情下更容易被拖进系统性风险。
这些差异,表面上看像“交易所风格不同”,本质上其实是:不同平台在价格真相、流动性承接、风险切割和坏账分配上的架构取舍不同。
所以,如果你准备进入永续合约赛道,真正要建立的第一层认知不是“公式”,而是“系统观”:
永续合约不是把现货交易加上一个杠杆按钮,而是把市场价格、用户行为、对手盘流动性和平台偿付能力绑进同一个实时系统里。
一、先看蓝图,而不是先背公式:永续系统真正由哪四个引擎驱动

从系统抽象层面看,一套成熟的永续合约平台,至少由四个核心引擎构成:
- Pricing Engine(定价引擎)
- Liquidity Engine(流动性 / 撮合引擎)
- Balancing Engine(平衡引擎)
- Risk Engine(风控引擎)
这四个模块不是并列功能,而是一条完整的因果链:
价格定义真相,撮合生成事实,资金费率负责纠偏,风控负责兜底。
1)Pricing Engine:先定义“系统认为什么是真相”

永续平台不能只相信最新成交价。
原因很简单:最新成交价最容易被短时操纵,尤其在深度不足、币种波动大的场景里,一笔异常成交就足以把价格打出“针”。
所以永续系统必须先建立一套更稳健的“真相层”,通常就是:
- Index Price(指数价格)
- Mark Price(标记价格)
其中,最新成交价用于交易执行;
标记价格用于盈亏计算、风险评估和强平判定。
很多人把标记价格理解成“另一个价格”,这其实不够准确。
从系统设计视角看,标记价格不是备用方案,而是清算与风险系统的裁判价格。
一旦这个裁判价格被操纵,系统就不再是交易系统,而会变成一台可被定向引爆的爆仓机器。
更进一步,成熟平台在标记价格构造上通常不会简单依赖单一源,而会引入多源聚合、中值过滤、基差平滑,甚至像“Median-of-Three”这种多路径合成机制。它表达的是同一个设计原则:
风险判断所依赖的价格,必须比交易行为本身更稳。
2)Liquidity Engine:系统必须让价格从“理论”走向“成交”
定价定义了真相,撮合才把真相变成市场事实。
这一层包括订单簿、撮合引擎、成交回报链路、盘口深度管理。
它的作用不是简单地“让买家碰到卖家”,而是要在不同市场结构下,让用户订单以可预期的方式被承接。
因此,Liquidity Engine 不是交易系统的“中间层”,而是它的心脏。
没有流动性,价格就只是参考;
没有成交,风控也失去基础;
没有承接能力,后面的清算、减仓、保险基金都会迅速暴露问题。
3)Balancing Engine:永续之所以能“永续”,靠的是主动纠偏

传统期货有交割日,价格最终会向现货收敛。
永续合约没有到期日,所以系统必须自己发明一个机制,让它始终不脱锚。
这就是“资金费率”的根本意义。
很多人把资金费率理解为“平台多收的一笔钱”,这是非常典型的误解。
它本质上不是平台收入,而是多空之间的一种再平衡机制:
- 合约价格高于现货,多头付钱给空头;
- 合约价格低于现货,空头付钱给多头。
它的功能,是把偏离现货的价格重新拉回锚点附近。
但真正理解资金费率,不能只停留在“纠偏工具”这一层。
在正常市场里,它是平衡器;
在极端市场里,它可以迅速升级为系统压力武器。
比如,当某个新上线标的波动过大时,平台可以通过提高结算频率、缩短费率周期,把原本温和的持仓成本压缩成一套高频惩罚机制,快速迫使一侧去杠杆。这不是“运营动作”,而是系统主动调用的一种市场防御能力。
4)Risk Engine:真正决定平台能不能活下来的,不是撮合,而是风控
前三个引擎分别解决的是:
- 价格真相
- 市场成交
- 价格锚定
而 Risk Engine 负责的是整套系统最底层的问题:
当市场开始失控时,平台还能不能继续履约。
它会持续读取前三个模块的信号:
- 价格是否触发清算阈值;
- 成交后保证金是否足够;
- 资金费率和持仓结构是否正在扩大潜在坏账;
- 深度是否足以承接强平;
- 保险基金是否还能兜底。
所以风控不是“交易后补上的安全层”,而是整套永续系统的生存系统。
二、永续合约最反直觉的地方:用户看到的是交易,系统关心的是偿付能力
很多没有金融系统经验的人,理解永续合约时容易犯一个错误:
从用户页面出发理解系统。
这条路恰恰是最容易走偏的。
因为用户看到的是:下单、成交、盈亏、保证金、杠杆、强平价
但系统真正关心的是:
- 当前价格是否可信;
- 这笔成交会不会放大坏账;
- 资金费率会不会把账户推向穿仓;
- 这个仓位一旦触发清算,订单簿能不能接住;
- 如果接不住,保险基金够不够;
- 如果基金不够,系统会不会被迫进入 ADL。
这意味着,永续系统的设计顺序,和普通互联网产品几乎是反过来的。
普通互联网产品常常是:
先做交互,再补逻辑,再补风控。
而永续系统更接近:
先定义真相,再定义纠偏,再定义风控,最后才轮到体验表达。
这就是为什么,很多平台前端上的“误解感”其实并不来自页面设计差,而是来自底层口径和用户感知没有打通。
最典型的问题就是:
为什么 K 线没有碰到我的强平价,我却被清算了?
从用户视角,这像 bug;
从系统视角,这往往是最正常不过的设计结果:
- K 线展示的是 Last Price;
- 强平依赖的是 Mark Price。
换句话说,用户看到的是交易现实,系统执行的是风险现实。
如果平台不主动把这两层现实区分清楚,用户一定会觉得系统“有鬼”。
所以在永续合约产品中,真正重要的不是把更多数字摆上页面,而是把风险口径表达清楚。
三、标记价格与资金费率:一个决定系统相信什么,一个决定系统如何把偏离拉回去

如果只允许用两个概念去解释永续系统,我会选:
- 标记价格
- 资金费率
因为前者定义系统的“真相来源”,后者定义系统的“纠偏方式”。
1)标记价格:为什么它一定要比最新价更慢、更稳、更不容易被操纵
标记价格最核心的任务不是“接近最新价”,而是“接近公允价值”。
这是两个完全不同的目标。
最新价反映的是订单簿此刻最前沿的瞬时成交;
标记价格反映的是平台愿意据此触发清算与计算未实现盈亏的可信价格。
所以一个好的标记价格模型,通常会在三个方向上做取舍:
- 源的质量:采用多交易所指数,而不是单一来源;
- 算法的稳健性:做中值过滤、基差修正、EMA/TWAP 平滑;
- 操纵成本:让“推高一瞬间成交价”的收益,小于“操纵清算系统”的成本。
也正因为如此,不同平台会显现出不同“性格”:
- 偏保护型平台,阈值更稳、回归更慢、对插针更宽容;
- 偏敏感型平台,价格更贴盘口、回归更快,但也更容易让用户体感到“被针”。
这不是优劣问题,而是目标用户不同。
标记价格模型,本质上就是交易所的用户筛选器。
2)资金费率:为什么它既是价格锚,也是仓位压力装置
如果说标记价格是在回答“系统信谁”,那么资金费率是在回答“系统怎么把价格拉回去”。
永续之所以叫“永续”,不是因为它不会结束,而是因为系统一直在拿 Funding 把它往现货锚上拽。
在表层上,Funding 看起来像一个固定时点发生的费用结算;
但从系统设计看,它至少承担了三层功能:
第一层:价格锚
当永续高于现货时,多头被加成本;
当永续低于现货时,空头被加成本。
最终让价格不断向现货回归。
第二层:仓位温度计
Funding 不是单独发生的,它其实是市场情绪的浓缩表达。
一个长期正且快速抬升的 Funding,往往意味着多头拥挤、杠杆过热;
一个极端负 Funding,也意味着市场另一侧的失衡。
第三层:风险武器
在极端行情下,Funding 不只是价格锚,更是压力传导工具。
平台可以通过缩短结算周期、修改取样方式、动态调整参数,让它从“温和纠偏器”迅速变成“仓位压缩器”。
这也是为什么,真正的专业讨论里,Funding 从来不是一个单独公式,而是一个兼具价格、仓位、风险三重属性的系统变量。
四、真正硬核的部分,不是下单,而是清算链路:系统怎么在别人爆仓时不把自己也带崩

如果说价格系统定义了真相,那么清算系统定义了平台在极端情况下的生存方式。
永续合约的本质,不只是放大收益,更是要求系统在高杠杆环境下,能承受失败者留下的洞。
一条成熟的风险处理链路,通常不是“触发清算 → 市价卖出”这么简单,而是一个完整的瀑布:
- 阶梯保证金 / 杠杆上限
- 触发维持保证金阈值
- 部分强平 / 梯度减仓
- 保险基金承接
- 最后才是 ADL
1)阶梯保证金:先在入口处限制“重卡失控”
仓位越大,允许杠杆越低,维持保证金率越高。
这不是限制用户,而是在做市场冲击管理。
小仓位像跑车,出事还能刹住;
大仓位像重卡,一旦翻车,不是司机的问题,而是整个高速公路都可能被堵死。
所以阶梯保证金不是用户规则,而是系统保护流动性的第一层闸门。

2)清算引擎:目标不是“一次卖完”,而是“恢复健康”
真正成熟的清算系统,通常不会一上来就把仓位一刀切掉。
它更像 ICU,而不是刑场。
它的优先目标不是“尽快处决”,而是“把账户恢复到健康状态”。
这就是为什么很多系统采用:
- 先取消挂单;
- 再释放占用保证金;
- 再做部分减仓;
- 只有还不够,才进入全量清算。
这背后的思路非常关键:
系统不追求把人清掉,而追求把风险切掉。
3)保险基金:把“订单簿接不住”的风险转成“平台库存风险”
如果所有清算仓位都直接砸向订单簿,系统会很快进入连锁踩踏。
于是保险基金的作用就体现出来了:它不是摆设,而是用来承接订单簿接不住的风险仓位。
从系统角度,它做的是一个重要转换:
把“立即向市场抛售的冲击风险”,转成“平台自己接库存、慢慢处理的库存风险”。
4)ADL:最后的按钮,按下去就意味着系统承认自己没把风险关住

ADL 最常被误解。
很多用户会把它理解成“平台随便减盈利用户的仓”,但从系统设计角度看,它代表的是一件更严肃的事:
保险基金已经不足以吸收坏账,系统只能把损失转嫁给另一侧盈利用户。
所以 ADL 不是常规功能,而是系统失败后的最后防线。
这也是为什么它的队列算法通常会综合“利润百分比 × 有效杠杆”等维度,优先处理那些高盈利、高杠杆、最适合承担对冲损失的仓位。
如果你站在系统视角,就会明白:
- 强平不是惩罚;
- ADL 也不是任意没收收益;
- 它们都是系统在高压状态下维持偿付能力的自救动作。
五、不同平台的本质差异,不在于有没有这些模块,而在于它们把敏感度、稳定性和风险转移给了谁

真正拉开平台差距的,不是有没有 Index Price、Funding、清算、基金、ADL。
这些几乎所有平台都有。

真正的差别在于:
- 标记价格更偏保护,还是更偏敏感;
- Funding 更偏平滑,还是更偏压仓;
- 保证金模型更偏静态,还是更偏动态;
- 清算更偏市场化出清,还是更偏基金接管;
- 风险是由平台吸收,还是由 LP、社区金库或对手方共同分担。
这也是为什么不同平台会呈现出完全不同的“系统性格”:
1)有的平台更像“银行”
- 标记价格平滑
- 回归速度温和
- 流动性保护更强
- 用户体感稳定
- 适合大资金、机构、长期持仓
2)有的平台更像“赌场”
- 价格更贴盘口
- 风险触发更灵敏
- Fee、IMN、清算逻辑更动态
- 用户体感刺激
- 适合高频、投机、博弈型用户
3)CEX 与 DEX 的差异,更不是“去不去中心化”这么简单

在 CEX 体系下,保险基金通常是平台自己的黑盒缓冲层;
在 DEX 风格模型里,风险可能会更透明,但也更容易直接传导到流动性提供者、社区金库乃至整个外部流动性池。
也就是说,所谓“透明”并不必然意味着“更安全”。
它可能意味着:风险没有被平台黑盒吃掉,而是更直接地暴露给了所有参与者。
所以,真正的专业问题不是:
平台有没有 Funding、基金和 ADL?
而是:
这套系统把风险、体验和确定性,分配给了谁?
当你开始用这个问题看平台时,你已经不是在看产品功能,而是在看一套系统的政治经济结构。
最后:理解永续合约,最终不是学会交易,而是学会判断一套系统如何在失衡中维持秩序

永续合约最值得学习的,不是某个公式,而是它如何把市场里的不确定性,持续转化成系统里的确定性动作:
- 价格偏离 → 触发标记与费率纠偏
- 保证金恶化 → 触发清算
- 深度不足 → 抬高风险等级
- 基金亏损 → 提前进入更强防御模式
- OI 激增、长短仓分裂、持仓集中 → 预示系统进入危险区
所以,从架构角度看,永续平台更像一套高压实时控制系统,而不是普通交易页面。
对准备入行的人来说,真正要建立的能力,不是“我会不会算 Funding”“我会不会背强平公式”,而是更高一级的判断:
- 这套系统的真相层稳不稳?
- 它的纠偏机制是温和还是激进?
- 它的坏账处理链条完整吗?
- 它把风险最终转移给了谁?
- 它在极端行情下,是优先保用户、保流动性,还是保平台自己?
当你能开始用这些问题观察一套永续系统时,你才真正从“会交易”,进入到了“懂系统”的阶段。
如果这篇文章还没看过瘾,可以在评论区留言 「我要视频讲解」。超过6个小伙伴想要,我就把今年 2 月初的一次内部完整分享视频整理出来放上来。
另:留给爱思考的小伙伴在评论区的 4 个小问题
- 你觉得标记价格应该更偏“保护型”还是更偏“敏感型”?为什么?
- 资金费率在极端行情下,更像平衡器,还是更像压仓武器?
- 如果你来设计平台,在极端行情下会优先保住用户体验,还是优先保住系统偿付能力?
- 在 CEX 与 DEX 两种模式中,你更认同哪一种风险分配方式?为什么?
本文由 @Terry的产品笔记 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
- 目前还没评论,等你发挥!

起点课堂会员权益



