1. Deribit 客服支援
  2. 交易所
  3. 订单

订单管理-最佳实践

  • 更新

高效的订单管理对于在Deribit上进行高性能交易至关重要。本文解释了如何通过 Deribit 的系统处理订单，并概述了实现最快、最可靠执行的最佳实践。我们涵盖了订单提交管道、内部队列、延迟优化、取消策略、订单编辑与替换、高级订单类型（如OCO/OTO），以及开发人员和机构交易者使用 Deribit API 的其他技巧。目标是帮助您有效地管理订单，同时最大限度地减少延迟并避免常见的陷阱

订单提交架构

当你向 Deribit 发送订单时（无论是通过 REST API， 网络套接字，或 修复），它在到达匹配引擎之前会经过多节点架构。Deribit 的交易平台内置于 Erlang 中，使用多个网关 节点 接受客户端连接和请求。这些网关节点由所有参与者共享；负载均衡器根据负载和网络位置将您的会话分配给节点。每个节点都与一个中心通信 主节点 或匹配引擎集群以确定订单状态并执行交易。您的订单从客户端进入一个 Deribit 的 API 网关节点，然后进入匹配引擎，在那里它与其他订单进行匹配

重要

所有 API 接口（REST、WebSocket、FIX）最终都会生效 进入同一个匹配引擎。使用 WebSocket 或 FIX 可以为这些节点提供持久连接，而 REST 则为每个请求建立一个新的 HTTP 连接。多个网关节点可确保可扩展性和负载分配，但它们不会改变匹配的公平性——所有订单都在单一匹配引擎上交汇以执行。

订单处理队列

在从您的系统到匹配引擎的路径上，订单可能会分几个阶段排队。了解这些队列有助于优化性能

  • 客户端和 TCP 队列： 首先，您的订单可能会短暂停留在连接的 TCP 发送缓冲区中。这是特定于客户的队列 未共享 与其他参与者一起。高网络延迟或发送大量数据可能会导致这种情况的积累

  • Deribit 入口节点队列： 在收到您的订单的 Deribit 节点中，有用于不同请求类型的单独线程池。例如，“公开” 数据请求（例如市场数据订阅）可能使用共享池，而 “私人” 操作（例如下达或取消订单）使用不同的池。来自您的会话的私人订单请求通常会进入专用于您的连接的队列（不与他人共享），而某些公共订阅源则在共享队列中处理。例如，这种设计可以防止缓慢的公开提要阻止您的私人订单命令。

  • 节点间通信： 如果网关节点需要与主匹配引擎或其他节点（使用 Erlang 的分发协议）进行通信，则这些消息将通过内部 TCP 通道传输。这个节点间通道可以考虑 共享的 从某种意义上说，来自许多参与者的消息可能会流过它，可能会在高负荷下排队。

  • 用户级锁定队列： 在匹配的引擎层，Deribit 强制对每位用户每种货币的操作进行排序。所有影响给定货币的单个用户账户的请求都通过以下方式提交 用户进程锁。这意味着，如果您使用同一个账户和相同的货币发送多个操作（订单、取消），它们将按照收到的顺序依次执行。如果您在同一个账户上有多个连接（或 API 密钥）使用相同的货币进行交易，为了保持一致性，它们仍会共享此队列。这个队列 是共享的 在该用户使用该货币的所有连接中。

  • 匹配引擎队列： 最后，每种工具的订单簿流程都有自己的接收订单和取消订单的队列。这是您的订单最终与其他订单竞争的地方。这个 是共享的 所有交易该工具的参与者——每个订单簿一次只能处理一个操作。如果许多订单大约在同一时间到达，它们将在这里短暂排队，然后按顺序进行匹配。

总而言之，有些队列（例如您的连接的 TCP 和私人工作队列）是您独有的，而其他队列（例如全球订单簿）则自然是共享的。知道了这一点，你就会明白为什么在系统负载过重的情况下有时会出现轻微的延迟或不确定的顺序——例如，如果很多信息同时传到同一台仪器的账本上

并发和请求流水线

Deribit 的 API 是异步和多线程的，这意味着尽可能可以无序并行处理请求。该平台有效 管道 不同类型的请求以最大限度地提高吞吐量。例如，针对WebSocket连接上的不同类别的操作，有不同的内部工作人员：一个用于比特币上的私有匹配引擎操作，另一个用于以太坊上的私人操作（类似地用于其他货币），另一个用于非匹配引擎的私人请求（例如账户查询），另一个用于公共数据订阅。由于这种分离，如果背靠背发送的请求属于不同的类别，则可以并行处理

乱序响应： 收到的响应顺序与您发送请求的顺序不同是正常的。例如，如果您快速发送订阅请求（公开数据），然后下订单（私人交易操作），则即使您先发送了订单，也可能会看到订阅回复在订单确认之前到达。这是由于请求由不同的工作线程处理，以及 不表示有任何问题。Deribit 的架构确保并行处理每个类别（以及每种货币的订单），因此最快的回复获胜。在一个示例中，一位用户指出，订阅响应在先前请求的响应之前到达，这是多线程设计下的预期行为

参赛者之间的比赛条件： 在高频环境中，两个参与者可能会竞相利用机会。谁赢得这场竞赛在很大程度上取决于外部因素（网络延迟、消息时间）和日程安排中的运气。从订单到达平台并进入匹配引擎的那一刻起，所有用户的订单都将以先到先得的方式得到公平对待。但是，在分布式多节点系统中，如果时间非常接近，则存在一些不确定性，即顺序首先到达。如果速度稍慢的参与者遇到更多的网络延迟，或者线程调度导致了短暂的重新排序，则速度稍慢的参与者可以先匹配他们的订单。本质上，无法保证参与者会 预期的 永远是第一位——真正的赢家是谁要求先通过管道到达匹配的引擎，这在并行处理环境中可能会有所不同。

可取消的排队请求： Deribit 的 WebSocket API 的一项高级功能是能够取消或覆盖仍在会话队列中的请求。例如，如果您发出一连串的订单，然后发送 cancel_all 命令，则系统不仅会取消已到达订单簿的订单，还会取消那些已到达订单簿的 还在你的连接队列中等待 （如果有的话）。那些在执行前取消的请求将返回 13666 （”request_cancelled_by_user“)，表示该请求从未到达订单簿，因为您在飞行途中取消了该请求。同样，cancel_by_label 可以在执行之前通过标签取消排队订单的特定子集。这种机制有助于防止积压的订单在不再需要时执行，从而有效地让您可以控制清空自己的队列

注意

错误码 13666 不是一个坏兆头；它明确告诉你待处理的请求已成功撤回。实际上，如果你发送了一批订单，然后快速全部取消，你可能会看到这种情况——其中一些订单可能在到达匹配引擎之前就被取消，从而返回这些特定请求的取消错误

延迟最佳实践

速度通常至关重要。以下是一些最佳实践，可将您的订单尽快发送到匹配引擎：

  • 使用 WebSocket 或 FIX 代替 REST： WebSocket（JSON-RPC）和 FIX 连接是持久的，并针对低延迟进行了优化，而 REST 会为每个请求带来额外的开销。实际上，在大多数情况下，WebSocket和FIX提供的延迟几乎相同。对于某些操作（例如批量取消），FIX可以稍快一些，因为它绕过了某些队列，但是与WebSockets相比，它的功能更少。另一方面，REST 稍慢一些，因为每个 HTTP 请求都必须单独设置、授权和处理。 底线： 如果您经常提交订单或需要实时速度，则首选 WebSocket 或 FIX。仅在不频繁的请求或简单性比速度更重要的情况下使用 REST

  • 保持轻量级连接： 避免在同一个连接上发送或接收过多的数据，因为大规模的突发会填满 TCP 管道和 JSON 解析器。例如，如果您在用于交易的同一个WebSocket上订阅数百种工具的每笔即时报价，则大量传入的数据可能会延迟订单消息的处理。明智的做法是将大量市场数据订阅与订单输入分开到不同的连接上，或者至少限制数据量

  • 发送少量订单： 如果您需要提交大量订单，请避免同时提交极大批量的订单。尽管Deribit的流水线可以处理大量订单，但使用相同的工具或货币一次性发送 “一次性发送数十个订单” 可能会造成积压，从而增加后续订单的延迟（“滚雪球效应”）。取而代之的是，可以考虑稍微错开批次提交或使用多个连接（或线程）进行超大型提交，尽可能按工具或货币进行拆分

    对于高频做市来说， 群众报价 功能提供了一种更有效的方法。Mass Quotes允许您在单个API调用中提交或更新一个或多个工具的多个买入/卖出对，而不是发送许多单独的下单请求。这样可以减少每笔订单的开销，降低网络流量，并有助于保持较低的延迟，即使在多次罢工或到期日报价时也是如此

    请记住，在单一货币中，请求是按用户序列化的。一次性发送50份比特币订单将按顺序排队；批量报价或谨慎的节奏可以帮助您实现相同的报价目标，减少队列积累，缩短整体周转时间

  • 优化网络条件： 确保您的交易服务器拥有通往 Deribit 服务器的快速、可靠的网络路径。如果您对延迟敏感，可以考虑在 Deribit 数据中心（主交易所为伦敦 LD4）附近托管。外部互联网连接通过负载均衡器并具有更长的路由，从而增加了一点延迟（LB 跳跃约为微秒，再加上任何地理延迟）。一些公司选择 托管 以减少往返时间。虽然这是 API 本身之外的基础设施考虑因素，但它是竞赛场景中的一个重要因素。

通过遵循这些做法——使用正确的协议、管理连接负载和优化网络——您可以最大限度地缩短订单到达匹配引擎所需的时间。

风险检查

修改投资组合（新订单、编辑、平仓等）的每笔订单都必须先通过 风险检查。该流程可确保整个平台的余额、头寸和利润保持一致。风险检查在内部执行 投资组合队列，其中每个请求都等待 “锁定”，然后才能更新投资组合状态。

当风险检查可能需要更长的时间时

风险检查通常很快，但有几个因素可以延长其处理时间：

  • 大型投资组合 — 大量的未平仓头寸增加了所需的增量投资组合更新和同步。

  • 高订单活动 — 大量活跃的未平仓订单会导致更繁重的利润计算。

  • 队列拥塞 — 如果有许多连接和请求正在等待投资组合访问权限，则支票可能会延迟。

订单类型和风险检查

  • 所有订单类型均使用相同的风险检查进行处理。仅限减少的标志或有效期指令（例如 GFD、IOC）

  • 取消请求 (cancel， cancel_all， cancel_by_label）也可以通过投资组合队列，但它们是在没有风险检查的情况下执行的。

  • 群众报价 是唯一的例外——他们跳过了大多数风险检查以支持高性能报价。

与风险检查相关的错误

  • 10047 matching_engine_queue_full：投资组合队列最多可容纳 8 个等待进程。如果已满，新请求将被拒绝，并出现此错误。在 FIX 中，它显示为 请求太多。

  • 10050 lock_time_exceeded：如果请求无法在 5 秒内完成锁定过程，则会超时，即使等待的进程少于 8 个。

提示

最佳实践

  • 将同步客户端连接的数量保持在最大值 8 以下，以最大限度地减少出现错误的机会 10047。

  • 请注意，内部操作（触发订单、清算订单、高级期权订单）也会消耗队列空位，从而减少可供客户活动使用的时间。

订单取消策略

高效管理未平仓订单通常涉及批量取消，特别是对于需要快速更新报价的做市商或算法交易者而言。Deribit 提供了几个 API 端点来取消订单，每个端点都适用于不同的

  • 取消单个订单： 您可以使用订单编号取消订单 私密/取消 方法（提供具体的 order_id）。对于一次性取消来说，这很简单

  • 按标签取消： 如果您在下单时使用标签（用户定义的字符串，最多 64 个字符）标记订单，则可以通过以下方式一次调用取消所有带有该标签的订单 private/cancel_by_label。这对于分组和管理相关订单很有用。例如，您可以为来自特定策略或工具的所有订单贴上标签，然后按标签一次性取消它们。

  • 取消所有订单：private/cancel_all 将尝试取消 每个 在您的账户中开立所有工具和货币的订单。虽然方便，但这是最繁重的取消通话，因为它涵盖了所有内容

  • 全部以一种货币取消：私有/全部按货币取消 是一种更有针对性的批量取消——它将取消所有以给定货币计价的订单（例如，所有比特币订单或所有以太坊订单）。如果需要，您甚至可以按工具种类或定单类型进行筛选（例如，仅限期权或仅限止损订单）。

  • 取消乐器中的所有内容：私有/全部按仪器取消 将取消特定工具（例如，特定期权或期货）的所有订单。

  • 通过批量报价取消报价： 如果您使用多种工具报价 群众报价 功能，你可以在单个 API 调用中取消所有活跃的报价 (私密/取消报价）。这比单独取消每份报价单更有效，对于管理大型多工具报价簿的做市商来说尤其有用

提示

哪个最快？

就原始延迟而言，按货币取消往往比全局取消更快。这是因为当你调用泛型 全部取消，系统内部将其拆分为每种货币的单独取消订单（一种用于比特币，一种用于以太坊等），外加一些管理费用。

如果你 知道 你只需要取消（比如）比特币和以太坊的订单，打电话会更快 私有/全部按货币取消 并行两次（一次用于比特币，一次用于以太坊）。这消除了额外的拆分逻辑，直接集中了取消请求。结果是降低了大规模取消的延迟，这在市场快速波动中可能至关重要

以下是使用 JSON-RPC API（通过 WebSocket 或 HTTP）取消比特币工具所有订单的示例：

{
 “jsonrpc”：“2.0”，
 “ID”：42，
 “方法”：“私有/全部按货币取消”，
 “参数”：{
 “货币”：“BTC”
 }

回复将显示成功取消了多少订单。例如，结果 {"result": 3} 表示有三笔订单被取消。你可以为你交易的每种货币都这样称呼。请务必处理某些订单可能已经成交或被取消的可能性；这些订单只会被跳过

订单编辑与取消和替换

当您需要更改未平仓订单的参数（价格或规模）时，通常有两种选择： 编辑 已下达的订单，或 取消 然后下新订单。Deribit 的 API 支持编辑订单，它通常比取消和重新提交新订单更有效

性能优势： 编辑是向系统发出的单个请求，而取消 + 新订单是两个请求。更少的请求意味着 API 队列中的开销更少，匹配引擎的工作量也更少。实际上，编辑订单往往更快，并且可以缩短变更启动和订单反映新参数之间的延迟。它还可以减少您的连接和 Deribit 基础架构（解析、排队等）的负载，这在高吞吐量期间非常有用。

订单簿优先级： 如果您减少订单数量或保持价格不变，则会进行编辑 不是 更改账簿中订单的优先级——它在该价格水平上保留其时间优先级。同样，如果你只是缩小规模，你可以在队列中保留自己的位置以备剩余的数量。相比之下，如果你取消并下了新订单，你将完全失去原来的队列位置；对于这个价格，新订单将被视为排在队列后面的新订单。

重要

如果你 增加 订单数量或更改价格（使其更具侵略性或更被动），编辑后的订单将被视为该价格水平上的新订单，这意味着它将排在队列末尾以获取新价格。（这是合乎逻辑的，因为其他订单已经以该价格计算。）重要的是，如果你只编辑价格，即使是为了改善价格（例如，向上移动买入或向下卖出），你也会丧失时间优先权，因为订单实际上是在转移到书中的另一个地方

部分填充注意事项： 编辑会保留所有填充的历史记录。如果订单在编辑前已部分成交，则这些成交量仍会被计算在内。累积成交量保持不变，剩余大小只需根据新的总量进行调整即可。

例如，假设您的订单包含 200 件商品，而 100 件已成交，剩下 100 件未配送。如果您编辑订单以将总金额增加到 400，则已成交的 100 个将保留在订单历史记录中，剩余数量将更新为 300。 编辑订单时，之前的填充不会 “重置”。

相反，如果您取消了剩余的100笔订单并以300美元的价格下了新订单，则新订单将没有之前100成交的记录，并且会收到新的ID和时间戳。出于会计目的，编辑通常更简洁，尤其是当您需要计算该订单的平均成交价格或费用时。

结论： 只要您的更改在允许范围内（例如，您不能通过编辑将限价单更改为止损订单；它是用于价格/金额调整的），只要有可能，最好编辑定单而不是取消并重新创建订单。Deribit 私密/编辑 （由 order_id) 或 private/edit_by_label （如果你使用 label) 可以用于此目的。以下是按标签编辑订单的示例：

{
 “jsonrpc”：“2.0”，
 “ID”：123，
 “方法”：“私有/按标签编辑”，
 “参数”：{
 “工具名称”：“BTC-PERPETUAL”，
 “标签”：“我的订单组”，
 “价格”：50111.0，
 “金额”：150
 }

在此示例中，我们以标签 “” 标识的订单为目标my_order_group” 然后更改它 price 到 50111.0 和 quantity 到 150。回复将返回更新的订单详情（新价格、剩余金额等）。 私密/编辑 用 order_id 如果您通过订单的ID而不是标签来追踪订单。

部分填写和取消通知

了解Deribit如何通知您订单事件非常重要，尤其是在部分成交的情况下。常见的困惑点是看到订单 已取消 通知和订单 填充的 的通知 相同 订购。一个订单如何既可以成交又可以取消？

当订单出现时，就会发生这种情况 部分填充 然后剩余部分被取消。例如，假设你发布了1000张合约的卖出订单。它立即部分填满了500个，剩下500个空缺。如果您随后取消订单，剩余的（500）将从书中删除。您将收到：

成交通知与同一订单的取消通知一起解释意味着确认该订单已部分执行，剩余数量已从账簿中删除。这样的订单既未完全成交，也未平仓；它已部分完成，然后关闭。

交易系统应始终设计为同时处理交易通知和订单更新，以保持对持仓和订单状态的准确跟踪，确保能够决定是否需要采取进一步行动。在这种情况下，取消不会撤消任何已执行的交易，但会阻止剩余数量的进一步执行，除非订单是使用诸如Fill-Or-Kill之类的特定指令下达的，否则不应将其假定为全有或全无

价格区间保护

为了防止错误的订单或极端的价格波动，Deribit 采用 交易价格带宽限制 在所有乐器上。这定义了可以下单的参考价格（通常是指数或最后交易价格）周围的上限和下限。如果您提交的价格超出此允许范围的订单，则该订单将被拒绝，错误如下 price_too_high 或者 price_too_low。

该怎么做： 如果您遇到这些错误，请检查您的定价逻辑是否正确。可能是您的价格来源过时或者您遇到了错误。如果你故意想在正常交易区间之外下订单（可能是作为深度止损或极端对冲），你根本无法——你需要监控市场，直到该价格进入区间为止。这种机制可以保护所有参与者免受由于异常顺序而导致的闪电崩溃或野外印记

有关价格带宽的更多详细信息，请参阅 Deribit 知识库中的仪器规格。不同工具种类的带宽限制可能有所不同，因此请务必查看您交易的每种产品的规格。

仅限发布的订单和价格调整

Deribit 提供了 “仅限发帖” 订单期权，这是避免接受者费用或意外执行的常见功能。 仅限发帖 订单只会带来流动性；它永远不会 拿 订单簿中的流动性。如果你提交的是仅限邮寄的订单 会 立即与现有订单进行匹配（从而使您成为接受者），Deribit 将根据设置调整或拒绝该订单：

  • 默认情况下，如果仅限后期的订单跨越价差并执行，则 Deribit 将自动执行 调整价格 在价差内仅跳动一次，以确保它成为制造商订单。例如，假设最佳卖出价为 10,000，而您提交的买入订单为 post_only 为 11,000。系统将以9,999.50美元（假设价格为0.50美元）（略低于最佳卖出价）下订单，而不是以10,000美元的价格填写订单，这样它就可以在不执行的情况下保留在账面中。这种行为可确保价格下滑使您的仅限发布的意图得到兑现

  • 如果您希望严格不执行订单 而且没有调整，你可以启用 仅发帖拒绝 功能。在 JSON API 中，这是用 “” 完成的reject_post_only“: true （在 FIX 中，使用 ExecInst 6A 而不是 6）。使用此设置，如果您的仅限帖子的订单会导致立即匹配，则系统 拒绝订单 而不是调整价格。这给了您更多的控制权，因为订单要么未按您的价格下单（没有匹配项），要么失败。一些交易者使用这种方法来避免价格的微小差异，如果订单不是纯粹增加流动性，他们宁愿直接拒绝

  • 编辑仅限后期的订单：如果您以激进的方式编辑现有的仅限后期的订单（例如，将其价格调至可对当前账面执行的水平），则行为取决于模式：

    • 在标准的仅限帖子模式下，系统将在编辑时调整价格以保持制造商地位（类似于初始投放）。

    • 在拒绝模式下 (ExecInst 6A / reject_post_only : true)，编辑请求将导致订单 取消 否则，它会变成接受者。本质上，如果您的更改违反了仅限发布的条件，则订单将不会

仅限后期的订单对于做市和确保您不会无意中占用流动性非常有用。只要注意价格的下滑行为即可，这样订单的价格与您要求的价格略有不同，您就不会感到惊讶。如果您需要确切的价格或什么都不需要，请使用拒绝模式。

冰山命令

Iceberg 订单允许您下大笔订单，同时只显示一小部分（ 显示金额) 在订单簿中。填充可见部分后，系统会自动对其进行补充（最多 刷新量) 直到订单总额被执行或取消。可见部分的行为类似于制造商订单，而出于收费目的，交易的隐藏部分被视为接受者

使用 API 下达或编辑订单时 (私密/购买， 私有/出售，或 私密/编辑），包括：

  • display_amount — 订单的可见提示。

  • refresh_amount — 填充可见部分时用于补充可见部分的固定金额。

这两个参数都是可选的，但是如果 display_amount 设置完毕后，它必须满足以下要求：

  • 至少 100 倍该工具的最小订单量。

  • 至少占总订单金额的1％。

其他注意事项

  • 这个 refresh_amount 保持不变；只有 display_amount 随着订单的完成而变化。

  • 隐藏部分在匹配后立即执行并引发 接受者费用。

  • Iceberg 订单可用于在不向市场透露全部规模的情况下谨慎执行大宗交易。

小心

冰山命令是 不支持 关于未来的利差

关联订单（OTO、OCO、OTOCO）

Deribit 允许将订单与条件关系关联在一起，这对于自动化复杂策略非常有用。主要的关联定单类型是：

  • OTO — 一触发器-其他: 这涉及一个主要订单和一个或多个在主要订单执行之前处于休眠状态的次要订单。当主要订单全部或部分成交时（取决于触发条件）， 触发器 下达的次要订单。例如，如果价格跌至20,000美元，你想买入100个比特币永续合约，如果该订单成交，你想立即以22,000美元的价格下止盈卖出订单。这是一个一触即发的设置：您的买入是主要的；卖出是次要的，只有在您的买入执行后才会进入账面

  • OCO — 一个取消-其他: 这会链接两个订单，这样，如果一个订单执行，另一个订单会自动取消。一个常见的用例是用一个包围市场 止损和止盈。如果价格跌至19,000美元，则您可能需要卖出止损市场订单，以及在22,000美元处止盈的限价卖出订单，两者均为相同头寸规模。你只希望其中一个最终命中——无论哪个先出现都会取消另一个。这两个订单将作为 OCO 关联。如果止损触发并成交，则止盈将被取消，反之亦然。

  • OTOCO — 一触发器一取消其他: 这本质上是结合 OTO 和 OCO。你有一个主订单，它在执行时会触发两个次要订单，这两个订单本身处于OCO关系中。这是经典之作 用方括号进入退出 场景。例如，您输入多头头寸（主订单）。当它成交时，它会触发同时下止损单和止盈订单（两个辅助订单）。这两个辅助节点相互关联，因此最终只有一个可以执行——如果利润目标达到，止损被取消，或者如果止损触及，则利润单被取消。因此，OTOCO实现了整个周期的自动化：进入，无论哪种方式都有受保护的出口。它对于不干预交易非常有用，可确保在没有人工干预的情况下管理风险和获利

这些关联订单允许您在服务器端设置复杂的逻辑。你不必留意你的主要订单是否成交，然后手动发送辅助订单——平台将在单个原子设置中为你完成任务。对于需要立即做出反应的策略（例如在预先确定的退出条件下进入仓位），它尤其有价值

关联订单成交条件

使用关联订单时，您可以控制 填充条件 这会触发二级订单（如果是 OCO，则会被取消）。Deribit 支持几种模式来控制链接的激活方式和时间

  • 第一击： 当主订单的任何部分执行时（即使是部分成交），条件就会触发。在 “第一击” 设置中：

    • 对于 OTO，一个 局部的 填写主要订单将立即触发全额下达次要订单。

    • 对于 OCO，部分填充初选将立即开始取消辅助分区（实际上，使用 OCO，通常需要等待完全填充，但系统允许先命中逻辑）。

    • 适用于 OTOCO，一旦主要订单首次执行，就会下达两个二级订单，并通过OCO相互关联。从本质上讲，保护令在您的头寸开始开仓后立即生效，甚至在头寸完全成交之前。

  • 完成填充： 此模式会等到主订单完全成交（完全执行）后再触发任何辅助订单。在 “完成填充” 下：

    • OTO: 只会下次要订单 在小学完全填满之后。如果主服务器仅部分填满，然后被取消或过期，则辅助系统将永远不会激

    • OCO：仅当主要订单完全成交时，次要订单才会被取消。（对于OCO来说，这有点奇怪，因为通常主要填充不是取消辅助填充的原因——在OTOCO背景下更适用

    • OTOCO：这两个二级订单仅在主要订单成交率为 100% 时下达。这意味着在您的入场订单完全完成之前，您的止盈和止损不会进入账簿。一些交易者更喜欢这样做，以避免因尚未完全获得的头寸而退出市场

  • 增量（比例）： 这是用户界面的默认设置，也是一个非常不错的功能。在增量模式下，次要订单根据主要订单的已成交数量按比例进行调整

    • 对于 OCO: 次要的（比如止损）将与主要股的填充量成比例地取消。例如，如果您的主备课程已填满 50%，则与 OCO 关联的辅助系统可能会取消 50% 的规模。（使用增量的 OCO 在使用中不太常见；在 OTOCO 环境中更直观

    • 对于 OTO: 次要订单将以与填充量成比例的增量下达。如果您的主要订单已部分成交，则会下达相应的次要订单。例如，主要买入100个比特币，次要卖出100个比特币（止盈）。如果主要货币中有40个比特币成交，则将立即下达以止盈价格卖出40个（或略少，见四舍五入）比特币的订单。如果以后填充了更多主要金额，则额外的辅助金额将不超过总金额。

    • 适用于 OTOCO: 两个辅助股票（止损和止盈）都是逐步放置的。以同样的例子为例，如果收购了40％的头寸，系统将下达40％的全部止盈订单和40％的止损订单。随着您的主要订单的持续填充，它将按比例增加这些次要订单的规模

    • 四舍五入： 在增量模式下，分数合约或手数没有意义，因此Deribit会将次要订单规模向下舍入到不超过预期比例的最接近的整张合约。这样可以确保您永远不会过度分配辅助订单。剩余的金额（四舍五入）只有在主库完全填满（如果有的话）后才会被放入。从本质上讲，在最终填充之前，系统在二次大小方面会稍微保守

选择哪种填充条件取决于您的策略。 第一击 提供最快的保护——只要主牌的任何部分被发出，你的辅助武器就会立即生效。 完成填充 确保只有当你处于满位时才放置出口，从而避免了在没有完整入口的情况下可能执行退出的情况（尽管系统无论如何都会通过链接它们来防止这种情况）。 增量 取得平衡：您的保护订单和利润订单会随着头寸的增长而增加，如果随着时间的推移出现部分成交，这可能会很有用。

在 API 中创建关联订单

要通过 API 创建关联订单，您需要提交主要订单以及任何辅助订单的配置。在 JSON-RPC API 中，这是 linked_order_type， trigger_fill_condition，以及 otoco_config 下单时的参数。

  • linked_order_type 指定订单之间的关系

  • trigger_fill_condition 决定何时下达或取消与主要订单成交相关的次要订单（默认为”first_hit“)

  • otoco_config 是一个对象数组，描述了主订单满足触发条件时要创建或取消的二级订单。每个对象都包含定单参数，例如工具名称、类型、金额和价格。

处理后，API 将返回所有生成的订单 ID 和状态。尽管出于简单性和安全性的考虑，Web UI 可能会限制组合（通常只允许一站式和一次止盈），但 API 提供了更大的灵活性，支持多个不同类型的二级订单。应谨慎使用这种灵活性，因为不正确的配置会导致意外的订单行为

OTOCO 订单示例：

        {
  "method": "private/buy",
  "params": {
    "instrument_name": "BTC-PERPETUAL",
    "amount": 1000,
    "type": "limit",
    "price": 115000,
    "linked_order_type": "one_triggers_one_cancels_other",
    "trigger_fill_condition": "complete_fill",
    "otoco_config": [
      {
        "amount": 1000,
        "direction": "buy",
        "type": "market",
        "price": 100000,
        "trigger": "last_price"
      },
      {
        "amount": 1000,
        "direction": "sell",
        "price": 112000,
        "trigger": "mark_price"
      }
    ]
  },
  "jsonrpc": "2.0",
  "id": 3
}

这个请求意味着什么

这会发送一个 主要限价买入订单 BTC-PERPETUAL 的价格为 115,000 美元。

一旦这个主要订单是 完全填满 （trigger_fill_condition = complete_fill)，它会触发 两个次要订单:

  1. A 市场买入订单 大小相同，由触发 last_price 达到 100,000 美元。

  2. A 限价卖出订单 价格为11.2万美元，由触发 mark_price。

这两个次要订单关联在一个 OCO 关系，因此，如果一个执行，另一个会自动取消。

示例响应：

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "order": {
      "label": "",
      "price": 115000,
      "user_id": 48595,
      "direction": "buy",
      "time_in_force": "good_til_cancelled",
      "instrument_name": "BTC-PERPETUAL",
      "api": true,
      "web": false,
      "amount": 1000,
      "order_id": "58167917688",
      "creation_timestamp": 1754907086852,
      "mmp": false,
      "order_type": "limit",
      "order_state": "open",
      "replaced": false,
      "filled_amount": 0,
      "trigger_fill_condition": "complete_fill",
      "post_only": false,
      "last_update_timestamp": 1754907086852,
      "reduce_only": false,
      "average_price": 0,
      "contracts": 100,
      "is_primary_otoco": true,
      "is_liquidation": false,
      "risk_reducing": false,
      "oto_order_ids": [
        "OTO-10838714",
        "OTO-10838715"
      ]
    },
    "trades": []
  }
}

这个回应证实了什么

  • 主要的限价买入订单现在是 打开 价格为115,000美元。

  • 它被标记为 初级 OTOCO （is_primary_otoco = true) 已经分配了两个辅助订单配置 ID (oto_order_ids）。

  • 还没有填充 (filled_amount = 0），所以次要订单是 尚未激活。根据规定，只有在小学完全填满后，它们才会被放置 trigger_fill_condition。

注意

除了您设定的条件外，API 不会保管您的关联订单。

网络用户界面不同，网页用户界面可能会阻止你设置明显错误的组合（例如多头头寸的止损高于止盈），而API将接受你给出的内容。可以创建关联订单设置，该设置会由于定价重叠或其他原因没有意义而立即相互取消。因此，请谨慎使用此功能，并尽可能在测试网上测试您的逻辑

其他注意事项

在我们总结之前，请记住以下其他一些最佳实践和事实：

  • 位置平均值的四舍五入： 当您的头寸因交易而发生变化时，Deribit 会将新的平均入场价格计算为 total_cost / total_quantity。在内部，以美元计算的成本保持在高精度（最多小数点后8位），比特币的金额最多保持在小数点后12位。但是，出于显示目的，平均价格四舍五入到小数点后两位。这意味着用户界面中显示的盈亏基于四舍五入的平均价格，而内部计算和最终结算使用确切的数值。如果您核对头寸成本，请注意，您在界面中看到的结果和精确的计算结果之间可能会出现微小的舍入差异

  • 订单和交易编号： 您从系统获得的每笔订单和交易都有一个唯一的标识符。这些 ID 不是全局顺序的，但可以保证它们是唯一的，并且会随着时间的推移而增加。例如，您的交易编号会增加，但并非每个数字都被使用（可能会存在差距，尤其是因为会进行其他账户或工具的交易）。你可以相信这样一个事实，即后期交易的ID将高于之前的交易，但并不是说它正好是+1。订单编号与此类似，不是连续的，而是单调递增的

  • 断开连接时取消 (CoD)： Deribit 提供了一项可选功能，默认情况下处于禁用状态，名为 断开连接时取消 (CoD)。启用后，如果您的API连接中断，它会自动取消您的活跃订单。这适用于 FIX 和 WebSocket 会话。如果您采用的策略中断连接可能会使市场上的订单不受监控，则启用 CoD 可以帮助降低风险

    必须通过 API 或在 Web 界面设置中明确启用 CoD。如果它未启用并且您的连接中断，则您的订单将保持活动状态，直到您手动取消订单、其他操作取消订单、订单已满或到期。

    有关启用和管理 CoD 的详细说明，请参阅 连接管理文章 或者 API 文档。

  • 速率限制： 虽然上面的章节没有直接介绍，但请记住 Deribit 有 API 速率限制。快速发送大量订单或取消订单等突发行为会受到限制。达到速率限制将导致您的会话中断，并可能抵消您的延迟收益。最佳做法是保持在规定的限额内，或者如果您需要更高的机构交易门槛，请联系Deribit。

  • 在测试网环境中测试： 如果您正在部署复杂的订单逻辑（如 OTOCO 或高频策略），请务必进行测试 test.deribit.com 第一。该API实际上是相同的，您可以模拟场景（包括部分成交、取消等），而不会冒实际资金的风险。这也可以确认您对 API 调用（尤其是关联订单）的理解是正确的。请参阅 测试网相关文章 了解更多详情。

通过整合上面讨论的策略和注意事项，您可以显著改善您在Deribit上的订单管理。从减少订单提交延迟到使用高级订单类型实现自动化，这些最佳实践将有助于确保您的交易高效、稳健并符合 Deribit 平台的内部运作方式