Time priority is lost. The new order executes after existing orders at the same price. 29 | 30 | **Order Amend Keep Priority** request modifies an existing order in-place.
The amended order keeps its time priority among existing orders at the same price. 31 | 32 | For example, consider the following order book: 33 | 34 | | User | Order ID | Side | Order price | quantity | 35 | | :---- | ----: | :---- | ----: | ----: | 36 | | User A | 10 | BUY | 87,000 | 1.00 | 37 | | ⭐️ YOU | 15 | BUY | 87,000 | 5.50 | 38 | | User B | 20 | BUY | 87,000 | 4.00 | 39 | | User C | 21 | BUY | 86,999 | 2.00 | 40 | 41 | Your order 15 is the second one in the queue based on price and time. 42 | 43 | You want to reduce the quantity from 5.50 down to 5.00. 44 | 45 | If you use **cancel-replace** to cancel `orderId=15` and place a new order with `qty=5.00`, the order book will look like this: 46 | 47 | | User | Order ID | Side | Order price | quantity | 48 | | :---- | ----: | :---- | ----: | ----: | 49 | | User A | 10 | BUY | 87,000 | 1.00 | 50 | | ~~⭐️ YOU~~ | ~~11~~ | ~~BUY~~ | ~~87,000~~ | ~~5.50~~ | 51 | | User B | 20 | BUY | 87,000 | 4.00 | 52 | | ⭐️ YOU | (new) 22 | BUY | 87,000 | 5.00 | 53 | | User C | 21 | BUY | 86,999 | 2.00 | 54 | 55 | Note that the new order gets a new order ID and you lose time priority: order 22 will trade after the order 20\. 56 | 57 | If instead you use **Order Amend Keep Priority** to reduce the quantity of `orderId=15` down to `qty=5.00`, the order book will look like this: 58 | 59 | | User | Order ID | Side | Order price | quantity | 60 | | :---- | ----: | :---- | ----: | ----: | 61 | | User A | 10 | BUY | 87,000 | 1.00 | 62 | | ⭐️ YOU | 15 | BUY | 87,000 | (amended) **5.00** | 63 | | User B | 20 | BUY | 87,000 | 4.00 | 64 | | User C | 21 | BUY | 86,999 | 2.00 | 65 | 66 | Note that the order ID stays the same and the order keeps its priority in the queue. Only the quantity of the order changes. 67 | 68 | ## Does Order Amend Keep Priority affect unfilled order count (rate limits)? 69 | 70 | Currently, Order Amend Keep Priority requests charge 0 for unfilled order count. 71 | 72 | ## How do I know if my order has been amended? 73 | 74 | If the order was amended successfully, the API response contains your order with the updated quantity. 75 | 76 | On User Data Stream, you will receive an `"executionReport"` event with execution type `"x": "REPLACED"`. 77 | 78 | If the amended order belongs to an order list and the client order ID has changed, you will also receive a "listStatus" event with list status type `"l": "UPDATED"`. 79 | 80 | You can also use the following requests to query order modification history: 81 | 82 | | API | Request | 83 | | :---- | :---- | 84 | | REST API | `GET /api/v3/order/amendments` | 85 | | WebSocket API | `order.amendments` | 86 | 87 | ## What happens if my amend request does not succeed? 88 | 89 | If the request fails for any reason (e.g. fails the filters, permissions, account restrictions, etc), then the order amend request is rejected and the order remains unchanged. 90 | 91 | ## Is it possible to reuse the current clientOrderId for my amended order? 92 | 93 | Yes. 94 | 95 | By default, amended orders get a random new client order ID, but you can pass the current client order ID in the `newClientOrderId` parameter if you wish to keep it. 96 | 97 | ## Can Iceberg Orders be amended? 98 | 99 | Yes. 100 | 101 | Note that an iceberg order's visible quantity will only change if `newQty` is below the pre-amended visible quantity. 102 | 103 | ## Can Order lists be amended? 104 | 105 | Orders in an order list can be amended. 106 | 107 | Note that OCO order pairs must have the same quantity, since only one of the orders can ever be executed. This means that amending either order affects both orders. 108 | 109 | For OTO orders, the working and pending orders can be amended individually. 110 | 111 | ## Which symbols allow Order Amend Keep Priority? 112 | 113 | This information is available in Exchange Information. 114 | Symbols that allow Order Amend Keep Priority requests have `amendAllowed` set to `true`. 115 | -------------------------------------------------------------------------------- /faqs/order_amend_keep_priority_CN.md: -------------------------------------------------------------------------------- 1 | # 保留优先级的修改订单请求（Order Amend Keep Priority） 常见问题 2 | 3 | **免责声明:** 4 | 5 | * 此处使用的交易对和价格是虚构的，并不反映实际交易所的设置。 6 | * 为了简化过程，本文档中的示例不包括佣金。 7 | 8 | ## 什么是 Order Amend Keep Priority？ 9 | 10 | 保留优先级的修改订单请求（Order Amend Keep Priority）用于修改（修正）现有订单并 **不失去在订单簿上的优先级**。 11 | 12 | 允许进行以下订单修改： 13 | 14 | * 减少现有订单的原始数量。 15 | 16 | ## 我该如何修改我的订单数量？ 17 | 18 | 使用以下请求： 19 | 20 | | API | 请求 | 21 | | :---- | :---- | 22 | | REST API | `PUT /api/v3/order/amend/keepPriority` | 23 | | WebSocket API | `order.amend.keepPriority` | 24 | | FIX API | OrderAmendKeepPriorityRequest `
在时间上的优先级会被丢失。 新订单在相同价格的现有订单之后执行。 29 | 30 | **留优先级的修改订单请求** 就地修改现有订单。
修改后的订单在相同价格的现有订单中保持其时间优先级。 31 | 32 | 比如，拿下面的订单簿为例： 33 | 34 | | 用户| 订单 ID | 订单方向 | 订单价格 | 数量 | 35 | | :---- | ----: | :---- | ----: | ----: | 36 | | 用户 A | 10 | BUY | 87,000 | 1.00 | 37 | | ⭐️ 你 | 15 | BUY | 87,000 | 5.50 | 38 | | 用户 B | 20 | BUY | 87,000 | 4.00 | 39 | | 用户 C | 21 | BUY | 86,999 | 2.00 | 40 | 41 | 您的订单 15 是根据价格和时间排在队列中的第二个订单。 42 | 43 | 您想将数量从 5.50 减少.50 降至 5.00。 44 | 45 | 如果您使用 **cancel-replace** 取消 `orderId=15` 并使用 `qty=5.00` 来下新订单， 订单簿将如下所示： 46 | 47 | | 用户| 订单 ID | 订单方向 | 订单价格 | 数量 | 48 | | :---- | ----: | :---- | ----: | ----: | 49 | | 用户 A | 10 | BUY | 87,000 | 1.00 | 50 | | ~~⭐️ 你~~ | ~~11~~ | ~~BUY~~ | ~~87,000~~ | ~~5.50~~ | 51 | | 用户 B | 20 | BUY | 87,000 | 4.00 | 52 | | ⭐️ 你 | (new) 22 | BUY | 87,000 | 5.00 | 53 | | 用户 C | 21 | BUY | 86,999 | 2.00 | 54 | 55 | 请注意：新订单将获得新的订单 ID，并且您会失去时间优先级：订单 22 将在订单 20 之后交易。 56 | 57 | 如果您改用 **保留优先级的修改订单请求** 将 `orderId=15` 的数量减少到 `qty=5.00`，订单簿将如下所示： 58 | 59 | | 用户| 订单 ID | 订单方向 | 订单价格 | 数量 | 60 | | :---- | ----: | :---- | ----: | ----: | 61 | | 用户 A | 10 | BUY | 87,000 | 1.00 | 62 | | ⭐️ 你 | 15 | BUY | 87,000 | (amended) **5.00** | 63 | | 用户 B | 20 | BUY | 87,000 | 4.00 | 64 | | 用户 C | 21 | BUY | 86,999 | 2.00 | 65 | 66 | 请注意：订单 ID 保持不变，订单在队列中保持其优先级。只有订单数量会发生变化。 67 | 68 | ## 保留优先级的修改订单请求是否会影响未成交订单数量（速率限制)? 69 | 70 | 目前，保留优先级的修改订单请求对未成交订单计数为 0。 71 | 72 | ## 我如何才能知道我的订单是否已被修改？ 73 | 74 | 如果订单修改成功，API 响应会包含具有新数量的订单。 75 | 76 | 在账户信息流上，您将收到执行类型为 `"x": "REPLACED"` 的 `"executionReport"` 事件。 77 | 78 | 如果修改后的订单隶属于订单列表，并且 client order ID 已被更改，您还将收到一个列表状态类型为 `"l": "UPDATED"` 的 "listStatus" 事件。 79 | 80 | 您也可以使用以下请求来查询订单修改历史： 81 | 82 | | API | 请求 | 83 | | :---- | :---- | 84 | | REST API | `GET /api/v3/order/amendments` | 85 | | WebSocket API | `order.amendments` | 86 | 87 | ## 如果我的修改请求不成功，该怎么办？ 88 | 89 | 如果请求由于任何原因失败（比如，因为过滤器，权限，帐户限制等而失败），那么订单修改请求会被拒绝，而订单将保持不变。 90 | 91 | ## 我有可能在我的修改订单请求中重用现在的 clientOrderId 么？ 92 | 93 | 没问题。 94 | 95 | 默认状态下，被修改的订单会得到一个随即生成的新 client order ID。但是，你可以通过现有的 current client order ID 赋值给 `newClientOrderId` 参数的方式来重用数据。 96 | 97 | ## 我可以对冰山订单进行修改吗？ 98 | 99 | 可以的。 100 | 101 | 请注意：只有当 `newQty` 低于未修改前的可见数量时，冰山订单的可见数量才能被改变。 102 | 103 | ## 我可以对订单列表进行修改吗？ 104 | 105 | 在订单列表中的订单是可以被修改的。 106 | 107 | 请注意：OCO 订单对必须具有相同的数量，因为只有一个订单可以执行。这意味着修改任一订单都会影响两个订单。 108 | 109 | 对于 OTO 订单，您可以对生效订单和待处理订单进行单独修改。 110 | 111 | ## 哪些交易对允许保留优先级的修改订单请求？ 112 | 113 | 相关信息可在 Exchange Information 中找到。 114 | 允许保留优先级的修改订单请求的交易对将会把 `amendAllowed` 设置为 `true`。 115 | -------------------------------------------------------------------------------- /faqs/order_count_decrement.md: -------------------------------------------------------------------------------- 1 | # Spot Unfilled Order Count Rules 2 | 3 | To ensure a fair and orderly Spot market, we limit the rate at which new orders may be placed. 4 | 5 | The rate limit applies to the number of new, *unfilled* orders placed within a time interval. That is, orders which are partially or fully filled do not count against the rate limit. 6 | 7 | > [!NOTE] 8 | > Unfilled order rate limit rewards efficient traders. 9 | > 10 | >**So long as your orders trade, you can keep trading.** 11 | > 12 | > More information: [How do filled orders affect the rate limit?](#filled-orders-rate-limit) 13 | 14 | ## What are the current rate limits? 15 | 16 | You can query current rate limits using the "exchange information" request. 17 | 18 | The `"rateLimitType": "ORDERS"` indicates the current unfilled order rate limit. 19 | 20 | Please refer to the API documentation: 21 | 22 | | API | Request | 23 | |:--------------|:-----------------------------------------------------------| 24 | | FIX API | [LimitQuery`
For example given this hypothetical timeline: 85 | * January 3024: Schema id 1 version 0 is released. This is the first version so this is usable once SBE is enabled in the exchange. 86 | * March 3024: Schema id 1 version 1 is released. This schema introduces a non-breaking change. 87 | * Schema id 1 version 0 is deprecated, but can still be used for at least another 6 months. 88 | * August 3024: Schema id 2 version 0 is released. This schema introduces a breaking change. 89 | * Schema id 1 version 0 is deprecated, but can still be used for at least another 1 month. 90 | * Schema id 1 version 1 is deprecated, but can still be used for at least another 6 months. 91 | * September 3024: 6 months have passed since the release of Schema id 1 version 1. 92 | * Schema id 1 version 0 is retired. 93 | * February 3025: Schema id 2 version 1 is released. This schema introduces a non-breaking change. 94 | * Schema id 1 version 1 is retired. 95 | * Schema id 2 version 0 is deprecated, but can still be used for at least another 6 months. 96 | * HTTP responses will contain a `X-MBX-SBE-DEPRECATED` header for requests specifying a deprecated `
Below is an example JSON based on the hypothetical timeline above: 100 | 101 | ```json 102 | { 103 | "environment": "PROD", 104 | "latestSchema": { 105 | "id": 2, 106 | "version": 1, 107 | "releaseDate": "3025-02-01" 108 | }, 109 | "deprecatedSchemas": [ 110 | { 111 | "id": 2, 112 | "version": 0, 113 | "releaseDate": "3024-08-01", 114 | "deprecatedDate": "3025-02-01" 115 | } 116 | ], 117 | "retiredSchemas": [ 118 | { 119 | "id": 1, 120 | "version": 1, 121 | "releaseDate": "3024-03-01", 122 | "deprecatedDate": "3024-08-01", 123 | "retiredDate": "3025-02-01", 124 | }, 125 | { 126 | "id": 1, 127 | "version": 0, 128 | "releaseDate": "3024-01-01", 129 | "deprecatedDate": "3024-03-01", 130 | "retiredDate": "3024-09-01", 131 | } 132 | ] 133 | } 134 | ``` 135 | 136 | ## Generate SBE decoders: 137 | 138 | 1. Download the schema: 139 | * [`spot_prod_latest.xml`](../sbe/schemas/spot_prod_latest.xml) for the live exchange. 140 | * [`spot_testnet_latest.xml`](../sbe/schemas/spot_testnet_latest.xml) for [SPOT Testnet](https://testnet.binance.vision). 141 | 2. Clone and build [`simple-binary-encoding`](https://github.com/real-logic/simple-binary-encoding): 142 | ```shell 143 | $ git clone https://github.com/real-logic/simple-binary-encoding.git 144 | $ cd simple-binary-encoding 145 | $ ./gradlew 146 | ``` 147 | 3. Run the SbeTool code generator. (Here are samples for [Java](https://github.com/binance/binance-sbe-java-sample-app), [C++](https://github.com/binance/binance-sbe-cpp-sample-app) and [Rust](https://github.com/binance/binance-sbe-rust-sample-app) decoding the payload from Exchange Information.) 148 | 149 | ### Decimal field encoding 150 | 151 | Unlike the FIX SBE specification, decimal fields have their mantissa and exponent fields encoded separately as primitive fields in order to minimize payload size and the number of encoded fields within messages. 152 | 153 | ### Timestamp field encoding 154 | 155 | Timestamps in SBE responses are in microseconds. This differs from JSON responses, which contain millisecond timestamps. 156 | 157 | ### Custom field attributes in the schema file 158 | 159 | A few field attributes prefixed with `mbx:` were added to the schema file for documentation purposes: 160 | - `mbx:exponent`: Points to the exponent field corresponding to the mantissa field 161 | - `mbx:jsonPath`: Contains the name of the equivalent field in the JSON response 162 | - `mbx:jsonValue`: Contains the name of the equivalent ENUM value in the JSON response 163 | 164 | 165 | 166 | 167 | 168 | 169 | -------------------------------------------------------------------------------- /faqs/sbe_faq_CN.md: -------------------------------------------------------------------------------- 1 | # 简单二进制编码 （SBE） 常见问题 2 | 3 | 本文档的目标是解释下列疑问: 4 | 5 | * 如何在现货交易API中启用 `SBE` 响应。 6 | * 如何对 `SBE` 的响应进行解码。 7 | 8 | SBE 是一种用于实现低延迟的序列化格式。 9 | 10 | 本实现是基于 `FIX SBE` 规范。 11 | * [GitHub repository](https://github.com/FIXTradingCommunity/fix-simple-binary-encoding) 12 | * [HTML document](https://www.fixtrading.org/standards/sbe-online) 13 | 14 | ### 如何获取 SBE 响应 15 | 16 | #### REST API 17 | 18 | * `Accept` 报文头必须包含 `application/sbe`。 19 | * 在 `X-MBX-SBE` 报文头中以 `
用以下这个假设的时间线为例: 89 | * 3024年1月：发布模式 id 1 version 0。这是第一版，一旦交易所启用 `SBE`，用户就立刻可以开始使用该模式。 90 | * 3024年3月：发布模式 id 1 version 1。这个模式引入了一个非破坏性的变化。 91 | * 模式 id 1 version 0 此时已被废止，但还可以至少再被使用6个月。 92 | * 3024年8月：发布模式 id 2 version 0。这个模式引入了一个破坏性的变化。 93 | * 模式 id 1 version 0 已被废止，但还可以再被使用至少1个月。 94 | * 模式 id 1 version 1 此时已被废止，但还可以再被使用至少6个月。 95 | * 3024年9月：自模式 id 1 version 1 发布以来已经过去6个月。 96 | * 模式 id 1 version 0 已被停用。 97 | * 3025年2月：发布模式id 2 版本 1。这个模式引入了一个非破坏性的变化。 98 | * 模式 id 1 version 1 已被停用。 99 | * 模式 id 2 version 0 此时已被废止，但还可以再被使用至少另外6个月。 100 | * HTTP将在针对 `X-MBX-SBE header` 中已被废止的 `SBE` 模式版本请求的响应中包含一个 `X-MBX-SBE-DEPRECATED` 报文头 。 101 | * 对于WebSocket响应，如果在其连接URL中指定了已弃用的`sbeSchemaId`和`sbeSchemaVersion`，`sbeSchemaIdVersionDeprecated`字段将被设置为`true`。 102 | * 指定已废止的`
以下是一个基于上述假设时间线的 `JSON` 示例： 104 | 105 | ```json 106 | { 107 | "environment": "PROD", 108 | "latestSchema": { 109 | "id": 2, 110 | "version": 1, 111 | "releaseDate": "3025-02-01" 112 | }, 113 | "deprecatedSchemas": [ 114 | { 115 | "id": 2, 116 | "version": 0, 117 | "releaseDate": "3024-08-01", 118 | "deprecatedDate": "3025-02-01" 119 | } 120 | ], 121 | "retiredSchemas": [ 122 | { 123 | "id": 1, 124 | "version": 1, 125 | "releaseDate": "3024-03-01", 126 | "deprecatedDate": "3024-08-01", 127 | "retiredDate": "3025-02-01", 128 | }, 129 | { 130 | "id": 1, 131 | "version": 0, 132 | "releaseDate": "3024-01-01", 133 | "deprecatedDate": "3024-03-01", 134 | "retiredDate": "3024-09-01", 135 | } 136 | ] 137 | } 138 | ``` 139 | 140 | ### 生成解码器： 141 | 142 | 1. 下载模式： 143 | * [`spot_prod_latest.xml`](../sbe/schemas/spot_prod_latest.xml) 适用于实时交易所。 144 | * [`spot_testnet_latest.xml`](../sbe/schemas/spot_testnet_latest.xml) 适用于 [现货测试网](https://testnet.binance.vision)。 145 | 2. 克隆并构建 [`simple-binary-encoding`](https://github.com/real-logic/simple-binary-encoding)： 146 | ```shell 147 | $ git clone https://github.com/real-logic/simple-binary-encoding.git 148 | $ cd simple-binary-encoding 149 | $ ./gradlew 150 | ``` 151 | 3. 运行 `SbeTool` 代码生成器。（请参考这里分别使用[Java](https://github.com/binance/binance-sbe-java-sample-app), [C++](https://github.com/binance/binance-sbe-cpp-sample-app) 和 [Rust](https://github.com/binance/binance-sbe-rust-sample-app) 解码交易所信息 payload 的样本。） 152 | 153 | #### 十进制字段编码 154 | 155 | 不同于 `FIX SBE` 的规范，十进制字段的尾数和指数字段被单独编码为原始字段，以便使负载量和消息内编码字段的数量达到最小化。 156 | 157 | #### 时间戳字段编码 158 | 159 | SBE响应中的时间戳(Timestamps)是以微秒为单位。这与包含毫秒时间戳的JSON响应不同。 160 | 161 | #### 模式文件中的自定义字段属性 162 | 163 | 在模式文件中添加了一些以 `mbx:` 为前缀的字段属性，供文档使用： 164 | - `mbx:exponent`：指向对应于尾数字段的指数域 165 | - `mbx:jsonPath`：包含了 `JSON` 响应中相应字段的名称 166 | - `mbx:jsonValue`: 包含了 `JSON` 响应中等价 `ENUM` 值的名称 167 | -------------------------------------------------------------------------------- /faqs/sor_faq.md: -------------------------------------------------------------------------------- 1 | # Smart Order Routing (SOR) 2 | 3 | **Disclaimer:** 4 | 5 | * The symbols and values used here are fictional, and do not imply anything about the actual setup on the live exchange. 6 | * For simplicity, the examples in this document do not include commission. 7 | 8 | ## What is Smart Order Routing (SOR)? 9 | 10 | **Smart Order Routing (SOR)** allows you to potentially get better liquidity by filling an order with liquidity from other order books with the same base asset and interchangeable quote assets. **Interchangeable quote assets** are quote assets with fixed 1 to 1 exchange rate, such as stablecoins pegged to the same fiat currency. 11 | 12 | Note that even though the quote assets are interchangeable, when selling the base asset you will always receive the quote asset of the symbol in your order. 13 | 14 | When you place an order using SOR, it goes through the eligible order books, looks for best price levels for each order book in that SOR configuration, and takes from those books if possible. 15 | 16 | **Note:** If the order using SOR cannot fully fill based on the eligible order books' liquidity, `LIMIT IOC` or `MARKET` orders will immediately expire, while `LIMIT GTC` orders will place the remaining quantity on the order book you originally submitted the order to. 17 | 18 | ### Example 1 19 | 20 | Let's consider a SOR configuration containing the symbols `BTCUSDT`, `BTCUSDC` and `BTCUSDP`, and the following `ASK` (`SELL` side) order books for those symbols: 21 | 22 | ``` 23 | BTCUSDT quantity 3 price 30,800 24 | BTCUSDT quantity 3 price 30,500 25 | 26 | BTCUSDC quantity 1 price 30,000 27 | BTCUSDC quantity 1 price 28,000 28 | 29 | BTCUSDP quantity 1 price 35,000 30 | BTCUSDP quantity 1 price 29,000 31 | ``` 32 | 33 | If you send a `LIMIT GTC BUY` order for `BTCUSDT` with `quantity=0.5` and `price=31000`, you would match with the best SELL price on the BTCUSDT book at 30,500. You would spend 15,250 USDT and receive 0.5 BTC. 34 | 35 | If you send a `LIMIT GTC BUY` order _using SOR_ for `BTCUSDT` with `quantity=0.5` and `price=31000`, you would match with the best SELL price across _all symbols in the SOR_, which is BTCUSDC at price 28,000. You would spend 14,000 USDT (_not_ USDC!) and receive 0.5 BTC. 36 | 37 | ```javascript 38 | { 39 | "symbol": "BTCUSDT", 40 | "orderId": 2, 41 | "orderListId": -1, 42 | "clientOrderId": "sBI1KM6nNtOfj5tccZSKly", 43 | "transactTime": 1689149087774, 44 | "price": "31000.00000000", 45 | "origQty": "0.50000000", 46 | "executedQty": "0.50000000", 47 | "cummulativeQuoteQty": "14000.00000000", 48 | "status": "FILLED", 49 | "timeInForce": "GTC", 50 | "type": "LIMIT", 51 | "side": "BUY", 52 | "workingTime": 1689149087774, 53 | "fills": [ 54 | { 55 | "matchType": "ONE_PARTY_TRADE_REPORT", 56 | "price": "28000.00000000", 57 | "qty": "0.50000000", 58 | "commission": "0.00000000", 59 | "commissionAsset": "BTC", 60 | "tradeId": -1, 61 | "allocId": 0 62 | } 63 | ], 64 | "workingFloor": "SOR", 65 | "selfTradePreventionMode": "NONE", 66 | "usedSor": true 67 | } 68 | ``` 69 | 70 | ### Example 2 71 | 72 | Using the same order book as Example 1: 73 | 74 | ``` 75 | BTCUSDT quantity 3 price 30,800 76 | BTCUSDT quantity 3 price 30,500 77 | 78 | BTCUSDC quantity 1 price 30,000 79 | BTCUSDC quantity 1 price 28,000 80 | 81 | BTCUSDP quantity 1 price 35,000 82 | BTCUSDP quantity 1 price 29,000 83 | ``` 84 | 85 | If you send a `LIMIT GTC BUY` order for `BTCUSDT` with `quantity=5` and `price=31000`, you would: 86 | 87 | * match with the 3 BTCUSDT at 30,500, and buy 3 BTC for 91,500 USDT 88 | * then match with the 3 BTCUSDT at 30,800, and buy 2 BTC for 61,600 USDT 89 | 90 | In total, you spend 153,100 USDT and receive 5 BTC. 91 | 92 | If you send the same `LIMIT GTC BUY` order _using SOR_ for `BTCUSDT` with `quantity=5` and `price=31000`, you would: 93 | 94 | * match with 1 BTCUSDC at 28,000, and buy 1 BTC for 28,000 USDT 95 | * match with 1 BTCUSDP at 29,000, and buy 1 BTC for 29,000 USDT 96 | * match with 1 BTCUSDC at 30,000, and buy 1 BTC for 30,000 USDT 97 | * match with 3 BTCUSDT at 30,500, and buy 2 BTC for 61,000 USDT 98 | 99 | In total, you spend 148,000 USDT and receive 5 BTC. 100 | 101 | ```javascript 102 | { 103 | "symbol": "BTCUSDT", 104 | "orderId": 2, 105 | "orderListId": -1, 106 | "clientOrderId": "tHonoNjWfOSaKiTygN3bfY", 107 | "transactTime": 1689146154686, 108 | "price": "31000.00000000", 109 | "origQty": "5.00000000", 110 | "executedQty": "5.00000000", 111 | "cummulativeQuoteQty": "148000.00000000", 112 | "status": "FILLED", 113 | "timeInForce": "GTC", 114 | "type": "LIMIT", 115 | "side": "BUY", 116 | "workingTime": 1689146154686, 117 | "fills": [ 118 | { 119 | "matchType": "ONE_PARTY_TRADE_REPORT", 120 | "price": "28000.00000000", 121 | "qty": "1.00000000", 122 | "commission": "0.00000000", 123 | "commissionAsset": "BTC", 124 | "tradeId": -1, 125 | "allocId": 0 126 | }, 127 | { 128 | "matchType": "ONE_PARTY_TRADE_REPORT", 129 | "price": "29000.00000000", 130 | "qty": "1.00000000", 131 | "commission": "0.00000000", 132 | "commissionAsset": "BTC", 133 | "tradeId": -1, 134 | "allocId": 1 135 | }, 136 | { 137 | "matchType": "ONE_PARTY_TRADE_REPORT", 138 | "price": "30000.00000000", 139 | "qty": "1.00000000", 140 | "commission": "0.00000000", 141 | "commissionAsset": "BTC", 142 | "tradeId": -1, 143 | "allocId": 2 144 | }, 145 | { 146 | "matchType": "ONE_PARTY_TRADE_REPORT", 147 | "price": "30500.00000000", 148 | "qty": "2.00000000", 149 | "commission": "0.00000000", 150 | "commissionAsset": "BTC", 151 | "tradeId": -1, 152 | "allocId": 3 153 | } 154 | ], 155 | "workingFloor": "SOR", 156 | "selfTradePreventionMode": "NONE", 157 | "usedSor": true 158 | } 159 | ``` 160 | 161 | ### Example 3 162 | 163 | Using the same order book as Example 1 and 2: 164 | 165 | ``` 166 | BTCUSDT quantity 3 price 30,800 167 | BTCUSDT quantity 3 price 30,500 168 | 169 | BTCUSDC quantity 1 price 30,000 170 | BTCUSDC quantity 1 price 28,000 171 | 172 | BTCUSDP quantity 1 price 35,000 173 | BTCUSDP quantity 1 price 29,000 174 | ``` 175 | 176 | If you send a `MARKET BUY` order for `BTCUSDT` _using SOR_ with `quantity=11`, there is only 10 BTC in total available across all eligible order books. Once all the order books in SOR configuration have been exhausted, the remaining quantity of 1 expires. 177 | 178 | ```javascript 179 | { 180 | "symbol": "BTCUSDT", 181 | "orderId": 2, 182 | "orderListId": -1, 183 | "clientOrderId": "jdFYWTNyzplbNvVJEzQa0o", 184 | "transactTime": 1689149513461, 185 | "price": "0.00000000", 186 | "origQty": "11.00000000", 187 | "executedQty": "10.00000000", 188 | "cummulativeQuoteQty": "305900.00000000", 189 | "status": "EXPIRED", 190 | "timeInForce": "GTC", 191 | "type": "MARKET", 192 | "side": "BUY", 193 | "workingTime": 1689149513461, 194 | "fills": [ 195 | { 196 | "matchType": "ONE_PARTY_TRADE_REPORT", 197 | "price": "28000.00000000", 198 | "qty": "1.00000000", 199 | "commission": "0.00000000", 200 | "commissionAsset": "BTC", 201 | "tradeId": -1, 202 | "allocId": 0 203 | }, 204 | { 205 | "matchType": "ONE_PARTY_TRADE_REPORT", 206 | "price": "29000.00000000", 207 | "qty": "1.00000000", 208 | "commission": "0.00000000", 209 | "commissionAsset": "BTC", 210 | "tradeId": -1, 211 | "allocId": 1 212 | }, 213 | { 214 | "matchType": "ONE_PARTY_TRADE_REPORT", 215 | "price": "30000.00000000", 216 | "qty": "1.00000000", 217 | "commission": "0.00000000", 218 | "commissionAsset": "BTC", 219 | "tradeId": -1, 220 | "allocId": 2 221 | }, 222 | { 223 | "matchType": "ONE_PARTY_TRADE_REPORT", 224 | "price": "30500.00000000", 225 | "qty": "3.00000000", 226 | "commission": "0.00000000", 227 | "commissionAsset": "BTC", 228 | "tradeId": -1, 229 | "allocId": 3 230 | }, 231 | { 232 | "matchType": "ONE_PARTY_TRADE_REPORT", 233 | "price": "30800.00000000", 234 | "qty": "3.00000000", 235 | "commission": "0.00000000", 236 | "commissionAsset": "BTC", 237 | "tradeId": -1, 238 | "allocId": 4 239 | }, 240 | { 241 | "matchType": "ONE_PARTY_TRADE_REPORT", 242 | "price": "35000.00000000", 243 | "qty": "1.00000000", 244 | "commission": "0.00000000", 245 | "commissionAsset": "BTC", 246 | "tradeId": -1, 247 | "allocId": 5 248 | } 249 | ], 250 | "workingFloor": "SOR", 251 | "selfTradePreventionMode": "NONE", 252 | "usedSor": true 253 | } 254 | ``` 255 | 256 | ### Example 4 257 | 258 | Let's consider a SOR configuration containing the symbols `BTCUSDT`, `BTCUSDC` and `BTCUSDP` and the following `BID` (`BUY` side) order book for those symbols: 259 | 260 | ``` 261 | BTCUSDT quantity 5 price 29,500 262 | 263 | BTCUSDC quantity 5 price 35,000 264 | BTCUSDC quantity 5 price 30,000 265 | 266 | BTCUSDP quantity 5 price 28,000 267 | ``` 268 | 269 | If you send a `LIMIT GTC SELL` order for `BTCUSDT` with `price=29000` and `quantity=10`, you would sell 5 BTC and receive 147,500 USDT. Since there is no better price available on the BTCUSDT book, the remaining (unfilled) quantity of the order will rest there at the price of 29,000. 270 | 271 | If you send a `LIMIT GTC SELL` order _using SOR_ for `BTCUSDT`, you would: 272 | 273 | * match with 5 BTCUSDC at 35,000 and sell 5 BTC for 175,000 USDT 274 | * match with 5 BTCUSDC at 30,000 and sell 5 BTC for 150,000 USDT 275 | 276 | In total, you sell 10 BTC and receive 325,000 USDT. 277 | 278 | ```javascript 279 | { 280 | "symbol": "BTCUSDT", 281 | "orderId": 1, 282 | "orderListId": -1, 283 | "clientOrderId": "W1iXSng1fS77dvanQJDGA5", 284 | "transactTime": 1689147920113, 285 | "price": "29000.00000000", 286 | "origQty": "10.00000000", 287 | "executedQty": "10.00000000", 288 | "cummulativeQuoteQty": "325000.00000000", 289 | "status": "FILLED", 290 | "timeInForce": "GTC", 291 | "type": "LIMIT", 292 | "side": "SELL", 293 | "workingTime": 1689147920113, 294 | "fills": [ 295 | { 296 | "matchType": "ONE_PARTY_TRADE_REPORT", 297 | "price": "35000.00000000", 298 | "qty": "5.00000000", 299 | "commission": "0.00000000", 300 | "commissionAsset": "USDT", 301 | "tradeId": -1, 302 | "allocId": 0 303 | }, 304 | { 305 | "matchType": "ONE_PARTY_TRADE_REPORT", 306 | "price": "30000.00000000", 307 | "qty": "5.00000000", 308 | "commission": "0.00000000", 309 | "commissionAsset": "USDT", 310 | "tradeId": -1, 311 | "allocId": 1 312 | } 313 | ], 314 | "workingFloor": "SOR", 315 | "selfTradePreventionMode": "NONE", 316 | "usedSor": true 317 | } 318 | ``` 319 | 320 | **Summary: The goal of SOR is to potentially access better liquidity across order books with interchangeable quote assets. Better liquidity access can fill orders more fully and at better prices during an order's taker phase.** 321 | 322 | ## What symbols support SOR? 323 | 324 | You can find the current SOR configuration in Exchange Information (`GET /api/v3/exchangeInfo` for Rest, and `exchangeInfo` on Websocket API). 325 | 326 | ```json 327 | "sors": [ 328 | { 329 | "baseAsset": "BTC", 330 | "symbols": [ 331 | "BTCUSDT", 332 | "BTCUSDC", 333 | "BTCUSDP" 334 | ] 335 | } 336 | ] 337 | ``` 338 | 339 | The `sors` field is optional. 340 | It is omitted in responses if SOR is not available. 341 | 342 | ## How do I place an order using SOR? 343 | 344 | On the Rest API, the request is `POST /api/v3/sor/order`. 345 | 346 | On the WebSocket API, the request is `sor.order.place`. 347 | 348 | ## In the API response, there's a field called `workingFloor`. What does that field mean? 349 | 350 | This is a term used to determine where the order's last activity occurred (filling, expiring, or being placed as new, etc.). 351 | 352 | If the `workingFloor` is `SOR`, this means your order interacted with other eligible order books in the SOR configuration. 353 | 354 | If the `workingFloor` is `EXCHANGE`, this means your order interacted on the order book that you sent that order to. 355 | 356 | ## In the API response, `fills` contain fields `matchType` and `allocId`. What do they mean? 357 | 358 | `matchType` field indicates a non-standard order fill. 359 | 360 | When your order is filled by SOR, you will see `matchType: ONE_PARTY_TRADE_REPORT`, indicating that you did not trade directly on the exchange (`tradeId: -1`). Instead your order is filled by _allocations_. 361 | 362 | `allocId` field identifies the allocation so that you can query it later. 363 | 364 | ## What are allocations? 365 | 366 | **An allocation** is a transfer of an asset from the exchange to your account. For example, when SOR takes liquidity from eligible order books, your order is filled by allocations. In this case you don't trade directly, but rather receive allocations from SOR corresponding to the trades made by SOR on your behalf. 367 | 368 | ```javascript 369 | [ 370 | { 371 | "symbol": "BTCUSDT", // Symbol the order was submitted to 372 | "allocationId": 0, 373 | "allocationType": "SOR", 374 | "orderId": 2, 375 | "orderListId": -1, 376 | "price": "30000.00000000", // Price of the fill 377 | "qty": "5.00000000", // Quantity of the fill 378 | "quoteQty": "150000.00000000", 379 | "commission": "0.00000000", 380 | "commissionAsset": "BTC", 381 | "time": 1688379272280, // Time the allocation occurred 382 | "isBuyer": true, 383 | "isMaker": false, 384 | "isAllocator": false 385 | } 386 | ] 387 | ``` 388 | 389 | ## How do I query orders that used SOR? 390 | 391 | You can find them the same way you query any other order. The main difference is that in the response for an order that used SOR there are two extra fields: `usedSor` and `workingFloor`. 392 | 393 | 394 | ## How do I get details of my fills for orders that used SOR? 395 | 396 | When SOR orders trade against order books other than the symbol submitted with the order, the order is filled with an **allocation** and not a trade. Orders placed with SOR can potentially have both allocations and trades. 397 | 398 | In the API response, you can review the `fills` fields. Allocations have an `allocId` and `"matchType": "ONE_PARTY_TRADE_REPORT"`, while trades will have a non-negative `tradeId`. 399 | 400 | Allocations can be queried using `GET /api/v3/myAllocations` (Rest API) or `myAllocations` (WebSocket API). 401 | 402 | Trades can be queried using `GET /api/v3/myTrades` (Rest API) or `myTrades` (WebSocket API). 403 | -------------------------------------------------------------------------------- /faqs/sor_faq_CN.md: -------------------------------------------------------------------------------- 1 | # 智能指令路由 (SOR) 2 | 3 | **声明:** 4 | 5 | * 这里使用的符号和数值是虚构的，并不意味着真实交易所中的设置。 6 | * 为简单起见，本文档中的示例不包括佣金。 7 | 8 | ## 什么是智能指令路由 (SOR)? 9 | 10 | **智能订单路由**（Smart Order Routing，简称SOR）允许客户通过使用具有相同基础资产(`base asset `)和可互换报价资产(`interchangeable quote assets`)的其他订单簿(order books)中的流动性来潜在获得更好的流动性。可互换报价资产是具有固定的1比1兑换率的报价资产，例如与同一法定货币挂钩的稳定币。 11 | 12 | 请注意，尽管报价资产(quote assets)是可互换的，但在出售基础资产(base asset)时，您将始终收到订单中交易对(symbol)对应的报价资产(quote asset)。 13 | 14 | 当您使用`SOR`下单时，它会在SOR配置的订单簿(order books)里，寻找每个订单簿的最佳价格水平，并在可能的情况下从中交易。 15 | 16 | **注意：** 如果使用SOR的订单无法根据符合条件的订单簿流动性完全成交，IOC限价单(`LIMIT IOC`)或市价单(`MARKET`)将立即过期，而GTC限价单(`LIMIT GTC`)将把剩余数量放置在您最初提交订单的订单簿(order book)上。 17 | 18 | 示例 1: 19 | 20 | 让我们考虑一个包含交易对`BTCUSDT`，`BTCUSDC`和`BTCUSDP`的SOR配置，并给出以下这些符号的卖出(`ASK`)方向的订单簿: 21 | 22 | ``` 23 | BTCUSDT quantity 3 price 30,800 24 | BTCUSDT quantity 3 price 30,500 25 | 26 | BTCUSDC quantity 1 price 30,000 27 | BTCUSDC quantity 1 price 28,000 28 | 29 | BTCUSDP quantity 1 price 35,000 30 | BTCUSDP quantity 1 price 29,000 31 | ``` 32 | 33 | 如果您以价格为31000、数量为0.5的限价挂单买入`BTCUSDT`，并且在`BTCUSDT`的订单簿中找到最佳的卖出价格为30,500 USDT，您将花费15,250 USDT 并收到0.5 BTC。 34 | 35 | 如果您通过使用SOR下达了一笔GTC限价买单(`LIMIT GTC BUY`)，购买`BTCUSDT`，数量为 0.5，价格为 31000，您将与SOR涵盖的所有交易对中最佳的卖出价格相匹配，即`BTCUSDC`，价格为 28,000。您将花费 14,000 USDT（不是 USDC！），并收到 0.5 BTC。 36 | 37 | ```javascript 38 | { 39 | "symbol": "BTCUSDT", 40 | "orderId": 2, 41 | "orderListId": -1, 42 | "clientOrderId": "sBI1KM6nNtOfj5tccZSKly", 43 | "transactTime": 1689149087774, 44 | "price": "31000.00000000", 45 | "origQty": "0.50000000", 46 | "executedQty": "0.50000000", 47 | "cummulativeQuoteQty": "14000.00000000", 48 | "status": "FILLED", 49 | "timeInForce": "GTC", 50 | "type": "LIMIT", 51 | "side": "BUY", 52 | "workingTime": 1689149087774, 53 | "fills": [ 54 | { 55 | "matchType": "ONE_PARTY_TRADE_REPORT", 56 | "price": "28000.00000000", 57 | "qty": "0.50000000", 58 | "commission": "0.00000000", 59 | "commissionAsset": "BTC", 60 | "tradeId": -1, 61 | "allocId": 0 62 | } 63 | ], 64 | "workingFloor": "SOR", 65 | "selfTradePreventionMode": "NONE", 66 | "usedSor": true 67 | } 68 | ``` 69 | 70 | 示例 2: 71 | 72 | 使用示例1中同样的订单薄: 73 | 74 | ``` 75 | BTCUSDT quantity 3 price 30,800 76 | BTCUSDT quantity 3 price 30,500 77 | 78 | BTCUSDC quantity 1 price 30,000 79 | BTCUSDC quantity 1 price 28,000 80 | 81 | BTCUSDP quantity 1 price 35,000 82 | BTCUSDP quantity 1 price 29,000 83 | ``` 84 | 85 | 如果您下达一笔GTC限价买单(`LIMIT GTC BUY`)购买`BTCUSDT`，数量为 5，价格为 31,000，则： 86 | 87 | * 与 `BTCUSDT` 订单簿中价格为 30,500 USDT 的 3 个 `BTCUSDT` 成交，以 91,500 USDT 的价格购买 3 个 BTC。 88 | * 然后与 `BTCUSDT` 订单簿中价格为 30,800 USDT 的 3 个 `BTCUSDT` 成交，以 61,600 USDT 的价格购买 2 个 BTC。 89 | 90 | 总计您花费了 153,100 USDT 并获得了 5 BTC。 91 | 92 | 如果您通过使用SOR下达相同的GTC限价买单(`LIMIT GTC BUY`)购买 `BTCUSDT`，数量为 5，价格为 31,000，则： 93 | 94 | * 与 `BTCUSDC` 订单簿中价格为 28,000 的 1 个 BTCUSDC 成交，以 28,000 USDT 的价格购买 1 个 BTC。 95 | * 与 `BTCUSDP` 订单簿中价格为 29,000 的 1 个 BTCUSDP 成交，以 29,000 USDT 的价格购买 1 个 BTC。 96 | * 与 `BTCUSDC` 订单簿中价格为 30,000 的 1 个 BTCUSDC 成交，以 30,000 USDT 的价格购买 1 个 BTC。 97 | * 与 `BTCUSDT` 订单簿中价格为 30,500 的 3 个 BTCUSDT 成交，以 61,000 USDT 的价格购买 2 个 BTC。 98 | 99 | 总计您花费了 148,000 USDT 并获得了 5 BTC。 100 | 101 | ```javascript 102 | { 103 | "symbol": "BTCUSDT", 104 | "orderId": 2, 105 | "orderListId": -1, 106 | "clientOrderId": "tHonoNjWfOSaKiTygN3bfY", 107 | "transactTime": 1689146154686, 108 | "price": "31000.00000000", 109 | "origQty": "5.00000000", 110 | "executedQty": "5.00000000", 111 | "cummulativeQuoteQty": "148000.00000000", 112 | "status": "FILLED", 113 | "timeInForce": "GTC", 114 | "type": "LIMIT", 115 | "side": "BUY", 116 | "workingTime": 1689146154686, 117 | "fills": [ 118 | { 119 | "matchType": "ONE_PARTY_TRADE_REPORT", 120 | "price": "28000.00000000", 121 | "qty": "1.00000000", 122 | "commission": "0.00000000", 123 | "commissionAsset": "BTC", 124 | "tradeId": -1, 125 | "allocId": 0 126 | }, 127 | { 128 | "matchType": "ONE_PARTY_TRADE_REPORT", 129 | "price": "29000.00000000", 130 | "qty": "1.00000000", 131 | "commission": "0.00000000", 132 | "commissionAsset": "BTC", 133 | "tradeId": -1, 134 | "allocId": 1 135 | }, 136 | { 137 | "matchType": "ONE_PARTY_TRADE_REPORT", 138 | "price": "30000.00000000", 139 | "qty": "1.00000000", 140 | "commission": "0.00000000", 141 | "commissionAsset": "BTC", 142 | "tradeId": -1, 143 | "allocId": 2 144 | }, 145 | { 146 | "matchType": "ONE_PARTY_TRADE_REPORT", 147 | "price": "30500.00000000", 148 | "qty": "2.00000000", 149 | "commission": "0.00000000", 150 | "commissionAsset": "BTC", 151 | "tradeId": -1, 152 | "allocId": 3 153 | } 154 | ], 155 | "workingFloor": "SOR", 156 | "selfTradePreventionMode": "NONE", 157 | "usedSor": true 158 | } 159 | ``` 160 | 161 | 示例 3: 162 | 163 | 使用示例1和2中同样的订单薄: 164 | 165 | ``` 166 | BTCUSDT quantity 3 price 30,800 167 | BTCUSDT quantity 3 price 30,500 168 | 169 | BTCUSDC quantity 1 price 30,000 170 | BTCUSDC quantity 1 price 28,000 171 | 172 | BTCUSDP quantity 1 price 35,000 173 | BTCUSDP quantity 1 price 29,000 174 | ``` 175 | 176 | 如果您通过使用SOR下市价买单(`MARKET` `BUY`) 购买 `BTCUSDT`，数量为 11，但在所有符合条件的订单簿中总共只有 10 个BTC可供交易。一旦所有SOR配置中的订单簿都耗尽了，剩余的数量1将过期。 177 | 178 | ```javascript 179 | { 180 | "symbol": "BTCUSDT", 181 | "orderId": 2, 182 | "orderListId": -1, 183 | "clientOrderId": "jdFYWTNyzplbNvVJEzQa0o", 184 | "transactTime": 1689149513461, 185 | "price": "0.00000000", 186 | "origQty": "11.00000000", 187 | "executedQty": "10.00000000", 188 | "cummulativeQuoteQty": "305900.00000000", 189 | "status": "EXPIRED", 190 | "timeInForce": "GTC", 191 | "type": "MARKET", 192 | "side": "BUY", 193 | "workingTime": 1689149513461, 194 | "fills": [ 195 | { 196 | "matchType": "ONE_PARTY_TRADE_REPORT", 197 | "price": "28000.00000000", 198 | "qty": "1.00000000", 199 | "commission": "0.00000000", 200 | "commissionAsset": "BTC", 201 | "tradeId": -1, 202 | "allocId": 0 203 | }, 204 | { 205 | "matchType": "ONE_PARTY_TRADE_REPORT", 206 | "price": "29000.00000000", 207 | "qty": "1.00000000", 208 | "commission": "0.00000000", 209 | "commissionAsset": "BTC", 210 | "tradeId": -1, 211 | "allocId": 1 212 | }, 213 | { 214 | "matchType": "ONE_PARTY_TRADE_REPORT", 215 | "price": "30000.00000000", 216 | "qty": "1.00000000", 217 | "commission": "0.00000000", 218 | "commissionAsset": "BTC", 219 | "tradeId": -1, 220 | "allocId": 2 221 | }, 222 | { 223 | "matchType": "ONE_PARTY_TRADE_REPORT", 224 | "price": "30500.00000000", 225 | "qty": "3.00000000", 226 | "commission": "0.00000000", 227 | "commissionAsset": "BTC", 228 | "tradeId": -1, 229 | "allocId": 3 230 | }, 231 | { 232 | "matchType": "ONE_PARTY_TRADE_REPORT", 233 | "price": "30800.00000000", 234 | "qty": "3.00000000", 235 | "commission": "0.00000000", 236 | "commissionAsset": "BTC", 237 | "tradeId": -1, 238 | "allocId": 4 239 | }, 240 | { 241 | "matchType": "ONE_PARTY_TRADE_REPORT", 242 | "price": "35000.00000000", 243 | "qty": "1.00000000", 244 | "commission": "0.00000000", 245 | "commissionAsset": "BTC", 246 | "tradeId": -1, 247 | "allocId": 5 248 | } 249 | ], 250 | "workingFloor": "SOR", 251 | "selfTradePreventionMode": "NONE", 252 | "usedSor": true 253 | } 254 | ``` 255 | 256 | 示例 4: 257 | 258 | 假设有一个包含 `BTCUSDT`, `BTCUSDC` 和 `BTCUSDP` 交易对的SOR配置, 以及下面这些交易对买方(`BID`)的订单簿： 259 | 260 | ``` 261 | BTCUSDT quantity 5 price 29,500 262 | 263 | BTCUSDC quantity 5 price 35,000 264 | BTCUSDC quantity 5 price 30,000 265 | 266 | BTCUSDP quantity 5 price 28,000 267 | ``` 268 | 269 | 如果您在`BTCUSDT`下一笔GTC限价卖单(`LIMIT GTC SELL`) 订单，价格是29000, 卖出10 BTC，那么您将卖出 5 个 BTC 并获得 147,500 USDT。由于`BTCUSDT`订单簿上没有更好的价格可用，订单的剩余（未成交）数量将会以29,000的价格保持在订单簿上。 270 | 271 | 如果您通过使用SOR下GTC限价卖单(`LIMIT GTC SELL`) 卖出 `BTCUSDT`，则会： 272 | 273 | * 与 `BTCUSDC` 订单簿中价格为 35,000 的 5 个 BTCUSDC 成交，以 175,000 USDT 的价格出售 5 个 BTC。 274 | * 与 `BTCUSDC` 订单簿中价格为 30,000 的 5 个 BTCUSDC 成交，以 150,000 USDT 的价格出售 5 个 BTC。 275 | 276 | 总计您卖出 10 个 BTC 并获得 325,000 USDT。 277 | 278 | ```javascript 279 | { 280 | "symbol": "BTCUSDT", 281 | "orderId": 1, 282 | "orderListId": -1, 283 | "clientOrderId": "W1iXSng1fS77dvanQJDGA5", 284 | "transactTime": 1689147920113, 285 | "price": "29000.00000000", 286 | "origQty": "10.00000000", 287 | "executedQty": "10.00000000", 288 | "cummulativeQuoteQty": "325000.00000000", 289 | "status": "FILLED", 290 | "timeInForce": "GTC", 291 | "type": "LIMIT", 292 | "side": "SELL", 293 | "workingTime": 1689147920113, 294 | "fills": [ 295 | { 296 | "matchType": "ONE_PARTY_TRADE_REPORT", 297 | "price": "35000.00000000", 298 | "qty": "5.00000000", 299 | "commission": "0.00000000", 300 | "commissionAsset": "USDT", 301 | "tradeId": -1, 302 | "allocId": 0 303 | }, 304 | { 305 | "matchType": "ONE_PARTY_TRADE_REPORT", 306 | "price": "30000.00000000", 307 | "qty": "5.00000000", 308 | "commission": "0.00000000", 309 | "commissionAsset": "USDT", 310 | "tradeId": -1, 311 | "allocId": 1 312 | } 313 | ], 314 | "workingFloor": "SOR", 315 | "selfTradePreventionMode": "NONE", 316 | "usedSor": true 317 | } 318 | ``` 319 | 320 | **概要：SOR的目标是潜在地在具有可互换报价资产(`interchangeable quote assets`)的订单簿之间获得更好的流动性。更好的流动性可以使订单以更好的价格，并更充分成交。** 321 | 322 | ## 什么交易对支持SOR? 323 | 324 | 当前SOR配置可以在交易所信息接口查询(Restful接口`GET /api/v3/exchangeInfo`, Websocket API的 `exchangeInfo`). 325 | 326 | ```json 327 | "sors": [ 328 | { 329 | "baseAsset": "BTC", 330 | "symbols": [ 331 | "BTCUSDT", 332 | "BTCUSDC", 333 | "BTCUSDP" 334 | ] 335 | } 336 | ] 337 | ``` 338 | 339 | `sors` 字段是可选的。 340 | 如果 SOR 不可用， 该字段在响应中会被忽略。 341 | 342 | ## 如何下SOR订单? 343 | 344 | 通过Rest API接口 `POST /api/v3/sor/order`. 345 | 346 | 通过WebSocket API接口 `sor.order.place`. 347 | 348 | ## 在API响应里, 有个字段workingFloor是什么意思? 349 | 350 | 这是一个用于确定订单的最后更新操作（成交、过期或作为新订单下达等）的术语。 351 | 352 | 如果 workingFloor 是 SOR，这表示您的订单与SOR配置中的其他符合条件的订单簿进行了交互。 353 | 354 | 如果 workingFloor 是 EXCHANGE，这表示您的订单在您发送该订单的订单簿上进行了交互。 355 | 356 | ## 如果查询订单是否使用过SOR? 357 | 358 | 您可以像查询任何其他订单一样来查询。主要的区别是对于使用SOR的订单，在响应中会有两个额外的字段：`usedSor` 和 `workingFloor`。 359 | 360 | ## 什么是资产分配? 361 | 362 | **资产分配**是从交易所转移资产到您的账户。例如，当SOR从符合条件的订单簿中获取流动性时，您的订单将通过资产分配来填充。在这种情况下，您不直接进行交易，而是通过SOR代表您进行交易，并接收对应于SOR为您进行的交易的资产分配。 363 | 364 | ```javascript 365 | [ 366 | { 367 | "symbol": "BTCUSDT", // Symbol the order was submitted to 368 | "allocationId": 0, 369 | "allocationType": "SOR", 370 | "orderId": 2, 371 | "orderListId": -1, 372 | "price": "30000.00000000", // Price of the fill 373 | "qty": "5.00000000", // Quantity of the fill 374 | "quoteQty": "150000.00000000", 375 | "commission": "0.00000000", 376 | "commissionAsset": "BTC", 377 | "time": 1688379272280, // Time the allocation occurred 378 | "isBuyer": true, 379 | "isMaker": false, 380 | "isAllocator": false 381 | } 382 | ] 383 | ```` 384 | 385 | ## 如何获取使用SOR的订单成交细节？ 386 | 387 | 当SOR订单与非提交订单的订单簿进行交易时，订单将通过资产分配（allocation）而不是交易(trade)来成交。使用SOR下达的订单可能同时拥有资产分配和交易。 388 | 389 | 在API响应中，您可以查看`fills`字段。资产分配具有`allocId`和`matchType`: "ONE_PARTY_TRADE_REPORT"，而交易将具有非负的`tradeId`。 390 | 391 | 您可以使用以下方式查询资产分配和交易： 392 | 393 | 查询资产分配：使用Rest API接口 `GET /api/v3/myAllocations` 或 WebSocket API 的 `myAllocations`。 394 | 395 | 查询交易：使用Rest API接口 `GET /api/v3/myTrades` 或 WebSocket API 的 `myTrades`。 396 | 397 | ## 什么交易对支持SOR? 398 | 399 | 当前SOR配置可以在交易所信息接口查询(Rest API接口`GET /api/v3/exchangeInfo`, WebSocket API的 `exchangeInfo`). 400 | 401 | ```json 402 | "sors": [ 403 | { 404 | "baseAsset": "BTC", 405 | "symbols": [ 406 | "BTCUSDT", 407 | "BTCUSDC", 408 | "BTCUSDP" 409 | ] 410 | } 411 | ] 412 | ``` 413 | 414 | 415 | -------------------------------------------------------------------------------- /faqs/spot_glossary_CN.md: -------------------------------------------------------------------------------- 1 | # 现货交易API术语表 2 | 3 | **声明:** 此术语表只适用现货交易（`SPOT`）；用于合约、期权或者其他币安API相应的术语可能有不一样的表达。 4 | 5 | ### A 6 | 7 | `ACK` 8 | * `newOrderRespType` 的枚举值，设置时下单的返回值只包括下面的字段: `symbol`，`orderId`，`orderListId`，`clientOrderId` 和 `transactTime`。 9 | 10 | `aggTrade` 11 | * 归集交易信息；此交易信息归集了在同一个时间同一个 `taker` 的订单生成的相同价格的交易信息。 12 | 13 | allocation 14 | * 在这里，分配指的是将资产从交易所转移到个人账户的过程（e.g. 当一个订单通过 SOR 成交而不是直接交易）。 15 | 16 | `allocationId` 17 | * 此字段是一个唯一识别码，用来标识针对某个交易对上进行的分配（allocation）。 18 | 19 | `allocationType` 20 | * 参考 [ 分配类型 ](../enums_CN.md#allocationtype) 21 | 22 | `askPrice` 23 | * `ticker` 请求返回的来自“卖"方的最低价格。 24 | 25 | `askQty` 26 | * `ticker` 请求返回的“卖"方以最低价格提供的总数量。 27 | 28 | `asks` 29 | * 卖单 30 | 31 | `avgPrice` 32 | * 表示相应 N 分钟之内的平均价格。 33 | 34 | --- 35 | 36 | ### B 37 | 38 | `baseAsset` 39 | * 基准资产；指代交易对中的第一个资产（比如 `BTCUSDT` 中的 `BTC`），表示被出售或者买进的资产。 40 | 41 | `baseAssetPrecision` 42 | * 基准资产精度；Exchange Information 响应中的一个字段，代表了基准资产（`baseAsset`）可以允许的最多小数位数。 43 | 44 | `baseCommissionPrecision` 45 | * Exchange Information 响应中用来表示基准资产手续费可以允许的最多小数位数。 46 | 47 | `bidPrice` 48 | * `ticker` 请求返回的来自“买"方的最高价格。 49 | 50 | `bidQty` 51 | * `ticker` 请求返回的“买"方以最高价格提供的总数量。 52 | 53 | `bids` 54 | * 买单。 55 | 56 | `BREAK` 57 | * 交易对的一个交易状态，用来表示某交易对无法交易。处于此状态的交易对无法产生市场行情数据。 58 | 59 | `BUY` 60 | * `side` 的一个枚举值，用来表示用户期望购买一个资产（比如 `BTC`）。 61 | 62 | --- 63 | 64 | ### C 65 | 66 | `CANCELED` 67 | * 订单的一个状态，用来表示订单被用户取消。 68 | 69 | `cancelReplaceMode` 70 | * 撤消挂单再下单接口的一个参数，用来定义如果取消订单的请求失败之后，是否继续下新的订单。 71 | 72 | `clientOrderId` 73 | * 用于下单请求，用户可以用此字段来设置自定义值，便于用来跟踪订单。 74 | 75 | `commission` 76 | * 交易费 77 | 78 | `commissionAsset` 79 | * 用于计算交易费的资产。 80 | 81 | Counter Order Id 82 | * 用户数据流 execution reports 中的一个字段，用来表示被阻止的撮合交易事务中的对手方订单。 83 | 84 | Counter Symbol 85 | * 用户数据流 execution reports 中的一个字段，用来表示被阻止的撮合交易事务中的对手方订单所使用的交易对。 86 | 87 | `cummulativeQuoteQty` 88 | * 订单的成交交易记录里面所有价格（`price`）乘以数量（`qty`）的和。 89 | 90 | --- 91 | 92 | ### D 93 | 94 | Data Source 95 | * 发送请求后得到数据的地方，比如数据库，缓存等。 96 | 97 | --- 98 | 99 | ### E 100 | 101 | `executedQty` 102 | * 订单中成交的数量。 103 | 104 | `EXPIRED` 105 | * 订单的一个状态，用来表示订单因为交易规则而取消，也可能是直接被交易所取消。 106 | 107 | `EXPIRED_IN_MATCH` 108 | * 订单的一个状态，用来表示订单由于 STP 而过期 （e.g. 带有 `EXPIRE_TAKER` 的订单与订单簿上属于同账户或同 `tradeGroupId` 的订单撮合）。 109 | 110 | --- 111 | 112 | ### F 113 | 114 | `filters` 115 | * 过滤器；用于定义交易规则。 116 | 117 | `FOK`/ Fill or Kill 118 | * `timeInForce` 的枚举值，用于下单时要求订单全部成交，不然就取消。 119 | 120 | `free` 121 | * 用户的可用余额，可以用来交易或者提取的金额。 122 | 123 | `FULL` 124 | * `newOrderRespType` 的枚举值，设置在下单接口时，请求会返回所有的交易信息，包括了成交记录（`fills`）。 125 | 126 | --- 127 | 128 | ### G 129 | 130 | `GTC`/ Good Til Canceled 131 | * `timeInForce` 的枚举值，表示订单会一直有效，直到全部成交或者被取消。 132 | 133 | --- 134 | 135 | ### H 136 | 137 | `HALT` 138 | * 交易对的一个交易状态，可以用来表示交易处于紧急暂停状态。此时市场信息还会生成。 139 | 140 | --- 141 | 142 | ### I 143 | 144 | `intervalNum` 145 | * 表示间隔时间，例如如果 `interval` 的值是 `SECOND`，并且 `intervalNum` 是 5，那么表示为每5秒钟间隔。 146 | 147 | `IOC` / Immediate or Canceled 148 | * `timeInForce` 的枚举值，表示订单会尽量的成交，而不能成交的部分则会被交易所取消。 149 | 150 | `isBestMatch` 151 | * 表示交易的价格是不是当时的最优价。 152 | 153 | `isBuyerMaker` 154 | * 表示交易双方的买家是否是市场的做市商（`Maker`）。 155 | 156 | `isWorking` 157 | * 表示订单是否出现在订单薄上。 158 | 159 | --- 160 | 161 | ### K 162 | 163 | `kline` 164 | * K线；包括了一定时期内的开盘价，收盘价，最高价，最低价，交易量，以及其他的市场数据。通常也被成为蜡烛图。 165 | 166 | --- 167 | 168 | ### L 169 | 170 | Last Prevented Quantity 171 | * 最后被阻止交易的数量。这仅在订单因 STP 触发而过期时可见。 172 | 173 | `lastPrice` 174 | * 最新一笔交易的成交价格。 175 | 176 | `lastQty` 177 | * 以 'lastPrice' 交易的总数量。 178 | 179 | `LIMIT` 180 | * 限价；一种订单形式，其订单的成交价格会是指定价格，或者更好的价格。 181 | 182 | `LIMIT_MAKER` 183 | * 一种订单形式，其订单会保证成为做市订单（`MAKER`），不会立刻成交进而成为`TAKER`。 184 | 185 | `limitClientOrderId` 186 | * OCO 订单下单接口的一个参数，方便用户自定义ID来标记 OCO 里的 `LIMIT_MAKER` 订单。 187 | 188 | `listClientOrderId` 189 | * OCO 订单下单接口的一个参数，方便用户自定义ID来标记 OCO 订单。 190 | 191 | `listenKey` 192 | * 系统提供的一个 Key，以方便用户来获取 WebSocket 中的用户相关信息。 193 | 194 | `locked` 195 | * 表示用户的某个资产余额中当前锁定在挂单或者被其他系统占用的数量。 196 | 197 | --- 198 | 199 | ### M 200 | 201 | `MARKET` 202 | * 一个订单的类型；其订单会在系统中尽可能的全部成交，除非市场没有流动性，无法成交部分会被交易取消。 203 | 204 | Matching Engine 205 | * 在数据源（`Data Source`）的部分指代的是请求获得数据的地方。 206 | * 也可以指代的是处理所有请求，撮合所有订单的后台系统。 207 | 208 | Match Type 209 | * 订单响应或 execution reports 中的一个字段，用来表示该订单是否通过 [智能指令路由 (SOR)](./sor_faq_CN.md) 成交。 210 | 211 | Memory 212 | * 数据源（`Data Source`）中指代数据存储在系统内部的缓冲。 213 | 214 | --- 215 | 216 | ### N 217 | 218 | `NEW` 219 | * 一个订单的状态，表示订单成功被发送到了交易引擎。 220 | 221 | `newClientOrderId` 222 | * 一个订单相关（下单，撤销订单等）请求中的参数；在请求的返回的时候，此值会被设置为 `clientOrderId`。 223 | 224 | Notional value 225 | * 订单的名义价值，值为 `price` * `qty`。 226 | 227 | --- 228 | 229 | ### O 230 | 231 | `OCO` 232 | 233 | * 二选一订单（`One-Cancels-the-Other`）；订单支持用户同时提交一系列订单，比如现价单（`LIMIT_MAKER`）和止盈止损订单（`STOP_LOSS` or `STOP_LOSS_LIMIT`）。 当执行其中一个订单时，另一个订单将自动取消。 234 | 235 | Order Book 236 | * 订单薄；包括了当前市场上买卖挂单。 237 | 238 | 239 | Order List 240 | * 订单列表；将多个订单组合为一个单元。请参考 `OCO` 与/或 `OTO` 241 | 242 | `orderId` 243 | * 订单数据里用来唯一标识的ID。 244 | 245 | `origQty` 246 | * 发送订单请求中的原始数量。 247 | 248 | `origClientOrderId` 249 | * 在查询或者取消订单请求中，用户设置在 `clientOrderId` 的值。 250 | 251 | `OTO` 252 | * 一个订单触发另一个订单（`One-Triggers-the-Other`）；这个订单列表含有一个生效订单和一个待处理订单。 253 | * 当生效订单完全成交时，待处理订单才会被自动下单。 254 | 255 | `OTOCO` 256 | * 由一个订单触发另一个二选一订单（`One-Triggers-a-One-Cancels-the-Other`）；这个订单列表含有一个生效订单和一个待处理的 OCO 订单。 257 | * 当生效订单完全成交时，待处理订单才会被自动下单。 258 | 259 | --- 260 | 261 | ### P 262 | 263 | `PARTIALLY_FILLED` 264 | * 订单的一种状态，表示订单被部分成交。 265 | 266 | Pending order 267 | * 订单列表中的订单，仅在相应的生效订单完全成交时才会被放在订单簿上。 268 | * 每个订单列表可以包含一个待处理订单，也可以包含2个可组成 `OCO` 的待处理订单。 269 | * 在单一订单的情况下，几乎支持任何订单类型，但不包括使用 `quoteOrderQty` 的 `MARKET` 的订单。 270 | 271 | `PENDING_NEW` 272 | * 订单 `status`；表示引擎已接受订单列表的待处理订单，但是待处理订单并没有被放到订单簿上。 273 | 274 | Prevented execution price 275 | * 用户数据流 execution reports 中的一个字段，用来表示被阻止的自我交易中的价格。参阅 [自我交易预防 (Self Trade Prevention - STP) 常见问题](stp_faq_CN.md)。 276 | 277 | Prevented execution quantity 278 | * 用户数据流 execution reports 中的一个字段，用来表示被阻止的自我交易中的订单量。参阅 [自我交易预防 (Self Trade Prevention - STP) 常见问题](stp_faq_CN.md)。 279 | 280 | Prevented execution quote quantity 281 | * 用户数据流 execution reports 中的一个字段，用来表示被阻止的自我交易中的报价订单量。参阅 [自我交易预防 (Self Trade Prevention - STP) 常见问题](stp_faq_CN.md)。 282 | 283 | `preventedQuantity` 284 | * 因为 STP 导致订单失效的数量。 285 | 286 | `preventedMatchId` 287 | * 与 `symbol` 结合使用时，可用于查询因为 STP 导致订单失效的过期订单。 288 | 289 | --- 290 | 291 | ### Q 292 | 293 | `quantity` 294 | * 订单量；买卖订单时候基本资产（`base asset`）的数量。 295 | 296 | `quoteAsset` 297 | * 定价资产；在交易对中的第二个资产，比如交易对 `BTCUSDT` 中的 `USDT`。 298 | 299 | `quoteAssetPrecision` 300 | * Exchange Information 响应中用来指明 `quoteAsset` 允许的最多小数位数。 301 | 302 | `quoteCommissionPrecision` 303 | * Exchange Information 响应中用来指明交易费用是 `quoteAsset` 允许的最多小数位数。 304 | 305 | `quoteOrderQty` 306 | * 市价单（`MARKET`）的下单接口中用于下反向市价单中的数量。 307 | 308 | `quoteQty` 309 | * 名义价值；为订单中数量（`qty`）乘以价格（`price`）。 310 | 311 | --- 312 | 313 | ### R 314 | 315 | `recvWindow` 316 | * API中的一个参数，值为毫秒；用以设定请求从 `timestamp` 开始的有效期。 317 | 318 | `RESULT` 319 | * `newOrderRespType` 的一个枚举值。用于下单的接口，会返回除了成交部分（`fills`）的所有值。 320 | 321 | Reverse `MARKET` order 322 | * 反向市价单；下市价单的时候使用 `quoteOrderQty`，而不是 `quantity`。 323 | 324 | --- 325 | 326 | ### S 327 | 328 | Self Trade Prevention (STP) 329 | * 自我交易预防；此功能能阻止订单与来自同一账户或者同一 `tradeGroupId` 下的账户的订单撮合交易。请阅读 [自我交易预防 (Self Trade Prevention - STP) 常见问题](./stp_faq_CN.md) 来了解更多详情。 330 | 331 | `selfTradePreventionMode` 332 | * 如果发生自我交易情况，此参数用来通知系统如何处理订单。 333 | 334 | `SELL` 335 | * 方向（`side`）的一个枚举值，用于用户希望卖出某一资产。 336 | 337 | Smart Order Routing (SOR) 338 | * 智能订单路由；使用可互换的定价资产（`quote asset`）来提高流动性。请阅读 [SOR 常见问题](./sor_faq_CN.md) 来了解更多详情。 339 | 340 | `SPOT` 341 | * 现货交易； 此种交易时候，买卖相应的资产会立刻到账。 342 | 343 | `stopClientOrderId` 344 | * 用于下OCO订单的接口；此ID可以用来标识OCO中 `STOP_LOSS` 或 `STOP_LOSS_LIMIT` 的订单。 345 | 346 | `stopPrice` 347 | * 用于设置逻辑订单（比如 `STOP_LOSS`， `TAKE_PROFIT`）中的触发价；此价格被触发后，订单会被放置到订单薄里面（`OrderBook`）。 348 | * 用于设置追踪止盈止损订单中的触发价；此价格被触发后，订单会被开始追踪。 349 | 350 | `STOP_LOSS` 351 | * 止损单；一种逻辑订单，市场价格达到 `stopPrice` 的时候，此订单会以市价单（`MARKET`）的形式执行。 352 | 353 | `STOP_LOSS_LIMIT` 354 | * 限价止损单；一种逻辑订单，市场价格达到 `stopPrice` 的时候，此订单会以限价单（`LIMIT`）的形式执行。 355 | 356 | `strategyId` 357 | * 策略单ID；用以关联此订单对应的交易策略。 358 | 359 | `strategyType` 360 | * 策略单类型；用以显示此订单对应的交易策略。 361 | 362 | `symbol` 363 | * 交易对；由交易对象（`base asset`）和定价资产（`quote asset`）组成。 364 | 365 | --- 366 | 367 | ### T 368 | 369 | `TAKE_PROFIT` 370 | * 止盈订单；当市场价格触及 `stopPrice` 价，此订单会以市价单（`MARKET`）被执行。 371 | 372 | `TAKE_PROFIT_LIMIT` 373 | * 限价止盈订单；当市场价格触及 `stopPrice` 价，此订单会以限价单（`LIMIT`）被执行。 374 | 375 | `ticker` 376 | * 用以汇报过去一段时间内的价格变动等市场信息。 377 | 378 | `time` 379 | * 对于交易/分配查询：交易/分配执行的时间。 380 | * 订单查询：订单创建时间。 381 | 382 | `timeInForce` 383 | * 定义订单的时效性，用以表明订单会在 orderbook 中的时长。 384 | * 支持的值包括了：`GTC`，`IOC` 和 `FOK`。 385 | 386 | `tradeGroupId` 387 | * 属于同一个交易组的账户组。 388 | 389 | `TRADING` 390 | * 一种交易状态，表明某交易对可以进行交易。 391 | 392 | `trailingDelta` 393 | * 用以定义追踪止盈止损订单被触发的价格差。 394 | 395 | `trailingTime` 396 | * 追踪单被激活和跟踪价格变化的时间。 397 | 398 | `transactTime` 399 | * 订单的更新时间：下单，成交或者取消。默认情况下，此字段（以及所有与时间戳相关的字段）在 JSON 响应中单位是毫秒。 400 | 401 | --- 402 | 403 | ### U 404 | 405 | `uiKlines` 406 | * 为了前端展示而优化的K线。 407 | 408 | `updateTime` 409 | * 订单的上次更新时间。默认情况下，此字段（以及所有与时间戳相关的字段）在 JSON 响应中单位是毫秒。 410 | 411 | User Data Stream 412 | * 通过 WebSocket 推送及时的个人用户信息，包括了账户余额的变动，订单的更新等。请阅读 [WebSocket 账户接口](../user-data-stream_CN.md) 来了解更多详情。 413 | 414 | `usedSor` 415 | * 用以标识该订单是否是通过 [智能指令路由 (SOR)](sor_faq_CN.md) 提交的。 416 | 417 | --- 418 | 419 | ### W 420 | 421 | `weightedAveragePrice` 422 | * 成交量加权平均价；将过去N分钟内所有交易的价格按各自的成交量加权而算出的平均价。 423 | 424 | `workingFloor` 425 | * 工作平台；该字段用于定义订单是通过 SOR 还是由订单提交到的订单薄（order book）成交的。 426 | 427 | Working order 428 | * 订单列表中的订单，该订单会立即放置在订单簿上。当此订单完全成交时，一个或多个待处理订单的自动下单会被触发。 429 | * 一个隶属于订单列表的订单，只能是单个 `LIMIT` 或 `LIMIT_MAKER` 类型的订单。 430 | 431 | `workingTime` 432 | * 指示订单何时添加到了 order book。 433 | --- 434 | 435 | ### X 436 | 437 | `X-MBX-ORDER-COUNT-XX` 438 | * 请求的返回 Header 里面一个自定义值，用来表明当前用户下单限制额的所剩额度。 439 | 440 | `X-MBX-USED-WEIGHT-XX` 441 | * 请求的返回 Header 里面一个自定义值，用来表明当前 IP 在一定时间内所剩的请求额度。 442 | -------------------------------------------------------------------------------- /faqs/trailing-stop-faq_CN.md: -------------------------------------------------------------------------------- 1 | # 追踪止盈止损(Trailing Stop)订单常见问题 2 | 3 | ## 什么是追踪止盈止损订单? 4 | 5 | 追踪止盈止损是一种用于追踪市场价格变动的工具. 现货的API中多了一个新参数 `trailingDelta`, 用来定义订单触发时机, 其值为基点(BIPS). 6 | 7 | 显然追踪止盈止损订单允许价格在有利的方向变动,同时限制在不利方向上的价格变动. 8 | 9 | 买单: _价格低_ 是有利的. 持续的价格 _下跌_ 是被允许的. 但是如果市场价格基于下单后的最低点 _上涨_ 了预定义的价格差, 订单会被触发. 10 | 11 | 卖单: _价格高_ 是有利的. 持续的价格 _上涨_ 是被允许的. 但是如果市场价格基于下单后的最高点 _下跌_ 了预定义的价格差, 订单会被触发. 12 | 13 | ## 什么是基点(BIPs)? 14 | 15 | 基点,又称为bps或bips,是金融学中用来描述百分比变化. 16 | 17 | 基点数 | 百分比 | 小数形式 18 | ---- | ---------- | ---------- 19 | 1 | 0.01% | 0.0001 20 | 10 | 0.1% | 0.001 21 | 100 | 1% | 0.01 22 | 1000 | 10% | 0.1 23 | 24 | 比如, 一个设置`trailingDelta=100`的止损(STOP_LOSS)卖单,则会构成一个追踪止损卖单, 此订单在提交后会跟踪价格变动,当价格从提交后的最高价下跌`1%`的时候会被触发为市价单卖掉. 25 | 26 | ## 什么样的订单可以成追踪止盈止损单? 27 | 28 | `STOP_LOSS`, `STOP_LOSS_LIMIT`, `TAKE_PROFIT`, 和 `TAKE_PROFIT_LIMIT` 支持追踪止盈止损功能. 29 | 30 | 限价止盈止损单订单(OCO)在其止盈止损单中支持追踪止盈止损功能. 如果追踪止盈止损被触发,其中的限价单(LIMIT)会被取消. 31 | 32 | ## 如果下追踪止盈止损订单? 33 | 34 | 追踪止盈止损订单的使用和`STOP_LOSS`, `STOP_LOSS_LIMIT`, `TAKE_PROFIT`, 或者 `TAKE_PROFIT_LIMIT` 订单很类似,但是多了一个`trailingDelta`参数. 此参数必须在交易对的`TRAILING_DELTA`过滤器定义范围内. 具体值可以参见接口 `GET /api/v3/exchangeInfo`. 35 | 36 | 不同于一般的止盈止损单,追踪止盈止损订单中的`stopPrice`是可选的. 如果`stopPrice`被设置了,那么订单只有当这个`stopPrice`价格被触发了后,才开始追踪价格变动.如果`stopPrice`被忽略,则会立刻开始追踪价格变化. 37 | 38 | ## 什么样的价格变动会触发追踪止盈止损订单? 39 | 40 | 追踪的订单类型 | 方向 | 止盈止损价(Stop price)条件 | 触发所需的价格变动 41 | ------------------- | ---- | -------------------------- | ---------------------------------- 42 | `TAKE_PROFIT` | 卖出 | 市场价 >= 止盈价 | 从最高价*回调* 43 | `TAKE_PROFIT_LIMIT` | 卖出 | 市场价 >= 止盈价 | 从最高价*回调* 44 | `STOP_LOSS` | 卖出 | 市场价 <= 止损价 | 从最高价*回调* 45 | `STOP_LOSS_LIMIT` | 卖出 | 市场价 <= 止损价 | 从最高价*回调* 46 | `STOP_LOSS` | 买入 | 市场价 >= 止损价 | 从最低价*上涨* 47 | `STOP_LOSS_LIMIT` | 买入 | 市场价 >= 止损价 | 从最低价*上涨* 48 | `TAKE_PROFIT` | 买入 | 市场价 <= 止盈价 | 从最低价*上涨* 49 | `TAKE_PROFIT_LIMIT` | 买入 | 市场价 <= 止盈价 | 从最低价*上涨* 50 | 51 | ## 如果使用 `TRAILING_DELTA` 过滤器? 52 | 53 | 对于 `STOP_LOSS` 买单, `STOP_LOSS_LIMIT` 买单, `TAKE_PROFIT` 卖单, 和 `TAKE_PROFIT_LIMIT` 卖单: 54 | 55 | * `trailingDelta` >= `minTrailingAboveDelta` 56 | * `trailingDelta` <= `maxTrailingAboveDelta` 57 | 58 | 对于 `STOP_LOSS` 卖单, `STOP_LOSS_LIMIT` 卖单, `TAKE_PROFIT` 买单, 和 `TAKE_PROFIT_LIMIT` 买单: 59 | 60 | * `trailingDelta` >= `minTrailingBelowDelta` 61 | * `trailingDelta` <= `maxTrailingBelowDelta` 62 | 63 | ## 追踪止盈止损订单用例 64 | 65 | ### 用例 A - 追踪止损限价买单 66 | 67 | 在 `12:01:00` 的时候,市场最新价为40,000. 这时候有一个限价止损买单(`STOP_LOSS_LIMIT`)进入交易所, 并且设置了止损价(`stopPrice`)为44,000, `trailingDelta`为500 (5%), 以及限价(`LIMIT`) 45,000. 68 | 69 | 在 `12:01:00` 到 `12:02:00` 之间市场上一系列的交易让最新价下跌到37,000. 到这里价格下跌了7.5%(750 BIPS), 超过了设置价格差值(`trailingDelta`). 但是因为还没有开始追踪市场, 所以价格变动被忽略. 70 | 71 | 在 `12:02:00` 到 `12:03:00` 之间市场上一系列的交易让价格开始上涨. 当一个交易(trade)价格等于,或者超过了止损价(`stopPrice`)(44,000),这时候订单立刻开始追踪价格变动. 满足条件的第一个交易会被看作"最低价", 在这个例子里就是44,000. 如果价格从44,000上涨了500个基点, 订单就会被触发. 72 | 这时候市场持续交易, 并将最新价推高到45,000. 73 | 74 | 在 `12:03:00` 到 `12:04:00` 之间市场的交易让最新价上涨到46,000. 这时价格已经从之前标记的最低价(44,000)上涨了大约454个基点, 但是还不到触发订单的要求(500个基点). 75 | 76 | 在 `12:04:00` 到 `12:05:00` 之间市场上一系列的交易让最新价开始下跌到42,000. 这是从之前的标记的最低价开始的下跌, 最低价被标记为当前价(42,000). 如果市场从这里上涨500个基点, 订单会被触发. 77 | 78 | 在 `12:05:00` 到 `12:05:30` 之间市场交易让最新价上涨到44,100. 最新的交易价格到达或者超过了订单设置的500个基点要求(`44,100 = 42,000 * 1.05`). 这导致了订单被触发, 然后被以限价45,000的价格放到订单薄(order book)里面. 79 | 80 |
81 |
82 | ### 用例 B - 追踪止损限价卖单
83 |
84 | 在 `12:01:00` 的时候, 市场最新价为40,000. 这时候有一个限价止损卖单(`STOP_LOSS_LIMIT`)进入交易所, 并且设置了止损价(`stopPrice`)为39,000, `trailingDelta`为1,000 (10%), 以及限价(LIMIT) 38,000.
85 |
86 | 在 `12:01:00` 到 `12:02:00` 之间市场上一系列的交易让最新价上涨到41,500.
87 |
88 | 在 `12:02:00` 到 `12:03:00` 之间市场的交易让价格开始下跌. 当一个交易(trade)价格等于, 或者低于了止损价(`stopPrice`)(39,000), 这时候订单立刻开始追踪价格变动. 满足条件的第一个交易会被看作"最高价", 在这个例子里就是39,000. 如果价格从39,000下跌了1,000个基点, 订单就会被触发.
89 |
90 | 在 `12:03:00` 到 `12:04:00` 之间市场上一系列的交易让最新价开始下跌到37,000. 这时价格已经从之前标记的最高价(39,000)回落了大约512个基点, 但是还不到触发订单的要求(1000个基点).
91 |
92 | 在 `12:04:00` 到 `12:05:00` 之间市场上一系列的交易让最新价开始上涨到41,000. 这是从之前的标记的最高价开始的上涨, 最高价被标记为当前价(41,000). 如果这时候有1000个基点下跌, 订单会被触发.
93 |
94 | 在 `12:05:00` 到 `12:05:30` 之间的一些市场交易让最新价下跌到36,900. 最新的交易价格到达或者超过了订单设置的1000个基点要求(`36,900 = 41,000 * 0.90`). 这导致了订单被触发, 然后被以限价38,000的价格放到订单薄(order book)里面.
95 |
96 | 
97 |
98 | ### 用例 C - 追踪止盈限价买单
99 |
100 | 在 `12:01:00` 的时候, 市场最新价为40,000. 这时候有一个限价止盈买单(`TAKE_PROFIT_LIMIT`)进入交易所, 并且设置了止盈价(`stopPrice`)为38,000, `trailingDelta`为 850 (8.5%), 以及限价(LIMIT) 38,500.
101 |
102 | 在 `12:01:00` 到 `12:02:00` 之间市场上一系列的交易让最新价上涨到42,000.
103 |
104 | 在 `12:02:00` 到 `12:03:00` 之间市场交易让价格开始下跌. 当一个交易(trade)价格等于, 或者超过了止盈价(`stopPrice`)(38,000), 这时候订单立刻开始追踪价格变动. 满足条件的第一个交易会被看作"最低价", 在这个例子里就是38,000.
105 | 市场的持续交易,让最新价下跌到37,000. 这时最低价被设为37,000. 如果价格从37,000上涨了850个基点, 订单就会被触发.
106 |
107 | 在 `12:03:00` 到 `12:04:00` 之间市场上一系列的交易让最新价开始上涨到39,000. 这时价格已经从之前标记的最低价(37,000)上涨了大约540个基点, 但是还不到触发订单的要求(850个基点).
108 |
109 | 在 `12:04:00` 到 `12:05:00` 之间市场上一系列的交易让最新价开始下跌到38,000, 没有低于之前的最低价, 所以不会有任何变化.
110 |
111 | 在 `12:05:00` 到 `12:05:30` 之间的一些市场交易让最新价上涨到40,145. 最新的交易价格到达或者超过了订单设置的850个基点要求(`40,145 = 37,000 * 1.085`). 这导致了订单被触发, 然后被以限价38,500的价格放到订单薄(order book)里面.
112 |
113 | 
114 |
115 | ### 用例 D - 追踪止盈限价卖单
116 |
117 | 在 `12:01:00` 的时候,市场最新价为40,000. 这时候有一个限价止盈卖单(`TAKE_PROFIT_LIMIT`)进入交易所, 并且设置了止盈价(`stopPrice`)为42,000, `trailingDelta`为 750 (7.5%), 以及限价(LIMIT) 41,000.
118 |
119 | 在 `12:01:00` 到 `12:02:00` 之间市场上一系列的交易让最新价上涨到41,500.
120 |
121 | 在 `12:02:00` 到 `12:03:00` 之间市场上一系列的交易让价格开始下跌到39,000.
122 |
123 | 在 `12:03:00` 到 `12:04:00` 之间市场上一系列的交易让最新价开始上涨.
124 | 当最新的交易价格到达或者超过了订单设置的止盈价(`stopPrice`),订单就会立刻开始追踪. 第一个满足条件的交易价就被设为"最高价". 在这个例子中, 最高价是42,000. 如果从最高价下跌750个基点, 订单就会被触发.
125 |
126 | 这时市场价格持续上涨,最新价到了45,000. 追踪止盈订单的"最高价"也被设置成了45,000. 如果价格从这里下跌750个基点, 订单会被触发.
127 |
128 | 在 `12:04:00` 到 `12:05:00` 之间市场上一系列的交易让最新价开始下跌到44,000. 这相当于从之前的最高价(45,000)下跌了大约222个基点, 不过没有达到追踪止盈订单设置的750个基点要求, 所以不会触发.
129 |
130 | 在 `12:05:00` 到 `12:06:00` 之间的一些市场交易让最新价上涨到46,500. 因为市场上涨,之前的最高价被设置成当前价(46,500). 如果价格从这里下跌750个基点, 订单会被触发.
131 |
132 | 在 `12:06:00` 到 `12:06:50` 之间的一些市场交易让最新价下跌到43,012.5. 当前价格达到或者超过了追踪订单设定的750个基点(`43,012.5 = 46,500 * 0.925`), 导致订单被触发, 以限价(LIMIT)41,000的价格被放入订单薄.
133 |
134 | 
135 |
136 | ### 用例 E - 不设置限价的追踪止盈止损订单
137 |
138 | 在 `12:01:00` 的时候, 市场最新价为40,000. 这时候有一个限价止损卖单(`STOP_LOSS_LIMIT`)进入交易所, 并且设置了`trailingDelta`为 700 (7%), 以及限价(LIMIT) 39,000, 但是没有设置限价(`stopPrice`). 订单创建后就开始追踪价格. 如果价格从40,000下跌了700个基点, 订单就会被触发.
139 |
140 | 在 `12:01:00` 到 `12:02:00` 之间市场上一系列的交易让价格开始上涨到42,000, 使追踪的"最高价"变成42,000. 如果价格从这里(42,000)开始下跌700个基点, 订单会被触发.
141 |
142 | 在 `12:02:00` 到 `12:03:00` 之间市场上一系列的交易让价格下跌到39,500, 这让市场从之前追踪的最高价（42,000)下跌了大约595个基点, 不过没有达到700个基点的要求, 订单不会被触发.
143 |
144 | 在 `12:03:00` 到 `12:04:00` 之间市场上一系列的交易让价格上涨到45,500. 市场的上涨, 让追踪的最高价变成当前价45,500. 如果价格从这里45,500下跌了700个基点, 订单就会被触发.
145 |
146 | 在 `12:04:00` 到 `12:04:45` 之间市场上一系列的交易让价格下跌到42,315. 当前价格达到或者超过了追踪订单设定的700个基点(`42,315 = 45,500 * 0.93`), 导致订单被触发, 以限价(LIMIT)39,000的价格被放入订单薄.
147 |
148 | 
149 |
150 | ## 追踪止盈止损下单示例
151 |
152 | 假设当前最新价是40,000.
153 |
154 | 下一个追踪止损(`STOP_LOSS_LIMIT`)的买单, 设置价格为42,000, 追踪价差（`trailingDelta`)为5%.
155 |
156 | ```bash
157 | # 不设置止损价(stop price)
158 | POST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=BUY&type=STOP_LOSS_LIMIT&timeInForce=GTC&quantity=0.01&price=42000&trailingDelta=500×tamp=49 | `avgPriceMins` is the number of minutes the average price is calculated over. 0 means the last price is used.
50 | There is a different range depending on whether the order is placed on the `BUY` side or the `SELL` side. 51 | 52 | Buy orders will succeed on this filter if: 53 | * `Order price` <= `weightedAveragePrice` * `bidMultiplierUp` 54 | * `Order price` >= `weightedAveragePrice` * `bidMultiplierDown` 55 | 56 | Sell orders will succeed on this filter if: 57 | * `Order Price` <= `weightedAveragePrice` * `askMultiplierUp` 58 | * `Order Price` >= `weightedAveragePrice` * `askMultiplierDown` 59 | 60 | **/exchangeInfo format:** 61 | ```javascript 62 | { 63 | "filterType": "PERCENT_PRICE_BY_SIDE", 64 | "bidMultiplierUp": "1.2", 65 | "bidMultiplierDown": "0.2", 66 | "askMultiplierUp": "5", 67 | "askMultiplierDown": "0.8", 68 | "avgPriceMins": 1 69 | } 70 | ``` 71 | 72 | 73 | ### LOT_SIZE 74 | The `LOT_SIZE` filter defines the `quantity` (aka "lots" in auction terms) rules for a symbol. There are 3 parts: 75 | 76 | * `minQty` defines the minimum `quantity`/`icebergQty` allowed. 77 | * `maxQty` defines the maximum `quantity`/`icebergQty` allowed. 78 | * `stepSize` defines the intervals that a `quantity`/`icebergQty` can be increased/decreased by. 79 | 80 | In order to pass the `lot size`, the following must be true for `quantity`/`icebergQty`: 81 | 82 | * `quantity` >= `minQty` 83 | * `quantity` <= `maxQty` 84 | * `quantity` % `stepSize` == 0 85 | 86 | **/exchangeInfo format:** 87 | ```javascript 88 | { 89 | "filterType": "LOT_SIZE", 90 | "minQty": "0.00100000", 91 | "maxQty": "100000.00000000", 92 | "stepSize": "0.00100000" 93 | } 94 | ``` 95 | 96 | ### MIN_NOTIONAL 97 | The `MIN_NOTIONAL` filter defines the minimum notional value allowed for an order on a symbol. 98 | An order's notional value is the `price` * `quantity`. 99 | `applyToMarket` determines whether or not the `MIN_NOTIONAL` filter will also be applied to `MARKET` orders. 100 | Since `MARKET` orders have no price, the average price is used over the last `avgPriceMins` minutes. 101 | `avgPriceMins` is the number of minutes the average price is calculated over. 0 means the last price is used. 102 | 103 | 104 | **/exchangeInfo format:** 105 | ```javascript 106 | { 107 | "filterType": "MIN_NOTIONAL", 108 | "minNotional": "0.00100000", 109 | "applyToMarket": true, 110 | "avgPriceMins": 5 111 | } 112 | ``` 113 | 114 | ### NOTIONAL 115 | The `NOTIONAL` filter defines the acceptable notional range allowed for an order on a symbol.
116 | `applyMinToMarket` determines whether the `minNotional` will be applied to `MARKET` orders.
117 | `applyMaxToMarket` determines whether the `maxNotional` will be applied to `MARKET` orders. 118 | 119 | In order to pass this filter, the notional (`price * quantity`) has to pass the following conditions: 120 | 121 | * `price * quantity` <= `maxNotional` 122 | * `price * quantity` >= `minNotional` 123 | 124 | For `MARKET` orders, the average price used over the last `avgPriceMins` minutes will be used for calculation.
125 | If the `avgPriceMins` is 0, then the last price will be used. 126 | 127 | **/exchangeInfo format:** 128 | ```javascript 129 | { 130 | "filterType": "NOTIONAL", 131 | "minNotional": "10.00000000", 132 | "applyMinToMarket": false, 133 | "maxNotional": "10000.00000000", 134 | "applyMaxToMarket": false, 135 | "avgPriceMins": 5 136 | } 137 | ``` 138 | 139 | ### ICEBERG_PARTS 140 | The `ICEBERG_PARTS` filter defines the maximum parts an iceberg order can have. The number of `ICEBERG_PARTS` is defined as `CEIL(qty / icebergQty)`. 141 | 142 | **/exchangeInfo format:** 143 | ```javascript 144 | { 145 | "filterType": "ICEBERG_PARTS", 146 | "limit": 10 147 | } 148 | ``` 149 | 150 | ### MARKET_LOT_SIZE 151 | The `MARKET_LOT_SIZE` filter defines the `quantity` (aka "lots" in auction terms) rules for `MARKET` orders on a symbol. There are 3 parts: 152 | 153 | * `minQty` defines the minimum `quantity` allowed. 154 | * `maxQty` defines the maximum `quantity` allowed. 155 | * `stepSize` defines the intervals that a `quantity` can be increased/decreased by. 156 | 157 | In order to pass the `market lot size`, the following must be true for `quantity`: 158 | 159 | * `quantity` >= `minQty` 160 | * `quantity` <= `maxQty` 161 | * `quantity` % `stepSize` == 0 162 | 163 | **/exchangeInfo format:** 164 | ```javascript 165 | { 166 | "filterType": "MARKET_LOT_SIZE", 167 | "minQty": "0.00100000", 168 | "maxQty": "100000.00000000", 169 | "stepSize": "0.00100000" 170 | } 171 | ``` 172 | 173 | ### MAX_NUM_ORDERS 174 | The `MAX_NUM_ORDERS` filter defines the maximum number of orders an account is allowed to have open on a symbol. 175 | Note that both "algo" orders and normal orders are counted for this filter. 176 | 177 | **/exchangeInfo format:** 178 | ```javascript 179 | { 180 | "filterType": "MAX_NUM_ORDERS", 181 | "maxNumOrders": 25 182 | } 183 | ``` 184 | 185 | ### MAX_NUM_ALGO_ORDERS 186 | The `MAX_NUM_ALGO_ORDERS` filter defines the maximum number of "algo" orders an account is allowed to have open on a symbol. 187 | "Algo" orders are `STOP_LOSS`, `STOP_LOSS_LIMIT`, `TAKE_PROFIT`, and `TAKE_PROFIT_LIMIT` orders. 188 | 189 | **/exchangeInfo format:** 190 | ```javascript 191 | { 192 | "filterType": "MAX_NUM_ALGO_ORDERS", 193 | "maxNumAlgoOrders": 5 194 | } 195 | ``` 196 | 197 | ### MAX_NUM_ICEBERG_ORDERS 198 | The `MAX_NUM_ICEBERG_ORDERS` filter defines the maximum number of `ICEBERG` orders an account is allowed to have open on a symbol. 199 | An `ICEBERG` order is any order where the `icebergQty` is > 0. 200 | 201 | **/exchangeInfo format:** 202 | ```javascript 203 | { 204 | "filterType": "MAX_NUM_ICEBERG_ORDERS", 205 | "maxNumIcebergOrders": 5 206 | } 207 | ``` 208 | 209 | ### MAX_POSITION 210 | 211 | The `MAX_POSITION` filter defines the allowed maximum position an account can have on the base asset of a symbol. An account's position defined as the sum of the account's: 212 | 1. free balance of the base asset 213 | 1. locked balance of the base asset 214 | 1. sum of the qty of all open BUY orders 215 | 216 | `BUY` orders will be rejected if the account's position is greater than the maximum position allowed. 217 | 218 | If an order's `quantity` can cause the position to overflow, this will also fail the `MAX_POSITION` filter. 219 | 220 | **/exchangeInfo format:** 221 | ```javascript 222 | { 223 | "filterType":"MAX_POSITION", 224 | "maxPosition":"10.00000000" 225 | } 226 | ``` 227 | 228 | ### TRAILING_DELTA 229 | 230 | The `TRAILING_DELTA` filter defines the minimum and maximum value for the parameter `trailingDelta`. 231 | 232 | In order for a trailing stop order to pass this filter, the following must be true: 233 | 234 | For `STOP_LOSS BUY`, `STOP_LOSS_LIMIT_BUY`,`TAKE_PROFIT SELL` and `TAKE_PROFIT_LIMIT SELL` orders: 235 | 236 | * `trailingDelta` >= `minTrailingAboveDelta` 237 | * `trailingDelta` <= `maxTrailingAboveDelta` 238 | 239 | For `STOP_LOSS SELL`, `STOP_LOSS_LIMIT SELL`, `TAKE_PROFIT BUY`, and `TAKE_PROFIT_LIMIT BUY` orders: 240 | 241 | * `trailingDelta` >= `minTrailingBelowDelta` 242 | * `trailingDelta` <= `maxTrailingBelowDelta` 243 | 244 | 245 | **/exchangeInfo format:** 246 | 247 | ```javascript 248 | { 249 | "filterType": "TRAILING_DELTA", 250 | "minTrailingAboveDelta": 10, 251 | "maxTrailingAboveDelta": 2000, 252 | "minTrailingBelowDelta": 10, 253 | "maxTrailingBelowDelta": 2000 254 | } 255 | ``` 256 | 257 | 258 | ## Exchange Filters 259 | ### EXCHANGE_MAX_NUM_ORDERS 260 | The `EXCHANGE_MAX_NUM_ORDERS` filter defines the maximum number of orders an account is allowed to have open on the exchange. 261 | Note that both "algo" orders and normal orders are counted for this filter. 262 | 263 | **/exchangeInfo format:** 264 | ```javascript 265 | { 266 | "filterType": "EXCHANGE_MAX_NUM_ORDERS", 267 | "maxNumOrders": 1000 268 | } 269 | ``` 270 | 271 | ### EXCHANGE_MAX_NUM_ALGO_ORDERS 272 | The `EXCHANGE_MAX_NUM_ALGO_ORDERS` filter defines the maximum number of "algo" orders an account is allowed to have open on the exchange. 273 | "Algo" orders are `STOP_LOSS`, `STOP_LOSS_LIMIT`, `TAKE_PROFIT`, and `TAKE_PROFIT_LIMIT` orders. 274 | 275 | **/exchangeInfo format:** 276 | ```javascript 277 | { 278 | "filterType": "EXCHANGE_MAX_NUM_ALGO_ORDERS", 279 | "maxNumAlgoOrders": 200 280 | } 281 | ``` 282 | 283 | ### EXCHANGE_MAX_NUM_ICEBERG_ORDERS 284 | The `EXCHANGE_MAX_NUM_ICEBERG_ORDERS` filter defines the maximum number of iceberg orders an account is allowed to have open on the exchange. 285 | 286 | **/exchangeInfo format:** 287 | ```javascript 288 | { 289 | "filterType": "EXCHANGE_MAX_NUM_ICEBERG_ORDERS", 290 | "maxNumIcebergOrders": 10000 291 | } 292 | ``` 293 | -------------------------------------------------------------------------------- /filters_CN.md: -------------------------------------------------------------------------------- 1 | # 过滤器 2 | 过滤器，即Filter，定义了一系列交易规则。 3 | 共有两类，分别是针对交易对的过滤器`symbol filters`，和针对整个交易所的过滤器`exchange filters` 4 | 5 | ## 交易对过滤器 6 | ### PRICE_FILTER 价格过滤器 7 | 价格过滤器用于检测order订单中price参数的合法性 8 | * `minPrice` 定义了 `price`/`stopPrice` 允许的最小值; `minPrice` == 0 的时候则失效。 9 | * `maxPrice` 定义了 `price`/`stopPrice` 允许的最大值; `maxPrice` == 0 的时候则失效。 10 | * `tickSize` 定义了 `price`/`stopPrice` 的步进间隔; `tickSize` == 0 的时候则失效。 11 | 12 | 以上每一项均可为0，为0时代表这一项不再做限制。 13 | 14 | 逻辑伪代码如下： 15 | * `price` >= `minPrice` 16 | * `price` <= `maxPrice` 17 | * `price` % `tickSize` == 0 18 | 19 | **/exchangeInfo 响应中的格式:** 20 | ```javascript 21 | { 22 | "filterType": "PRICE_FILTER", 23 | "minPrice": "0.00000100", 24 | "maxPrice": "100000.00000000", 25 | "tickSize": "0.00000100" 26 | } 27 | ``` 28 | 29 | ### PERCENT_PRICE 价格振幅过滤器 30 | 可以理解为一个瞬时的涨跌停限制，不允许价格瞬间剧烈浮动。 31 | `avgPriceMins` 指用过去几分钟的平均价格来计算价格基准. 0 表示用最新成交价格作为价格计准。 32 | 33 | 逻辑伪代码如下： 34 | * `price` <= `weightedAveragePrice` * `multiplierUp` 35 | * `price` >= `weightedAveragePrice` * `multiplierDown` 36 | 37 | **/exchangeInfo 响应中的格式:** 38 | ```javascript 39 | { 40 | "filterType": "PERCENT_PRICE", 41 | "multiplierUp": "1.3000", 42 | "multiplierDown": "0.7000", 43 | "avgPriceMins": 5 44 | } 45 | ``` 46 | 47 | #### PERCENT_PRICE_BY_SIDE 48 | `PERCENT_PRICE_BY_SIDE` 过滤器定义了基于交易对平均价格的合法价格范围. 取决于`BUY`或者`SELL`, 价格范围可能有所不同.
49 | 50 | `avgPriceMins` 是用来计算平均价格的分钟数. 0 表示用最新价(last price).
51 | 52 | 买向订单需要满足: 53 | 54 | * `Order price` <= `weightedAveragePrice` * `bidMultiplierUp` 55 | * `Order price` >= `weightedAveragePrice` * `bidMultiplierDown` 56 | 57 | 卖向订单需要满足: 58 | 59 | * `Order Price` <= `weightedAveragePrice` * `askMultiplierUp` 60 | * `Order Price` >= `weightedAveragePrice` * `askMultiplierDown` 61 | 62 | 63 | **/exchangeInfo 响应中的格式:** 64 | ```javascript 65 | { 66 | "filterType": "PERCENT_PRICE_BY_SIDE", 67 | "bidMultiplierUp": "1.2", 68 | "bidMultiplierDown": "0.2", 69 | "askMultiplierUp": "5", 70 | "askMultiplierDown": "0.8", 71 | "avgPriceMins": 1 72 | } 73 | ``` 74 | 75 | ### LOT_SIZE 订单尺寸 76 | "lots" 是拍卖术语，这个过滤器对订单中的 `quantity` 也就是数量参数进行合法性检查。包含三个部分： 77 | 78 | * `minQty` 表示 `quantity`/`icebergQty` 允许的最小值. 79 | * `maxQty` 表示 `quantity`/`icebergQty` 允许的最大值 80 | * `stepSize` 表示 `quantity`/`icebergQty` 允许的步进值。 81 | 82 | 逻辑伪代码如下： 83 | 84 | * `quantity` >= `minQty` 85 | * `quantity` <= `maxQty` 86 | * `quantity` % `stepSize` == 0 87 | 88 | **/exchangeInfo 响应中的格式:** 89 | ```javascript 90 | { 91 | "filterType": "LOT_SIZE", 92 | "minQty": "0.00100000", 93 | "maxQty": "100000.00000000", 94 | "stepSize": "0.00100000" 95 | } 96 | ``` 97 | 98 | ### MIN_NOTIONAL 最小金额 99 | MIN_NOTIONAL过滤器定义了交易对订单所允许的最小名义价值(成交额)。 100 | 订单的名义价值是`价格`*`数量`。 101 | 如果是高级订单(比如止盈止损订单`STOP_LOSS_LIMIT`)，名义价值会按照`stopPrice` * `quantity`来计算。 102 | 如果是冰山订单，名义价值会按照`price` * `icebergQty`来计算。 103 | `applyToMarket`确定 `MIN_NOTIONAL`过滤器是否也将应用于`MARKET`订单。 104 | 由于`MARKET`订单没有价格，因此会在最后`avgPriceMins`分钟内使用平均价格。 105 | `avgPriceMins`是计算平均价格的分钟数。 0表示使用最后的价格。 106 | 107 | 108 | **/exchangeInfo 响应中的格式:** 109 | ```javascript 110 | { 111 | "filterType": "MIN_NOTIONAL", 112 | "minNotional": "0.00100000", 113 | "applyToMarket": true, 114 | "avgPriceMins": 5 115 | } 116 | ``` 117 | 118 | ### NOTIONAL 名义价值 119 | 120 | **/exchangeInfo 响应中的格式:** 121 | 122 | ```javascript 123 | { 124 | "filterType": "NOTIONAL", 125 | "minNotional": "10.00000000", 126 | "applyMinToMarket": false, 127 | "maxNotional": "10000.00000000", 128 | "applyMaxToMarket": false, 129 | "avgPriceMins": 5 130 | } 131 | ``` 132 | 133 | 名义价值过滤器(`NOTIONAL`)定义了订单在一个交易对上可以下单的名义价值区间.
134 | `applyMinToMarket` 定义了 `minNotional` 是否适用于市价单(`MARKET`)
135 | `applyMaxToMarket` 定义了 `maxNotional` 是否适用于市价单(`MARKET`). 136 | 137 | 要通过此过滤器, 订单的名义价值 (单价 x 数量, `price * quantity`) 需要满足如下条件: 138 | 139 | * `price * quantity` <= `maxNotional` 140 | * `price * quantity` >= `minNotional` 141 | 142 | 对于市价单(`MARKET`), 用于计算的价格采用的是在 `avgPriceMins` 定义的时间之内的平均价.
143 | 如果 `avgPriceMins` 为 0, 则采用最新的价格. 144 | 145 | ### ICEBERG_PARTS 冰山订单拆分数 146 | `ICEBERG_PARTS` 代表冰山订单最多可以拆分成多少个小订单。 147 | 计算方法为 `向上取整(qty / icebergQty)`. 148 | 149 | **/exchangeInfo 响应中的格式:** 150 | ```javascript 151 | { 152 | "filterType": "ICEBERG_PARTS", 153 | "limit": 10 154 | } 155 | ``` 156 | 157 | ### MARKET_LOT_SIZE 市价订单尺寸 158 | `MARKET_LOT_SIZE`过滤器为交易对上的`MARKET`订单定义了`数量`(即拍卖中的"手数")规则。 共有3部分： 159 | 160 | * `minQty`定义了允许的最小`quantity`。 161 | * `maxQty`定义了允许的最大数量。 162 | * `stepSize`定义了可以增加/减少数量的间隔。 163 | 164 | 为了通过 `market lot size`，`quantity` 必须满足以下条件： 165 | 166 | * `quantity` >= `minQty` 167 | * `quantity` <= `maxQty` 168 | * `quantity` % `stepSize` == 0 169 | 170 | **/exchangeInfo 响应中的格式:** 171 | ```javascript 172 | { 173 | "filterType": "MARKET_LOT_SIZE", 174 | "minQty": "0.00100000", 175 | "maxQty": "100000.00000000", 176 | "stepSize": "0.00100000" 177 | } 178 | ``` 179 | 180 | ### MAX_NUM_ORDERS 最多订单数 181 | 定义了某个交易对最多允许的挂单数量（不包括已关闭的订单） 182 | 普通订单与条件订单均计算在内 183 | 184 | **/exchangeInfo 响应中的格式:** 185 | ```javascript 186 | { 187 | "filterType": "MAX_NUM_ORDERS", 188 | "maxNumOrders": 25 189 | } 190 | ``` 191 | 192 | ### MAX_NUM_ALGO_ORDERS 最多条件单数 193 | `MAX_NUM_ALGO_ORDERS`过滤器定义允许账户在交易对上开设的"algo"订单的最大数量。 194 | "Algo"订单是`STOP_LOSS`，`STOP_LOSS_LIMIT`，`TAKE_PROFIT`和`TAKE_PROFIT_LIMIT`止盈止损单。 195 | 196 | **/exchangeInfo 响应中的格式:** 197 | ```javascript 198 | { 199 | "filterType": "MAX_NUM_ALGO_ORDERS", 200 | "maxNumAlgoOrders": 5 201 | } 202 | ``` 203 | 204 | ### MAX_NUM_ICEBERG_ORDERS 最多冰山单数 205 | `MAX_NUM_ICEBERG_ORDERS`过滤器定义了允许在交易对上开设账户的`ICEBERG`订单的最大数量。 206 | `ICEBERG`订单是icebergQty大于0的任何订单。 207 | 208 | **/exchangeInfo 响应中的格式:** 209 | ```javascript 210 | { 211 | "filterType": "MAX_NUM_ICEBERG_ORDERS", 212 | "maxNumIcebergOrders": 5 213 | } 214 | ``` 215 | 216 | ### MAX_POSITION 过滤器 217 | 218 | 这个过滤器定义账户允许的基于`base asset`的最大仓位。一个用户的仓位可以定义为如下资产的总和: 219 | 1. `base asset`的可用余额 220 | 1. `base asset`的锁定余额 221 | 1. 所有处于open的买单的数量总和 222 | 223 | 如果用户的仓位大于最大的允许仓位，买单会被拒绝。 224 | 225 | 如果一个订单的数量(`quantity`) 可能导致持有仓位溢出, 会触发过滤器 `MAX_POSITION`. 226 | 227 | **/exchangeInfo 响应中的格式:** 228 | ```javascript 229 | { 230 | "filterType": "MAX_POSITION", 231 | "maxPosition": "10.00000000" 232 | } 233 | ``` 234 | 235 | ### TRAILING_DELTA 过滤器 236 | 237 | 238 | 此过滤器定义了参数`trailingDelta`的最大和最小值. 239 | 240 | 下追踪止损订单, 需要满足条件: 241 | 242 | 对于 `STOP_LOSS BUY`, `STOP_LOSS_LIMIT_BUY`, `TAKE_PROFIT SELL` 和 `TAKE_PROFIT_LIMIT SELL` 订单: 243 | 244 | * `trailingDelta` >= `minTrailingAboveDelta` 245 | * `trailingDelta` <= `maxTrailingAboveDelta` 246 | 247 | 对于 `STOP_LOSS SELL`, `STOP_LOSS_LIMIT SELL`, `TAKE_PROFIT BUY`, 和 `TAKE_PROFIT_LIMIT BUY` 订单: 248 | 249 | * `trailingDelta` >= `minTrailingBelowDelta` 250 | * `trailingDelta` <= `maxTrailingBelowDelta` 251 | 252 | **/exchangeInfo format:** 253 | ```javascript 254 | { 255 | "filterType": "TRAILING_DELTA", 256 | "minTrailingAboveDelta": 10, 257 | "maxTrailingAboveDelta": 2000, 258 | "minTrailingBelowDelta": 10, 259 | "maxTrailingBelowDelta": 2000 260 | } 261 | ``` 262 | 263 | ## 交易所级别过滤器 264 | ### EXCHANGE_MAX_NUM_ORDERS 最多订单数 265 | `EXCHANGE_MAX_NUM_ORDERS`过滤器定义了允许在交易对上开设账户的最大订单数。 266 | 请注意，此过滤器同时计算"algo"订单和常规订单。 267 | 268 | **/exchangeInfo 响应中的格式:** 269 | ```javascript 270 | { 271 | "filterType": "EXCHANGE_MAX_NUM_ORDERS", 272 | "maxNumOrders": 1000 273 | } 274 | ``` 275 | 276 | ### EXCHANGE_MAX_NUM_ALGO_ORDERS 最多条件单数 277 | `EXCHANGE_MAX_ALGO_ORDERS`过滤器定义了允许在交易上开设账户的"algo"订单的最大数量。 278 | "Algo"订单是`STOP_LOSS`，`STOP_LOSS_LIMIT`，`TAKE_PROFIT`和`TAKE_PROFIT_LIMIT`订单。 279 | 280 | **/exchangeInfo 响应中的格式:** 281 | ```javascript 282 | { 283 | "filterType": "EXCHANGE_MAX_NUM_ALGO_ORDERS", 284 | "maxNumAlgoOrders": 200 285 | } 286 | ``` 287 | 288 | ### EXCHANGE_MAX_NUM_ICEBERG_ORDERS 冰山订单的最大订单数 289 | 290 | 此过滤器定义了允许账号持有的最大冰山订单数量. 291 | 292 | 293 | **/exchangeInfo 响应中的格式:** 294 | 295 | ```javascript 296 | { 297 | "filterType": "EXCHANGE_MAX_NUM_ICEBERG_ORDERS", 298 | "maxNumIcebergOrders": 10000 299 | } 300 | ``` -------------------------------------------------------------------------------- /fix/schemas/spot-fix-md.xml: -------------------------------------------------------------------------------- 1 |
4 | Please read it carefully before proceeding. 5 | -------------------------------------------------------------------------------- /testnet/enums.md: -------------------------------------------------------------------------------- 1 | # ENUM Definitions 2 | 3 | This will apply for both REST API and WebSocket API. 4 | 5 | ## Symbol status (status): 6 | 7 | * `TRADING` 8 | * `END_OF_DAY` 9 | * `HALT` 10 | * `BREAK` 11 | 12 | 13 | 14 | ## Account and Symbol Permissions (permissions) 15 | 16 | * `SPOT` 17 | 18 | ## Order status (status) 19 | 20 | Status | Description 21 | -----------| -------------- 22 | `NEW` | The order has been accepted by the engine. 23 | `PENDING_NEW`|The order is in a pending phase until the working order of an order list has been fully filled. 24 | `PARTIALLY_FILLED`| A part of the order has been filled. 25 | `FILLED` | The order has been completed. 26 | `CANCELED` | The order has been canceled by the user. 27 | `PENDING_CANCEL` | Currently unused 28 | `REJECTED` | The order was not accepted by the engine and not processed. 29 | `EXPIRED` | The order was canceled according to the order type's rules (e.g. LIMIT FOK orders with no fill, LIMIT IOC or MARKET orders that partially fill)
or by the exchange, (e.g. orders canceled during liquidation, orders canceled during maintenance) 30 | `EXPIRED_IN_MATCH` | The order was expired by the exchange due to STP. (e.g. an order with `EXPIRE_TAKER` will match with existing orders on the book with the same account or same `tradeGroupId`) 31 | 32 | ## Order List Status (listStatusType) 33 | 34 | Status | Description 35 | -----------| -------------- 36 | `RESPONSE` | This is used when the ListStatus is responding to a failed action. (E.g. order list placement or cancellation) 37 | `EXEC_STARTED`| The order list has been placed or there is an update to the order list status. 38 | `UPDATED` | The clientOrderId of an order in the order list has been changed. 39 | `ALL_DONE` | The order list has finished executing and thus is no longer active. 40 | 41 | ## Order List Order Status (listOrderStatus) 42 | 43 | Status | Description 44 | -----------| -------------- 45 | `EXECUTING` | Either an order list has been placed or there is an update to the status of the list. 46 | `ALL_DONE`| An order list has completed execution and thus no longer active. 47 | `REJECT` | The List Status is responding to a failed action either during order placement or order canceled. 48 | 49 | ## ContingencyType 50 | 51 | * `OCO` 52 | * `OTO` 53 | 54 | 55 | 56 | ## AllocationType 57 | 58 | * `SOR` 59 | 60 | 61 | 62 | ## Order types (orderTypes, type) 63 | 64 | * `LIMIT` 65 | * `MARKET` 66 | * `STOP_LOSS` 67 | * `STOP_LOSS_LIMIT` 68 | * `TAKE_PROFIT` 69 | * `TAKE_PROFIT_LIMIT` 70 | * `LIMIT_MAKER` 71 | 72 | 73 | 74 | ## Order Response Type (newOrderRespType) 75 | 76 | * `ACK` 77 | * `RESULT` 78 | * `FULL` 79 | 80 | ## Working Floor 81 | 82 | * `EXCHANGE` 83 | * `SOR` 84 | 85 | 86 | 87 | ## Order side (side) 88 | 89 | * `BUY` 90 | * `SELL` 91 | 92 | 93 | 94 | ## Time in force (timeInForce) 95 | 96 | This sets how long an order will be active before expiration. 97 | 98 | Status | Description 99 | -----------| -------------- 100 | `GTC` | Good Til Canceled
An order will be on the book unless the order is canceled. 101 | `IOC` | Immediate Or Cancel
An order will try to fill the order as much as it can before the order expires. 102 | `FOK`| Fill or Kill
An order will expire if the full order cannot be filled upon execution. 103 | 104 | 105 | ## Rate limiters (rateLimitType) 106 | 107 | * REQUEST_WEIGHT 108 | 109 | ```json 110 | { 111 | "rateLimitType": "REQUEST_WEIGHT", 112 | "interval": "MINUTE", 113 | "intervalNum": 1, 114 | "limit": 6000 115 | } 116 | ``` 117 | 118 | * ORDERS 119 | 120 | ```json 121 | { 122 | "rateLimitType": "ORDERS", 123 | "interval": "SECOND", 124 | "intervalNum": 1, 125 | "limit": 10 126 | } 127 | ``` 128 | * RAW_REQUESTS 129 | 130 | ```json 131 | { 132 | "rateLimitType": "RAW_REQUESTS", 133 | "interval": "MINUTE", 134 | "intervalNum": 5, 135 | "limit": 61000 136 | } 137 | ``` 138 | 139 | ## Rate limit intervals (interval) 140 | 141 | * SECOND 142 | * MINUTE 143 | * DAY 144 | 145 | 146 | 147 | ## STP Modes 148 | 149 | Read [Self Trade Prevention (STP) FAQ](../faqs/stp_faq.md) to learn more. 150 | 151 | * `NONE` 152 | * `EXPIRE_MAKER` 153 | * `EXPIRE_TAKER` 154 | * `EXPIRE_BOTH` 155 | * `DECREMENT` 156 | -------------------------------------------------------------------------------- /testnet/sbe-market-data-streams.md: -------------------------------------------------------------------------------- 1 | # SBE Market Data Streams 2 | 3 | ## General Information 4 | 5 | * The base endpoint is **stream-sbe.testnet.binance.vision** or **stream-sbe.testnet.binance.vision:9443**. 6 | * To retrieve market data in JSON format, please refer to [this page](web-socket-streams.md). 7 | * SBE schema used for decoding the streams can be found [here](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/stream_1_0.xml). 8 | * All symbols in stream names are **lowercase**. 9 | * You can subscribe to a single stream at **/ws/\
| Field | 128 |Name | 129 |Description | 130 |Examples | 131 |
|---|---|---|---|
d |
134 | Trailing Delta | 135 |Appears only for trailing stop orders. | 136 |"d": 4 |
137 |
D |
140 | Trailing Time | 141 |"D": 1668680518494 |
142 | |
j |
145 | Strategy Id | 146 |Appears only if the strategyId parameter was provided upon order placement. |
147 | "j": 1 |
148 |
J |
151 | Strategy Type | 152 |Appears only if the strategyType parameter was provided upon order placement. |
153 | "J": 1000000 |
154 |
v |
157 | Prevented Match Id | 158 |Appears only for orders that expired due to STP. | 159 |"v": 3 |
160 |
A
163 | | Prevented Quantity | 164 |"A":"3.000000" |
165 | |
B |
168 | Last Prevented Quantity | 169 |"B":"3.000000" |
170 | |
u |
173 | Trade Group Id | 174 |"u":1 |
175 | |
U |
178 | Counter Order Id | 179 |"U":37 |
180 | |
Cs |
183 | Counter Symbol | 184 |"Cs": "BTCUSDT" |
185 | |
pl |
188 | Prevented Execution Quantity | 189 |"pl":"2.123456" |
190 | |
pL |
193 | Prevented Execution Price | 194 |"pL":"0.10000001" |
195 | |
pY |
198 | Prevented Execution Quote Qty | 199 |"pY":"0.21234562" |
200 | |
W |
203 | Working Time | 204 |Appears when the order is working on the book | 205 |"W": 1668683798379 |
206 |
b |
209 | Match Type | 210 |Appears for orders that have allocations | 211 |"b":"ONE_PARTY_TRADE_REPORT" |
212 |
a |
215 | Allocation ID | 216 |"a":1234 |
217 | |
k |
220 | Working Floor | 221 |Appears for orders that potentially have allocations | 222 |"k":"SOR" |
223 |
uS |
226 | UsedSor | 227 |Appears for orders that used SOR | 228 |"uS":true |
229 |
| Field | 129 |Name | 130 |Description | 131 |Examples | 132 |
|---|---|---|---|
d |
135 | Trailing Delta | 136 |Appears only for trailing stop orders. | 137 |"d": 4 |
138 |
D |
141 | Trailing Time | 142 |"D": 1668680518494 |
143 | |
j |
146 | Strategy Id | 147 |Appears only if the strategyId parameter was provided upon order placement. |
148 | "j": 1 |
149 |
J |
152 | Strategy Type | 153 |Appears only if the strategyType parameter was provided upon order placement. |
154 | "J": 1000000 |
155 |
v |
158 | Prevented Match Id | 159 |Appears only for orders that expired due to STP. | 160 |"v": 3 |
161 |
A
164 | | Prevented Quantity | 165 |"A":"3.000000" |
166 | |
B |
169 | Last Prevented Quantity | 170 |"B":"3.000000" |
171 | |
u |
174 | Trade Group Id | 175 |"u":1 |
176 | |
U |
179 | Counter Order Id | 180 |"U":37 |
181 | |
Cs |
184 | Counter Symbol | 185 |"Cs": "BTCUSDT" |
186 | |
pl |
189 | Prevented Execution Quantity | 190 |"pl":"2.123456" |
191 | |
pL |
194 | Prevented Execution Price | 195 |"pL":"0.10000001" |
196 | |
pY |
199 | Prevented Execution Quote Qty | 200 |"pY":"0.21234562" |
201 | |
W |
204 | Working Time | 205 |Appears when the order is working on the book | 206 |"W": 1668683798379 |
207 |
b |
210 | Match Type | 211 |Appears for orders that have allocations | 212 |"b":"ONE_PARTY_TRADE_REPORT" |
213 |
a |
216 | Allocation ID | 217 |"a":1234 |
218 | |
k |
221 | Working Floor | 222 |Appears for orders that potentially have allocations | 223 |"k":"SOR" |
224 |
uS |
227 | UsedSor | 228 |Appears for orders that used SOR | 229 |"uS":true |
230 |
| 字段 | 116 |名称 | 117 |描述 | 118 |示例 | 119 |
|---|---|---|---|
d |
122 | Trailing Delta | 123 |出现在追踪止损订单中。 | 124 |"d": 4 |
125 |
D |
128 | Trailing Time | 129 |"D": 1668680518494 |
130 | |
j |
133 | Strategy Id | 134 |如果在请求中添加了strategyId参数，则会出现。 |
135 | "j": 1 |
136 |
J |
139 | Strategy Type | 140 |如果在请求中添加了strategyType参数，则会出现。 |
141 | "J": 1000000 |
142 |
v |
145 | Prevented Match Id | 146 |只有在因为 STP 导致订单失效时可见。 | 147 |"v": 3 |
148 |
A
151 | | Prevented Quantity | 152 |"A":"3.000000" |
153 | |
B |
156 | Last Prevented Quantity | 157 |"B":"3.000000" |
158 | |
u |
161 | Trade Group Id | 162 |"u":1 |
163 | |
U |
166 | Counter Order Id | 167 |"U":37 |
168 | |
Cs |
171 | Counter Symbol | 172 |"Cs": "BTCUSDT" |
173 | |
pl |
176 | Prevented Execution Quantity | 177 |"pl":"2.123456" |
178 | |
pL |
181 | Prevented Execution Price | 182 |"pL":"0.10000001" |
183 | |
pY |
186 | Prevented Execution Quote Qty | 187 |"pY":"0.21234562" |
188 | |
W |
191 | Working Time | 192 |只有在订单在订单簿上时可见 | 193 |"W": 1668683798379 |
194 |
b |
197 | Match Type | 198 |只有在订单有分配时可见 | 199 |"b":"ONE_PARTY_TRADE_REPORT" |
200 |
a |
203 | Allocation ID | 204 |"a":1234 |
205 | |
k |
208 | Working Floor | 209 |只有在订单可能有分配时可见 | 210 |"k":"SOR" |
211 |
uS |
214 | UsedSor | 215 |只有在订单使用 SOR 时可见 | 216 |"uS":true |
217 |