本文介绍加密货币做市中的延迟问题，分析行情数据、数据处理、交易决策与订单执行速度如何影响报价准确性、买卖价差和逆向选择风险，并探讨 WebSocket、FIX 协议及网络优化在低延迟做市中的作用。
文章作者、来源：区块链工具
引言：更快的执行，始于更及时的信息
在加密货币做市中，速度并不只是订单到达交易所的速度，还取决于交易系统接收市场数据、识别市场变化并作出交易决策的速度。
一个交易引擎可能拥有很快的订单提交能力，但如果接收到的行情数据已经过时，最终作出的交易决策仍然可能滞后。当订单真正进入市场时，最佳买价、最佳卖价以及可用订单簿深度都可能已经发生变化。
这就是执行速度（Execution Speed）与决策速度（Decision Speed）之间的区别。
对于加密货币做市商而言，低延迟行情数据、高效的数据处理和可靠的订单执行，共同决定了做市策略的执行质量。理解这些环节之间的关系，是构建自动化做市策略的重要基础。
一、延迟差距：为什么行情数据的及时性至关重要？1.1 什么是加密货币做市中的延迟？
延迟（Latency）是指交易系统中不同事件之间产生的时间差。根据测量范围不同，延迟可能包括接收行情数据、处理市场更新、作出交易决策、发送订单，以及接收订单确认或成交回报所需的时间。
在自动化加密货币做市中，以下几类延迟尤其值得关注。
- 行情数据延迟： 市场事件发生后，交易系统接收到相关更新所需的时间。
- 数据处理延迟： 系统解析行情并计算下一步操作所需的时间。
- 决策延迟： 系统接收信息后，确定相应交易操作所需的时间。
- 订单提交延迟： 订单从交易系统发送至交易所所需的时间。
- 成交回报延迟： 系统接收订单已接受、成交、拒绝或状态变更等信息所需的时间。
这些延迟可能相互叠加。即使一个系统提交订单的速度很快，如果依赖过时的行情数据或低效的决策逻辑，其交易表现仍可能不理想。
1.2 REST API 一定不适合做市吗？
REST API 广泛应用于加密货币交易，包括账户查询、历史行情获取、订单管理和其他交易所操作。在部分策略中，REST API 也可以满足需求，具体取决于更新频率、接口限制和系统设计。
但如果系统通过反复轮询 REST 接口获取最新价格，就可能在两次请求之间错过订单簿变化。即使市场已经发生变化，系统也可能需要等待下一次请求才能获取新的行情快照。
对于需要频繁获取市场更新的策略，交易所提供的 WebSocket 行情流通常更适合实时监控，因为它能够在相关事件发生时向订阅客户端推送数据。不过，实际表现仍受到交易所接口设计、网络状况和数据处理能力的影响。
因此，关键并不是简单地判断 REST API 和 WebSocket 哪个更好，而是评估整条数据链路能否为具体策略提供足够及时、准确且可靠的信息。
对于长期投资组合监控而言，定期更新价格可能已经足够。但对于需要持续调整买卖报价的做市策略，过时的行情数据可能直接增加交易风险。
二、低延迟交易基础设施：机构级交易系统需要什么？
低延迟交易基础设施的目标，是减少市场事件、交易决策和订单执行之间不必要的时间损耗。
部分机构交易团队和高频交易系统会使用专业化基础设施，但具体配置应根据交易所、策略类型、接入条件和成本效益决定。
2.1 WebSocket 实时行情接口
WebSocket 允许交易所主动向订阅客户端推送市场更新，而不需要客户端为每一次行情变化单独发送 REST 请求。
根据交易所的支持情况，相关数据流可能包括：
- 最佳买价和最佳卖价
- 订单簿深度变化
- 逐笔成交数据
- 行情及价格更新
- 订单状态和成交回报
对于做市策略而言，及时获取订单簿更新，有助于判断当前报价是否仍具竞争力，以及是否需要调整报价参数。
但仅仅接收高频更新并不足够。系统还需要正确处理数据、维护一致的订单簿状态，并在连接中断或数据序列缺失时进行检测与恢复。
2.2 FIX 协议接入
FIX，即 Financial Information eXchange，是一种广泛用于电子交易的消息协议，主要用于传递订单、成交以及相关交易信息。
部分机构交易环境和交易所支持 FIX 接入，而其他加密货币交易所可能主要依赖 REST API 和 WebSocket 接口。
FIX 并不意味着在所有环境下都拥有更低的延迟。它的实际价值取决于交易所的实现方式、连接架构、支持的订单类型以及具体运营要求。
对于做市商而言，核心目标是选择能够满足策略延迟、吞吐量和风控要求的可靠接口。
2.3 服务器共址与网络距离优化
在部分传统金融市场中，交易机构可以将服务器部署在靠近交易所撮合引擎的位置，以减少网络传输时间。这种方式通常被称为共址（Co-location）。
其效果取决于交易所是否提供相关服务，以及交易机构是否具备相应的接入资格。并非所有加密货币交易所都支持与撮合引擎共址，具体条件也因平台而异。
对于许多 Web3 项目而言，优化受支持的交易所连接、服务器部署位置、网络路由和软件架构，可能比追求专业化机构基础设施更加实际。
2.4 高效的订单处理机制
行情数据需要经过处理和分析，才能转化为具体的交易决策。
低效的数据处理、过多的计算步骤、不必要的网络跳转，以及订单状态管理不完善，都可能增加系统延迟，即使底层网络连接已经足够快速。
设计良好的交易系统应当具备以下能力：
- 高效处理市场更新。
- 避免基于过时或不一致的数据作出决策。
- 准确追踪待成交订单和实际成交情况。
- 妥善处理交易所限频和订单拒绝。
- 检测连接故障并安全恢复。
- 测量完整交易流程中的各环节延迟。
因此，低延迟是一项端到端的系统工程目标，而不是仅靠选择某一种通信协议就能保证的功能。
三、延迟如何影响买卖价差？
延迟与价差管理之间的关系，是做市策略中的重要问题。
做市商通过挂出买单和卖单提供流动性，同时承担订单成交前市场价格发生变化的风险。当报价更新滞后时，其他交易者可能在做市商调整或撤销订单之前，先以对做市商不利的价格完成交易。
这就是逆向选择（Adverse Selection）风险的一种表现。
3.1 过时的报价会增加成交风险
假设某个做市商在 1.00 美元的位置挂出卖单。
随后，新的市场信息推动该资产的合理价格上涨至 1.02 美元。如果做市商的行情数据或订单更新流程存在延迟，原本位于 1.00 美元的卖单可能仍然留在订单簿中。
买方就可能以 1.00 美元买入，而此时市场价格已经发生变化。这种成交对做市商而言可能是不利的。
当价格下跌而过时的买单仍留在订单簿中时，也可能出现相反的情况。
这个例子说明了行情及时性和订单更新速度的重要性，但并不意味着每次价格变化都会造成损失。实际结果还取决于订单流、成交概率、手续费以及后续价格走势。
3.2 为什么做市商可能扩大价差？
当做市商无法准确判断当前价格，或者面临更高的逆向选择风险时，可能采取以下措施：
- 扩大买卖价差。
- 降低挂单规模。
- 收紧库存限制。
- 调整报价和风险参数。
这些操作有助于应对增加的执行风险，但也可能降低报价的竞争力。
如果交易系统能够获取可靠、及时的行情数据，并高效地更新订单，就有机会更精确地管理相关风险。在市场条件允许时，这有助于维持更具竞争力的报价。
不过，低延迟并不意味着一定能够维持更窄的价差。市场波动、流动性、库存敞口、交易费用和竞争情况仍然会影响最终报价。
四、执行速度与决策智能：两者有什么区别？
快速发送订单与智能作出交易决策，是两个相关但并不相同的问题。
1. 行情数据
需要关注获取的市场信息是否足够及时，这决定了系统能否准确反映当前市场状况。
2. 数据处理
需要评估系统能否高效处理市场更新，这会影响系统识别市场变化的速度。
3. 决策逻辑
需要明确系统应当如何利用市场信息，这会影响买卖价差、订单规模和风险响应方式。
4. 订单传输
需要关注订单能够多快到达交易所，这会影响交易策略的执行及时性。
5. 订单管理
需要确保系统能够准确追踪订单状态和实际成交情况，以减少状态不一致和意外风险敞口。
6. 风险控制
需要明确在什么情况下应限制或停止交易，这决定了系统可接受的风险范围以及异常情况的处理方式。
快速的网络连接无法弥补糟糕的策略逻辑。同样，再复杂的策略，如果始终依赖过时的行情数据，也很难作出及时、合理的决策。
有效的自动化做市，需要这些环节协同运作。
五、机构级做市是否一定需要亚毫秒级延迟？
并不是所有加密货币做市策略都需要亚毫秒级延迟。
具体的延迟要求取决于策略周期、交易频率、目标交易所和市场竞争环境。
对于依赖极短暂价格差异的高频策略而言，专业化基础设施和严格控制的执行链路可能十分重要。
但其他做市策略可能拥有更长的交易周期，更关注可靠的订单簿监控、合理的价差管理、库存控制和运营稳定性，而不是极限延迟。
例如，一个需要在中心化交易所持续提供双边报价的代币项目，可能通过可靠的 WebSocket 行情数据、高效的订单管理和自动化价差调整，获得显著的运营改善，而不一定需要直接与交易所撮合引擎共址。
正确的目标不是盲目追求某个延迟指标，而是让系统性能与策略需求相匹配。
在评估做市平台时，项目团队应了解延迟是如何测量的、测量覆盖哪些环节、测试在什么市场条件下进行，以及公布的数据代表典型表现还是最佳表现。
六、如何构建响应更及时的自动化做市流程？
一个实用的低延迟做市流程，需要将行情数据、决策逻辑、订单管理和风险控制结合起来。
第一步：接收相关市场数据
使用交易所支持且适合具体策略的数据接口。对于需要频繁监控订单簿的策略，事件驱动的数据流通常比反复轮询更合适。
第二步：验证数据质量
检查行情是否及时、一致，并且足以支持相关交易决策。对于过时的数据、适用情况下的数据序列缺失，以及异常行情，都应建立检测机制。
第三步：评估市场状态
综合分析波动率、买卖价差、订单簿深度、价格变化和当前库存等相关指标。
第四步：执行策略规则
根据预先配置的策略，决定维持现有报价、调整价差、降低订单规模，或修改报价价格。
第五步：执行并追踪订单
通过受支持的交易所接口提交订单，并持续监控订单确认、成交、撤销和拒绝等状态。
第六步：执行风险控制
确保延迟优化不会绕过持仓限制、风险敞口控制和异常处理机制。当行情数据不再可靠时，系统可能需要限制报价，而不是继续使用过时信息交易。
第七步：评估端到端表现
追踪数据接收延迟、处理时间、订单提交延迟、成交结果，以及过时报价和订单拒绝的发生频率。
通过这一流程，项目团队能够更全面地评估交易系统，而不是只关注某一次 API 调用的速度。
七、自动化做市如何运营？
CiaoAI 为 Web3 项目提供做市软件和流动性管理基础设施，支持在相应的中心化交易所（CEX）与去中心化交易所（DEX）环境中开展做市运营。根据所选产品及具体集成情况，项目团队可以通过 CiaoAI 管理已配置的交易参数、执行受支持的自动化交易操作，并借助可用的监控工具查看做市活动。
对于正在评估做市软件的项目团队，建议重点了解以下技术问题：
- 系统支持哪些交易所和行情数据接口？
- 行情更新如何被处理和监控？
- 系统支持哪些价差、订单规模和库存控制功能？
- 如何处理订单拒绝或连接中断？
- 可以查看哪些运营数据来评估策略表现？
- 系统提供哪些延迟指标，这些指标的定义是什么？
这些问题有助于判断平台是否适合项目的实际交易需求。具体的延迟表现、FIX 协议接入、服务器共址以及亚毫秒级执行能力，应针对相关交易所和产品配置进行确认，而不能仅凭平台提供自动化交易功能就推定其具备这些能力。
八、如何评估做市系统的延迟表现？
有效的延迟评估应当覆盖完整的交易流程。
1. 行情数据延迟
衡量市场更新到达交易系统所需的时间，用于评估交易信息的及时性。
2. 数据处理时间
衡量系统解析行情并计算操作所需的时间，用于识别软件处理和计算环节的瓶颈。
3. 决策至下单时间
衡量从形成交易决策到提交订单所需的时间，用于评估交易执行流程的响应能力。
4. 订单确认时间
衡量系统接收交易所订单响应所需的时间，用于评估连接状况和订单提交表现。
5. 成交延迟
在适用情况下，衡量从提交订单到实际成交所需的时间，帮助分析交易执行情况。
6. 过时报价频率
衡量报价不再符合预设时效标准的发生频率，用于识别市场变化带来的报价风险。
7. 滑点（Slippage）
衡量预期成交价格与实际成交价格之间的差异，是分析实际交易执行成本的重要指标之一。
8. 订单拒绝率
衡量被交易所拒绝的订单占比，用于识别订单配置、连接状况或交易规则方面的问题。
延迟指标应采用一致的测量方法，并结合实际交易结果分析。仅关注平均延迟可能掩盖偶发的严重延迟，因此可以进一步观察 p95 和 p99 等百分位指标，以了解系统在高负载下的表现。
这些数据也有助于区分网络延迟、数据处理问题和策略本身的问题。
九、常见问题 FAQ什么是加密货币做市中的延迟？
延迟是指交易流程中不同事件之间的时间差，例如接收行情、作出决策、提交订单和接收成交回报。不同的延迟指标对应不同的系统环节。
WebSocket 一定比 REST API 更适合做市吗？
对于需要频繁接收行情更新的策略，WebSocket 通常更适合，因为交易所可以主动推送市场变化。REST API 仍然适用于许多其他操作，也能满足部分策略需求。具体选择取决于交易所接口设计、更新频率、限频规则和系统架构。
低延迟一定能带来更窄的买卖价差吗？
不一定。低延迟可以减少过时报价带来的风险，但最终价差还受到波动率、流动性、库存风险、交易费用和市场竞争等因素影响。在不确定性增加时，做市商仍可能需要扩大价差。
FIX 协议和 WebSocket 有什么区别？
FIX 是一种广泛用于电子交易的消息协议，常用于订单、成交及相关交易信息的传输。WebSocket 是一种通信技术，在加密货币交易所中经常用于推送行情和账户更新。两者的适用性取决于交易场所和具体功能。
所有做市商都需要亚毫秒级执行吗？
不需要。亚毫秒级延迟对于部分高频交易策略可能十分重要，但许多加密货币做市业务更关注可靠的行情数据、及时的报价调整、库存管理和风险控制。
项目方应该如何评估做市平台的执行速度？
建议要求服务商提供定义清晰的延迟指标，包括测量范围、测试条件，以及数据代表典型表现还是最佳表现。同时，还应综合评估数据可靠性、订单处理能力、风险控制和实际执行质量。
结语：更好的做市，始于更及时的信息
在加密货币做市中，执行速度固然重要，但它只是整个交易流程的一部分。系统还需要获取足够及时的行情数据、正确处理信息、作出合理决策，并可靠地提交订单。
延迟的市场信息可能让报价暴露于逆向选择风险。可靠的数据接口、高效的数据处理、及时的订单管理和预先设定的风险控制，有助于做市商更有效地适应不断变化的市场环境。
真正的目标不是不计成本地追求最低延迟，而是构建一套在速度、可靠性和决策逻辑方面都符合策略需求的交易系统。
快速执行决定订单移动的速度；及时的数据与合理的决策逻辑，决定这个订单是否应该出现在市场中。