随着 DeFi 市场逐渐从简单资产兑换扩展到高频交易与专业衍生品领域,链上撮合系统的重要性也不断提高。Phoenix 的链上撮合流程不仅影响订单执行效率,也直接关系到市场流动性、风险控制与交易成本。
在 Solana 高频交易生态快速发展的背景下,Phoenix 所代表的链上订单簿模式正重新成为市场关注重点。
Phoenix 采用中央限价订单簿(Central Limit Order Book,CLOB)模式完成交易撮合。用户提交的买单与卖单会进入链上订单簿,并根据价格与时间优先原则进行匹配。
与 AMM 模型不同,Phoenix 不依赖流动性池自动定价,而是通过真实挂单形成市场价格。这意味着市场价格来自买卖双方的供需关系,而不是算法公式。
在 Phoenix 中,订单簿数据、订单状态与成交记录都保存在链上。用户能够公开查看市场深度、挂单价格与成交历史,这种设计提高了市场透明度与可验证性。
由于订单簿交易需要更高频率的数据更新与状态同步,因此 Phoenix 对底层网络性能要求较高。Solana 的高吞吐与低延迟能力,使其能够支持链上实时撮合系统运行。
当用户在 Phoenix 提交订单时,系统会经历多个步骤。
首先,用户需要通过钱包签署交易请求。订单信息会包含交易方向、价格、数量、杠杆比例以及订单类型等内容。
随后,Phoenix 的风险引擎会检查账户状态,包括:
当前保证金余额
持仓风险水平
杠杆限制
可用保证金比例
只有当账户满足风险要求时,订单才会被允许进入订单簿。
如果用户提交的是限价单,订单会挂在订单簿中等待匹配;如果是市价单,则会立即尝试与当前市场中的挂单成交。
整个订单提交过程均发生在链上,因此所有订单状态都能够被公开验证。
Phoenix 的撮合逻辑遵循价格优先与时间优先原则。
当新的买单进入市场时,系统会寻找价格最低的卖单进行匹配;反之,当卖单进入市场时,则会优先匹配价格最高的买单。
如果多个订单价格相同,则会优先执行更早进入订单簿的订单。这种机制与传统金融市场中的订单簿逻辑基本一致。
例如:
用户 A 挂出 BTC 多单
用户 B 提交 BTC 空单
当双方价格匹配时,系统完成撮合
双方仓位状态随后更新
Phoenix 的撮合过程并不依赖中心化服务器,而是通过链上程序完成订单状态更新与成交确认。这也是 Fully On-Chain 模型的重要特点之一。
永续合约交易涉及杠杆,因此保证金管理是撮合流程中的关键部分。
当订单成交后,Phoenix 会更新用户账户中的:
仓位规模
开仓价格
未实现盈亏
保证金占用
杠杆比例
系统会持续监控账户风险水平。当市场价格波动导致账户净值下降时,维持保证金比例也会随之变化。
如果账户风险超过安全阈值,Phoenix 的风险引擎可能会触发清算机制,以避免协议出现坏账风险。
由于所有仓位状态均记录在链上,因此用户能够实时查看账户风险变化。
Phoenix 虽然采用订单簿定价,但仍需要依赖 Oracle 提供市场参考价格。
Oracle 价格主要用于:
计算标记价格(Mark Price)
评估账户风险
判断清算条件
防止异常价格操纵
如果仅依赖订单簿价格,市场可能会因为流动性不足而出现短时异常波动。因此,Phoenix 会结合 Oracle 数据维持风险系统稳定性。
在链上衍生品市场中,Oracle 系统通常是风险控制的重要组成部分。预言机异常可能影响资金费率、清算逻辑与市场稳定性,因此 Phoenix 需要依赖可靠的数据源。
当订单完成撮合后,系统会将成交结果写入链上状态,并更新用户仓位数据。
链上结算包括:
更新账户余额
调整保证金状态
记录成交信息
更新市场持仓数据
由于 Phoenix 采用非托管结构,用户资产始终由链上账户控制,而不是由中心化平台托管。
这种模式提高了透明度,但也意味着所有交易行为都依赖区块链网络确认。因此,底层网络性能会直接影响交易体验。
Solana 的快速确认能力是 Phoenix 能够运行链上订单簿的重要原因之一。
Phoenix 与传统 AMM 协议最大的区别在于交易执行方式。
AMM 模型依赖流动性池与算法定价,用户实际上是与资金池交易。而 Phoenix 的订单簿模型则是用户之间直接匹配订单。
两种模式在交易流程上存在明显差异:
| 对比维度 | Phoenix | AMM 模型 |
|---|---|---|
| 交易结构 | 订单簿撮合 | 流动性池 |
| 价格形成 | 买卖挂单 | 算法定价 |
| 滑点控制 | 相对较低 | 大额交易较明显 |
| 做市方式 | 专业做市商 | LP 提供流动性 |
| 高频交易支持 | 较强 | 相对有限 |
| 订单类型 | 限价单、市价单 | 通常较少 |
订单簿模式通常更适合专业交易与量化策略,而 AMM 更适合基础资产兑换与开放流动性供给。
随着 Solana 等高性能网络的发展,越来越多链上衍生品协议开始重新探索订单簿架构。
Phoenix 的链上撮合流程不仅关系到订单执行效率,也反映出 DeFi 市场结构正在发生变化。
早期 DeFi 协议更强调开放参与与无需许可流动性,而新一代链上衍生品协议则开始关注:
更低延迟
更高资本效率
更专业交易体验
更精细的订单控制
Phoenix 的 Fully On-Chain Order Book 模型,实际上是在尝试将传统金融市场中的订单簿结构迁移到区块链环境中。
这类协议的发展,也意味着 DeFi 正逐渐从简单资产交换工具,演变为更复杂的链上金融基础设施。
Phoenix 使用 Fully On-Chain Order Book 架构完成链上永续合约交易,其撮合流程包括订单提交、风险检查、订单匹配、仓位更新与链上结算等多个阶段。
相比传统 AMM 模型,Phoenix 更强调订单深度、价格发现效率与高频交易能力。依托 Solana 的高性能网络,Phoenix 能够在链上环境中运行接近传统交易所的撮合系统。
随着 DeFi 市场逐渐向专业交易场景扩展,链上订单簿模式也正在重新受到关注。Phoenix 的撮合流程不仅体现了链上衍生品协议的发展方向,也反映出 DeFi 基础设施正在向更复杂的金融市场结构演进。
是。Phoenix 采用 Fully On-Chain Order Book 架构,订单簿与撮合逻辑均运行在链上。
Phoenix 更强调订单深度、低滑点与专业交易体验,因此选择订单簿模式而不是流动性池模型。
Phoenix 通常采用价格优先与时间优先原则进行订单匹配。
不需要。Phoenix 属于非托管协议,用户通过钱包直接管理资产。
Oracle 主要用于提供参考价格,帮助系统完成风险控制与清算判断。
Phoenix 基于 Solana 高性能网络运行,能够提供较低延迟与更快订单确认速度。





